On Tue, Oct 31, 2006 at 10:43:17PM +0100, Aurélien GÉRÔME wrote: > > On Tue, Oct 31, 2006 at 07:46:01PM +0100, Diego Biurrun wrote: > > Removing the embedded copies of FFmpeg libraries from MPlayer is a bad > > idea. > > For the workload on the security team and the overall quality of Debian > (a single source package for whatever produced binary packages), > I strongly disagree.
I won't comment on the workload of the security team, even though Joey appears to disagree about the issue. > > 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. > > Other software also use ffmpeg. AFAIK, ffmpeg do *not* need mplayer > to work. FFmpeg does not require MPlayer. I never intended to say that. > > 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. > > The Debian version can also be updated. I fail to see the issue here. xine upstream currently uses a private fork of an older version of FFmpeg. Exchanging this for a newer version might bring along problems... > > 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. > > First, on what architecture did you test that? I expect the gap > to be reduced on non-x86 architectures. x86 is a register-starved > architecture and one of those four general purpose registers is used > by PIC code, so dynamic linking can really drop the performance as > your benchmark shows. That benchmark was done on x86. But let's face it, it's the architecture that counts. Mind that I am writing this from a PPC, which is my main machine.. > Then, I can agree with you that static linking has better performance. > Therefore, what I can recommand is to build mplayer statically, but > with a Debian up-to-date ffmpeg package. I am CCing Samuel Hocevar > to get his opinion on the matter... I know that distro people dislike static linking, but multimedia players are speed-critical applications. Not everybody has a multi-GHz machine and even on those high definition content takes them to the limit... > > Plus I expect random bugs to creep up. As mentioned above FFmpeg is > > highly volatile and fast-moving. Backwards-compatibility is not a > > priority. > > That will *not* happen with an up-to-date ffmpeg package which other > packages might benefit from. What I'm afraid of is that such an updated package might not sit well with xine and the other users of FFmpeg. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
