[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Alexander Strange]

On Feb 17, 2011, at 3:48 PM, Nicolas George wrote:

> Le nonidi 29 pluvi?se, an CCXIX, Luca Barbato a ?crit :
>> I don't see why. Cramming half demuxer in libavcodec doesn't sound
>> correct.
> 
> That is the other way around: determining the PTS when there is none
> requires cramming a significant part of a decoder (the parser) in the
> parser.
> 
> Do you agree with the following principle:
> 
> A demuxer that decodes perfectly the information in its supported format but
> does not examine the payload data at all should be acceptable.
> 
> ?
> 
>> The main flaw is assuming that libavcodec, with the data it has, can do
>> something reliable.
> 
> Why should lavf be able to do it then? lavc has more information than lavf,
> since it has all information extracted by lavf plus everything in the
> payload.
> 
>> I understood your point of view but please understand that gst, vlc,
>> tcvp and even mplayer might rather have lavc not do this kind of work.
> 
> I did not manage to find where mplayer finds the timestamp. As for VLC, at a
> first glance, it uses obsoletes API to do mostly the same thing as
> guess_correct_pts, with its own load of special cases and heuristics.

mplayer has two modes, nocorrect-pts and correct-pts. Both of them work at the demuxer layer, but are complicated, and neither work right.

The first one behaves effectively like ffplay with decoder_reorder_pts == 0, though I'm not sure what data it uses.
The second one buffers demuxed pts values, and then I think it sorts them in order and dequeues them based on the current decoder delay (has_b_frames) afterwards.

It doesn't work with several file formats so it falls back to nocorrect.

In general I'd expect other clients to act like ffmpeg.c, which was wrong and frequently had times 1-2 frames off sync before I fixed it.