[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp
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)
>>> ./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
>> 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.
mans at mansr.com
More information about the ffmpeg-devel