[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