[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Nicolas George]

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.

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

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

>					       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 the algorithm is broken, *which you still have to prove*, it can be
changed, but this is an different issue.

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

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110216/169ea91b/attachment.pgp>