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.
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…
Great work, looking forward to the 1.2 release!
a year ago or so, i thought to myself that xine-lib is a mess.it’s pretty ironic that i didn’t know a thing about it, and yet i wasn’t exactly wrong either :]i love that optimizations that are happening now. let’s hope that 1.2 comes soon :]
well, i’ve always thought that xine was better than other similar software and the development that it now has is really awesome. though, i still have some problems with mkv decoding. it seems that xine cannot decode the formatting of the characters, but that is also visible with mplayer, and when it encounters some strange formatting which contains negative values for attachment ids like the following:Track ID 1: video (V_MPEG4/ISO/AVC)Track ID 2: audio (A_VORBIS)Track ID 3: subtitles (S_TEXT/ASS)Attachment ID -8618919320180990512: type ‘application/x-truetype-font’, size 69172 bytes, file name ‘BARTH_N.TTF’Attachment ID 5057498693352570238: type ‘application/x-truetype-font’, size 75812 bytes, file name ‘BARTH_NI.TTF’Attachment ID 5633278775117138056: type ‘application/x-truetype-font’, size 38344 bytes, file name ‘CTMercuriusStd-Black.ttf’Attachment ID 6550448973828372231: type ‘application/x-truetype-font’, size 39064 bytes, file name ‘CTMercuriusStd-BlackItalic.ttf’Attachment ID -3087811779052269942: type ‘application/x-truetype-font’, size 37668 bytes, file name ‘CTMercuriusStd-Light.ttf’Attachment ID 5681934878107839910: type ‘application/x-truetype-font’, size 38560 bytes, file name ‘CTMercuriusStd-LightItalic.ttf’Attachment ID 8560027258570362406: type ‘application/x-truetype-font’, size 37912 bytes, file name ‘CTMercuriusStd-Medium.ttf’Attachment ID -7412377026830453843: type ‘application/x-truetype-font’, size 38928 bytes, file name ‘CTMercuriusStd-MediumItalic.ttf’xine cannot open the demuxer. should i post this as a bug somewhere? it is surely related to the negative id attachments since other files with the same components but only positive attachments play. mplayer with this file didn’t also play the osd but it was able to start the file.some new wmv also have some tearing problems. i think that this is due to the way the wmv and real codecs are read, but the one thing that gives me problems is that i cannot play mkv’s like in windows neither in xine or mplayer.the last thing i’d like to know is:is there a gentoo ebuild somewhere for this new ffmpeg free xine-lib version?ps. last but not least: i’m very happy that you’ve decided to stay in the xine team. thank you for continuing to help out the opensource community.