[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Måns Rullgård]

Martin Storsj? <martin at martin.st> writes:

> On Wed, 16 Feb 2011, M?ns Rullg?rd wrote:
>
>> Martin Storsj? <martin at martin.st> writes:
>> 
>> > On Wed, 16 Feb 2011, M?ns Rullg?rd wrote:
>> >
>> >> A VFR stream obviously needs timestamps.  I'm not aware of any
>> >> VFR-capable container providing only DTS.  In fact, I'm not aware of
>> >> _any_ container providing only DTS.  Even if such a container did exist,
>> >> DTS is not PTS.  PTS can, of course be derived from DTS, decoder delay,
>> >> and frame reordering, but that is not what any code in ffmpeg does, at
>> >> least not correctly.
>> >
>> > 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.
>> 
>> I suggest to anyone who wants to understand timestamps to get a copy of
>> the MPEG2 systems spec (ITU-T H.222.0, free download).  It explains how
>> it all works in great detail.
>
> Downloaded a copy, thanks for the tip. I'll browse it later.

Annex D has a good explanation of the timing model.

>> > The new AVFrame.pkt_dts should track this right, as far as I know. As in, 
>> > it isn't reordered along with the PTS, but it is set to the DTS of the 
>> > AVPacket that triggered this frame to be emitted.
>> 
>> pkt_dts is apparently set to the DTS of the AVPacket passed to
>> avcodec_decode_video2(), making it rather pointless.
>
> Earlier it would probably be kinda pointless, yes. For -mt, however, it 
> would be useful if you previously used AVPacket.dts directly, AFAIK.

Apart from the fact that DTS is uninteresting after decoding.

-- 
M?ns Rullg?rd
mans at mansr.com