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

Reimar Döffinger Reimar.Doeffinger
Mon Nov 9 10:47:30 CET 2009


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, 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.



More information about the ffmpeg-devel mailing list