One of the most annoying parts to be maintained in xine-lib I can think of is the FFmpeg decoding plugin, this because there’s an inline copy of FFmpeg, but to be synced one need to update the Makefile.am files for automake, and there’s a patch to apply that integrates FFmpeg with xine’s configure system.
FFmpeg upstream already said that the correct way to handle FFmpeg is to build it with its own build system, and integrate that into the code.. so that’s what I’m now trying. I’ve created a branch for xine-lib’s CVS and I’m now working on getting xine building with the libraries from FFmpeg built directly with the original build system.
The results up to now are kinda good, I was able to get both the decoding plugins and the postproc plugin to build using this external version, but there’s quite a bit of work to do still, mostly related to automake to FFmpeg buildsystem integration, like make dist and similar.
I hope these improvements can be merged for a 1.2.0 release of xine-lib sooner or later, one of the interesting thing I’m experimenting with is the ability to split the source that’s not originally part of FFmpeg into a contrib subdirectory, so that Debian and Ubuntu, both needing to repackaging xine, can have a simpler life to it.
The bad size of this is that I’ll have to write again to ffmpeg-devel, and you know how much that destroy my morale.
hmm.. would that allow amaroK to play real files on AMD64? (rtsp radio streams)currently the only engine amaroK uses is xine, but the new ffmpeg does play real fine (without using w32codecs).sofar we have to use mplayer to listen to rtsp streams.