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

[Måns Rullgård]

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.

-- 
M?ns Rullg?rd
mans at mansr.com