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):

x264enc bitrate scaling

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)

x264's ratecontrol can enforce accurate per-frame size caps with the appropriate VBV settings, as well as being able to change these caps arbitrarily on the fly.

Of course, if you don't ask x264 for it, you won't get it.

Comment by Dark Shikari Mon Apr 18 23:33:43 2011

It actually looks like it responds pretty quickly to bitrate changes(assuming x axis is sec). Obviously the bigger the change the longer the response and as the bitrate gets lower you seem to be hitting the bullseye. Nice! Have you tried this in a multicast setting?

Comment by liam Tue Apr 19 08:34:05 2011

It actually looks like it responds pretty quickly to bitrate changes(assuming x axis is sec). Obviously the bigger the change the longer the response and as the bitrate gets lower you seem to be hitting the bullseye. Nice! Have you tried this in a multicast setting?

Comment by liam Thu Apr 21 05:03:47 2011
I think the encoder response time looks good. I am wondering if you plan to use TFRC over RTP/RTCP to do this in real-time.
Comment by Varun Singh Tue May 10 15:33:06 2011