On Sun, Oct 29, 2006 at 12:53:37AM +0200, Moritz Muehlenhoff wrote: > On Sat, Oct 28, 2006 at 01:08:09PM -0400, Joey Hess wrote: > > Moritz Muehlenhoff wrote: > > > > > > > The testing security team tracks probably hundreds of possibly security > > > > relevant code copies in data/embedded-code-copies in their svn repo. As > > > > long as the security teams know about code copies, they can deal with > > > > updates due to them. > > > > > > No, we have already way too much work and artifially introducing more is > > > not a option. For Sarge there was no clean solution, as ffmpeg provided > > > only a static libavcodec, but since this exists, there's no reason not > > > to use it. > > > > How is mplayer different than the 200 or so other items listed in > > embedded-code-copies? Other than only getting through incoming now. > > Two complexes of code embedding have caused serious trouble for security > support in Sarge; xpdf and libavcodec. xpdf is resolved for Etch, libavcodec > is being adressed currently, thus this bug.
Removing the embedded copies of FFmpeg libraries from MPlayer is a bad idea. The relationship between MPlayer and FFmpeg is very intimate to say the least. MPlayer uses FFmpeg HEAD via a svn:external declaration. In the future we will move both to a common repository. Most FFmpeg developers work on MPlayer as well. FFmpeg is highly volatile and fast-moving. The FFmpeg snapshot in Debian is two months older than the one in MPlayer 1.0rc1. This may not sound much, but it means more than 600 (!) commits to the FFmpeg repository. Using the Debian version of FFmpeg in MPlayer would create a beast entirely different from 1.0rc1. Several codecs have been added which were only available through binaries before, many bugs have been fixed and speed improvements committed. A H.264 video decoding benchmark done by a fellow developer gives the following numbers: self-built custom binary: 13.9 seconds Debian MPlayer package: 14.7 seconds binary with Debian's FFmpeg: 17.7 seconds The Debian FFmpeg binary was built against dynamic FFmpeg, the other two with static FFmpeg. That's a massive 20% performance degradation.. Using a shared dynamic version of FFmpeg would disable several video filters, so there would be even more feature loss. Plus I expect random bugs to creep up. As mentioned above FFmpeg is highly volatile and fast-moving. Backwards-compatibility is not a priority. regards Diego Biurrun MPlayer / FFmpeg developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
