[FFmpeg-devel] [PATCH] Use ff_thread_once() to initialize sin/cos static tables.

[wm4]

On Sun, 25 Oct 2015 07:56:49 -0400
"Ronald S. Bultje" <rsbultje at gmail.com> wrote:

> Hi,
> 
> On Sun, Oct 25, 2015 at 7:48 AM, Derek Buitenhuis <
> derek.buitenhuis at 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.