[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Måns Rullgård]

Nicolas George <nicolas.george at normalesup.org> writes:

> L'octidi 28 pluvi?se, an CCXIX, M?ns Rullg?rd a ?crit?:
>> How did you obtain those timestamps?
>
> The transcode line I pasted plus ffprobe, plus awk to keep only the
> timestamps in the output of ffprobe.

So you're looking at lavf-mangled values.  You need to look at the raw
values from the file itself.  You cannot use any ffmpeg-based tools to
do that.  Use a hex viewer if you have nothing better.

>>					Whatever the answer, they are
>> different from the original.  They should not be.
>
> The original declares time_base = 1/1000 and frame_rate = 24000/1001.
>
> The transcoded declares time_base = 1/24000, and same frame_rate.
>
> The timestamps in the input are rounded to the insufficient accuracy of its
> time base.
>
> The timestamps in the output are perfect.
>
>> Good would be equal.  These are not equal, and therefore not good.
>
> This is not merely good, this is better: it does not dumbly copies the
> timestamps, it unrounds them and restores them to their perfect accuracy.
> This is not good, this is better.

If the specified time base and frame rate are at odds, how do you know
which is more accurate?  Perhaps the time base and timestamps are
correct and the frame rate has a rounding error.

>> There is an "algorithm" where there should be none.
>
> How do you select which one, among the PTS and the DTS from the container,
> should be used?

If the container does not supply a PTS, one must be derived in a
well-defined manner.  Taking DTS and calling it PTS is always wrong.

>> I did exactly that and convinced several others.
>
> Then why are they still discussing the question with me?

I suppose they, like myself, are engaged in a desperate, but most likely
futile, attempt to educate you about timestamps and proper engineering
practices.

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