I am very happy to announce the release of Transmageddon 0.7. This release of my simple to use video converter got some major new features. First of all it now sports full i18n support, thanks to a patch from Łukasz Jernaś. We only got Polish and Norwegian translations so far, but hopefully once I move Transmageddon into GNOME git, interested translators will find the infrastructure in place for easily adding more.

The second major feature in this release is that I did away with hardcoded element names. Instead I query GStreamer for possible plugins which I can then access using the GStreamer caps format. For instance to get mp3, instead of hardcoding the ‘lame’ element, I am now able to ask for a encoder doing ‘audio/mpeg,mpegversion=1,layer=3’ and GStreamer will provide me with any element I might have which supports creating mp3 files. The code for this is all in codecfinder.py.

This also let me enable another major feature, which is hooking into the automatic codec download system for GStreamer, now available in most major distros.

As you might notice in the screenshot, Transmageddon now also displays the height and width of the video you are transcoding. Apart from the minor informational value this is not very useful atm, but it was a prerequisite for me to be able to add videoscaling support, which is my next step.

I also came across another python/gstreamer transcoder the other day, Arista. It got a pretty nice feature set already, and both application and website is a bit more polished in terms of looks than Transmageddon :) One thing I want to try to share with Arista is the XML device profile format, so that we can start building a database of profiles that can be shared between a lot of different applications.

Anyway, I hope people will try out this version of Transmageddon and let me know what you think. I am especially curious to hear how the automatic codec downloading stuff works for people.

Coherence nominated
Finally I would like to congratulate Frank his Coherence DLNA framework for being nominated to the 2009 Free Software Trophy in the multimedia category. Best of luck for the start of June when the winner is announced.

Entropy Wave launched
David Schleef who most of you probably know as a long time GStreamer contributor and the lead developer behind the Schrodinger Dirac library got the website up for his new company, Entropy Wave. David aims at offering various codecs and services for GStreamer and multimedia in general through Entropy Wave. At Collabora Multimedia we are looking forward to working with David and his company going forward. Lets just hope we can manage to get our own new website public soon :)

In case people are wondering if I have stopped working on Transmageddon, I haven’t. It is just that I suddenly reached a point where I couldn’t google and look at other peoples code to do what I wanted so I have been stuck in a mode for some time now with writing small python applications to test various APIs and try to figure out who I can avoid harcoding the element names of my muxers and encoders. That combined with being in San Fransisco for a while to attend the CE Linux and Linux Foundation Collaboration summits has left progress slow.

Had a bit of a breakthrough today though when I finally managed to get an element factory to report back to me the GStreamer equivalent of a mimetype it supported as output, so hopefully I can sort out this snag and continue forward again at a brisker pace.

I am also still working on getting more GStreamer related interviews published on gnomedesktop, but the two people I am trying to interview currently seem to have engaged in a competition to see who will be the slowest to get back to me :)

So Google has made public the projects that will go forward in the Google Summer of Code this year. In the GStreamer community we are very happy with the five proposals we ended up being able to greenlight in the end.

So this year we will aim at getting a MPEG PS muxer and improve our MPEG TS muxer, we also have a project to create an ASF muxer and ASF payloader plugin. With these in place we will pretty much have muxers for all the important formats out there available GStreamer.

We are also aiming at pulling more plugins into the GStreamer sphere with the addition of wrapper plugins for LADSPA version 2 plugins and Avisynth filters.

And last, but not least we got a project to do MHEG support in GStreamer. So people here in Britain for instance will be able to use a GStreamer based DVB application and be able to ‘press the red button’ to access the interactive features of DVB.

A big thanks to everyone who applied to this years summer of code, and I sincerely wish we could have greenlighted more of the applications. For those who did not get accepted feel free to grab me on IRC (uraeus) or send me an email and I will try to provide you with some more details if you are interested on why we didn’t choose your specific application to go forward. In general we looked at factors such as viability (how likely we thought it would be the proposal was successfully completed), importance to GStreamer (whether the project would help bring even more developers and users to GStreamer) and sustainability (we considered to what degree the projects would continue to be valuable after the SoC was over, even if the student decided to disappear into the void). The last point actually was one of the biggest proposal killers as we ditched a lot of projects based on the fact that without continued heavy maintenance after the SoC they would bit rot really fast.

Released a 0.6 version of Transmageddon today. The user noticeable new feature is support for outputting Quicktime, MPEG4 and 3GPP files. Internally that was actually a big hurdle with some major code reorganisation and me learning about multiple new concepts on the way. A big thanks goes to Sjoerd Simons and Tim-Philipp Müller, because I don’t think I would have managed to sort out the state change stuff in the code without their help and input.

Would also like to thank David Love for sending in the first patch for Transmageddon. It switches the UI over from using radioboxes to drop down lists instead. This was also something quite a few people suggested to me both in person and in the comments to the previous blog. I haven’t merged the patch yet as I am still very uncertain about if I want to do this change. I like the visual feedback you get from seeing the radioboxes getting made sensitive/insensitive bases on container format and drop down lists simply do not give me or the user the same level of feedback. So I think I keep the current UI at least until I get moving on the output profiles.

One thing I realized after adding 3GPP as a container format is that we do not have a good AMR encoder and decoder in GStreamer. The reason for this is mostly that the people who most care about AMR are mobile phone people and even though a lot of them use GStreamer today, they got their own proprietary AMR plugins they use. So to alleviate this I added writing AMR encoder and decoder plugins to our suggested projects list for this years Google Summer of Code. One could probably take the code in Android for AMR and refactor it into a set of GStreamer plugins. Be aware though that Edward tells me that the current Android codec code is very ugly, so be prepared for some spring cleaning if you apply for Summer of Code to do this. This task would even have a bit of synergy effect with Edwards effort of porting GStreamer to Android.

One thing I should mention is that I have been spending a lot of time looking at the code of OggConvert when working on this version. It is really nice code and it does stuff correctly. So far it has always been to complex for me to understand when I look at it, but once I have managed to learn enough by trial and error to get my own code to work, I tend to notice that I am doing more or less the same as OggConvert :)

Just wanted to remind all interested students who want to do a Google Summer of Code project to apply as soon as possible. You need your proposal to be submitted before April the 3rd to have a chance to be accepted, but as always the sooner your apply the better. Be sure to look at our guidelines for how to write your GSoC application and if you need some ideas for what to propose look at our ideas list.

Also let me also point you to my earlier blog post about what kind of Google summer of code project to do. The key factor of success is motivation, which in turns depend on having chosen a project you think is fun and which challenge you enjoy.

So January 2008 I posted blog entry in which I expressed the hope for an easy to use GStreamer transcoding application.
Well after so much time gone by and still none on the horizon I decided to bite the bullet myself and make a go for it. Only problem was that I didn’t have either a clue about programming or about how glade works. But upon skimming through the book Learning Python at Robs place I decided to try to do it.

In addition to the book there was two online resources who helped to make things connect for me. The first was this tutorial on how to make user interfaces with python and glade and Jono Bacons blog about getting started with gstreamer and python.

My first application from playing with those tutorials was a GTK button which when you pressed it played a beep sound using the audiotestsrc element in GStreamer. But I kept at it and after having now spent about 5 days on learning the basics I am pretty happy with the progress I have made
on my application named ‘Transmageddon’:

The application is still very early stage, but if you got all the GStreamer plugins modules installed it should work. I even posted Fedora RPM on the very basic Transmageddon homepage.

There is a lot of coding stuff that needs fixing behind the scenes to enable more features and make the application more robust. My big long term goal is to add support for profiles to the application, so you choose Nokia 810 or iPod or PSP and the application chooses the container format and codecs for you and also rescale the video if needed to be optimal for that device. For those who care I have a fairly detailed Todo list here.

Any feedback people want to provide please feel free to email me or post a comment on this blog entry, just make sure to read the Todo list before suggesting stuff ;)

I also hope to write some blog entries explaining how I did some of the stuff in the application as I don’t think there is a very simple tutorial on how you do a progressbar with GStreamer for example.

So GStreamer is also this year part of the Google Summer of Code. This means all multimedia interested students should start thinking of a cool project they can do for or with GStreamer. For example if you are interested in learning more about multimedia formats I suggest writing a GStreamer muxer or demuxer for a missing container format (although the list of truly interesting container formats we do not have good support for is getting rather short). Or if you are more interested in networking protocols maybe you could do a project on writing and implementing an RFC for how to do Dirac over RTP? Or if your interest is mostly in the application layer you could write or enhance an existing GStreamer application or development tool. We got a webpage with some information about what you should consider when applying for a GStreamer summer of code project which includes a list of GStreamer SoC ideas, but be aware that these are just that, ideas, most of them are not fully developed project ideas, so be prepared to bring your own vision and ideas to the table to take them to the finish line :)

Students can start to apply on the 23rd of March, hope to see your applications!

As mentioned before getting MXF support in GStreamer and Pitivi is a priority for us here at Collabora Multimedia. In that regard Sebastian is still working hard on providing GStreamer with top notch MXF support. The demuxer is mostly done these days, handling the testclips we have decoders for, so he is currently focusing on getting an initial muxer ready. He hopes to commit the first version of this muxer to gst-plugins-bad any day now, but while he cleans up the final bits of code, it would be great if people grabbed the generated MXF sample files and tried them with any MXF supporting application and/or library they might have around. If you are not able to load any of the files please let us know through our bugzilla and please include as many details as possible about your application and platform.

Another thing we are looking at the moment is getting some specifications written to put free codecs inside MXF, like Vorbis, Theora, FLAC and Dirac.

Over the last few months a lot of effort has been put into getting Empathy up to scratch as not only a chat client, but also for use as an audio and video conferencing client, the long term goal being to support all the major instant messaging based videoconf systems in addition to stalwarts such as SIP. Being free software enthusiasts we have of course been especially keen on combining the open protocol of XMPP, used by Jabber and Google Talk, with a set of free video and audio codecs, namely Speex for audio and Theora for video.

Theora RTP being a bit special meant we had to wait on the integration of Farsight2 into Empathy for this to work, but now using our eminent stack of GStreamer with Farsight and Telepathy, this now works on my computer as shown by the screenshot above. It requires the very latest versions of everything, and there are still some bugs that need hammering out, but all in all we are very close to reaching the goal. So once the relevant versions of Empathy and the underlying libraries have trickled out into the distribution ecosystem over the next months, we will finally have fully working XMPP based Speex+Theora video conferencing working out of the box between all Linux and Unix systems. Empathy supports doing audio calls with Google Talk, and video calls with the Nokia N810 devices over XMPP if you install the relevant H.263 encoders and decoders for GStreamer. We’re still working on support for the new GMail Video Chat plugin, which initially supported H.264 SVC, although even though it now also supports H.264 AVC we can’t get it to decode streams created by the x264 encoder.

One of my favourite books series currently is Ice & Fire by George R.R. Martin. Due to like many other fans waiting on the upcoming book in this series I check his blog from time to time for news. George Martin, like a lot of other people today is quite active online and thus interact with his fans through his blog and through email. In some way he is as available to the readers of his books as an open source developer is to the users of his or her software. And it is not always fun as George recently pointed out. As it turns out George experience is in no way unique and another writer, Patrick Rothfuss, did the following hillarious cartoon for his blog, which explains exactly how it these things feels for the author.

I think a lot of open source developers can recognize some of the stuff in those cartoons, the internet seems to be one of the best methods humanity has ever created for spreading negative energy around quickly and easily. So while less people bother emailing or blogging or commenting on a forum about their favourite open source tool compared to best selling books, the effect tend to be the same. The barrage of negative feedback drains the developer of energy and instead of encouraging him or her to bring out a new version to fix issues, in fact such feedback cause the developer to do less than they otherwise would.

I guess open source developers tend to be quite hard skinned in general, but I do remember for instance Arlo Rose, the guy who did the original graphics for Nautilus back in the day, saying he stopped being involved with the Linux community partly due to all the negative comments he saw on footnotes.

So a word for the road, if you want to achieve something in terms of dealing with anyone, be it the author of your favourite book or your favourite piece of software, your chance of doing that is much much higher if you stay positive.