[FFmpeg-devel] [Patch] Fix for static leaks in h264.c

Art Clarke aclarke
Wed Jun 25 15:43:58 CEST 2008


On Wed, Jun 25, 2008 at 9:25 AM, Michael Niedermayer <michaelni at gmx.at>
wrote:

> > +// Overallocate each table to the largest table; this wastes
> > +// a few bytes on the stack at startup, but leads to simpler
> > +// code
> >  static VLC coeff_token_vlc[4];
> > +static VLC_TYPE coeff_token_vlc_tables[4][520][2];
> > +static const int coeff_token_vlc_tables_size[4] = { 520, 332, 280, 256
> };
>
> coeff_token_vlc_tables[520+332+280+256][2];
> would avoid the overalloc
>
> Yup, I thought of that before I submitted the patch (hence highlighting it
with a comment), but then I have to do math to compute the offsets for each
"table" packed in the array at line 1988.

As it stands in the current patch, I just need to pass:

coeff_token_vlc_tables[i]

to INIT_VLC_STATIC_WITH_TABLES on each trip through the loop -- no messy
computing of offsets.

By packing more tightly, I'm going to need to compute the offset of each
coeff_token_vlc table in the larger packed array, which means I need the
offsets of all prior 'tables' in the loop.

It's a trade-off between code-complexity and stack space.  I don't know
which the ffmpeg team values more (I suspect the stack space), but I figured
I'd point that out and ask for your direction.

Assuming I'm right in my analysis (always a dicey assumption) let me know
which you'd prefer of the following two choices:

Choice A: Simpler code but waste some stack space.
Choice B: More complex code but be as efficient as possible with stack
space.

I'll adjust the patch accordingly if you choose Choice B.

- Art




More information about the ffmpeg-devel mailing list