So today the allocated projects for the various organisations accepted in Google Summer of Code were released, and I decided to skim through them to see if there was something interesting; especially with xine-lib in mind.
First, FFmpeg projects, as FFmpeg is for good or bad xine’s heart, and improvement in it is certainly going to do good to xine project too. There are four decoders proposed and accepted: RV40 (Real Video), E-AC3 (used in some kind of HD media if I remember correctly), Dirac and QCELP. I sincerely never heard of the last one, and of Dirac I heard only as an experiment from BBC; I prepared the ebuild for the Dirac library when I was trying to support it in VLC, but as there was not a simple way to test it I left it masked in the tree for a while; the package is still there, masked, but someone else probably took it over; with further experience, I should have put it in an overlay.
While really interesting, RV40 and E-AC3 doesn’t sound that appealing for the target of xine users; first the Real demuxer needs an overdue overhaul, second E-AC3 only makes sense if we also start supporting HD media, which I don’t think we’d be doing soon enough. I was hoping for a Monkey’s Audio decoder, but that was not the case neither this year.
Users interested in having Monkey’s audio support in Amarok and other xine-based players might consider the idea to start a Chinese wall reverse engineering for it from the macport library, also if some description is present already, and might be enough to start working on it; I’m not keen on going to do it myself though; beside having other things to do, I don’t really know where to start at the moment.. bribes might make me reconsider but remember that almost anything I do goes to help in some way…
Now instead FreeBSD has interesting ideas, I’m quite interested in support for the Apple’s MacBooks (hoping that they will also consider MacBookPro), as I’m an user for it; the TCP/IP regressions testing might also help, as there has been a few TCP/IP problems in the past that might get solved once and forever with this, but what is really interesting is the bintools project to replace parts of binutils with BSD-licensed variants.. interesting not much for its usefulness, but just to see the mess when you add bintools’s commands to binutils’s and elfutils’s … reinventing the wheel, year after year.
For what concerns KDE I think we’ll see the results only in a few months, but I’m happy to see that there are projects to improve Kopete’s MSN and Jabber protocols. I just hope that in KDE4 Kopete is going to get more maintenance and won’t be allowed to fall behind every year to an obsolete state (Jingle support was nice… but it was left incomplete and never update up to now!. And I don’t intend to forget Mike’s project on Kontact’s blogging support.. that will be neat for a blog-addicted like me.
For X.org, the server-side XCB support is something that I’ve read about for a few months now in the xcb mailing list and seems like it’s going to be quite useful to reduce the possibility of a mistake in the X server code, which is something we all rely upon nowadays (by the way, since X.Org was founded, using X started to be less a pain that it was before, the no-configuration startup is nice, too bad xorg.conf still uses that obscure format :( ).
When it comes to GCC instead, the projects are more technicalities, but there is at least a speedup project that all Gentoo users should welcome easily, and the SEH support (that by the way comes from a friend of mine, hey Hyp if you’re reading! :) ), that will be one less reason not to use MinGW32 rather than VC++.
And not directly related to xine, but coming from one of xine’s contributors in the last months, there’s a project for Wine to support Solaris.. I wish him good luck, as that might make wine’s code even better, as usually portability helps cleaning up after yourself.
Okay now let’s hope these projects will all be completed during Summer of Code and maintained for a long time afterward! :)