From: Bill F. <bil...@mi...> - 2007-12-15 03:22:29
|
On Fri, 14 Dec 2007, Diego 'Flameeyes' Petten=F2 wrote: > Here comes a probably controversial proposal: let's remove the internal > copy of FFmpeg from xine-lib-1.2. >=20 > Now let me explain. >=20 > While FFmpeg sync in 1.2 is quite easier compared to 1.1, as we don't > use a new build system, but simply FFmpeg's, syncing is somewhat of an > hassle on the long term, and right now there aren't really enough > developers to take care of that. Mike, you don't seem to be much active > around here, I don't blame you for that because I do know you're busy, > but that also means that the main mediator with FFmpeg is missing. >=20 > Also, in the new xine-lib-1.2-libavutil branch, I've started using > libavutil (part of FFmpeg) on both libxine and a few other plugins that > have nothing to do with FFmpeg; using a shared system library will > certainly improve the performance here, rather than using the internal > copy. >=20 > A similar use of libavutil could happen on xine-ui itself, removing for > instance the need for a strlcat replacement for GLIBC systems, but it's > silly to add a libavutil external dep on xine-ui and not on xine-lib. >=20 > Do we lose something with this change? Sort of... >=20 > Probably all the distributions, at least all the distributions I know > of, use an external copy of FFmpeg anyway, packaging it for the > system. The only people who probably still use the internal FFmpeg copy > are random users installing from source. >=20 > For those users, we can get the best of the two worlds by providing a > "recommended" snapshot of FFmpeg, and the documentation on how to build > it, either to install it on the system, or to leave it uninstalled, and > link to it statically; thanks to pkg-config, doing both is almost > trivial. >=20 > Anybody has comments about this? I'd quite like if this could go in 1.2 > before release, as moving code out of xine-lib is not a bad thing > considering also the limited number of developers we have :) I understand that it's ultimately up to the developers who actually do the work, and that there does seem to be fewer active xine devs now then there used to be. That said, from the user perspective, I found it a strong selling point of xine that it had a guiding principle of being self-contained for doing its basic core functionality. It makes it a real pain to have to track down and install a number of external packages just to get a working media player (for example there doesn't appear to be an ffmpeg package included in any Fedora distro). Also, I thought there were a number of xine internal patches to ffmpeg that are carried along with xine, and that haven't been merged back upstream to mainline ffmpeg for some reason. On the plus side, I guess we could get new capabilities faster, but it could also make troubleshooting problems somewhat harder as there could be a variety of different ffmpeg versions being used with a variety of xine versions. My overall preference would be to keep using an internal ffmpeg version, but allow using an external version for distros that do distribute an ffmpeg package (I believe that's already allowed). -Bill |