GSoC week #8 (kcall) – writing Gstreamer bindings for Qt and more…

This week I wrote some exciting (for me) code. Last weekend, while playing with gstreamer, I had this crazy idea to write gstreamer bindings for Qt. So, I started writing it for fun, outside the scope of kcall. It took me about one day to write something usable and I was really excited. Then, I remembered that some days ago, bradh in irc had told me that it would be possible to use solid to autodetect audio/video devices for gstreamer. Being excited with the bindings, I thought about making one library with the 1-1 gstreamer-Qt bindings and one extra library with extra stuff, like device autodetection using solid. So, I started writing this new library as well. I developed those two libraries for about 4 days and I reached a point where they were usable for the purposes of kcall. So, I merged them in kcall and rewrote the part of kcall that handles audio/video streaming to use them. At that point, I also wrote a small telepathy-farsight Qt wrapper (libqtpfarsight), mostly to provide a sane API for it (as the original telepathy-farsight API is really bad) and not to get rid of GObject stuff, but eventually I achieved both. So, now the core kcall code uses only Qt, the GObject ugliness is hidden in the libQtGstreamer and the libqtpfarsight libraries and I have device autodetection using solid😀 I think that was worth the effort, although it doesn’t offer any significant functionality to kcall.

And to add to my excitement, there was already interest for my bindings by one guy who is writing a plasmoid that uses a webcam to take photos. He couldn’t use phonon because phonon has no support for video input (yet?), so he started writing it with gstreamer and so he was interested about my work, which he already has started to use. I’m really happy to see my work becoming useful for others:)

Today I spent my day doing debugging, trying to understand why kcall does not receive correctly video from the remote end. I still haven’t reached the answer and I’m really disappointed because everything in the code and the gstreamer logs looks perfect.😦

Sending video is not implemented yet, but with the code as it is now, it is a matter of about 10-20 lines of code to add support for it. I will definitely do this in the following days, possibly tomorrow. I am also going to write a KCM for configuring device preferences, which is mostly done, as the library I mentioned above with the extra stuff that sit on top of QtGstreamer, already has a DeviceChooser widget, which can be used for selecting devices and has also support for saving and loading the selected device using KConfig😀 Next weekend this will hopefully be over, and I hope I will also have solved the strange bug regarding receiving video.

The only thing that makes me sad now is that this week of coding essentially sent to the trash the code I wrote two weeks ago, which took me some time to write, but at least I know it was self-educating.

27 thoughts on “GSoC week #8 (kcall) – writing Gstreamer bindings for Qt and more…

  1. Hey man really appreciate your effort to develop a decent voip applications in KDE…do you think you will help kopete team with regards to voice and video. I personally think kopete seems to have stagnated in terms of their development in this arena.

    1. My mentor is working on porting kopete to telepathy. When he has finished the port, it will be as simple as adding a button with some extra ~10 lines of code to support making audio/video calls with contacts in there, using kcall’s user interface. This is the advantage of the telepathy framework, that all components are independent of each other, but they can be combined together to do cool stuff.

    1. Not possible. I’ve told this many times before, I am using the farsight library to handle audio/video streaming over the network and this library is based on gstreamer. I can’t use anything else apart from gstreamer to provide it with data. And besides, phonon is not good enough for this kind of work imho. Some backends have more capabilities than others, which means that if phonon is extended to support audio/video capture, some backends will support it and some others won’t, which will essentially mean that different apps will require different backends and that’s a mess… For example, the gstreamer backend is possible to support audio/video capturing, encoding, decoding and many other cool features, but the xine backend can’t. Xine is only a player, while gstreamer is a powerful multimedia framework. And apart from all that, I like Gstreamer:)

        1. It’s not that nobody cares about phonon, it’s that *I* don’t care. There is a difference…😉 Now if phonon doesn’t have people to work on it, that doesn’t surprise me. This is happening with most of KDE… But iirc, you are working on phonon, so we *do* have people working on phonon😉

  2. I know phonon doesn’t support capture, are you going to make implement capture in phonon or use something else for kcall?

    1. I think you didn’t understand well. I am already using the Gstreamer framework. I am not going to work with Phonon, Gstreamer provides all I need.

  3. Interesting news. This might become handy for KMess as well!:)

    Where is the library located?

    1. All my code is in trunk/playground/network/kcall in the kde svn. However, the QtGstreamer library is developed separately in git and the code in svn is a copy of it. I will push the git repo somewhere publicly available later today.

  4. Wow, sounds really cool:) Though I don’t fully understand the connections between all those libraries.
    Keep it up!

    1. Xine?? Xine is a player, not a multimedia framework. What makes you think I could use xine to capture video from a webcam, encode it and send it over UDP? See also my comments above.

  5. KDE is lacking a good multimedia framework since phonon is only (at the moment) an ouput library😦
    I’m developing something that also needs input (audio and video) and record it, and do that with the current “K” stuff is so paintfull.

  6. Hi, I not a specialist at all so forgive me if I say something wrong:)

    there is a VLC backend for Phonon (a work in progress I think). Will it be possible in the future to use it to do some stuff Xine can’t (audio/video capturing, encoding…) ?

  7. Hello,
    I’m looking to write a Qt app that can display a video in a widget using Gstreamer (without Phonon). Will your bindings be able to help me with this?

    1. Sure they can help. They are not complete though, but it is still better than having to deal with the native gstreamer api. I bet you will also want to have a look at libkgstdevices in kcall’s source code, which has a video widget implementation (a QWidget which can embed a gstreamer video output element).

        1. If you are not yet familiar with gstreamer, you should first have a look at the gstreamer documentation. After you have undestood how to use gstreamer, you can have a look here: (in method void TableDeviceChooser::Private::testDevice()) for a simple example on how to construct a minimalistic pipeline. There is also some minimal documentation on some classes’ headers, for example,

  8. Have you ever cross-compiled this by any chance? I’m trying to cross-compile it for arm, but the doc I’ve seen for cross-compiling cmake doesn’t seem to be working😦

      1. If you mean QtGStreamer python bindings, then the answer is no. However, there are native python bindings for GStreamer, which you can probably use with PyQt.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s