[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Jean-Daniel Dupas]

Le 16 f?vr. 2011 ? 17:13, M?ns Rullg?rd a ?crit :

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


Even with accurate timestamp, you have to handle the case where only dts is provided, only pts is provided, bot are provided, neither are provided.
But I clearly understand that you decided that all clients writing the same code again and again and again it  the right solution, and you don't want to talk about any solution that may improve this situation.

-- Jean-Daniel