Using an external ffmpeg is contrary to the xine authors' recommendations and I can't find any reason in the changelog or bugzilla that explains why the ebuild, which (IIRC) used to have a "ffmpeg" USE flag so that you could ignore those recommendations at your own risk, now actually *forces* you to ignore them. The ffmpeg included with this version of xine-lib does happen to be a later version than the one in portage but even when they match, I've noticed that the xine authors often patch the internal one so that it works better. It certainly always has done for me. Having noticed that the xine-lib of this ebuild seemed rather flaky and to be performing poorly, I replaced it with one configured and built 'manually' out of the same source tarball and it does indeed seem to work better now. I also chose not to explicitly disable optimizations, as the ebuild does, but there doesn't seem to be any good reason for doing that either - there definitely isn't on my machine, AFAICT. So... I certainly can't see any good reason for using the external ffmpeg but even if crippling xine performance-wise or building it with some non-standard and even explicitly discouraged configuration is the only way to get it to work for /some/ users, I don't think we should all have to suffer the consequences. Please can we have the "ffmpeg" USE flag restored (or preferably something like "ext-ffmpeg") and one for enabling/disabling optimizations too?
Not going to change, we won't be fixing tons of bundled stuff when security bugs appear when we can fix just one external library and be done w/ it. It's a general policy, not just xine-specific one.
(In reply to comment #1) > Not going to change, we won't be fixing tons of bundled stuff when security > bugs appear when we can fix just one external library and be done w/ it. It's a > general policy, not just xine-specific one. > Perhaps I am wrong but I get the impression that xine-lib's use of ffmpeg is rather like mplayer's (which IIRC doesn't even allow trying to build with an external 'vanilla' version) and not at all like, for example, VLC's use of it as an unmodified "third-party library". So what happens about all the bugs that appear in xine based apps because the ffmpeg in portage doesn't work well (or at all) with xine-lib (as it now doesn't)? I'd found two specific bugs already (other than a general poor performance/flakiness) before I realised what was going on and that building xine-lib with its internal ffmpeg was the sensible way to fix the problems. Reporting bugs that are due to this incompatibility would be decidedly un-sensible under the circumstances, so I'm forced to make my own ebuild to get a properly working xine and I expect the same will be true for most other xine users. You say that you can just fix the one external library and be done with it but I don't see how that can be true. xine-lib may offer the option to build with an external ffmpeg but that doesn't mean it is a good idea or will even work. Treating the external ffmpeg as though it were equivalent to the xine-lib internal one seems extremely unwise to me. As it says on the ffmpeg site, xine is one of the "projects known to incorporate work from the FFmpeg project". I don't think that description is accidental.
