[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Jean-Daniel Dupas]

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.
> 
>>> 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. 
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.

-- Jean-Daniel