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

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> 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.
>
> Can't really happen since this is an array,

I am obviously suggesting we should NOT be using the array as the
primary interface, only as fallback when a bitrev instruction isn't
available.

> the worst that can happen is
> that we will have to waste 256 bytes for backwards-compatibility on
> these systems.
> You can still switch libavcodec to use an internal ff_reverse function
> that may or may not need/use the array.
> Actually, why not add a ff_log2 function that either is defined as
> av_log2 or uses assembler optimizations?
> Means external users can still use the ok but potentially slower av_log2
> while libavcodec can make full use of asm.

Wasn't that already rejected?

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