[FFmpeg-soc] [soc]: r2530 - aac/aac.c

[Michael Niedermayer]

On Sun, Jun 22, 2008 at 01:10:15PM +0100, Robert Swain wrote:
> 2008/6/22 Michael Niedermayer <michaelni at gmx.at>:
> > On Sun, Jun 22, 2008 at 12:30:32PM +0200, superdump wrote:
> >> Author: superdump
> >> Date: Sun Jun 22 12:30:31 2008
> >> New Revision: 2530
> >>
> >> Log:
> >> Migrate to new static VLC table initialisation
> >>
> >>
> >> Modified:
> >>    aac/aac.c
> >>
> >> Modified: aac/aac.c
> >> ==============================================================================
> >> --- aac/aac.c (original)
> >> +++ aac/aac.c Sun Jun 22 12:30:31 2008
> >> @@ -801,6 +801,62 @@ static int aac_decode_init(AVCodecContex
> >>      avccontext->sample_rate = ac->m4ac.sample_rate;
> >>      avccontext->frame_size  = 1024;
> >>
> >> +    if(!books[0].table)
> >> +        INIT_VLC_STATIC(&books[0], 6, tmp[0].s/sizeof(tmp[0].a_code[0]),
> >> +            tmp[0].a_bits, sizeof(tmp[0].a_bits[0]), sizeof(tmp[0].a_bits[0]),
> >> +            tmp[0].a_code, sizeof(tmp[0].a_code[0]), sizeof(tmp[0].a_code[0]),
> >> +            144);
> >
> > what are the if() good for?
> 
> To check for existence of the tables? I see there is code within
> init_vlc() checking the table size against the allocated size. Would
> one check ( if(!books[0].table) ) encompassing all the
> INIT_VLC_STATIC() calls be OK?

I dont think any check is needed


> 
> I wanted to keep this in the loop but as the macro declares a static
> variable, within a loop the variable is local to that code block which
> breaks the table generation even if the static_size doesn't change.
> 

> Also, is there a good way of dealing with situation like this where
> the static_size differs for each books[i]? The static_size argument
> must be a constant at compile time so I thought of hacking up a macro
> but when I discovered the aforementioned static var issue with loops I
> gave up and just unrolled the calls.

well
you can seperate the static arrays unroll them have a array of their
sizes and use init_vlc() I do not know if this would be clean/smaller
or worse ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080622/9a5260bb/attachment.pgp>