So the official part of the summer of code is now over. I am sure the mentors will blog about the results in general, but since I have followed the Quicktime muxing project the closest myself and since Wim do not have a blog I thought it would be nice to give it a mention. Quicktime is a quite complicated format, orignally created with both editing in use, but also tied quiet closely to the quicktime media framwork. It also has a lot of derivatives like the MPEG4 container format and the 3GPP mobile container format. So when writing a muxer one need to take into account that the user might want a muxed file conforming to any of those 3 standards.
Anyway, Thiago Sousa Santos has been working hard over the summer and we now have the basic muxer working. With the baseline in place there are of course a lot of small details that needs to be taken care of, like adding support for all the different codecs which can go into a Qt/MP4/3GPP container format for instance. Thiego is well underway with that effort already though with h264 support added just a few days ago (I found a bug in the muxer testing it though, but I am sure we will sort that out quick enough). Other codecs we would want to support soon would be Dirac in Quicktime for instance.
The code is not yet in GStreamer CVS, but currently hosted in this SVN repository. But with the Summer of Code over I guess we can look into moving it into the main GStreamer repo. The great thing is that Thiego will continue working on the muxer even though the Summer of Code project period is over so hopefully all GStreamer users will have a top notch Quicktime/mp4/3gpp muxer to use once all major media formats are supported and tested.
So I would like to congratulate Thiego on having completed this years Google Summer of Code project in a absolutely brilliant way and thank him for the effort so far. The future looks bright!
I have been looking for a new hosting option for a while and last week I finally choose one. Based on recommendations from others I ended up going with Slicehost. Slicehost advertise themselves as being a hosting company for developers, which I learned is definitely true. It is the first time ever I had a hosting setup where I even needed to install and configure my own email server. Learned a lot about Postfix over the last weekend :)
That said their setup is pretty nice. You can choose which linux distro you prefer from a quite big list and they will automatically set up your slice with that distro for you. They also have nice webtools for configuring things like DNS. And finally they got a lot of easy to follow tutorials on how to get common server tasks configured and running. Most of them Ubuntu centric, but I found it easy enough to find the Fedora equivalents when needed.
Once the basics was taken care of it was time for me to get my photo gallery back online after a longer period of being offline. Mostly due to me not having kept the gallery code up-to-date (and thus secure) it had been disabled at my old hosting provider. So upgrading to latest version was step one. The upgrade instructions turned out to not work at all, but doing a fresh install seemed to do the upgrade job just as well, it still managed to pick up all my old photos. I am still using Gallery 1.x though, but I noticed that Fedora packages Gallery 2. So I should probably switch to that at some point as having Fedora packagers make sure I am up to date without glaring security holes is more likely to work in the long run.
Anyway, to summarize a long story, my photos from GUADEC are now online :)
I also orderd myself an Epson 350 photo scanner today after discovering that <a href=”http://avasys.jp/hp/menu000000500/hpg000000442.htm”>Epson</a> actually provides official drivers for Linux. Hopefully I will soon also get all my pre-digital photos online.
Got a question on IRC today about the licensing of a specific file in GStreamer CVS, as it was under a MIT license instead of the LGPL license. While we strive to keep our licensing simple by making all new code LGPL or in some specific cases dual licensed, there are a few cases where we got code which is under the MIT or BSD license. This create a situation where we have some files in a directory under the LGPL while others are MIT for example. While I think he have kept things on an even keel within GStreamer, I have noticed that there is a lot of confusion in the open source community in general, about how you deal with MIT and BSD code in a GPL/LGPL context. In some extreme cases I have even seen people just cut’n pasting the MIT code into their GPL project believing that the MIT ‘do what you want license’ includes the right to relicense the code. It does not.
Anyway, to clear up the details for myself I contacted Luis Villa to get some help understanding some of the possible corner cases. Luis then pointed me at this great resource from the Software Freedom Law Center for understanding how MIT and GPL code can co-exist in your codebase. I absolutely recommend reading over this to better understand the implications.
Some time ago I blogged about cdparanoia switching from GPLv2 to LGPLv3 on our request. After that time we have been discussing in the GStreamer community about licensing and what is the exact and implicit licensing promise we are and have been making with GStreamer. The conclusion was that since the LGPLv3 is more restrictive than the LGPLv2 we do not want LGPLv3 dependencies in gst-plugins-good and gst-plugins-base. As mentioned before we always tried to be very serious and coherent with our licensing in GStreamer and suddenly reducing the rights we offer application and plugin developers is not something we feel should be done without very good reason. This is a policy I hope also other important libraries decide to follow, personally I would think it would be a very sad thing if Glib and Gtk+ for instance started taking away rights from their users without a very well reasoned explanation.
Luckily Monty is a very kind soul, and starting from yesterday there is a new version of cdparanoia III out, 10.1, which is dual-licensed under the LGPLv2 and the GPLv2. So even in the future there will be cdripping support offered in GStreamer gst-plugins-base package.
So go to the cdparanoia download page and get yourself this minty fresh version of cdparanoia. We recommend distributions to update to this version as soon as possible to ensure there are no licensing conflicts in their distribution.
I was watching The Daily Show yesterday and Seth Rogen was on as the guest. For those who doesn’t know him, he is a comedian who has starred in movies such as Superbad, Knocked up, Pineapple Express and the upcoming Kevin Smith movie ‘Zack and Miri Make a Porno’. Anyway when listening to him it struck me that I had heard that exact voice and accent somewhere else recently. Then it struck me, vocally Seth Rogen and our own Luis Villa are identical twins. So if you are doing a podcast and Luis is not available for an interview take comfort in knowing you can hire Seth Rogen to do the interview instead and nobody will know the difference.
One of the tasks we gave Sebastian Dröge when he joined us here at Collabora Multimedia was to make sure we had a decent deinterlacer plugin in GStreamer. There had been a plugin in bugzilla for quite some time which contained some code culled mostly from the tvtime application by Billy Biggs. I had spent quite some effort back in the day tracking down the needed people to relicense that code to the LGPL, but it still needed quite some work to be functional. Sebastian has been cleaning up the code and also ported all assembly code in there to C so that it works on all platforms (the assembly code is still in place for relevant platforms). The code for this ‘deinterlace2’ plugin is in gst-plugins-bad currently where Sebastian is fixing up the last niggling issues. But for the adventurous the code can be grabbed from CVS. Below are two screenshots showing a interlaced video with and without the use of the deinterlace2 plugin.
So here is a screenshot using a playback pipeline with the deinterlacer plugin inserted:
gst-launch filesrc location=clip.vob ! decodebin2 ! ffmpegcolorspace ! deinterlace2 ! xvimagesink
And here is the same clip using a pipeline without the deinterlacer:
gst-launch filesrc location=clip.vob ! decodebin2 ! ffmpegcolorspace ! xvimagesink
The clip isn’t of the best quality to begin with, but it was the only one I found with interlacing on my disk. But if you click in and look at the two pictures you do very clearly notice the interlacing creating a jagged look of the second image.
This new improved deinterlacer should be very useful for some DVD’s and DVB transmissions, so once we get this fully integrated both DVD watching and DVB watching in Totem should be a very nice experience.
After getting a lot of updates on the GStreamer DVD menu support bugzilla entry, I figured it was time to make sure Jan Schmidt got some well deserved credit for the work he is doing getting the GStreamer DVD support fixed. Up to know people have had two choices for GStreamer based DVD playback, either Seamless which is a stand-alone DVD player, or using Totem. However the DVD playback you got in Totem using GStreamer up to know has been fairly basic, without DVD menu support for instance. With Jan’s ongoing work on his new resindvd plugin we are on the way to having full featured GStreamer-based DVD playback in Totem.
The resindvd plugin currently resides in plugins-bad, and Totem will automatically use it if you have it installed (and do not have the dvdnav plugin installed). Below is a screenshot of Totem displaying a fully functional DVD menu using the new resindvd plugin.
Only hick up I had was that was something weird happening in the Pulseaudio sink, so in the end I had to kill Pulseaudio to get audio to work when playing DVDs.
So if you like me are very excited about this stuff Jan is doing be sure to test it out and file bug reports if any of your DVD’s fail to work properly. You can also ping thaytan on IRC and tell him you will get him a beer at the next free software conference he attends :)
I guess I am not the only one to try out Pitivi from time to time to check its progress. Edward has been working on Pitivi, GStreamer and Gnonlin for quite a few years now, but of course urgent tasks at work has tended to take presedence of course, leading to a pace of development which hasn’t always been blazing. But a lot of things seems to be coming together these days. When I checked out SVN head of Pitivi today I had a much better experience than before as almost everything I tried work fine for me. I was able to import both an AVI and a MP4 file into Pitivi and easily trim of some uneeded stuff of the clips. I was also able to output them in nice looking Ogg files using Dirac video. All this worked without any hickups on Pitivi’s side. I tried both using Vorbis and FLAC for audio output. Vorbis worked perfectly, but FLAC had some issues with audio/video syncronisation. This is probably caused by a GStreamer bug as embedding FLAC in an Ogg file together with video hasn’t really been widely tested up to now. Sebastian Droge is on the case so hopefully it will be sorted soon :)
But in addition to having reached a point where it has a stable foundation things have also started to pick up pace for Pitivi on the developmer side of things. With two Google Summer of Code students and multiple other community developers starting to dive into the code there is a good chance for Pitivi starting to take much bigger leaps in functionality between releases going forward. My hope at this point is that we can offer a version of Pitivi by Christmas which contains most of the functionality the hobbyist want. So you can edit your Christmas recordings using Pitivi.
Anyway, if you are interested in Pitivi development the best place to keep abreast of things are of course #pitivi on irc.freenode.org.
Screenshot of our editing friend: