[FFmpeg-cvslog] r18681 - trunk/libavcodec/rv34.c

[Kostya]

On Mon, Apr 27, 2009 at 01:04:24AM +0200, Michael Niedermayer wrote:
> On Sun, Apr 26, 2009 at 06:43:51AM +0300, Kostya wrote:
> > On Sun, Apr 26, 2009 at 02:45:41AM +0200, Michael Niedermayer wrote:
> > > On Sat, Apr 25, 2009 at 07:47:38AM +0200, kostya wrote:
> > > > Author: kostya
> > > > Date: Sat Apr 25 07:47:38 2009
> > > > New Revision: 18681
> > > > 
> > > > Log:
> > > > Get rid of monstrous static table and initialize VLCs for RV3/4 dynamically.
> > > > 
> > > [...]
> > > 
> > > > +/**
> > > > + * Initialize all tables.
> > > > + */
> > > > +static av_cold void rv34_free_tables(void)
> > > 
> > > seems the journey to chernobyl did more harm than good
> > 
> > It's not related but looks like current environment is not very good for work.
> 
> anything that can be done to improve it?
 
Unlikely without a shotgun. 
 
> > > > +{
> > > > +    int i, j, k;
> > > > +
> > > > +    for(i = 0; i < NUM_INTRA_TABLES; i++){
> > > > +        for(j = 0; j < 2; j++){
> > > > +            free_vlc(&intra_vlcs[i].cbppattern[j]);
> > > > +            free_vlc(&intra_vlcs[i].second_pattern[j]);
> > > > +            free_vlc(&intra_vlcs[i].third_pattern[j]);
> > > > +            for(k = 0; k < 4; k++){
> > > > +                free_vlc(&intra_vlcs[i].cbp[j][k]);
> > > > +            }
> > > > +        }
> > > 
> > > anyway your code is totally utter broken now, thats besides the fact that
> > > the very same monstrous tables are still there
> > 
> > Better 180 smaller ones than single with size around 800kB.
> > 
> > > before it all worked now 2 instances of rv will cause double
> > > frees or at the least crash, you treat the static tables like they are
> > > owned by a codec instance
> > 
> > Okay, what solution can you suggest? Moving VLCs to codec context?
> 
> id suggest a revert but thats because i didnt see a solveable problem
> to begin with.

done

> I mean if the amount of bytes of tables could be reduced
> without speedloss that would be great but the place where the tables
> where didnt make them bigger or smaller, it just made it more clearly
> vissible to the human reader how large they where. With the dynamic
> alloc of "as much as needed" its just hidden from view but it will reach
> the very same amount.

Decreasing number of bits per table can save some memory but not that much
though (50-60% for tables with < 1000 elements and ~30% for bigger ones).

> And the static tables wont take real memory until the codec is initialized
> either on any modern os ...

Maybe some build system maintainer can propose a solution for disabling
such memory hogs for systems with certain restrictions?
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB