[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