This feed contains pages in the "telepathy" category.
One of the more exciting upcoming features of Farsight is the ability to change the amount of required bandwidth depending on network conditions. Which means Telepathy based VoIP clients will be able to use higher resolutions and better audio/video quality if the network connectivity allows. And ofcourse, when the available bandwidth is low, the bandwidth usage can be lowered such that calls are still possible with lower but hopefully still acceptable quality.
One side of the full story is measuring the available bandwidth, which hopefully Olivier will tell at some point. The other part is actually using less bandwidth. In case technical details are not that interesting to you, probably best to stop reading at this point..
An important way to control the bandwidth we're using in a call is setting the target bitrate on the encoding GStreamer element. While previously it was enough for us to set the bitrate before encoding started, we now need to be able to change it at runtime. And not only that, the codec implementation should ideally respond within a few frames and have a reasonable constant per-frame size.
All in all, a lot of requirements on codecs we didn't really have before. Which usually means we need to retest the various codecs we often use and make sure we configure them correctly for the behaviour we'd like to see (and fix them if necessary). To do this I've written a small test program, which simply changes the target bitrate over time and outputs some numbers suitable to feed into gnuplot to turn into graphs.
For example, when using x264enc with the current default farsight settings a part of the resulting graph looks something like this (full graph here):
The blue impulses is the per-frame size (scaled), the green line the bitrate average over 10 frames and the red line the target bitrate. Clearly this isn't an ideal picture, we will need to do some more tweaks to our default settings to make x264 behave the way we want. The same will be true for all other codecs and codec elements, at the moment the GStreamer VP8 element doesn't handle run-time bitrate changes at all and the Theora element acts it its very own interesting way (graph here)
Since some time the good people at NlNet have been sponsoring Collabora to add multi-party audio/video calling to XMPP and do an implementation of this in Telepathy. This project is otherwise known as Muji.
This work has resulted in:
- an experimental XMPP extension called Muji
- a new and more modern telepathy API for doing calls (currently still in draft), which allows multi-party calls as well as adding the possibility to support call forking (ringing multiple remote devices, call goes to the one that's picked up first).
- An implementation of both of these in telepathy-gabble
- A small telepathy client for testing and demo purposes.
To proof it actually works, a nice screenshot of the demo client in a 4-way call:
The screenshot is featuring myself in Collabora's UK office (top-left), Robert McQueen from a hotelroom in Taipei (top-right), Will Thompson and Magical trevor also from the Collabora UK office (bottom-left) and Mike Ruprecht from somewhere in Missouri. So we were quite spread out over our little planet. Both audio and video quality was quite good, even though the network in robs hotel was a bit flaky from time to time.
In case you want to try it out have a look at the MujiDemoClient page.
Yesterday Google announced the WebM Project, giving the world a new open and royalty-free video codec called VP8. Thanks to Collabora Multimedia and Entropy Wave support for it landed in gstreamer git shortly after the announcement.
In Telepathy we quite like video conferencing, so as a logical next step i quickly put together some proof of concept RTP payloading elements for Gstreamer with the obvious result:
The screenshot isn't very exciting, which is exactly how it should be. In the world i would like to live in people don't have to care about video codecs, whether it is for video calls, playing online media or whatever else they want to do with video. Looking at the list of supporters for the WebM project this may actually happen and that in my opinion is much is actually the most important aspect of it all.
The most important aspect that is missing at this point to bring VP8 as the video calling codec to the world is the lack of a standard RTP specification. Which is something we will hopefully start working on with various other parties in the WebM project reasonably soon. For now if you want to feel cutting edge get Empathy from git master and my rtp elements. To give things a first try
A Belorussian translation of this article is available here