[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[John Cox]

On Wed, 16 Feb 2011 20:38:18 +0200 (EET), you wrote:

>On Wed, 16 Feb 2011, John Cox wrote:
>
>> >I'm not sure if any such formats exist though, I'm just trying to make 
>> >sure my knowledge of the subject is right.
>> >
>> >As far as I understand, DTS'es shouldn't be reordered? The definition I 
>> >saw is that whatever comes out from an ideal, instanteous decoder, when 
>> >fed with a packet at time DTS, should be displayed at that particular 
>> >time.
>> 
>> No.  At least not of you are using DTS in the sense it is defined in H.222.  An
>> "instantaneous decoder" is one that takes no time processing a frame.  A frame
>> may be delayed or reordered by such a decoder.  If you put a frame in at time
>> DTS you would expect it to come out at time PTS.  In the decode pipeline DTS
>> has no useful meaning after the decode stage.
>
>Yes, I think I expressed myself incorrectly, I'm not too well-versed with 
>the exact terminology.
>
>The packet that made the instantaneous decoder output the delayed frame, 
>the DTS of that frame would be equal to the PTS of the frame that was 
>output, is that right?

In many cases that will occur but with things like 3:2 pulldown (where in a
horrible oversimplification you effectively put in frames at 24Hz and get them
out at 30Hz) that will not occur as the output frames have a different rate so
pretty much by definition they won't match up.  H.264 makes the distinction
between a timing compliant decoder and an order compliant decoder.  In a timing
compliant decoder the frames turn up at the output at the right time, in an
order compliant one they merely turn up in the right order.  Most practical
implementations will be order compliant which will normally mean that you need
to add a timing (avsync) stage after the decoder to play the frames out at the
right speed.

In the case of decoders like ffmpeg where decode isn't rigorously synced to a
real-time bitstream, DTS can be used to establish the "time at the decoder". If
the stream is completely devoid of PTSs (a case that cannot occur in an H.222
stream) then it is certainly plausible to assert that the last decoded frame
that is emitted by a decoder in response to a coded frame being injected has a
PTS equal to the DTS of the injected frame.  Note however that this does NOT
apply if there are occasional PTSs in the stream and the decoded frame merely
happens to be one of the ones without a PTS.

DTS-PCR is also interesting as that allows you to establish the correct
buffering levels when playing a multicast (or other real-time stream) to avoid
future underrun.

Regards

John Cox