[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp
Wed Feb 16 19:48:06 CET 2011
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
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.
> 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.
pkt_pts is, contrary to the doxygen comment, the PTS of the coded frame
corresponding to the output frame.
> So given this, I could either use AVFrame.pkt_pts, if set, or
> AVFrame.pkt_dts if that exists instead, and if that doesn't exist either,
> I'd have to revert to calculating it from the frame rate.
This works under the assumption that the decoded picture buffer has a
constant size. If this is not true for some codec, using input DTS as
output PTS will not work. VP8 is an example of a codec where this is
mans at mansr.com
More information about the ffmpeg-devel