[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp
Wed Feb 16 20:13:14 CET 2011
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.
mans at mansr.com
More information about the ffmpeg-devel