On Sun, Oct 25, 2015 at 11:48:12AM +0000, Derek Buitenhuis 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.
the problem that causes the slowdown should be due to initializing all table sizes when only 1 or a few small ones are needed making the init more fine grained (as it was) should solve this that could be done with a single mutex (not of once type) and initializing only the needed table when its not already inited or with a once mutex for each table size there are certainly also other options [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
