[FFmpeg-cvslog] r14475 - trunk/libavutil/internal.h

Måns Rullgård mans
Wed Jul 30 18:02:17 CEST 2008


Reimar D?ffinger wrote:
> On Wed, Jul 30, 2008 at 02:55:17PM +0100, M?ns Rullg?rd wrote:
>>
>> Diego Biurrun wrote:
>> > On Wed, Jul 30, 2008 at 01:14:06PM +0100, M?ns Rullg?rd wrote:
>> >>
>> >> diego wrote:
>> >> >
>> >> > Log:
>> >> > USE_FASTMEMCPY is now called CONFIG_FASTMEMCPY in MPlayer.
>> >> >
>> >> > --- trunk/libavutil/internal.h	(original)
>> >> > +++ trunk/libavutil/internal.h	Wed Jul 30 14:02:22 2008
>> >> > @@ -106,7 +106,7 @@
>> >> >
>> >> > -#ifdef USE_FASTMEMCPY
>> >> > +#ifdef CONFIG_FASTMEMCPY
>> >> >  #    include "libvo/fastmemcpy.h"
>> >> >  #    define memcpy(a,b,c) fast_memcpy(a,b,c)
>> >> >  #endif
>> >>
>> >> What is this fast_memcpy anyway?  If it is useful, it should be in
>> >> FFmpeg.  If not, this hack should go away.
>> >
>> > This was discussed before without resolution.  I would surely like to
>> > resolve this now.  What do you propose?
>>
>> I see two options:
>>
>> 1. Move fast_memcpy(), whatever it does, to libavutil.
>> 2. Delete this hack.
>
> fast_memcpy is GPL, so that might complicate things a bit.
> It will complicate things even more, since it will speed up some things
> and slow down other things (esp. memcpy with constant size which is
> replaced by a compiler builtin otherwise).

In other words, its utility is questionable.  Why does mplayer use it,
if it is not good for anything?

> I once started to make fast_memcpy uses explicit in MPlayer where they
> helped performance and get rid of it where it does not, but it is still
> incomplete.

How much of a difference does it make, anyway?  Perhaps the best solution
is to simply drop, except perhaps in a few critical places.

I have one more option:

3. Move this nasty hack to mplayer, where it belongs.

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




More information about the ffmpeg-cvslog mailing list