[Ffmpeg-cvslog] r7238 - in trunk/libavutil: common.h internal.h

Michael Niedermayer michaelni
Thu Dec 7 18:18:00 CET 2006


Hi

On Thu, Dec 07, 2006 at 12:39:20PM +0100, Reimar D?ffinger wrote:
> Hello,
> 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 for
> > it to be officially exported.  Symbols whose name begin with av are official API,
> > 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*


> I wonder if suggesting FFBE_32 and av_bswap_32 everywhere has much of a
> chance.

i definitly want these to be available to the outside of libav so if we dont
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
...
#endif
in libavutil or similar could be used?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali




More information about the ffmpeg-cvslog mailing list