GStreamer maintainer Wim Taymans decided that having a brand new GStreamer 1.x series was only worth the effort if we also had some nice up to date documentation for GStreamer 1.0. So over the last week he has been going over the GStreamer Application Development manual making sure it is up to date and fixing all the code examples and adding new chapters even. So if you want to get into GStreamer development our introduction manual should now be a good starting point again!
Category Archives: Transmageddon
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.
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.
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 :)
Further hacking on Transmageddon
Heading off to Munich in an hour, but I been spending the morning trying to get git master transmageddon into shape. I think I am getting there as things works a lot better for me now. I even added a small feature, namely output to the notification area as seen in the screenshot below. Still very basic, but I hope to improve on it over the next few weeks. Also wondering if putting the Transmageddon nuclear mushroom in the notification area is a good way to keep users calm, or if they see the icon and start wondering if their system is suffering from a meltdown :)
Screenshot of Transmageddon with GNOME Shell notification
Transmageddon and GStreamer 1.0
Spent today working on Transmageddon, trying to get it ready for the GStreamer 1.0 release. It is frustrating going as I only get a little time here and there to work on it, and thus my memory of the code is not as good as it needs to be in order to do this efficiently. But I did in the end manage to file a couple of GStreamer 1.0 bug reports and restore the preset functionality to almost where it was before the GTK3/GStreamer 1.0 port.
When starting the port I disabled and removed a lot of code that in retrospect I still needed as I made some wrong assumptions about how encodebin would work. Going over the code now I also realize I have done some things in a quite stupid manner, or maybe the approaches made sense in the original codebase and just now over a series of iterations have become cludgy, anyway tried cleaning it up a bit, but didn’t have the time to really go over the code and make sure it looks nicer.
Of big issues remaining is that the missing codec functionality is still not 100% restored and working nicely, so a little more work needed there. But if you have all codecs already installed then things are shaping up quite nicely. So I think I am getting very close to having a GTK3 and GStreamer 1.0 version of Transmageddon at feature parity with the GTK2 and GStreamer 0.10 version.
Also thanks to Kalev Lember, Transmageddon is now in Fedora (the latest 0.10 based release) and he also made me co-maintainer of the package which I a very happy about. Hopefully this means that when Fedora switches to GStreamer 1.0 I can get the new Transmageddon up and running there quite quickly.
Also Gendre Sébastien plans on working on Transmageddon going forward and have already made some really cool mockups for a revamped UI. A lot of new features are planned, like the number one request I keep getting, support for setting up batches of transcoding jobs instead of having to do them one by one like now. My plan is to release a first version with the current UI and featureset for GTK3 and GStreamer 1.0, and then work with Gendre to implement his ideas. This new UI will also be more GNOME 3 styled, so hopefully it will provide users with something that feels more at home in the GNOME Shell and on Unity.
Plotting the future of Transmageddon
After a long period of very slow development of Transmageddon where most work has been in debugging issues with GStreamer 0.11 and porting existing features to GTK3 and GStreamer 0.11, I decided it was time to start thinking about where to go forward again. That said, there are still some issues with the new GTK3 and GStreamer 0.11 version, but I needed a break from just tedious porting/re-implementation work and instead start looking at some new ideas and features.
There are two major items I am thinking of. The first is what to do with the usecase of people just wanting to create a manual transcode. The goal of Transmageddon is to make transcoding simple, but the problem is that I am trying to simplify something that is inherently quite complex. The current user interface doesn’t really let you set a lot of things and I know that sometimes that will create files that doesn’t conform to the needs of the user, for instance a lot of settings are just kept from the original output file, like number of audio channels or bitrate used and so on. And many others just rely on the default values of the GStreamer elements used. I don’t want to try to support tweaking all of them through the user interface as there is no way of doing so without making the user interface either cluttered or filled with what will be for most people just gibberish. It is the problem I feel for instance Handbrake is suffering from, that yes it does let you set everything you could ever need, so it can create files that will be useable in some cases where the default user interface of Transmageddon falls short, but it also becomes a hard to navigate jungle for people. My answer to the need for that level of settings is and will continue to be the device profiles option, which I also have some plans for. That said there are a couple of features I do think would be useful to enable from the non-preset interface, like being able to resize the video, choose if you want deinterlacing or not and to allow you to choose stereo output for the audio and finally I want to allow the creation of transcoding queues, so you don’t have to wait until one transcode is finished before configuring another one.
The one special feature I already got in there, the ability to rotate the video, so that if your video for instance was shot with a camera held sideways, also felt rather arbitrary (it was put in there due to a very early bug request) to have exposed in the userinterface.
So what I have been experimenting with is as user interface which has an Advanced menu option in which you can set certain things and also enable certain extra options in the user interface.
Idea around adding an Advanced option in Transmageddon
So as you see in the screenshot above there are certain options which you just turn on/off and certain options which when enabled will add extra elements to the userinterface as shown below.
If I go down this route the question of course comes what options to put into this Advanced menu and also if I should make the settings persistent accross runs of Transmageddon or if I should let Transmageddon return to its default settings every time you start it.
Transmageddon with all advanced options enabled
The Transmageddon editor
Of course the Advanced menu will never become the solution to all transcoding challenges, the device profiles will still be that. But I realized that editing textfiles is not for everyone and it also makes creating advanced profiles a task for even fewer people than there needs to be. I don’t know how many people out there have made their own profiles, but the only one I ever got submitted was from Stefan Kost who made one for the N900. That is probably mostly due to lack of documentation of how to create profiles and where to put them, a problem I have been planning to remedy. That said I realized that maybe creating some kind of editor would be an even better solution, as it could provide a lot of helpful tools for profile creation and thus making it accessible to a lot more people. Which is why I been trying to prototype what such an user interface could look like.
Screenshot of prototype for Transmageddon profile editor
The interface above is what I got so far, and it is just a glorified profile viewer atm, but my hope is to make it fully functional and hopefully useful to people. One feature I really want to do is to allow you to take an existing video, have the profile editor analyze it and create a new profile that will allow you to replicate the settings of that file. So when you get a new phone or device the manufacturer most likely put a sample file on it, you can then load that sample into the editor and the editor will create a profile that matches it. This will enable you to transcode other files to that profile and thus make them work on your device.
That said this will be a major task creating this editor, because I want to to contain a lot of clever logic, so that it doesn’t just end up being a glorified text editor, but I will need to test and experiement to figure out what that logic will be and how to expose it in the user interface.
Anyway, I am hoping to hear back from the community on these two new things and playing with to hear what you think, both from a usability standpoint and of course ideas for how the features could work or should not work, and what you would need to make Transmageddon suit your needs.
Summary of GStreamer Hackfest
So as I talked about in my last blog post we had a great GStreamer hackfest. A lot of things got done and quite a few applications got an initial port over to 0.11. For instance Edward Hervey ended up working on porting the Totem video player, or rather trying to come up with a more optimized design for the Clutter-gst as the basis port was already done.
Another cool effort was by Philippe Normand from Igalia who put a lot of effort into porting WebKit to use 0.11. His efforts where rewarded with success as you can see in this screenshot.
Jonathan Matthew had flown up all the way from Australia and made great progress in porting Rhythmbox over to the 0.11 API, a port which became hugely more useful after Wim Taymans and Tim-Phillip Muller fixed a bug that caused mp3 playback not to work :).
Peteris Krisjanis made huge strides in porting Jokosher to 0.11. Although like Jason DeRose from Novacut and myself on Transmageddon he did end up spending a lot of time on debugging issues related to gobject-introspection. The challenge for non-C applications like Jokosher, Novacut, Transmageddon and PiTiVi is a combination of the API having changed quite significantly due to the switch to gobject-introspection generated bindings, some general immaturity challenges with the gobject-introspection library and finally missing or wrong annotations in the GStreamer codebase. So once all these issues are sorted things should look a lot brighter for language bindings, but as we discovered there is a lot of heavy lifting to get there. For instance I thought I had Transmageddon running quite smoothly before I suddenly triggered this gobject-introspection bug.
There was a lot of activity around PiTiVi too, with Jean-François Fortin Tam, Thibault Saunier and Antigoni Papantoni working hard on porting PiTiVi to 0.11 and the GStreamer Editing Services library. And knowing Jean-François Fortin I am sure there will soon be a blog with a lot more details about that :).
Thomas Vander Stichele, who also wrote a nice blog entry about the event, was working with Andoni Morales Alastruey, both from Flumotion, on porting Flumotion to 0.11, but due to some of the plugins needed not having been ported yet most of their effort ended up being on porting the needed plugins in GStreamer and not so much application porting, but for those of you using plugins such as multifdsink, this effort will be of great value and Andoni also got started on porting some of the non-linux plugins, like the directsoundsink for Windows.
Josep Torra from Fluendo ended up working with Edward Hervey on hammering out the design for the clutter-gst sink at the conference, but he also found some time to do a port of his nice little tuner tool as you can see from the screenshot below.
Tuner tool for GStreamer 0.11
George Kiagiadakis kept hammering away at the qtGStreamer bindings, working both on a new release of the bindings for the GStreamer 0.10 series, but also some preparatory work for 0.11.
In addition to the application work, Wim Taymans, Tim-Phillip Müller and Sebastian Dröge from Collabora did a lot of core GStreamer clean ups and improvements in addition to providing a lot of assistance, bugfixing and advice for the people doing application porting. All critical items are now sorted in 0.11 although there are some nice to have’s still on the radar, and Wim plans on putting out some new releases next week, to kickstart the countdown to the first 1.0 release.
As for my own little pet project Transmageddon, it is quite far along now, with both manually configured re-encodes and profile re-encodes working. Still debugging remuxing though and I am also waiting for the deinterlacer to get ported to re-enable deinterlacing in the new version. For a screenshot take a look at the one I posted in my previous blogpost.
