Hi, On Sun, Oct 25, 2015 at 9:39 AM, wm4 <nfx...@googlemail.com> wrote:
> 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. The result is not incorrect, not on any real platform. Show me any real platform where an actual bug occurs. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
