[FFmpeg-devel] [PATCH] Move ff_reverse to libavutil

[Michael Niedermayer]

On Mon, Nov 09, 2009 at 02:25:30PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Mon, Nov 09, 2009 at 12:30:35PM +0000, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > On Mon, Nov 09, 2009 at 02:07:44AM +0000, M?ns Rullg?rd wrote:
> >> >> M?ns Rullg?rd <mans at mansr.com> writes:
> >> >> 
> >> >> > Michael Niedermayer <michaelni at gmx.at> writes:
> >> >> >
> >> >> >> On Sat, Nov 07, 2009 at 09:44:21PM +0100, Reimar D?ffinger wrote:
> >> >> >>> On Sat, Nov 07, 2009 at 09:21:56PM +0100, Michael Niedermayer wrote:
> >> >> >>> > On Sat, Nov 07, 2009 at 08:48:49PM +0100, Reimar D?ffinger wrote:
> >> >> >>> > > Sorry if this is a bit confusing, this is basically carried over
> >> >> >>> > > from a MPlayer discussion I think.
> >> >> >>> > > The main question I'd say is whether ff_reverse should be moved to
> >> >> >>> > > libavutil and independently from that whether it should be made part
> >> >> >>> > > of the public API as av_reverse.
> >> >> >>> > 
> >> >> >>> > what advantage is there in moving it into libavutil?
> >> >> >>> 
> >> >> >>> That MPlayer makes no effort to compiler without libavutil while
> >> >> >>> it was once supposed to work without libavcodec.
> >> >> >>> Not that I consider that really relevant, I suggested libavutil
> >> >> >>> without really thinking about it.
> >> >> >>
> >> >> >> Well, i dont mind moving it into lavutil if you think thats a good
> >> >> >> idea
> >> >> >>
> >> >> >>> 
> >> >> >>> > about making it public, if some projects wants to use it iam fine with
> >> >> >>> > that of course.
> >> >> >>> 
> >> >> >>> So renaming ff_reverse to av_reverse and put extern declaration in
> >> >> >>> avcodec.h? Or some other header?
> >> >> >>
> >> >> >> yes
> >> >> >
> >> >> > Many CPUs have bit reversal instructions.  We should probably use
> >> >> > those where possible if this is at all speed-critical.
> >> >> 
> >> >> Any comment on this?  I don't want another av_log() situation.
> >> >
> >> > av_log ?
> >> 
> >> We have a function that ought to be optimised with inline asm (it
> >> gives several % speedup), but we can't because it's in a public
> >> header.
> >
> > we can optimize it if we put the part of config.h that specifies 
> > the architecture in a installed header
> 
> This is not an option.  We've had this discussion before.  Summary:
> config.h depends on the compiler used to build FFmpeg.  Users of the
> installed headers might be using a different one.

the architecture does not depend on the compiler used
the user can specify his compilers asm ability per #define, if the user
doesnt then the generic C code can be used

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091109/1f2432b4/attachment.pgp>