On Wednesday 26 March 2008 14:47, Peter Ueger wrote: > 2008/3/25, Francesco Romani <[EMAIL PROTECTED]>: > > Yup, but they are used (mostly?) on the encoder side; > > AFAIK the MPEG-1/2 decoder is multi threaded too. And they will > certainly add more. > > > the ffmpeg program doesn't use threading extensively: > > > > grep thread ffmpeg.c > > Where else would you want threads? When libavfilter is fully merged > into trunk, it will certainly run in its own thread. > > > ...and plans to replace all of them :) (http://svn.mplayerhq.hu/soc/) > > I will certainly not replace libx264 or libmp3lame anytime soon. And > while they have their own implementation of MPEG-4 ASP and Ogg Vorbis, > they haven't abandoned their wrappers for libxvidcore or libvorbisenc. > > > Moreover, ffmpeg people seems to not have exactly a good attitude > > towards shared objects/libraries and dynamic linking :) > > Why would you want to use them? Because people like me just want to play around with there own video filter without even having to compile transcode on my machine myself. I only have to compile my shared objects and that's it. That is called plugins and I think it is a great plus of transcode.
Regards!
Georg
>
> > so extend ffmpeg usually means patch the sources and recompile.
>
> It actually means sending a patch to ffmpeg-devel to get your changes
> merged into trunk.
--
---- Georg Martius, Tel: +49 177 6413311 -----
------- http://www.flexman.homeip.net ----------
pgpGOygmGka7Z.pgp
Description: PGP signature
