[FFmpeg-devel] [PATCH] hardcoding for pcm alaw/ulaw tables

Reimar Döffinger Reimar.Doeffinger
Sun Mar 21 19:54:21 CET 2010


On Sun, Mar 21, 2010 at 07:24:46PM +0100, Michael Niedermayer wrote:
> > +#define av_cold
> > +#define CONFIG_HARDCODED_TABLES 0
> 
> ugly

Yes, I haven't come up with a good way to avoid it yet though.
Thinks I've been thinking about:
1) adding it to tableprint.h
2) a new header file, possibly created by configure, with a few
stubs like these and also some defines like CONFIG_SMALL etc.

> > +    {
> > +        "static const uint8_t linear_to_ulaw[1 << 14]",
> > +        write_uint8_array,
> > +        linear_to_ulaw,
> > +        1 << 14,
> > +        0
> > +    },
> 
> cleaner and with half the code:
> 
> printf("static const uint8_t linear_to_ulaw[1 << 14]= {\n");
> for(i=0; i < 1<<14; i++)
>     printf("%d,", linear_to_ulaw[i]);
> printf("};\n");

Well, I can beat that easily:
{ "static const uint8_t linear_to_ulaw[1 << 14]",
  write_uint8_array, linear_to_ulaw, 1 << 14 },

I don't see the point though, and that struct-based approach has
a chance to be reused for other purposes e.g. analyzing the tables
and give a somewhat human-readable result - 16k values in a single
line certainly doesn't qualify as that.
Human-readable is useful for getting an idea how likely it is possible
to reduce the size otherwise for CONFIG_SMALL.
Lastly, I consider it more scalable - even with a huge number of generators
the maintenance effort should not grow much, with well-tested write_* functions
available for almost all cases, and if necessary those struct
definitions are easier to modify by a script than code that is likely to be
slightly different for each case.

> > +#define pcm_alaw_tableinit()
> > +#define pcm_ulaw_tableinit()
> 
> ugly

What is ugly about it and what would you prefer instead?
E.g. declaring the functions always and putting the function
body under #if?
Or doing a if (CONFIG_HARDCODED_TABLES) return;
at the start of the function?
Your one-line "ugly" comments are of no help, I'm not writing ugly
code on purpose, I either don't consider it ugly or can't think
of a better way, neither of which such a statement alone is going
to change.
However I admit that my plan was to review the whole design once there
are enough table generators there to get a feel for what works and what
doesn't, maybe now is the time to look into it (e.g. I've never liked
the size being duplicated in the declaration string, but I could not
decide on how else to do it).
Of course it's still going to be a biased selection since nobody except
me tried to use it...



More information about the ffmpeg-devel mailing list