[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