I am going to explain in this blog post how video quality functions in flash video chat apps.

Understanding the steps the video quality goes trough in its travel from the broadcaster to the viewer is vital when trying to raise the general video quality experienced by your users.

This tutorial applies to AVChat, AVConference, SimplChat but also in some extent to HDFVR and AVChat IM.

So, here we go.

The  journey of the video from the broadcaster to the viewer can be imagined as a funnel with 8 steps. At each step the video quality can suffer. To increase the video quality at the end (on the viewer’s side) you can take measures at every step.

Step 1:  the lighting.

The amount of light in the space where the video is being captured is very important for the frame rate and detail a webcam can capture. The more light the better. Lots of natural light works best. Most of the lower end webcams can not capture more than 5fps when just a light bulb is lighting a room.

Step 2: the webcam itself.

Good “HD” webcams can capture video at high resolutions, high fps and high detail.

Step 3: the video settings used to capture video.

Once you have good light (Step 1) and a good webcam (Step 2) you must make sure nothing is lost in the encoding process.

Al0 our products ship with at least 90% picture quality setting and 15fps so if you’re getting low picture quality or low frame rate, something is happening in one of the other 8 steps.

Step 4: the CPU on the broadcaster’s computer.

Let’s say we have good light a good webcam and we’ve setup AVChat to record 400×300 at 30fps with 90% picture quality. Cool!

The limit will now be the CPU on the computer doing the encoding. A slow CPU will limit the amount of frames it can encode/second.

Microsoft recommends an Intel Dual-Core 3.0 GHz or higher CPU for 720p (HD) video calling with the Microsoft LifeCam Studio.

Step 5: the Internet connection of the broadcaster with the media server.

Once the video is properly captured and encoded, it needs to be sent to the media server.

For a live stream the connection bandwidth is vital. If there’s not enough “upload” bandwidth Flash Player will stop sending the video data to the media server and only send the audio data. On the viewer’s end this will be experienced as blocked/choppy video.

Low “upload” bandwidth can be caused by:

  • the “upload” limit of the broadcaster’s Internet connection
  • busy/high traffic network/internet connection
  • the peak bandwidth limit of the media server hosting account (both influxis.com and uvault.com have peak bandwidth limits for their shared media server hosting accounts)

For when doing 2 way video chat the latency is also vital. If the video arrives with delay the 2 way video chat will not be very fluid.

Latency can be caused by any of these factors:

  • broadcaster being connected via wifi
  • media server being far away from the broadcaster (in another country/continent)
  • broadcaster is behind a proxy

We recommend getting a media server as close as possible to your users and without any limit on peak bandwidth if you’re shooting for HD video broadcasting.

Step 6: the media server software

The media server just passes the video stream from one user to another but there are slight differences between the 3 big media servers: Red5, FMIS and Wowza.

There are also differences in what regards the load a media server software puts on the hardware with Wowza and FMIS being more efficient than Red5.

Step 7: the connection of the viewer with the media server

Again we’re hitting the internet connection limit but this time it’s the “download” connection from the media server to the viewer.

If the viewer has a “download” connection slower than the bandwidth/s used by the stream it will get choppy video.

Step 8: the CPU on the viewer’s computer

If you’re broadcasting high quality HD video and it manages to get trough all previous 7 steps without losing any quality, then a slow CPU will transform that beautifully smooth crisp video in’to choppy playback.

Leave a Reply

Your email address will not be published. Required fields are marked *