Anger, and xine-lib’s mov support (plus a lot more xine stuff!)

*If there is something that makes me very angry is the Summer; I shut down Enterprise during the night because it’s noisy and my mother whines about the noise; I usually could work with Intrepid (the laptop) from my room, but there I don’t have a desk, and the mattress is latice and it doesn’t seem to be a good heat sink, so it overheats, and I can’t even type on the keyboard; this was one of the reasons I bought a 32” LCD TV, which I can connect to the laptop, leaving the laptop on a chair or on the drawer, where it doesn’t overheat, but then I can’t type on it. I should have bought a bluetooth keyboard too, but they are so damn expensive! Plus, standing on the bed trying to sleep doesn’t work well for me when I have my brain going on its own path, and I get angry, angry, so angry that I could smash the laptop over the chair entirely for being unhelpful in this situation. So here I am, in my home office, at Enterprise’s keyboard, trying to relax myself, with bad results.*

Today, I wanted to get started on my plan to improve xine’s support for m4a files; looking at xine playing a generic file, I understood that the metadata wasn’t being loaded at all; on the other hand, there seemed to be a function that was supposed to load it; luckily, it never worked.

Why do I say luckily? Well, most of the code in the qt/mov demuxer does not give problem, but does not even try to parse correctly all of the possible variants. The first example is that most likely the 64-bit offset specifiers will drive xine crazy and get it to crash; luckily there don’t seem to be many 64-bit mov files out there, so it shouldn’t be an issue (please don’t confuse this issue with 64-bit timebases, like the ones generated by FFmpeg, that causes QuickTime to skip over the file; those works fine since 1.1.7 as I fixed their loading). Also, the function that supposedly parsed the metadata increased the pointer on the file by increments of the byte, which is quite wrong, and nasty too.

So then, why do I say it never worked? Well, the code tried to look for a meta atom (an atom is an element of a qt/mov file) inside the main moov atom; but the metadata is actually stored inside /moov/udta/meta atom (consider the path like an XPath applied to qt/mov atoms; yeah the atoms are usually nested).

Now in xine-lib-1.2 the code is fixed to actually load the metadata correctly, and I’ve also improved the code to use switches instead of multiple if cases, this should improve the runtime speed to parse the qt/mov files, and at the same time makes the code more readable. While the first change is totally useless to Amarok users (Amarok uses a TagLib plugin to get the metadata out of m4a files, so it gets it right already), the latter might be appreciated.

My next step would be to try making use of the coverart metadata, to display the cover while playing the audio track and no video is present; it might be a bit of an issue as it should be possible to switch between the cover and the visualisation plugins, but that’s a long story.

I’ve also been thinking about the «Digital Booklet» that iTunes offers with some albums, which I suppose contains the album art; I’m not sure which format it uses, but I’d suppose it’s still a qt/mov file with image data in it (yes, the format also allows still images to be loaded there); it could be quite nice to support that in xine, too, and Amarok could use such a feature to display the booklet data, as in Amarok 2 there should be at least some video playing capabilities. Unfortunately I couldn’t find an album that I’d spend money on without too much regret that had such a digital booklet to get to test.

This work let me consider about the way xine loads the metadata; right now just a subset of the possible information is recovered from the files; it might be nicer to actually provide all the metadata loaded as possible, trying to map it into standard values, or providing string-mapped values for extended metadata as found in qt/mov/mp4 files. Unfortunately there are two things to consider against such an idea: the first is that the API has to be changed to be able to get the extended metadata, the second is that the metadata loading might be time and memory consuming, and a few xine frontends, like Amarok, might not care about it at all, and as such it would require to add an option (at runtime) to load or not the metadata when opening streams (it cannot be global, as Amarok uses xine’s metadata load to get information about the streams that are being played through http and other protocols where TagLib is useless).

Another thing that might be useful to implement, although Amarok wouldn’t likely make use of it, would be last.fm playback, directly in xine. Unfortunately I never looked up the protocol used, so I can’t assess how much work it’s needed to send the messages and receive the additional metadata; the datastream is actually HTTP-based, at least that’s how Amarok’s proxy mangle it, so it shouldn’t be impossible to implement; there is probably the need of adding an option with username and password to use to connect to last.fm.

Again, optimisations that xine-lib might take is an option to enable/disable the visualisation plugins; this is helpful because most users will likely not use them at all, so why build them? They take up space and time without reason; and it’s also the place where a TEXTREL is found, at the moment, so it might be a good idea to make them optional for security reasons too.

I hoped to make use of exmap to actually track down some of the memory usage in xine, but the current version doesn’t work for me on a current kernel on AMD64, so I gave up for now. If somebody has a clue how to make it work, I’d be happy to know.

To give an update about the current works in progress, then, I’ll try to summary most of what I talked about for 1.2 series:

• the audio conversion branch is happy that aRTs output has been removed from 1.2 series of xine; unfortunately it requires still porting for ESounD (can do it on Enterprise), JACK, FusionAudio (these two are Linux’s so they are somewhat doable if I have a lot of time) and SunAudio (Solaris or NetBSD, I don’t have either available to test with); if I can’t find anybody to help me out with this, it might require quite a lot of time before the port is done;
• the XDG compliancy work is half done, half because Matt Messier reported some problems when building for a prefix that is not in the default XDG_DATA_DIRS path; in theory we should be changing the code to look first in the prefix for which we built, and then check into the rest of XDG paths; I still have to find time to do this, and that’s why xine-ui isn’t ported yet;
• the new libdvdnav copy requires some testing with non-encrypted ISO9660 DVDs, that should work fine with the current internal copy of libdvdnav, albeit with a very nasty hack that we’re lucky is working; I have to find such a DVD myself first hand to be able to test if the new libdvdnav can be fixed without the same hack, before merging it into mainline;
• the new DocBook guide got me a bit stuck; I’ve converted the documentation to DocBook 4.4 XML, and then converted the fig images to SVG (which is quite more modern, and probably easier to deal with), and I got the rules in place to build them; unfortunately there doesn’t seem to be a nice and little SVG rendering program for OS X, so I can’t make the dependency over xmlto and rsvg (or any other rendering program) mandatory (for installing from Hg), which means I have to return to the previous nasty hacks;
• what else? Well there are a lot of things to work on in xine, unfortunately we need waaay more man power; Thibaut started working on the new plugin loading code, but he’s gone MIA again.

Anyway, if you want to help in any way with these tasks, it’s certainly appreciated; development is the best thing, but if you cannot, maybe you can find someone who can actually grok xine-lib, and convince her/him to help, we do need people. On the other hand, if you know of a decent album of Metal, J-Pop or Jazz music, available on iTunes Plus (note the Plus, it has to be DRM-free) that contains a digital booklet, please let me know – or even better send a gift card to me with the name of it 😉 – so that I can try to work on that particular issue.

Now I should really try to sleep, if I can without wanting again to smash something. I don’t think I live well enough if just thinking of what to do about my life gets me to this point, do I?