[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

Måns Rullgård mans
Wed Feb 16 17:13:30 CET 2011

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

More information about the ffmpeg-devel mailing list