[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

Måns Rullgård mans
Wed Feb 16 16:40:35 CET 2011


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.  The current code mangles the values from the
container in unpredictable ways.  That is wrong.

>>					       All it does is make some
>> broken guesswork part of the API.
>
> Not part of the API, part of the logic behind the API.

If an API function does something, that something is part of the API.

> If the algorithm is broken, *which you still have to prove*, it can be
> changed, but this is an different issue.

There is an "algorithm" where there should be none.  That is wrong.

>>				     On those grounds, the patch is
>> rejected.
>
> As you are not project leader nor file maintainer, you are not entitled to
> reject anything. You can only convince other people here that you are right,
> and you still need to give technical evidence for that.

I did exactly that and convinced several others.  You seem to have
trouble accepting that fact.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list