Debating removing internal FFmpeg from xine

I’m probably going to mail this later today on xine-devel, but in the mean time I want to at least express my thoughts so that I can straight them up.

As you probably know if you follow xine development, xine-lib has an internal copy of FFmpeg. The current version in xine-lib-1.1 is no more updated for a while, because updating it is actually quite some work, as the build system from FFmpeg is not used at all.

On 1.2 the situation is simpler as I’ve wrote an integration between xine and the FFmpeg build system, which makes updating it almost a piece of cake. Still, it’s some work to do.

There is another point to consider, that is that most distributions nowadays don’t use the internal copy of FFmpeg at all, preferring to install their own FFmpeg in system, and then using that.

So I’m considering the idea of removing the internal FFmpeg from xine-lib entirely. Why this? Well, it makes less work for us xine developers, and should better follow what FFmpeg developers prefer too.

To make it easier for casual users who install by source, we could simply provide tested snapshots of FFmpeg (maybe coordinating with distributions too), and document how to build that and link to that statically without actually installing it on the system (thanks to pkg-config that should be quite easy, and thanks to Mans, probably headers will soon be easier to handle too).

Another reason why I’d rather get users to build FFmpeg outside xine-lib, beside the fact that by using more libavutil functions more than just the FFmpeg plugin would be linking to libavutl, is that this way it would be simpler for frontends like xine-ui to link to it. Why should they? Well, libavutil again. The new versions provide av_strlcat function, for instance, which I could use in xine-ui without having to use a BSD replacement when using GLIBC.

I think xine (and xine-ui) should really try to move away as much code as possible from the main source trees because, at the moment, there aren’t enough people who can handle the amount of code present.

This should go on the same pace as writing documentation for the code that is there and remains there, but even that is quite lacking.

I hope to find my motivation back by doing this kind of cleanup, which is actually quite funny to do, in some masochistic way. I’m not sure if it will, but I’ll at least try.