So I’ve been spending some time talking with Daniel G. Taylor of Arista transcoder fame and I think there is a good chance we will be collaborating quite a bit going forward. Neither Transmageddon or Arista will be going away as separate projects, but we will collaborate on many features and the focus of Transmageddon will change slightly.

Daniel plans on making sure Arista works on latest Ubuntu releases, which means Arista will be the transcoder which actually works with what people have out there. Transmageddon will on the other hand
track GStreamer git master quit closely as I try out and help mature various GStreamer features. Of course as soon as these features matures and starts being shipped in the GStreamer versions shipped by distributions then Arista will start using them too.

There are a range of issues where I think this model will suit all our needs fine. First of all I worked quite a bit on a plugins based on caps system in Transmageddon 0.7 instead of using specific element names. Daniel wants this for Arista too, but until we get things like bug 580005 in GStreamer resolved and GStreamer versions with this change shipped by distros then of course it will break functionality to use the plugins from caps system.
So I will track GStreamer git and use whatever we have there, and Daniel will look to see when the distros ship this stuff to decide when Arista picks it up.

Another feature where this will come into play is presets. Daniel and I will work together on the presets stuff, figuring out what needs to work on the GStreamer level using the GStreamer element level preset system and what will go into a higher level device definition file, based on the XML files Daniel currently ships with Arista.

Arista has also been switched over to the LGPL(v21) starting from todays Arista 0.9 release to ease code flowing back and forth between Transmageddon (which is already LGPL) and Arista, and at the same time we hope to lay the foundation for a python transcoding library that can be used by stuff like Conduit. By defining this API hopefully we can also help establish what would be a useful C API for a GStreamer encoding/transcoding API.

Btw, I released 0.8 of to Transmageddon today, mostly containing some bugfixes. MPEG4/Divx5 encoding should work again for instance and xvid support is also added.

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.