[FFmpeg-devel] avformat/utils : estimate_timings_from_pts - increase retrys
michael at niedermayer.cc
Wed Feb 7 01:21:52 EET 2018
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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the ffmpeg-devel