On Sun, 25 Oct 2015 07:56:49 -0400 "Ronald S. Bultje" <rsbul...@gmail.com> wrote:
> Hi, > > On Sun, Oct 25, 2015 at 7:48 AM, Derek Buitenhuis < > derek.buitenh...@gmail.com> wrote: > > > On 10/25/2015 11:44 AM, Michael Niedermayer wrote: > > >> One could argue this is not a representative sample. It's a single > > small file, > > >> which must always init (as opposed to a longer running process such as > > Chrome. > > >> Whereas if you have a longer sample, it wouldn't even be within the > > margin of > > >> error, I bet. > > > > > > If the usecase is to probe many files, then file duration would not > > > help hideing the init time. (to fill a GUI list or whatever) > > > > I reject this notion. You are completely discounting that people use > > libavcodec *as a library*, and not via CLI. > > > > > Also startup time for normal playback itself does matter, as its > > > part of user vissible responsiveness, the user clicks play in his > > > players playlist and if that isnt instantaneaously starting playback > > > the user notices. So IMO startup time is not irrelevant > > > > I agree, but neither is thread-safety. Perhaps there is a middle ground. > > > So this is likely because we init all tables instead of just these that we > need, right? So how about having one ff_once per table? That should be > trivial to implement. > > Obviously anyone using shell scripts and calls to CLI ffmpeg versions to do > probing of production-level numbers of files on production systems deserves > the results (s)he'll be getting. Having more AVOnce to reduce the load might be ok. But am I the only one who thinks it's ridiculous to reject a patch fixing thread-safety issues, because someone MIGHT probe 100s of small files on a weak ARM? I'd say correctness first, then performance. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
