[FFmpeg-devel] [PATCH] Add AV_CONFIG_* for libav* libs to libavutil/avconfig.h

Måns Rullgård mans
Sat Mar 6 02:49:45 CET 2010


Michael Niedermayer <michaelni at gmx.at> writes:

> On Sat, Mar 06, 2010 at 01:37:32AM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Sat, Mar 06, 2010 at 12:07:16AM +0000, M?ns Rullg?rd wrote:
>> > [...]
>> >> The ff* apps are in a special situation in that they are considered
>> >> external to the libav* libraries, and thus must use only public the
>> >> API, while still sharing configure script and makefiles.  This is not
>> >> a problem at all in my opinion.  The config.h file we create does in
>> >> no way depend on internals of the libraries.  It is therefor not wrong
>> >> of ffmpeg.c et al to #include config.h.  If they were built separately
>> >> from the libs, there would still be a configure script creating a very
>> >> similar config.h.
>> >> 
>> >> What we should _not_ be doing is defining HAVE_AV_CONFIG_H when
>> >> compiling ffmpeg.c.  That would expose internals which we should not
>> >> be touching.
>> >
>> > indeed
>> 
>> Due to an oversight on my part we always define this symbol, even for
>> ffmpeg.c etc.  I was about to fix it, when I noticed that ffplay.c
>> includes dsputil.h, which is of course not public API at all, in order
>> to use the rdft.
>> 
>> I'm all for providing such functionality in the public API, but the
>> current definitions in dsputil.h expose much more internals than
>> belong in the public interface.  We need to have the freedom to change
>> the internals without breaking the API.
>
> yep, we should export just the rdft ...

The rdft is tightly coupled to the fft, and the interfaces to both of
them take pointers to structs which should not be exposed.  I'll try
to think of something.  Ideas welcome.

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



More information about the ffmpeg-devel mailing list