I have to thank Aurelien a lot, now xine-lib-1.2-libavutil branch works fine out of the box with an unpatched FFmpeg copy!
He modified the CRC code from FFmpeg to actually be installable, and then made sure that he header was installed, with this, xine-lib can use FFmpeg’s libavutil to calculate checksums (CRC and SHA1) and to encode to base64 (which was used in three places already: CDDA input plugin, to fetch CDDB data, librtsp for RTSP protocol handling and the HTTP input plugin for digest authentication).
Reducing the redundant code in xine also means saving memory space, and as we already use FFmpeg, this does not increase the amount of code that is loaded and dynamically linked to.
The libavutil branch also spots a huge change: internal FFmpeg is no more, now you need to build a copy of FFmpeg from SVN (or use the one your distribution packaged), to be able to use xine-lib-1.2; it actually requires a fresh copy out of current FFmpeg SVN at the moment, so that Aurelien’s patches are present. I think Debian should package a new snapshot soon enough, and probably should Luca although I use a live FFmpeg ebuild for my development needs 😉 ).
There were still a few rough spots regarding the removal of internal FFmpeg in the Mercurial code, the first was the need for the MANGLE definition, that FFmpeg project does not want to export, so I added it to an header inside xine-lib for now, until we can look at the code to see if it can be rewritten not to use MANGLE at all.
Another was the dvdata.h header that is used by the “FFmpeg-based” DV Audio decoder. I put the quotes because no FFmpeg code was used, just the dvdata.h header; the plugin is now moved away from the ffmpeg plugin directory, and a copy of dvdata.h was imported as ff_dvdata.h.
As I was looking at that, I also removed the code used by the DXR3 plugin from the ffmpeg plugin. Up to now, to use the FFmpeg mpeg encoder, the DXR3 plugin added code to the FFmpeg decoder plugin, to initialise the encoder, then the video output driver dlopened the FFmpeg plugin, loaded the init function and called it. This was because the FFmpeg functions were built in the FFmpeg plugin when internal FFmpeg is used. Now that FFmpeg is no more used internally, I simply moved the FFmpeg-based encoder into dxr3 itself, make it link to FFmpeg, and be done with it. This actually removes the need of exporting an extra function from the FFmpeg plugin.
Now that I think of it, I forgot to remove DYNAMIC_LD_LIBS from the linked libraries of the DXR3 plugin, it shouldn’t be needed anymore as no dlopen() is used, which should make it faster at runtime too.
Talking about FFmpeg, with one of my recent warning-fixing spree in xine-lib (too bad I can’t remove all the warnings without breaking API – double pointers are evil), I found a function in libpostproc not accepting constant strings by prototype (see this entry), and then seen the pp_help entry which got defined in .data; RSS for libpostproc should be down now, but I start to wonder if the library is a bit rough, and in need for some improvement. I’ll probably look at it too, as xine uses it.
FFmpeg itself should instead be quite more friendly when it comes to table being constant and properly in .rodata; I found a few things that are in .data but could go in .data.relro though, I’ll probably take a look at it tomorrow – remember: .data.relro stuff could be mitigated with prelink, if prelink worked properly .
Instead, unrelated to FFmpeg but still related to xine-lib, tomorrow I hope to refresh the new libdvdnav branch, and then proceed to merge it in 1.2 quite soon; the new libdvdnav branch uses the libdvdnav code that is now developed by the MPlayer developers (Nico, mostly), while xine-lib currently uses an internal copy of libdvdnav coming from linux-dvd’s CVS. If we migrate to use MPlayer’s libdvdnav, we can finally use an external version, and we slim down the DVD input plugin quite a lot, which is not bad at all.
I sent two patches for libdvdnav tonight before going to bed, one fixes a lot of string tables so that they can go to .rodata and so take up less memory, and one to mark a single variable static (the variable could also be removed by using UINT16_MAX, but that’s for tomorrow).
Too bad that libdvdread implements its own MD5 routines, if it used libavutil we’d be saving more memory again. I suppose I could look at patching libdvdread too in the future. A perfect setup would have libavutil providing basic implementations for various multimedia software, so we don’t have to invent the wheel every time…