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

[Michael Niedermayer]

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 ?

Iam not sure i understand what comment you want?
We can make the table public, or leave it non public and we can
do so from libavcodec or libavutil but providing optimzed code
for reversing a byte/int/whatever small thing requires static inline code
in a header that requires the asm/cpu stuff to be available that is the
specific part of config.h has to be in a installed header

If you meant something else, please elaborate

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/884467eb/attachment.pgp>