[FFmpeg-devel] [PATCH] lavc/aacenc_quantization: use cbrt table
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Sat Mar 12 18:35:31 CET 2016
On Sat, Mar 12, 2016 at 12:09:13PM -0500, Ganesh Ajjanagadde wrote:
> And yes, for me the proof of the pudding is in the eating. In other
> words, if you or someone else sends a small, simple patch achieving
> the above one-line change, I will be very happy and will learn
> something.
Does that mean you did not see my patch, you did not consider
it because it was not quite finished, or because it was still
too complicated?
> 3. Why do we even need all this hardcoded table chicanery? No one has
> presented a use case where they make a serious difference, with
> benches to support when I called for it wrt cbrt_tab and aac. Of
> course it will be faster in many cases (e.g mpegaudio_tablegen still
> takes 1M cycles down from 10M before), but by how much is really the
> question. Ronald gave one related to numerous small files, but even
> that was a stretch as one can batch process them together.
The point is to avoid each table using up memory if you run hundreds
of instances, reduce the attack surface for security issues by having
more data in .rodata, and for platforms supporting it allow the
tables to be stored and used directly from ROM, and even on normal
platforms all them being swapped out to the binary instead of a swap
file.
That should mostly be useful for special platforms.
But for some codecs the biggest: It makes things actually properly
thread-safe instead of the hacks and luck we in some cases rely on
to make initializing those table thread-safe/reliable.
It is part of a plan B in case we ever need truly, 100% reliable
thread safety without placing a significant number of functions under
locks.
More information about the ffmpeg-devel
mailing list