No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Scalable Video and Packet Loss

In my last post I talked about the way SVC breaks up a video image into different streams that can be used to build up a high resolution, high frame-rate image. One of the claims of SVC is that it is much more tolerant of packet loss in the network. Let's take a look at why that is true.H.264 video streams today (non scalable) do a masterful job of compressing data, and do it by using every trick in the book. One of the key tricks is to send incremental information. If a video image is only slightly changed from the previous image (frame), then there is no need to send all the unchanged information. The codec sends out incremental information that says "these pixels have changed in this way, leave the rest as it was". This is much less information than sending the whole frame again, and so it results in much better compression.

The disadvantage of this approach shows up when the network drops a packet. When a packet goes missing, the receiver does not get the latest information on how some part of the video image has changed, and so the video image is slightly wrong. Then when it gets the next packet, it is now building on bad information, and so the video image gets worse. Current codecs overcome this problem by occasionally sending a full frame of information, and when packet loss occurs the receiver can request a full frame update to speed up the correction process. But this takes a full round-trip delay of the network, plus processing time in the codecs, and the results are quite visible.

Some of the vendors now implement Forward Error Correction algorithms (FEC) to help solve this problem. FEC is a block coding algorithm that creates redundant information that is sent along with the original packet stream. This redundant information can then be used to recreate packets that were dropped by the network, assuming sufficient good information and sufficient redundant information are received. This is pretty cool, but of course has its tradeoffs. Because the codec is sending redundant information, its bandwidth requirements go up. Some codecs compensate for this by reducing the video bandwidth to keep the transmitted bandwidth (video plus FEC overhead) constant. This reduces the quality of the video stream. Additionally, FEC adds latency because a block of packets have to be created and the FEC calculated before they are sent, and on the receive side a block of packets have to be collected and the redundant information from each used to recreate the missing packets. Increased latency reduces the interactive nature of the video call, making two way conversations more difficult.

Why does SVC help solve this problem? Remember that SVC has a base layer and then one or more enhancement layers to create the video image. These streams are carried by different packets on the network. Packet loss to the base layer will have the same effect as it does in non scalable codecs, but packet loss in enhancement layers has a much less dramatic impact. The enhancement layers are building on the base layer, not on previous frames. Thus loss in an enhancement layer means a temporary drop in resolution or frame rate, but not in the basic structure of the video image.

FEC can be used to protect the base layer of an SVC video stream in exactly the same way as it is used for non scalable codecs. For low resolution SVC video calls this will have the same limitations as a low bandwidth non scalable call, adding overhead and latency as before. For higher bandwidth calls, however, the effect will be quite different because the overhead is only occurring on the base layer, not on the enhancement layers. If, for example, FEC adds 20% overhead, and the base layer is only 25% of the bandwidth of the total video call, then the FEC is only adding 5% to the whole call as opposed to the full 20% in a non-scalable codec.

So the advantage here comes from the structure of the scalable video stream in combination with FEC protection for the base layer. For low bandwidth calls the effect will be comparable to what can be done with a non-scalable codec. But for high bandwidth calls SVC will provide high quality over a lossy network with much lower protection overhead than a non-scalable approach.

In my next post I'll take a look at how SVC supports heterogeneous endpoints, meaning endpoints that have different bandwidth connections and different computing abilities.