One request we get often here at Collabora Multimedia is from people using GStreamer in the embedded and mobile sector and are looking for ways to stream over RTSP with GStreamer, often in combination with various kinds of transcoding and proxying functions. Due to this we have launched a new project, the GStreamer RTSP server. This server is written by GStreamer maintainer Wim Taymans and is tightly based on the RTP infrastructure in GStreamer that he has been working on for quite some time now.

It is a server written in C which can stream any GStreamer supported file over RTSP using any of the wide range of RTP formats supported by GStreamer. It also allows you to take any RTSP or HTTP stream and proxy it onwards over RTSP. The screenshot below is of totem playing a RTSP stream of the Max Payne trailer from Apple’s website. The stream offered by Apple is a normal Quicktime http stream, but our RTSP server repackages it and retransmits it over RTSP on my local network on the fly.

The code is currently only available through a git repository which you can grab using this command:
git clone git://git.collabora.co.uk/git/gst-rtsp-server.git gst-rtsp-server

The reason there is no formal release yet is due to early stage the software is in, while it works it is not very user friendly yet, with media paths having to be edited and compiled in with the server for instance. But for those looking for a RTSP server solution using GStreamer, which is suitable for putting onto embedded and mobile devices, then it might be enough to get you started and of course we at Collabora are available to offer assistance for those who want it. One hope we have is that this code will help people doing DLNA servers support the mobile profile of that specification for instance.

We also plan on moving the code into GStreamer’s code repository once that is migrated to git from CVS.

For a long while we had discussions here at Collabora Multimedia about how to push Pitivi forward at a more rapid pace. While Edward has been working on it as time allows, we came to the conclusion that if the Linux desktop was going to have a nice and easy to use video editor any time soon, we needed to do something to increase the pace of development significantly. We have several efforts under way to achieve this and I will announce the first one today:

We just hired Brandon Lewis for the sole purpose of doing Pitivi development. Brandon has been working on Pitivi for a long time now, having gotten involved during last years Google Summer of Code. He brings a lot of python development skills to the table and will let Edward focus his currently limited Pitivi hacking time (we hope to change this too soon :) on Pitivi related improvements in GStreamer and Gnonlin.

Brandon job will be making sure all the features available gets exposed in the user interface and that the user interface is intuitive and easy to use.

So Brandon, welcome to the team and lets make Pitivi rock!

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: