[FFmpeg-cvslog] r29354 - trunk/libswscale/swscale-example.c
Sat Jun 13 00:31:51 CEST 2009
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
> 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.
mans at mansr.com
More information about the ffmpeg-cvslog