On Wed, Mar 26, 2008 at 03:02:57PM +0100, Francesco Romani wrote: > > > > > 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)
indeed. since we're talking pros/cons. this is a disaster on the part of ffmpeg, perpetuated mostly by mplayer. just think about it from the security standpoint. there's a security problem with some ffmpeg code. now, I have to go hunt down everything using ffmpeg, and see if it's relevant to that version of ffmpeg. what a waste/headace. should just be replacing 1 package and be done. it's also a total waste of time and energy to compile ffmpeg over and over. first for ffmpeg proper, then for mplayer, avidemux, etc, etc. and the worst part is, it's not even _possible_ to compile, e.g. mplayer with an outside ffmpeg, unless it is _exactly_ the version that comes in mplayer's sources, which largely defeats the purpose. ffmpeg is the only package I know of these days, that as large, mature and widespread as it is, can't make a real release, and still tells developers to include private copies in their sources. sorry, but that's just idiotic. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
