Setting optimal video quality:

Understanding Flash and Red5 bandwidth management

Setting an optimal video quality can be hard using Flash and Red5 (Apideo relies on both). In this article, I'm trying to understand why we can have some issues like big lags when using a webcam.

In order to achieve optimal quality, the Flash player offers several parameters we can play with. The goal of this article is to share my understanding of the streaming process.

Do not hesitate to post a comment below if you think I'm wrong :)

The most common parameters we can play with Flash are the width and height of the resolution of the camera. There is also the number of frame per seconds, the microphone sampling rate, etc...

Two very interesting parameters are the maximum bandwidth, and the quality.

• By setting the quality, you specify the level of compression that Flash will apply to your stream, 1 being the most compressed, and 100 being no compression. The amount of bandwidth required will depend on the quality, but also on the picture. The more you stand still, the less bandwidth will be required to achieve the quality you seek.
• By setting the bandwidth, you sepcify directly the maximum bandwidth Flash can use. If Flash hits the maximum bandwidth, it will increase the level of compression (and therefore decrease quality) to keep the stream into the available bandwidth.

When streaming video from a camera in Flash, the stream must go up to the server and down to its destination. Therefore, there can be 2 bottlenecks: one possible bottleneck is during the upload to the server, the other bottleneck is during the download from the server.

In order to achieve the best quality possible, you should ensure that you have enough bandwidth for the stream both ways. But what happens if there is not enough bandwidth?
In an ideal world, we would like the stream quality to naturally degrade, in order to keep a smooth movie. However, in practice, tests have shown that anything can happen, from choppy video to an increasing lag while the movie is played.

In this article, I'm trying to understand what is the impact of an insufficient bandwidth on the average stream quality.

Test environment

In order to test the behaviour of Flash and Red5, I've set up a test environment. This test environment is made with:

• Red5 0.8RC2 (trunk release 3565)
• Trickle (a bandwidth shaper)
• A standard flash movie that streams to flash and plays the stream it sends, at various qualities
• The software is running on a DualCore with 4GB or RAM, running a Ubuntu 8.10 Linux distribution

I'm running Red5 using Trickle. Trickle can limit the amount of data Red5 receives (to simulate a slow upload connection) or can limit the amount of data Red5 sends (to simulate a slow download connection).

In my tests, I use a high quality for the video:

• Camera resolution: 640x480
• Frames per second: 30
• Microphone rate: 22kHz

I set the quality to "0", which means that Flash will try to get the best quality from the available bandwidth. Because the resolution is high, I am almost sure it will never be able to send the whole video at maximum quality. Therefore, I know that if set the bandwidth parameter to 20 kB/s, it will use the whole bandwidth. This is important because in my tests, when I try to limit the Red5 bandwidth to 10 kB/s, I want to be sure Flash will always try to send 20 kB/s.

I will split the tests in 2 parts. First part is limited upload, second part is limited download.

Limited upload

Limited upload is quite common. Most people having ADSL connections have a small upload speed, and a big download speed (the A in ADSL stands for Asymmetrical).

Therefore, while most people have a download speed of 20 Mb/s (this can vary depending on your country), the upload speed is often limited to 256 kb/s... up to 1 Mb/s if you are lucky. Furthermore, these upload speed are only theoretical, and can be much lower in practice.

The table below shows what happens when the upload speed is artificially limited using the trickle command:

This is quite interesting because we can see that Flash can deal with a bandwidth that is smaller than the bandwidth required. For instance, if only 20 kB/s is available, but if we ask Flash to send 50 kB/s, everything runs fine. However, if we require more bandwidth (for instance 200 kB/s), Flash cannot cope with it and the video stops.

It seems that Flash can handle restrictive upload conditions but fails if conditions are too restrictive.

Limited download

Limited download is less common. Most people having ADSL connections have a huge download speed (at least enough to receive a video stream).

However, limited download can occur on the Red5 server. For instance, this can happen if the server tries to send a stream to several hundreds people. A typical server has a bandwidth between 10 Mb/s and 100 Mb/s.

The table below shows what happens when the download speed is artificially limited using the trickle command:

Those results show that Red5 can handle restrictive download conditions. If the client does not have enough bandwidth to download the live stream, Red5 will automatically drop some frames. This is what happens when the sender is streaming at 100 kB/s but when the receiver only receives at 20 kB/s.

However, Red5 cannot cope with download restricitions if they are too high. If the download bandwidth is too restricted, the stream will stop playing.

Conclusion

While streaming video from a web-cam, the available upload bandwidth and download bandwidth is very important. Although both Red5 and Flash seem to have a degree of resilience regarding restricted network conditions, both can just stop working when available bandwidth is too low.

Of course, this is not the ultimate test. Trickle is good at limiting bandwidth but does not generate any delay. Simulating delay would be interesting. Furthermore, tests have been performed with the Ubuntu Flash player, that seems to play videos in a different way than the Windows player (video seems more smooth, I can't figure why).

I must also admit I have been surprised by the quality of the video with highly restricted download bandwidth.

At least, now, I am pretty sure that a high lag in a conversation is due to limited upload bandwidth between the sender and the server.

What about you? Have you had any similar experience? Do you have any clue on how to make your video conversation smoother? Is there any advice you would like to give about getting optimal video quality out of Flash and Red5? Did I make a major mistake in my test scenario? Please drop a comment!

David Négrier