[FFmpeg-cvslog] r29354 - trunk/libswscale/swscale-example.c

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Fri, Jun 12, 2009 at 09:36:11AM +0100, M?ns Rullg?rd wrote:
>> Diego Biurrun <diego at biurrun.de> writes:
>> 
>> > On Fri, Jun 12, 2009 at 02:06:41AM +0100, M?ns Rullg?rd wrote:
>> >> 
>> >> For the record, the stuff in libavutil/internal.h is intended to be
>> >> used everywhere in FFmpeg.  All that used to be scattered about
>> >> common.h under separate #ifdef HAVE_AV_CONFIG_H.  We moved it to a
>> >> separate file to clean things up a bit.
>> >
>> > Didn't I just hear Michael say the opposite?
>> 
>> He's wrong then.  Just look at the file.  Some of it is *only* used in
>> lavc even.  The name "internal" means internal to FFmpeg, not to lavu.
>
> theres still the issue of some functions in internal.h using
> internal tables of libavutil like ff_inverse this creates
> dependancies between any part of ffmpeg and libavutils internal
> stuff
> Of course this issue is not new and as you say some of it is only used
> outside lavu but its still an issue.
>
> I mean that someone who wants to change the sqrt algorithm sees the code
> is in internal.h and has a ff_ prefix also meaning internal and so goes
> ahead and changes it while beliving there wont be an ABI/API issue
> month later some distro maintainer tries to hire a hitman to take us out
> for the resulting mess ...

What do you suggest then?  I can only think of worse options:

1. Duplicate all those functions/macros in each of libav*.
2. Make them public, and remove all asm optimisations.

In the past I have suggested moving the parts only used by lavc back
there, but you didn't like that either.  Some macros did get moved,
but some still remain.

-- 
M?ns Rullg?rd
mans at mansr.com