Transmageddon 0.24 is out

So I finally released an official new Transmageddon release today, 0.24. In addition to the changes from the 0.23 test release (GTK3 and GStreamer 1.0), this new version uses Python 3 and got some fixes for improved handling of missing codecs. Let me know if its giving you any trouble.

Next step is looking into how to implement some or all of the new interface design from Gendre Sébastien.

GStreamer 1.0 Released

So this news is a couple of days old now, but I wanted to write a blog entry about the exciting release of GStreamer 1.0. When we released GStreamer 0.10 about 7 years ago we did not expect or plan the 0.10 series to last as long as it did, I think if we had it would have been called 1.0 instead of 0.10. Our caution back then was that 0.10 was a quite revolutionary version with the core of GStreamer extensively re-designed around effective use of threads and thread safety. The new GStreamer 1.0 is more of incremental improvement, cleaning up the API and making doing things modern systems expect easier and more straightforward. I think a lot of the work that went into 1.0 could be said to be based on cleaning up the awkward APIs that can evolve as you are not able to change anything existing, just add new stuff that does not affect the old.

That said there are a lot of major improvements to be seen too, with the list that Tim-Phillip Muller put together for the GStreamer website catching the major items:

  • more flexible memory handling
  • extensible and negotiable metadata for buffers
  • caps negotiation and renegotiation mechanisms, decoupled from buffer allocation
  • improved caps renegotiation
  • automatic re-sending of state for dynamic pipelines
  • reworked and more fine-grained pad probing
  • simpler and more descriptive audio and video caps
  • more efficient allocation of buffers, events and other mini objects
  • improved timestamp handling
  • support for gobject-inspection-based language bindings

The list can seem a bit technical and dry, but there are a lot of things that will benefit users here once plugins and applications start taking advantage of them. For instance the more flexible memory handling will improve performance when for instance running GStreamer on ARM boards like a Panda board or a Raspberry Pi. The changes will also make it a lot easier to write plugins and use plugins on PC platforms which use the GPU for decoding or encoding and that use OpenGL for rendering the playback. These things where possible with 0.10, but they required a bit more special casing and more code in the plugins and a bit more overhead in setting up the pipeline. If you want a great introduction to what is in this 1.0 release I recommend the keynote by Wim Taymans about GStreamer 1.0 and the GStreamer Status report keynote by Tim-Phillip Müller which both talk alot about the new features and the possibilities they open.

I think that the biggest change for a lot of developers though will be if they are using a language binding for their application, GStreamer 1.0 is offering Gobject introspection bindings support, which means that most bindings from now on will be using that. For Python developers like myself that is a quite big change in API. On the other hand it also does mean that porting to Python3 has become very simple. For Transmageddon I simply ran it through the Python 2to3 script and it just worked.

There are a lot of contributors to this release, and I would love to thank them all, but I think Wim and Tim also deserve a special mention as I don’t think there would be a GStreamer 1.0 without them. Wim has of course been the GStreamer maintainer for a long while and he shepherded this release from the beginning when he was the only developer working on it. Tim has been the GStreamer release manager for a long while now and are doing a wonderful job, fixing a gazillion bugs and making sure we regressions are not allowed to creep into GStreamer releases. He ended up doing a lot of heavy lifting to get the final GStreamer 0.11 test releases and the final 1.0 out the door. So a big big thanks to both of them.

Another person I want to give an extra kudos to is Bastien Nocera who have done a lot of working porting GNOME applications to GStreamer 1.0, there is and was of course a lot of other people involved in that process too, but Bastien did an incredible job working through that list and writing patches to port many of them over.

What I am really looking forward to now is the release of Fedora 18 as I think it will be the first chance for a lot of users and developers to try out all the great work that has been done on GStreamer 1.0 and porting applications over to it. I am personally targeting Fedora 18 with Transmageddon, doing my current testing and development on a F18 system, making sure things like the PackageKit integration is working smoothly.

A great service for Fedora and Humble Bundle

I think most people are aware of the Humble Bundle which have been releasing a range of cool and great games on Linux since they started up. The games though has usually tended to be distributed as a tarball and doesn’t automatically integrate itself into your Fedora system like you would like. Well thanks to the cool effort called Mumble RPMS you can now turn all those tarballs from the Humble Bundle into nice RPMS for Fedora. So a big thanks to the author of Muble RPMS for doing this work!

Transmageddon test release available

I have made a first test release of Transmageddon today, 0.23. It is the first release depending on GStreamer 0.11/1.0 and GTK3. It also features a little bit of GNOME Shell and Unity integration in the form of a notification message when its done transcoding and the menu has been moved into the shell. You can find the test release in the pre-release directory on linuxrising.org. Let me know if you have any issues so I can try to fix them before I make a final stable release when GStreamer 1.0 is released. Be aware that you want the GStreamer 0.11 releases from yesterday to try this release.

New GTK3 and GNOME shell friendly Transmageddon

The above screenshot is taken on my Fedora 18 test system!

Bye bye Slicehost

Finally closed my slicehost account today and deleted my slice. I set it up a few years ago to host linuxrising.org and some misc other sites I was planning. I also hosted my own private email server on it.
In the end I think it just ended up being an overkill solution for what I really needed, but I thought it was a good experience to run my own server on the net. Anyway, Slicehost got bought by Rackspace some time ago and I kept getting these emails telling me to migrate to Rackspace and the rackspace priceplan. I took it as the kick I needed to get a hosting setup more suited to my actual need and save quite a bit of money in the process. So now the site is just hosted on my domain registrar as a simple website and the email I moved into Google Apps. At this point I am just happy I don’t have to fiddle with postfix and dovecot config files anytime in the forseeable future :)

While the DNS records etc. gets updated you might have some issues with the Transmageddon website, but it should hopefully be sorted before Monday.

New Transmageddon release should follow shortly after that.

Interested in joining the Red Hat Desktop team here in Brno?

So I am looking to hire two more people to join our team. So if you ever wanted to join the worlds leading Linux company and work on making the desktop rock this is your chance.

The first position I have available at this point is for a Webkit developer. We have a lot of applications these days in the desktop relying on Webkit and we need someone in the team who can both work on making sure our webkit packages in Red Hat Enterprise Linux(RHEL) and Fedora are kept up to date, but also work with other desktop team members with application integration issues and so on. You will also have time to work upstream to help push Webkit and especially WebKitGTK+ forward.

The second position I am looking for a candidate for is working on the Evolution email client. Evolution has been with us for quite some time and thanks to the effort of the current development team a lot of important infrastructure work has been done, like a new accounts system and the soon to be finished migration to Webkit. But we want to make sure Evolution keeps progressing and have the features it needs to be the primary email client for both Fedora and RHEL users. In addition to the work on Fedora and RHEL this job will include working on upstream Evolution and upstream libraries used by Evolution, such as WebKit, OpenChange and Kolab.

Also beyond these jobs Red Hat is looking for more people with Python development experience to join our 500 strong team here in Brno, Czech Republic, so even if the two jobs above is not your cup of tea, but you do have Python experience and joining Red Hat in Brno is something that could be of interest to you, please get in touch and I well put you in contact with the right people here. We are looking both of all levels for these python jobs, so both people fresh of out Uni or with many years of experience should get in touch. Be aware that these python jobs are not in the Desktop team though, but in some of our other cool teams here.

So if any of the above is of interest to you please contact me on cschalle(at)redhat(dot)com.

Does GStreamer scale?

Sometimes we get questions about if GStreamer can scale to handle really complex pipelines. Well thanks to Kipp Cannon and his talk at this years GStreamer Conference we know have the answer.
They are part of a research project called LIGO which is doing researching gravitaional waves, which can be described as ripples in the fabric of space-time. Kipp is part of the LIGO Data Analysis Software Working Group which has develop a what the call gstlal.

P.S. You might want to download and view the following with an image viewer application as the browser struggles to render it in any detail :)
Anyway, to make a long story short, their pipeline looks something like this image (created with the built in graph dump functionality of GStreamer using graphviz).

If you ever seen a bigger pipeline please let me know :) Also it should alleviate any concerns you might have about GStreamers scalability.

Gearing up Transmageddon for release

As we count down towards the GStreamer 1.0 release I been spending some free moments preparing the new Transmageddon version, today I re-enabled multipass encoding, removed the redundant xvid option (as we already do MPEG4) and polished the notification message a little. Tried to run through with as many codecs as I can, and so far they all seem to work perfectly with GStreamer 1.0. So hopefully a new Transmageddon release soon :)

I think I got everything that was there before the 1.0 port back again, but I wouldn’t be surprised if I have managed to miss a feature somewhere :)