[FFmpeg-devel] [PATCH] support for hardcoded mpegaudiodec tables

Michael Niedermayer michaelni
Wed Oct 21 21:44:54 CEST 2009


On Wed, Oct 21, 2009 at 08:34:07PM +0200, Reimar D?ffinger wrote:
> On Wed, Oct 21, 2009 at 07:44:57PM +0200, Michael Niedermayer wrote:
> > On Wed, Oct 21, 2009 at 05:50:03PM +0200, Reimar D?ffinger wrote:
> > > what is an acceptable way to avoid that to you?
> > 
> > > Putting that duplicated part into a header?
> > > Or a separate .c file?
> > 
> > yes both are possible, either way it should be done for all (non small)
> > hardcoded tables and the files should have consistent names like
> > mpegaudiodec_tblgen.c or so
> > all these files should be listed at Makefile level and Makefile
> > magic should then either link them into libav* or link them to a
> > table printer, print the tables, compile them and link them
> > ... or something like that ...
> 
> Sorry, but I just can't parse it. In addition, it makes no sense to me,

its some approximate draft not a fully thought through suggestion


> if it's supposed to be switched by linking using a .h file is not possible.

> Furthermore if those tables are supposed to be compiled and linked separately
> that means it will be impossible to hardcode static tables, and it also
> means that renaming them to ff_ is a must to hardcode them.

one could use
init_mp3_table_foo(uint32_t *table)
and pass a static table as argument ...


> Also "either link them into libav* or link them to a table printer" is not
> possible either since those two may be compiled for different architectures,

It should be possible to have some
mpegaudiodec_tblgen.c -> mpegaudiodec_tblgen.o      (target arch)
mpegaudiodec_tblgen.c -> mpegaudiodec_tblgen_host.o (host arch)
or something like that ...
but ive no objection to .h files instead if you prefer ...


> and worse we can not use config.h for the host-compiled stuff.
> I attached a maybe better patch, but I'll surely be flamed for that as
> well because it breaks "make checkheaders" but I don't see a way to avoid
> that.

To be honest, i would prefer a more generic solution, not one where every
2nd line in every file depends on a specific array name.

if we take the header with the table generator in it as you suggest but
instead of doing
array[i]= v;
do
SET(array, i, v);

then in the hardcoded table generator SET could be a printf() while in
mpegaudiodec.c it could be array[i]= v;

in addition to that a
PRINT_HARDCODED_REFIX("static const blah[123]={");
could be in the header 

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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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-devel/attachments/20091021/87dd40f5/attachment.pgp>



More information about the ffmpeg-devel mailing list