[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:
>
>> 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.

> 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
not true.

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