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