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

Måns Rullgård mans
Mon Nov 9 15:25:30 CET 2009


Michael Niedermayer <michaelni at gmx.at> writes:

> 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

This is not an option.  We've had this discussion before.  Summary:
config.h depends on the compiler used to build FFmpeg.  Users of the
installed headers might be using a different one.

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



More information about the ffmpeg-devel mailing list