On Sat, 30 Aug 2014 18:41:52 +0200
Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 30.08.2014, at 18:29, Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> > On Sat, Aug 30, 2014 at 06:20:56PM +0200, wm4 wrote:
> >> On Sat, 30 Aug 2014 18:18:41 +0200
> >> Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> >>
> >>> Moves it from .data to .bss, slightly reducing binary size.
> >>>
> >>> Signed-off-by: Reimar Döffinger <reimar.doeffin...@gmx.de>
> >>> ---
> >>> libavcodec/cabac.c | 26 ++++----------------------
> >>> 1 file changed, 4 insertions(+), 22 deletions(-)
> >>>
> >>> diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
> >>> index 65579d8..803c81c 100644
> >>> --- a/libavcodec/cabac.c
> >>> +++ b/libavcodec/cabac.c
> >>> @@ -32,28 +32,7 @@
> >>> #include "cabac.h"
> >>> #include "cabac_functions.h"
> >>>
> >>> -uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
> >>> - 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
> >>> - 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
> >>> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> >>> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> >>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> >>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> >>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> >>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> >>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> >>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> >>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> >>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> -};
> >>> +uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
> >>>
> >>> static const uint8_t lps_range[64][4]= {
> >>> {128,176,208,240}, {128,167,197,227}, {128,158,187,216},
> >>> {123,150,178,205},
> >>> @@ -143,6 +122,9 @@ void ff_init_cabac_states(void)
> >>> if (initialized)
> >>> return;
> >>>
> >>> + for (i = 0; i < 512; i++)
> >>> + ff_h264_norm_shift[i] = i ? 8 - av_log2(i) : 9;
> >>> +
> >>> for(i=0; i<64; i++){
> >>> for(j=0; j<4; j++){ //FIXME check if this is worth the 1 shift we
> >>> save
> >>> ff_h264_lps_range[j*2*64+2*i+0]=
> >>
> >> Doesn't this make library safety issues worse, instead of improving it?
> >
> > Why would it make anything even a slightest bit worse than it is now?
> > Also, it makes it easier to make this hardcoded, which I think solves
> > your concern?
>
> Just to be clear since it's not obvious: the lines just below what I added
> initialise the second half of the array.
> I just added that the first half is initialised in the same place.
I have no strong feelings about it, but adding even more global mutable
state feels wrong. Yes, I know there are many places like this etc.,
so your patch is pretty innocent, but still I wonder why you'd optimize
for binary size, in exchange for higher RAM usage. What is your
motivation for doing this?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
