On Wed, Mar 26, 2008 at 2:47 PM, Peter Ueger <[EMAIL PROTECTED]> 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.
Nice, it's a good thing (even if I think it makes more sense for cpu-hungry codecs like h264/vc-1). > > > 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. Nice. Until it got merged completely, let's keep this point on hold. > > > ...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. Yep, and I'll bet this happened because native implementation ins't matured yet enough, not for any other reason. I was describing an attitude, confirmed multiple times on MLs. > > > 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? More flexibility, and it _helps_ to achieve better isolation between modules. Moreover, ffmpeg is the best of the breed on *nix, almost all F/OSS projects use it, and it is pretty annoying to bundle it every time in every package. That's the reason why we have shared libs. (...that's also the reason why it would be better to have formal releases and some stricter API/ABI guarantees, but that's a different story) > > > 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. It's just the same thing, modulo the review process. But we aren't talking about code quality, we're talking about ease of extension. (and no, ease of extension doesn't necessarily imply a code quality loss; they are different topics.) Bests, -- Francesco Romani // Ikitt
