On Tue, Feb 06, 2018 at 08:58:01AM +0000, Gaullier Nicolas wrote: > >> The number of extra retries to get more than a single duration is > >> currently limited to 1 (see commit 77a0df4b5). > >> This patch raises this number of retries to 4 (amongst the overall 6 max > >> retries). > >> In my experience, the need for 2 extra retries is something commonplace. > >> 3 extra retries is not far away and we have an exemple on ffmpeg.org : > >> http://samples.ffmpeg.org/archive/extension/ts/mpegts+mpeg2video+ac3++ > >> mpegts_multiple_ts_packets_pmt_pid_0x50.ts > > >This would make the code read much more of the file if it cannotz figure out > >the duration of every stream. > >In which use case are the individual stream durations needed ? > > > >btw, while 4 retries might sound low, each reads twice as much data than the > >previous IIRC > > The use case is probing, and especially quickly determining the exact number > of video frames (guessing ptses are correct), but indeed, it is useless for a > regular ffmpeg transcoding command.
> Maybe a better option would be to change the "#define DURATION_MAX_READ_SIZE" > by an overridable command line option ? > Then, when using for example ffprobe, I could raise the max readsize to 4Mo > to cover my worst case scenario without affecting the default behaviour. yes, something like that would make sense i guess, question though is also how bad the extra read is in practice. Maybe it affects few files or it can be made to not read alot in almost all files that would require some testing thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
