Supporting Pitivi

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!

Syndicated 2008-10-09 10:18:51 from Christian Schaller

Totem BBC plugin

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

Syndicated 2008-10-08 16:40:52 from Christian Schaller

Updates on cool GStreamer happenings

Axis and GStreamer

Axis got a new camera out these days called the Axis P3301. Axis is well known for having what is probably the best network camera’s on the market and this new beauty is especially nice as it uses GStreamer internally. It also supports Avahi, so you can get access to its services through avahi enabled applications, hopefully a feature we can get supported in Totem so you get access to these kind of cameras in your network very easily. Wim got gifted one of these by Axis while at their office in Sweden, which we got up and running at the Collabora Multimedia office now. Axis also got a video server, the <a href=”http://www.axis.com/products/cam_q7401/”>AXIS Q7401</a> which also use GStreamer internally.

Jokosher

Jokosher is making great strides forward currently too. They did <a href=”http://www.jokosher.org/”>their 0.10 release</a> a little over a Month ago and today Peteris Krisjanis told me that they just landed support for multichannel soundcards, which has been a major missing feature for a lot of potential Jokosher users. The mutichanel code is currently hosted in this branch on launchpad, but it will of course move into head once it gets stabilized.

Pitivi

Things are also moving forward with the Pitivi video editor these days. Edward recently merged the two Google Summer of Code projects that had been happening over the summer and also switched to the so called advanced timeline view to be the default in Pitivi. Thanks to Serat’s work there is now a structure in place in Pitivi for handling live sources, like webcams or DV cameras for instance. The simple timeline feature has also been dropped now as it turned out to be a lot less useful than we originally envisioned. So going forward the focus will be on making the previously named ‘advanced’ timeline userfriendly and easy to use instead. We will have some further cool Pitivi related announcements coming soon

Collabora Multimedia

We had our first ever full meeting of the Collabora Multimedia division over the last few days in Barcelona. It was the first time Wim, Edward, Tim, Mark, Sebastian and myself where all together. It was both a social event to get to know eachother, but also a good chance to discuss various technical issues. For instance Tim and Edward managed to solve a painful python threading issue we have been experiencing in a current project we have been doing together with Canonical and the BBC, which is writing a Totem plugin to enable viewing of various BBC content easily through Totem (as mentioned in the Ubuntu beta release notes. The plan is to push this plug-in upstream also, so that everyone using Totem can get it.

Syndicated 2008-10-03 13:55:44 from Christian Schaller

The arguments for using GStreamer

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.

Syndicated 2008-09-26 11:23:38 from Christian Schaller

In the land of silly arguments

Seems Lennart started a bit of a debate with his Linux Sound layers blog post. Not all the reponses has been as enlightened though. For instance Aaron Segio managed to make me laugh with his argument for why Phonon was a good alternative for non-Qt applications:

“Phonon is also more than just an option for Qt apps: you’d be making a huge mistake not to use it. You see, Phonon gets you equal and native support on Windows and Mac as well without the user having to install, say, GStreamer..”

Really? Wow, I would never have thought that if you use something instead of the other you wouldn’t need the other…an absolutely brilliant deduction. While we are at it lets point out that if you install Firefox you do not need to install Opera, cause you already got a web browser!!

GStreamer is already used by cross platform applications such as Songbird and SyncTV. And Songbird is using the native codecs provided by DirectShow and Quicktime where available.

So in a celebration of self serving arguments: So if you just use GStreamer you get equal and native support on Windows and Mac as well without the user having to install, say, Phonon…

Syndicated 2008-09-25 15:51:57 from Christian Schaller