As I mentioned in my previous blog post here at Collabora Multimedia we have been working with Canonical and the BBC to create a plugin for Totem which plays BBC content. This work is progressing well and with the recent patches we made for Totem to sort out python threading issues are looking really good. I really recommend that people running the latest Ubuntu test releases grab this for some testing. I attached a screenshot of Totem playing a Dirac stream from the BBC showing Big Buck bunny.

Big Buck Bunny

Update:: I noticed a lot of people commenting on the user interface. We are aware that the current user interface is far from perfect and a lot of the requested features are planed. So far we have focused on getting the base technology working smoothly which I think you will agree is the most important first step. A nice looking user interface is of little value if the application locks up :)

There ended up being quite a lot of comments posted to my blog post yesterday where I pointed out a logical fallacy in a blog post by Aaron Segio. I wasn’t online in the evening so I didn’t reply to the comments posted, but let put down my arguments here instead.

Benoit Jacobs posted a reply making the point about Phonon being smaller than a multimedia framework and that on Windows and Mac installing another multimedia framework would be redundant. This argument rests on some assumptions I think are false. First of all it assumes that GStreamer is huge while Phonon is small. The core idea behind GStreamer since day one was to keep the core small and media agnostic while all functionality was put into plugins. This means that what you install on Windows or Mac, if all you want is access to the codecs provided on those platforms is actually very small. And while I haven’t looked at Phonon’s disk usage I would be suprised if Phonon plus dependencies really had much of an advantage in that area.

The second assumption is that using three different media frameworks is in some way work saving. Having talked with people who tried going the multi framework route before deciding to just use GStreamer on all three major platforms I can tell you that this simply isn’t true. First of all is the problem that you have three major sources for bugs instead of one. So what people trying this experienced was that instead of hitting one bug in GStreamer and having to fix that, they instead hit one bug in GStreamer, one bug in Quicktime and one bug in DirectShow. And since they didn’t have the source code to Quicktime and DirectShow they often had to introduce ugly work arounds in the application layer. The other cost people experience is that everytime a new feature is needed they would have to implement it once for each of their backends. And Phonon do not insulate people against these kind of problems. They will still hit bugs in the underlaying frameworks and whenever they try to do something Phonon do not support, they either have to try to extend Phonon, hoping that the media frameworks are similar enough in terms of that specific functionality to make this viable, or access the underlaying frameworks directly. And if they want to add a new codec for instance they would still have to implement that codec for three media frameworks instead of one.

bluescarni commented that I had a comprehension problem since Aaron was clearly talking about Qt apps. I am not sure what to reply to that considering you in your own comment posted the quote from Aaron starting with the words ‘Phonon is also more than just an option for Qt apps’. True enough, English is a second language for me, but I do feel I am somewhat in firm ground here…

There was quite a few comments about how Phonon was a better choice for Qt developers. First of all my original blog post was in direct response to a claim by Aaron that Phonon was a good choice also for non-Qt developers doing cross platform applications. So I do not feel a strong need to engage in that debate. But my paragraph above on the second assumption made by Benoit sums up why I do think there might not even be true for even for Qt developers in a lot of cases.

Aaron commented that Phonon is not in the same space as GStreamer. Sure, Phonon does not do most of what GStreamer does, but GStreamer does provide a key feature of Phonon, providing an easy to use API across Windows, Mac and Linux/Unix. Sure you ‘don’t get a hard dependency on any one multimedia system’ with Phonon, but you do get a dependency on Phonon and its dependencies instead. So the argument that ‘and like it or not most aren’t using GStreamer on those platforms’ doesn’t compute, because most applications on those platforms are not using Phonon either. The argument is not about what applications use today, cause if that is the argument then people should just use DirectShow or Quicktime. But instead the argument is about what is the best way to write a cross platform multimedia application today. And here I think GStreamer is a better option in most cases, especially the cases when your application is not using Qt.

Aaron also repeated the oft heard argument that Phonon is for KDE about not repeating the mistakes of Arts. And I guess this is one of the big differences in perception. Because for Aaron for KDE to have used GStreamer would have been repeating Arts, but for me Phonon is repeating the Arts story. Back in the day if one dared to take issue about any of the wonderous claims made about Arts one got tons of comments about just being partisan and ‘hating Arts or hating KDE’. Kinda like how it is today when one tries to point out that Phonon is not the universal wonder solution that Aaron likes to paint it as.

So to make it clear, I am not arguing that using Phonon is the biggest mistake you can ever make in any possible situation. I am taking issue with the promotion of Phonon as a better solution than just using GStreamer for a lot of specific use cases including cross-platform development. The strength of Phonon lies in providing a familiar API to existing Qt developers, giving them access to some limited multimedia functionality, but in terms of promoting itself as a generic cross platform multimedia development API it falls down, Phonon is attempting to do what wxWidgets tries to do for GUI components, and I never thought it worked very well for wxWidgets either.

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:

Arrived in Istanbul on Friday in preparation for GUADEC. Had a great time so far visiting the main attractions like Haga Sofia, The Blue Mosque, the Sultans palace and the underground water cistern. Last night Wim, Tim, Edward and myself went out to met Jan and Jaime for some food. A lot of other people ended up there too and it was nice seeing people again. Turns our there is a really nice street close to the Golden Horn Hotel which provide you with a lot of pillows to sit on as you see in the picture below:

I got myself a Lumix TZ4 camera just before leaving the UK as I wanted to be able to take some good pictures. Compared to my earlier cameras this camera is a huge step up. 10x optical zoom makes a world of difference in terms of what kind of pictures I can take. Was also very happy last night to find that GStreamer is able to play the .mov files generated by the camera easily. Some time ago now we did a call for people to provide us with camera video files, and it seems that work has paid of in handling a lot of the semi-standard mov files that cameras create.

Today we have gathered in front of our hotel for a little impromptu GStreamer summit. So far discussion has been about Git and the possibility of migrating to it from our current CVS repository. While using CVS do give us an air of age, wisdom and venerability there is an inkling in the GStreamer community that we might be using a slightly outdated version control system :)