[FFmpeg-devel] [PATCH] Add AV_CONFIG_* for libav* libs to libavutil/avconfig.h
Sat Mar 6 02:38:03 CET 2010
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 ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel