Category Archives: General

Improved handling of files with multiple tracks in GStreamer

Posted on by

Thanks to Sebastian Dröge there is a new thing in GStreamer called streamid. It basically gives all streams inside a given file a unique id, making files with multiple streams a lot easier to deal with. This streamid is also supported by the GStreamer discoverer object. So once you identified the contents of a file with discoverer you can be sure to grab the exact stream you want coming out of (uri)decodebin by checking the pad for the streamid. The most common usecase for this is of course files with multiple audio streams in different languages.

From the output of Discoverer the stream id is really easy to get:
On the stream object you get out of Discoverer you just run a:

stream.get_stream_id()

On the pad you get from decodebin or uridecodebin the patch is a bit more convoluted, but not
to hard once you know how (there might be some kind of convenience API added for this at some point).

Before you connect the pad you get from the bin you attach a pad to it like this:

src_pad.add_probe(Gst.PadProbeType.EVENT_DOWNSTREAM, self.padprobe, None)


Then you in the function you define you can extract the stream_id with the parse_stream_start call as seen below:

def padprobe(self, pad, probeinfo, userdata):
       event = probeinfo.get_event()
       eventtype=event.type
       if eventtype==Gst.EventType.STREAM_START:
           streamid = event.parse_stream_start() 
       return Gst.PadProbeReturn.OK

I been using this code in my local copy of Transmageddon to start implementing support for files with multiple audio streams (also supporting multiple video streams would be easy, but I am not sure how useful it would be). Got a screenshot of my current development snapshot below, but I am still trying to figure out what would be a nice way to present it. The current setup will look quite crap if the incoming file got more than a few audio streams. Suggestions welcome :)

Transmageddon multistream devshot

Transmageddon multistream development snapshot

Python and libcheese, the simple way of dealing with camera devices

Posted on by

GStreamer does assembling advanced video application quite easy, in fact so easy that even I can write such an application in Python :) What I have had a lot more issues with is understanding how to deal with things like USB cameras and such. Well luckily the developers of Cheese realized this and created libcheese to help. libcheese is today used by Cheese itself of course, but also by Empathy for its camera handling.

Since I been thinking about adding some kind of video recording support in Transmageddon I wanted to test libcheese from Python. Unfortunately there was no Python examples available anywhere online, so I had write my own example :)
With some pointers from David King I managed to put the following python code together.

import sys
from gi.repository import Gtk
from gi.repository import Cheese
from gi.repository import Clutter
from gi.repository import Gst
Gst.init(None)
Clutter.init(sys.argv)

class VideoBox():
   def __init__(self):
    self.stage = Clutter.Stage()
    self.stage.set_size(400, 400)
    self.layout_manager = Clutter.BoxLayout()
    self.textures_box = Clutter.Actor(layout_manager=self.layout_manager)
    self.stage.add_actor(self.textures_box)

    self.video_texture = Clutter.Texture.new()

    self.video_texture.set_keep_aspect_ratio(True)
    self.video_texture.set_size(400,400)
    self.layout_manager.pack(self.video_texture, expand=False, x_fill=False, y_fill=False, x_align=Clutter.BoxAlignment.CENTER, y_align=Clutter.BoxAlignment.CENTER)

    self.camera = Cheese.Camera.new(self.video_texture, None, 100, 100)
    Cheese.Camera.setup(self.camera, None)
    Cheese.Camera.play(self.camera)

    def added(signal, data):
        uuid=data.get_uuid()
        node=data.get_device_node()
        print "uuid is " +str(uuid)
        print "node is " +str(node)
        self.camera.set_device_by_device_node(node)
        self.camera.switch_camera_device()

    device_monitor=Cheese.CameraDeviceMonitor.new()
    device_monitor.connect("added", added)
    device_monitor.coldplug()

    self.stage.show()
    Clutter.main()
if __name__ == "__main__":
    app = VideoBox()

The application creates a simple clutter window to host the stream from the webcam. So when you run the application it should display the video from the system webcam. Then if you plug a second webcam into a USB port it will switch the video feed to that stream. Not a very useful application in itself, but hopefully enough to get you started on using libcheese from Python. You can find the libcheese API docs here, they are for C, but Python API from Gobject Introspection follows it so close that you should be able to find the right calls. And remember for figuring out exact API names ipython is your friend :)

P.S. You need Cheese 3.6 installed to be able to use libcheese with Python, this version which will be in Fedora starting with Fedora 18.

LibreOffice coding at Red Hat

Posted on by

At Red Hat we are involved with a lot of cool open source projects. One of these is the popular LibreOffice productivity Suite, where we are putting in a lot of effort to make sure Red Hat customers and the community in general have a dependable and feature rich Office Suite available.

In addition to of course doing work to add features requested by Red Hat customers, the team focuses on helping build the upstream project and making sure we help push desktop integration forward.

In fact the work done by Caolán McNamara, David Tardon, Stephan Bergmann, Michael Stahl and Eike Rathke is making Red Hat a major contributor to LibreOffice. So to celebrate the success of our team so far we wanted to have some nice t-shirts made for this years
LibreOffice conference in Berlin to give the team. It would have added a nice little touch to a conference where Caolan did a talk about his cool widget layout work (*1), Michael did a talk about the migration of LibreOffice to gbuild, Stephan did a talk about API stability and Eike did a talk about collaborative editing.

Unfortunately the t-shirts came back late from the printer and thus missed the conference, but I will be sending them out to the team today so that they have them ready for the next LibreOffice event :)

RedHat LibreOffice team t-shirt

Anyway a big thank you from me to the team, they have been a pleasure working with since I joined Red Hat and I am looking forward to seeing what we will achieve over the next years.

Transmageddon 0.24 is out

Posted on by

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.

On the way to the GStreamer Conference in San Diego

Posted on by

Doing the last preparations for my trip to the United States. I got a few stops on this visit, starting with the Red Hat office in Westford. Looking forward to meeting with Jonathan and the team there to discuss our goals for the coming year and discuss what we can do to make Fedora and RHEL even greater.

The on Friday I am heading down to New York for a short visit to say hi to my good friend Ian, before flying onwards to San Diego on Saturday to attend the GStreamer Conference 2012. I think we have a great lineup of talks this week and I look forward to hanging out will all the other key GStreamer contributors again. So if you haven’t registered yet for the GStreamer Conference yet, make sure to do so and book your travel :)

The Future of GNOME

Posted on by

Having just returned from GUADEC and now having the desktop as my job focus I been thinking about where we are going and what to do next. Benjamin managed to get quite a bit of press for his abysmally negative post, but I think his mis-stated the situation quite badly. As Dave Mason said during the history of GNOME talk, we have more or less always feel threatned and felt at times that we had an insurmountable task competing against systems with a lot more developers available than we do. There are some dark clouds in the skies, no doubt about that, but when hasn’t there been in the 15 years of GNOMEs existence? For instance the current tug of war between the GNOME shell and Unity? We have been there before, with Ximian and Eazel pushing competing visions for the GNOME desktop back in the day. Major corporate backers leaving (Nokia) or being in trouble(Novell)? Eazel and Ximian again. GNOME being perceived as being Red Hat only? That was the exact story that was being pushed before Sun and Ximian came on the scene. GNOME 3 turning away users? Hey, I can tell you that the amount of flames we got for GNOME 2 easily beats the GNOME 3 flames.

But for each of those events in the past we ended up bouncing back stronger afterwards, and I suspect we will come back with a vengance this time too. The thing is a lot of things are actually going very well. First of all the are a lot more shared projects with a healthy amount of resources behind them these days. WebKit is a great example of a project of crucial importance to GNOME, but which we share with a lot of other projects and companies. Take LibreOffice for example, yes LibreOffice do not contribute a lot of git commits to the GNOME git respository statistics, but thanks to LibreOffice we have the best and most full featured Office suite ever available to our users. And thanks to Firefox and Chrome we have browsers available with world known brands. And thanks to GStreamer, which is on freedesktop, we have a world class multimedia framework available. Instead of having our own sound server like we did with ESD, we now share a top notch sound server with all linux systems in the form of Pulse Audio.

Back during the GNOME 2 development cycle the GNOME project took an active decision that we would try to reach out to more of these external projects and try to work with them to integrate them into the GNOME experience. And we have succeeded at that, which of course have the side effect that instead of having all that development happen inside GNOME, we have bigger more active GNOME friendly projects doing these things outside GNOME.

We also made a conscious decision to focus on draining the swamp, which meant that instead of trying to work around issues and come up with funky configuration options on the user interface level to deal with missing features and bugs in the underlaying system, we instead have tried working with and contributing to fixing things in the underlaying levels. This of course moves attention away from ‘GNOME’, because people then commit their new fixes to those underlaying systems instead of implementing 100 000 lines of workaround code to ‘GNOME’, I mean I still consider Lennart Poettering a GNOME hacker even though his current work isn’t on anything in the GNOME git repository. But that does not mean that GNOME does not benefit greatly from these improvements.

So as we have succeeded in all these goals, GNOME should be a leaner setup than it used to be, as we don’t have to do all the heavy lifting inside the GNOME project anymore and that is a good thing.

As for projects such as Unity, well personally I don’t mind them at all. I mean I always saw XFCE as being a strenght and benefit to GNOME as it brought more users and developers to the shared library stack, and there is nothing different with Unity. And yes, there are some unfortunate duplications which seems redundant even in the context of differentiation, like the GNOME Online Accounts and Ubuntu Online accounts split, but hopefully we can work together to resolve such things over time.

And as for taking the desktop to the next level I think the main challenge for GNOME is not inside the GNOME 3 desktop, but instead it is a question of if the open source community can come together around pushing things like the Linux OpenGL support forward and make sure we have a strong foundation for supporting games and improving visual effects in the desktop. I for one really hope that Valve’s decision to support Linux with Steam, and the success of the Humble Bundle games on Linux, will help rally support behind the efforts to get Mesa to support newer iterations of OpenGL and get the open source Nvidia and AMD drivers in shape. Microsoft has long ago abanndoned PC gaming in favour of the Xbox, lets see if we can make Linux fill the gap.

In general I am very optimistic about the future, the strenght of the open source ecosystem is not that we have more developers to assign to a given project at a given time than Windows or Mac, but no matter what they do we keep moving forward on all fronts, so while Apple and Microsoft focus on beating each other in the tablet and phone space, maybe the time is ripe for us to strenghten our positions in the server and desktop markets? I mean tablets and phones might be all the rage atm, and maybe they are bigger markets than the traditional server and desktop market, but the server and desktop markets are still huge and ripe with opportunity if we play our cards right. And if we can deprive Microsoft of things like their Office cash cow, then that levels the playing field all the more when we later take them on again in other areas.

GUADEC 2001 : Down memory lane

Posted on by

Came accross a photo album today from GUADEC 2001 in Copenhagen. It was the first GUADEC I attended (the second ever) and it was quite fun to see the photos again. Not to many photos of me in this gallery, closest I found was a group shot of myself and others listening to a gnome-print talk, where I can be spotted wearing a blue shirt, but partly covered by my friend Owen-Frasier Green.

An interesting photo though is this one, showing what was actually the first time the GStreamer team got together in person. In this photo you can see the blue shirted back of Wim Taymans, a head scraching Erik Walthinsen and a red cap wearing Zaheer Merali in addition to Wim’s girlfriend at the time, Michelle and the creator of aRTS, Stefan Westerfeld.

GStreamer team at GUADEC in Copenhagen

That said I think the best GStreamer photo from GUADEC in Copenhagen is still this one:

GStreamer team

Zaheer Merali, Wim Taymans, Owen Frasier-Green, Christian Schaller, Richard Boulton, Erik Walthinsen and Bastien Nocera

Anyway, I hope to see as many of you as possible at this years GUADEC in A Coruna, Spain. And who knows, maybe there will be some fun photos taken to look at 11 years from now :). I am especially looking forward to talks from my fellow Red Hatters here at the Brno office, I think we do a lot of cool stuff here in Brno and it will be good to let the world know about it.

Third week in Brno

Posted on by

Into my third Red Hat and Brno week now, Enjoying it a lot, but of course there is a lot of initial ramping up that needs happening and a lot of new faces and names to remember :)

As for Brno I am getting a bit more settled, got an appartment now that I can sleep in (although no furniture atm :), got myself a local bank account and a local phone sim and this morning internet was connected in the flat. So I guess I got the basics sorted for now :)

Looking forward to going to GUADEC next meet, to meet up with old and new friends and discuss plans for the coming year. It will also be my first chance to talk in person with many people from the Red Hat desktop engineering team since joining the company.

Things will be busy going forward though with a trip to Munich planned just as I return from GUADEC and then the GStreamer Conference at the end of August. Hoping to get the full program online within the next few days to allow people to see the great schedule we put together this year and book their trips to San Diego :)

GStreamer and the Google Summer of Code 2012

Posted on by

A big thanks to Google for making GStreamer part of also this years Google Summer of Code. For those of you who might not know the Google Summer of Code it is basically a program that lets you do a summer internship with various leading open source projects and get paid for it (if you are a student).

So if you always wanted to get involved with the GStreamer project and become a multimedia wizard, this is a great way to do so. The process is quite simply, you write a proposal for what you want to do (some possible suggestions and info found here) and submit it to Google when the application period starts on the 26th of March. Before then you would do well to speak with us on IRC or email lists to discuss your project to maximise your chances of getting selected.

We have a special Google Summer of Code student information page with information on what the GStreamer project specifically expects of you and your proposal. So for those interested that should be a good starting point.

Hope to see many great applications this year on either GStreamer itself or GStreamer using projects. And remember, you don’t have to feel bound by our suggestion list, if you have a great idea for a project that involves GStreamer, then we are happy to mentor it, just be sure to talk to us as soon as possible so we can let you know if we think it is a suitable Summer of Code project.

Collabora and Fluendo partners to invest in GStreamer

Posted on by

So working up to MWC in Barcelona this week we just announced a great new effort by Collabora and Fluendo around the GStreamer project. The goal is to ease adoption of GStreamer by making sure that no matter what platform you are in, there are well tested and easy to install and use binaries of GStreamer available. This means that not matter if you are running Windows, MacOS X or Linux, you will have a GStreamer SDK available to use. Eventually we will also cover various embedded platforms with this SDK, making it easier than ever to use GStreamer to create great cross platform multimedia applications. You can find out more about this effort by checking out the press release which have all the relevant details.