Tag Archive: farsight


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 :D 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 :D 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.

GSoC Week #4

I skipped a week without blogging, mostly because I was busy last weekend, but now I think it’s time to report my status on kcall again…

Last week I spent about 3 days studying gstreamer and I ended up creating a media handler class using telepathy-farsight and gstreamer, which is able to handle audio calls without problems. The only bug I have there is that the microphone volume control does not work correctly, but I hope I will solve this some time (it’s not urgent anyway). The code is heavily based on andrunko’s telepathy-qt4 media branch, a branch of the telepathy-qt4 library that includes a high level API for handling all this farsight/gstreamer stuff, but as this branch is not ready yet and as I will probably need more control over gstreamer than what this media API gives me, I just copied and adapted this code to work in kcall. The only part I don’t like about this gstreamer stuff is that its dependencies are HUGE. For example, I just need to depend on libxml2 and telepathy-glib because some of the headers I include, include in turn some headers from those libraries… Totally unacceptable imho. Actually, big part of my work here was to create correct cmake scripts that can find and use all those dependencies….

Ok, so after making the media handler, I split the part that handles calls in a separate executable, implementing the telepathy Client.Handler interface. I merged in this executable the kpart I had created, as after reading the telepathy spec about the channel dispatcher, I realized that there is no need to have a kpart. A separate handler process is enough to be reusable by any other program. If another program (for example, kopete) wants to start a media call, it can just request a media channel from the channel dispatcher, and the channel dispatcher will automatically open a handler for media channels, such as this kcall handler. Apart from that, I also created a system tray icon (using the new KNotificationItem API) and an approver class, which shows a popup message (using knotify) when there is an incoming call and allows the user to accept/reject the call.

This week I had an exam on Wednesday, which prevented me a bit from working on kcall. In the time that was left, I started working on improving the call window. I added a dock widget with volume controls and a timer showing call duration, and I also fixed some internal stuff to report correct status to the user and accept incoming calls correctly.

Next thing to do now is to improve the UI of the call window, so that I can also add the video widgets on there and play with video support. I will also need to find some software and protocol that will allow me to test video calls easily. I tried connecting to ekiga.net over SIP yesterday to use its handy 500@ekiga.net echo-test service, but it seems that telepathy-sofiasip has trouble connecting to ekiga.net.

Btw, if any of you out there would like to help me designing a good UI, I would love to hear some ideas and/or see mockups of how the call window UI should be, as I’m really bad at designing GUIs on my own :P The basic idea is that I need some widgets to see video in the middle, plus some list with the participants of the call, plus volume controls for mic & speakers, plus a dial pad… I’m currently thinking of putting all optional stuff (participants list, volume controls, dial pad) in dock widgets and put two video widgets in the middle (one for the remote contact and one for myself)… but now that I think it again, the problem here is that *theoretically* a call can have many participants, so just two video widgets may not be enough. And on the other hand, what should be displayed for audio-only calls? I think you get an image of the situation, so, I would love some ideas here :)

GSoC week #2

This week went a bit out of plan. I didn’t work much on kcall as I was busy with other things. On Tuesday I had two exams (fortunately, quite easy ones), which kept me busy for both Monday and Tuesday. Then from Wednesday I started packaging KDE 4.3 beta2 for debian, which was quite challenging and kept me busy for 3 days (Wednesday-Friday). I packaged only the basics (kdelibs, kdepimlibs, kdebase-runtime, kdebase-workspace and some kdesupport dependencies) and of course they are not of release quality yet (so don’t expect 4.3 beta2 packages in debian).

In the meanwhile, despite being busy with other stuff, I took some time to study a bit more the “call example” from the TelepathyQt4 examples, which is essentially a simple version of what I am developing, and I wrote some code for a “call window”, which is an object that in the future it will be able to handle a call and display a nice window with status info, the video widget, audio/video controls, etc… Yesterday (Saturday), I polished a bit the API of this object and I implemented some really basic functionality. While I was looking at the code, I thought it may be better to develop this window as a kpart, which will make it possible to be reused later in other projects, like kopete for example (when it is ported to telepathy, if this ever happens). So, late yesterday afternoon, I ported this window to use kparts. However a linker issue (telepathy bug 21340) stopped me from finishing it. Today I managed to fix this issue and I am now working on finishing the kpart. Unfortunately I don’t have much time to work on it today, but I promise it will be ready by late night today or tomorrow morning.

Now, the next step is to implement an object that will do the encoding/decoding of the audio/video. As an exception to the general design of telepathy, audio/video handling is specified to be done by the application itself and not from the connection manager that connects to the protocol. To handle this, telepathy developers have designed a library called telepathy-farsight, which internally communicates with the connection manager and handles the audio/video streaming part. To do the actual encoding/decoding, gstreamer must be used. Gstreamer is a library that resembles phonon a lot. It uses a similar pipelined architecture. From what I understand, telepathy-farsight provides a gstreamer source and a sink, which can be connected to other gstreamer objects that will do encoding/decoding, grab source from the mic or camera, output to alsa and some video widget, etc… Unfortunately, farsight and gstreamer are the only way to go here. This is how the telepathy specification is designed, and while I bet it would be possible to write something similar to farsight that will do the same job using Qt and phonon, this is too much work to do and if this ever happens, that will take a few years. So, I will have to spend this week learning the glib/gobject and gstreamer basics, so that I will be able to write this part of kcall. The “call example” I mentioned earlier provides a sample implementation of this object, but although I could just copy it, I need to understand what it does so that I will be able to extend it.

I hope this week I will work more and I will manage to make a simple call :) My current plan is to have audio/video fully working (with controls and options) before July 6th (the middle of the gsoc period), so that I can spend the rest of the period doing UI/usability improvements and implementing secondary features that may be needed. (Notice: The author of this post has the authority to change this plan without previous notice! :P)

Follow

Get every new post delivered to your Inbox.