[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp
Wed Feb 16 16:50:38 CET 2011
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.
>>> 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.
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.
More information about the ffmpeg-devel