It has been a while since I last blogged about the technical progress of xine, because I mostly didn’t follow his technical progress in the past months, being too occupied trying to save myself from my own body, I decided to dedicate myself first to some less technical issues.
The first of which was the bug tracker, as it seems that almost unanimously, the developers of xine, me included, hate the SourceForge tracker and the ones like it (GForge’s and Savane’s). There are also enough people not interested in jumping on the Launchpad boat, or the Google boat, as they both havethe same technical limitation that SourceForge has: they are not open solutions; SF was but it was then closed up, GForge also was, but now is no more (this probably accounts for the fact that many new services provided by Alioth aren’t well integrated into the GForge installation), Savane still is free, and I admit their bug tracker is a bit better, although it’s not exactly the best, acceptable though. The last decision was to choose between Scarab (JSP-based) or Roundup (Python-based); the first should be faster to set up as it’s pretty much ready out of the box, while Roundup requires quite some fiddling (that Luca actually already did for FFmpeg and MPlayer so the problem does not even pose itself); just lately an user proposed FlySpray to me in a comment, and that entered the competition too, especially since, being PHP based, it’s less burden than JSP, and it’s certainly good enough out of the box when compared to Roundup.
The current status of the bug tracker is still unsure. I’m waiting for Siggi (one of the oldest xine developers still active and maintainer of the xinehq.de website) to see if he has time to manage and administrate the Roundup install; if he does, then you’ll soon see the tracker on that site, maybe a bit rough until we can find someone with HTML and CSS skills to improve it. If Siggi is unable to take care of it, we have a Plan B, as IOS Solutions (the same provider where my blog is located now, and where Reinhard Tartler – the Debian and Ubuntu maintainer of xine packages – works) is ready to offer us a vserver for the xine project (which I’m ready to maintain myself, after all it will probably share a good 80% of packages and configurations with my own).
So the bug tracker should be solved, it’s just a matter of time to decide with which plan to proceed, but there should be no mistake, the bug tracker will be opened soon, and we can ditch the SourceForge tracker soon.
There is one other non-technical problem though, that I started looking at some days ago: the licences, as I already suggested in my blog about OpenGL.
If you follow the recent changes in software licences due to the release of GPLv3 you’ll see that there are indeed many projects moving forward to use the new version of the licence released by the Free Software Foundation. Beside the GNU project’s packages, that of course were already supposed to move to GPLv3 when it was released, and this includes binutils and gcc, two major parts of a standard toolchain for Free Operating Systems, there is the change in Samba’s licence, that is causing already headaches to KDE people, as you break the license if you distribute binary packages of software linking at the same time to the new Samba and Qt (as Qt, although allowing to be used with LGPL-licensed code, does not allow GPLv3 yet).
xine does use Samba, for the SMB input plugin; xine also uses libcdio, that was being discussed for moving to GPL3, too. So on suggestion of Matthias Kretz (the Phonon maintainer for KDE4), I decided to make sure that the xine code was clean when it came to license. It wasn’t and still isn’t.
The main problems were due to source files and scripts that were added by project members but lacked any header with licence information and copyright. Most of the times the cause is just laziness, and I can’t really blame them 🙂 Other times is just assuming that the code is so trivial that it makes no sense to put a license on it. For those cases I suggested using ISC license (mostly an as-is license) that explicitly permits the use of the code almost for everything.
Unfortunately there are also cases of license incompatibilities: to play NSF files (NES audio format), xine uses code taken from nosefart; although nosefart is declared GPL2, almost all the source files have no header with copyright and license, while some of them shows a clear copyright referring to MAME, which I’m quite sure is not GPL-compatible; the Goom visualisation plugin, then, has some files with a “All rights reserved” notice, which makes it a very bad idea to distribute. These are the biggest cases, but of course there is the libw32dll code, that although taken from MPlayer and Wine does not show any copyrights or licences, and the vidix code that… well that’s just a mess in every way.
Up to now I was able to replace some functions’ replacements with copies from OpenBSD and NetBSD, licensed under ISC or 3-clauses BSD licences, making them safe and compatible with any GPL. The alternative of course was to make use of gnulib, but I’m not ready enough to shoot at the bird with a BFG10K; for xine-ui it might be too much, although a proper fix in the xine-lib build system might help. The problem is that for now the replacement functions are built into libxine.so itself, rather than being compiled in every other plugin. It might not get into xine-lib-1.2, but if I ever get around to add a libxinecore in 1.3 (which provides a “protected ABI”, that only libxine and the plugins can use, but the frontends can not), it might be moved there to be done with it.
For what concerns vidix instead, Diego (the other Diego) informed me that MPlayer does have a newer version of vidix with all the license information cleared up. Unfortunately my Enterprise can’t really run vidix (at least last time I tried), but I’ll certainly try to find time to work on it in the next week, so to merge the code coming from MPlayer and replacing it at least for 1.2 series.
The problems remain with Nosefart and Goom. What I have intention to do (as soon as I find time to) is to make both of them optional at runtime (right now nosefart is always built because it adds no external dependency, and same applies to Goom), and then make sure that they are not built by binary distributions. At the same time, they should be disabled with the USE flag bindist, but that’s another story.
I hope to clear the use of those as soon as possible, as I don’t really want to have a package that is inconsistent with its own licence.
On the theme of micro-optimisations, instead, I want to say that I’ve done “some” commits on xine-ui in the past days, I decided to take a look at the code trying to see what could be fixed, as I found some pretty nasty things while I was checking its licences. The result is that the current CVS version of xine-ui should have a reduced vmsize, at the cost of some kilobytes more on disk. I achieved this by marking as constant as many global symbols (they can also be static to an unit actually) as possible (if you have a non stripped binary of an app you want to optimise this way, check the output of objdump -t file | fgrep .data and objdump -t file | fgrep .rodata, and make sure the first is almost empty. I’m still not sure why the on-disk file gets bigger rather than smaller, but it might depend by the fact that I have debug information available.
Unfortunately xine-ui really was written over and over, and it might as well use a good rewrite. I tried to fix some stuff, but it’s just one bandaid over another.
The same technique I used to find the symbols to move from .data to .rodata (the first is the section where variables are declared in an ELF file, while the latter is where constants are written, it’s read only and can be shared among processes) cannot be applied so easily to xine-lib though: the -fvisibility tricks we use hide the symbols from objdump output. Plus there is the problem that for instance by running it over the FAAD plugin, I’d get all the libfaad symbols too, as without libfaad in Portage I’m still building my local xine-lib without system libfaad (Alexis if you read this, I’d be very happy if you could at least provide an overlay with the ebuild for 2.6.1 🙂 ).
I don’t know why, but such micro-optimisations that most likely don’t change the speed of the code, nor the biggest memory problems in xine, are something that I like to do, they relax me quite a bit.
Anyway, today I worked on libcdio too, but as I have yet to finish what I started during the night, I’ll blog about that tomorrow.