D Richard Felker III | 1 Feb 07:16 2004

Re: CVS: ffmpeg/libavcodec fastmemcpy.h,1.1,NONE

On Sun, Feb 01, 2004 at 04:57:19AM +0100, Måns Rullgård wrote:
> D Richard Felker III <dalias <at> aerifal.cx> writes:
> 
> > On Sat, Jan 31, 2004 at 07:13:07PM -0700, Mike Melanson wrote:
> >> On Sun, 1 Feb 2004, Alex Beregszaszi wrote:
> >> 
> >> > All includes are in USE_FASTMEMCPY ifdef switch, and that's only present
> >> > if mplayer says so. For now, I have changed to pass -I../libvo/ through
> >> > OPTFLAGS so we don't need that crappy fastmemcpy.h file, which only
> >> > contained a single #include "../libvo/fastmemcpy.h" line...
> >> 
> >> 	This strikes me as the wrong way to approach the problem.
> >> ffmpeg-enabled apps have ways of asking ffmpeg to use custom functions.
> >> get_buffer() is a good example of this. There has never been any "#include
> >> "../libvo/get_buffer.h" stuff if ffmpeg. The fastmemcpy stuff should
> >> follow the same model.
> >
> > We should make fastmemcpy slow by wrapping it in conditionals and
> > indirect calls? Wow, what a brilliant idea!!
> >
> > What's wrong with the current approach??
> 
> At least agree that mplayer specific files don't belong in ffmpeg.

I agree -- that's why I'm glad Alex fixed that! Maybe we should
integrate a copy of fastmemcpy into libavcodec...but then there needs
to be a compiletime option to select between dynamic cpu selection and
static, because the overhead of indirect calls really sucks.

Rich

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Gmane