[Ffmpeg-cvslog] r7238 - in trunk/libavutil: common.h internal.h
Thu Dec 7 18:39:19 CET 2006
Michael Niedermayer said:
> On Thu, Dec 07, 2006 at 12:39:20PM +0100, Reimar D?ffinger wrote:
>> On Thu, Dec 07, 2006 at 11:20:13AM -0000, M?ns Rullg?rd wrote:
>> > Reimar D?ffinger said:
>> > > So you suggest the better solution would have been to simply leave a
>> > > 99,9% (i.e. except the always_inline) bswap.h in MPlayer instead of
>> > > using the libavutil one?
>> > > And does this mean that you do not agree that not being able to export
>> > > any functions using always_inline is a bad thing?
>> > If you want to use currently not exported functionality, submit an RFE asking
>> > it to be officially exported. Symbols whose name begin with av are official
>> > nothing else is.
>> I thought the intention was all of libavutil becoming "official API"
>> in the long term.
>> But since a ff_ prefix to always_inline was already considered too much
> ive no problem with a av_always_inline or similar for a externally vissible
> one ...
> also a av_inline would be a interresting option which would be shorter and
> with which i would be perfectly fine even inside libav*
Fine, I'll create a prefixed macro instead.
I grepped the entire ffmpeg source, and the only uses of always_inline (and the
other moved macros) were in our code, none in API headers. For this reason I
deemed it safe to move the macros to another place where they would not be
visible to the outside, but still work exactly as before when building ffmpeg.
I (or any other ffmpeg dev) can't reasonably be expected to keep track of which
third-party apps abuse lav* internal symbols. We broke VLC once by removing
something they were illicitly using. They happily fixed their code without
making a fuss. IMHO, MPlayer should not be receiving special treatment from
this point of view, even if some ffmpeg devs also work on mplayer.
BTW, common.h has *no* listed maintainer. I also thought the policy was that
trivial changes didn't need approval, and I honestly think this qualifies as
trivial. Nobody would have objected, had it not been for mplayer being naughty
and assuming things it shouldn't.
>> I wonder if suggesting FFBE_32 and av_bswap_32 everywhere has much of a
> i definitly want these to be available to the outside of libav so if we dont
Then we must rename them.
> find another solution then iam fine with these but it really would be nicer
> if a user app could use BE_32 instead of FFBE_32
> maybe some
> #ifdef AV_NO_PREFIXES
> #define BE_32 FFBE_32
> in libavutil or similar could be used?
That would open a whole new can of worms. We already know that Solaris
system headers #define BE_16 and friends. It is a very generic name, so
we have no business imposing it on the world.
We have an established convention of using an av prefix for the external API
and ff_ prefix for internal symbols that need extern linkage. Let's keep it
mru at inprovide.com
More information about the ffmpeg-cvslog