Date: Mon, 4 Nov 2002 01:56:46 -0500 From: Anish Mistry <mistry.7@osu.edu> To: Mario Sergio Fujikawa Ferreira <lioux@FreeBSD.org> Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: ffmpeg compile optimisation helps no end! was Re: FreeBSD 4.7R: no sound when recording with ffmpeg? Message-ID: <200211040156.46548.mistry.7@osu.edu> In-Reply-To: <20021102220232.40685.qmail@exxodus.fedaykin.here> References: <20021028063325.224adec5.steve@sohara.org> <20021102173507.352ddc71.steve@sohara.org> <20021102220232.40685.qmail@exxodus.fedaykin.here>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 02 November 2002 05:02 pm, Mario Sergio Fujikawa Ferreira wro= te: > On Sat, Nov 02, 2002 at 05:34:45PM +0100, Steve O'Hara-Smith wrote: > > On Mon, 28 Oct 2002 23:21:32 +1100 > > Carl Makin <carl@stagecraft.cx> wrote: > >=20 > > CM> I have a Celeron 600 and the above ffmpeg parms give me excellent > > CM> video with only the occasional jerkyness, however the audio goes = out > >=20 > > =09I've just noticed something silly, ffmpeg is compiled > > completely without optimisation. Try applying the attached patch in > > /usr/ports/graphics/ffmpeg (it adds -O3-fomit-frame-pointer to the > > compile options). > >=20 > > =09I think this is worth committing, with it I can use default > > motion estimation and even high quality settings at full resolution > > without dropping frames. >=20 > =09Humm, I am improved a bit on your idea. :) >=20 > =09First, ffmpeg is now CFLAGS safe (I'm a bit confused as to > why it was not before); meaning that it will use your CFLAGS now. > =09Second, it will add some optimizations if WITH_OPTIMIZED_CFLAGS > is enabled. > =09Third, if not defined WITHOUT_LIBA52, ffmpeg will now > use ports' liba52 port instead of internal code. liba52 in ports > is faster than ffmpeg's version. > =09Finally, ffmpeg will now use FreeBSD byteswap optimized > routines IF you happen to be using a FreeBSD 4.7-RELEASE or later > (any 5.x-CURRENT applies) >=20 > #if defined(__FreeBSD__) && __FreeBSD_version >=3D 470000 > #endif >=20 > It will use both 16 and 32 bits kernel byteswap routines available > in /usr/include/sys/endian.h instead of its own version of them. > As far as I can tell, these byteswap routines are only used with > mpeg video. However, mpeg video seems to be used a lot by booktree > users so it should help a bit. :) >=20 > =09I tested these changes with several mpeg output formats: > mpeg1video mpeg4 msmpeg4v1 msmpeg4v2 msmpeg4. Everything seems fine > but I did not benchmark anything. Steve? Could you try some benchmarks > since you've been timing stuff? Unfortunaly, I do not have a booktree > board to test capture performance. >=20 > =09Regards, >=20 > --=20 > Mario S F Ferreira - DF - Brazil - "I guess this is a signature." > Computer Science Undergraduate | FreeBSD Committer | CS Developer > flames to beloved devnull@someotherworldbeloworabove.org > feature, n: a documented bug | bug, n: an undocumented feature >=20 On my 650MHz Duron brooktree capturing at 30 fps @ 320x240 I get good qu= ality=20 and no drops and about ~45% CPU usage with the modifications. :) --=20 Anish Mistry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211040156.46548.mistry.7>