[FFmpeg-devel] Remaining problems in H.264 handling

[Ivan Schreter]

Uoti Urpala wrote:
> On Sat, 2009-03-28 at 23:27 +0100, Ivan Schreter wrote:
>   
>> Carl Eugen Hoyos wrote:
>>     
>>> Thank you for resending.
>>> Unfortunately, the patch fixes no samples with MPlayer.
>>>
>>>   
>>>       
>> Sorry to hear that. I tested the second sample with my patch and it 
>> detected correct frame rate. So it must be something different, what is 
>> going wrong in mplayer and must be analyzed by mplayer developers.
>>     
>
> MPlayer does not care about frame rate, it's perfectly fine if no two
> intervals between frames in the video are the same and there is no sane
> way to even define a "frame rate". What it cares about is packet
> timestamps (the pts timestamp to be precise). And if there are two input
> packets with set timestamps (not NOPTS_VALUE) for every output frame
> from the decoder then things won't work well because the current code
> does not know what input timestamp to associate with what decoder
> output.
>
> To produce output that works with current MPlayer code libavformat would
> need to either combine the packets so that one input packet corresponds
> to one decoder output, or leave out "extra" timestamps that will not
> correspond to anything output by the libavcodec decoder and use
> AV_NOPTS_VALUE instead. Alternatively MPlayer can be changed to use a
> different timing mode for such streams that have lots of timed packets
> that do not correspond to video frames.
>   
Combining packets of one frame was also my first idea for solving the 
problem of field-based videos. However, this solution is not correct. 
There are also formats, which code more than one frame in one packet. So 
it won't work.

However, to address your particular problem, consider the following:

1) before calling avcodec_decode_video(), set reordered_opaque in codec 
context to the PTS of the packet you want to decode.
2) after avcodec_decode_video() returns a frame, you can read PTS of 
this frame in frame's reordered_opaque member.

Thus, you'll always have the correct PTS and don't need to care about 
number of packets per frame. Additional benefit is that you have exact 
PTS, even if the packtets are reordered (e.g., in MPEG streams) and you 
don't need to care about PTS reordering yourself - lavf does it for you.

I suppose this will fix your problem then...

To support the opposite case (more than one frame in one packet), some 
more logic is necessary (e.g., first calling avcodec_decode_video() 
without a packet and only if nothing is returned, feed it packets until 
something will be returned). Also, I suppose it won't be possible to get 
PTS of the second frame of the packet directly by ffmpeg means, i.e., 
reordered_opaque will be either not filled or set to the same value as 
last frame, but I have no experience there - never tested such a stream.

Regards,

Ivan