[FFmpeg-user] Video with copyright

Nicolas George george at nsup.org
Wed Jun 4 20:07:23 CEST 2014


Le sextidi 16 prairial, an CCXXII, Carl Eugen Hoyos a écrit :
> Because you added an option that said "please 
> corrupt my audio stream."
> (Of course I may be wrong but if the parameter 
> seems unneeded, I don't think my interpretation 
> is less likely than yours.)

Please correct me if I am wrong: if you have a valid uncorrupted
non-braindead file, then the timestamps will match the sample count exactly;
in that case, -async 42 should not change anything, for whatever value of
42. Right?

If -async 1000 corrupts the audio stream, that means that either the
timestamps were wrong to start with, or there is a bug in the code
implementing the -async option.

I suspect we could do with a dump of the timestamps and lengths of frames
and packets. Something like this:

ffprobe -select_streams a -of compact \
  -show_entries frame=pkt_pts,pkt_duration,nb_samples \
  -show_entries packet=pts,dts,duration \
  -show_streams file

Just an excerpt, of course, as it will be huge: the beginning, and the place
around the first DTS errors reported by ffmpeg, and the very end with the
streams, otherwise we can not know the time base used.

You (Massimo) can probably run the tests yourself, more efficiently because
you can try different things immediately without waiting a reply on the
mailing-list: pipe that to your favourite scripting language, and make the
computations, compare the time given by the sum of the packets' durations
with the time given by the PTS and with the time given by the sum of the
frames' sample count, and find out what is wrong, if anything.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-user/attachments/20140604/b15e2652/attachment.asc>


More information about the ffmpeg-user mailing list