[FFmpeg-devel] [PATCH] hardcoded ff_cos tables

Reimar Döffinger Reimar.Doeffinger
Wed Oct 14 23:23:00 CEST 2009

On Wed, Oct 14, 2009 at 10:09:44PM +0100, M?ns Rullg?rd wrote:
> >> >> Which is a completely unrelated, already existing mess.
> >> >> And no, I can't see a reason to use those tables from C code, that's
> >> 
> >> Same reason as using it from asm...
> >> 
> >> >> what ff_cos_tab is there for (and it _might_ even make sense to use it
> >> >> from asm code).
> >> 
> >> That would be slower.
> >
> > I'm unconvinced you'd get any consistent results unless you used asm.
> We were talking about asm.

Well, when you use them via MANGLE in asm there is no point in having a
Unless you only were referring to my "might" part - there I only meant e.g.
if there are enough registers available going through ff_cos_tab might be
a non-issue and look nicer.

> >> > This patch should demonstrate it is an independent issue, it needs no
> >> > extra header file and eliminates a good bit of code duplication.
> >> 
> >> I fail to see how this patch demonstrates anything related to that
> >> issue.  There are still external symbols with no declaration in a
> >> header file.  On the contrary, you now have symbols referenced in
> >> multiple places with no common declaration.  This is *always* a bad
> >> thing.
> >
> > Huh? The symbols are not referenced in any more places than before.
> Of course they are.  They are now in the new file as well as
> everywhere they are without the patch.

Well, I didn't consider the definition as "referencing".
I'm still thinking what would be a not completely-ugly way of handling
this, and in particular if we really want even more of this stuff in dsputil.h
I'll probably make something up based on the COSTAB macro I used in the
latest patch, I just don't really like having that kind of macro in dsputil.

More information about the ffmpeg-devel mailing list