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

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- 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/72e26ef4/attachment.pgp>