[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Måns Rullgård]

Jean-Daniel Dupas <devlists at shadowlab.org> writes:

> Le 16 f?vr. 2011 ? 16:40, M?ns Rullg?rd a ?crit :
>
>> Nicolas George <nicolas.george at normalesup.org> writes:
>> 
>>> L'octidi 28 pluvi?se, an CCXIX, Luca Barbato a ?crit :
>>>> Transcoding results in a foo.mp4 with the correct timing? (shouldn't)
>>> 
>>> With:
>>> 
>>> ./ffmpeg -i hellsing-h264-blocking.mkv t.mp4
>>> 
>>> I get:
>>> 
>>> pts_time=0.000000  dts_time=0.000000	(time_base = 1/24000)
>>> pts_time=0.041708  dts_time=0.041708
>>> pts_time=0.083417  dts_time=0.083417
>>> pts_time=0.125125  dts_time=0.125125
>>> pts_time=0.166833  dts_time=0.166833
>>> pts_time=0.208542  dts_time=0.208542
>>> pts_time=0.250250  dts_time=0.250250
>>> pts_time=0.291958  dts_time=0.291958
>>> pts_time=0.333667  dts_time=0.333667
>>> pts_time=0.375375  dts_time=0.375375
>>> 
>>> while the original had:
>>> 
>>> pts_time=0.000000  dts_time=0.000000	(time_base = 1/1000)
>>> pts_time=0.042000  dts_time=N/A
>>> pts_time=0.084000  dts_time=0.084000
>>> pts_time=0.125000  dts_time=0.125000
>>> pts_time=0.167000  dts_time=0.167000
>>> pts_time=0.209000  dts_time=0.042000
>>> pts_time=0.251000  dts_time=0.209000
>>> pts_time=0.292000  dts_time=0.251000
>>> pts_time=0.334000  dts_time=0.334000
>>> pts_time=0.376000  dts_time=0.292000
>>> 
>>> I think these timestamps are completely valid.
>> 
>> How did you obtain those timestamps?  Whatever the answer, they are
>> different from the original.  They should not be.

Altering the time base is an error too.

>>>> I think we are hitting two different orthogonal issues here...
>>> 
>>> I think so too.
>>> 
>>> M?ns Rullg?rd:
>>>> With the same bad inputs as trigger the error you see in copy mode.
>>> 
>>> And with the same bad inputs, it manages to produce good output.
>> 
>> Good would be equal.  These are not equal, and therefore not good.
>> 
>>>> The topic of the thread is timestamps.  Your patch does not fix any
>>>> existing problem in the timestamp handling.
>>> 
>>> This is not the purpose of my patch. The purpose of my patch is to
>>> introduce, as part of the API, a single, preferred timestamp for the decoded
>>> frames.
>> 
>> The timestamp of a decoded frame is _exactly_ what the container says it
>> is, nothing else.
>
> This is exactly the problem. Not all containers can provide a timestamp. 

MKV does provide PTS for every frame, yet the conversion above changed
them.  If that is not an error, I don't know what is.

> Some containers provide only pts. Some others only dts. They are a lot
> of cases to handle, and actually each client must rewrite this
> handling.  If I understand correctly, the proposed changed it to add a
> timestamp that is always valid.  Its purpose is not to replace the raw
> values, but to handle all subtleties of timestamp interpretations.

There are no subtleties.  Correct timestamp handling is trivial if one
assumes the container-provided ones are correct by default.  Assuming
they are wrong and applying shady fixups is bound to cause problems, and
that is precisely what ffmpeg is currently doing.

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