Compression is a core enabling technology for the digital television revolution. Without it, digital television simply would not be possible. It allows viewers to experience outstanding quality without huge increases in cost. Seemingly, compression is relatively straightforward. Broadcasters should use as much compression as their viewers can stand. Of course, the issue of compression is especially critical in IP-based networks, where bandwidth is usually at a premium.
Constant bit rate
Once the compression is complete, there are two ways to clock the data out of the encoder: constant bit rate (CBR) and variable bit rate (VBR).
As Figure 1 shows, in a CBR system, the output of the compression device is constant. After you set the compression parameters, the bit rate from the encoder never changes.
CBR has great advantages. For example, you always know how much bandwidth is required to transmit the stream, whether that is over an STL or during transmission to the home. Encoder design is relatively simple, so costs can be reduced.
Although CBR is simple and predictable, it is also inefficient. The complexity of an image varies with the image content. In other words, it is much more difficult to compress a panning shot of a basketball game than it is to compress a talking head during a newscast. With CBR, it's important to allocate enough bits to know that when you air a basketball game, the viewers have an acceptable quality level delivered into their homes. Set the CBR level accordingly. But when you are transmitting a simple image, such as a newscaster sitting behind a desk, you could get the same quality level using much less bandwidth. Since the bandwidth is nailed down at a worst-case CBR rate, that extra bandwidth is wasted.
This is not a major problem when you are transmitting single signals across an STL, or sending a single television transmission over the air to someone's home. It becomes a big problem when you are transmitting signals over a computer network with limited bandwidth. IPTV distribution networks, satellite transmission systems and the Internet are all examples of network systems where bandwidth is at a premium. In these systems, it would be great if the engineer could establish a picture quality level and then have the compression system only allocate the bits needed to reach that level. In this way, more bits are used when the scene is complex with a lot of information, and fewer bits are used when the scene is simple with less information. This is the basis of VBR systems.
Variable bit rate
VBR systems allow the engineer to set a high limit and a floor. From that point on, the bit rate varies between these two values. These parameters establish the best quality achievable for complex scenes because the encoder is capped and cannot use more bits to encode the complex scene than is allowed by the high limit. They also determine the minimum bit rate the encoder will produce, with the simplest content presented to the encoder input. As you can imagine, this system is much more efficient in its use of bandwidth. Now that there is extra bandwidth in the system, how can we make use of it?
This may not be as simple as it seems. While there is extra bandwidth available, you never know when it will be available, because it's hard to predict the level of complexity of video appearing at the input to the encoder. That said, if the system is properly configured, using statistics, we can predict with some certainty that over a given period of time, a particular range of extra bandwidth will be available.
Assuming there's a transport medium that will carry a number of channels, the VBR system will allow us to multiplex several channels on to a single transport, using much less bandwidth than if a CBR was used for each channel. (See Figure 2.) As long as the peaks and valleys in the different channels are randomly distributed (in other words you are not carrying the same content on all channels at the same time), an intelligent multiplexer can intermix the bit streams from several channels in such a way as to maximize the quality on all the channels while at the same time reducing the total bandwidth consumed.
Comparing CBR and VBR
Looking at the figures again, in a CBR system, encoder output bandwidth stays constant. However, the amount of bandwidth required to compress the image while maintaining a set quality level at any given point in time varies such that there is extra, unused bandwidth available in the channel. Of course, if multiple CBR streams are sent across a packetized network, this unused bandwidth is multiplied by the number of CBR streams.
In a VBR system, the bandwidth of each channel fluctuates. When several VBR streams are multiplexed into a single transport channel, the output of the multiplexer tends to remain relatively constant. The transport pipe is filled completely. VBR systems are more complex than CBR systems. Not only does the system need to perform the compression process, but it also needs to multiplex the various streams together. Finally, it needs to control the compression process to ensure that bits available for each channel meet the maximum and minimum settings specified during configuration.
CBR MPEG-2 transmission over IP has been defined in a new SMPTE standard (SMPTE 2022). The Video Services Forum is now working on an addition to this standard which will cover VBR transmission. The group intends to submit this for standardization next year.
Low bit rate transmission over IP
Another interesting aspect of transmission of video over packetized networks is the issue of low bit rate transmission. There may be times when the output of an encoder may drop to almost zero for an extended period of time. This may seem alien to broadcasters who are almost always dealing with compression at data rates of more than 1Mb/s. What sort of use case is there for a compressed feed where the bit rate goes to zero?
The application is picture-in-picture (PIP). PIP streams produce a small image of an alternate channel that the viewer is interested in watching on the TV screen. For example, the viewer can watch a movie channel while simultaneously keeping an eye on a football game on another channel. The PIP channel may run at a nominal rate of some hundreds of kilobits per second. Because the PIP channel display is small, and because every bit used for PIP takes away bandwidth from the main channel, it makes sense for design engineers to minimize the amount of bandwidth used by PIP.
Logically, PIP channels are VBR. In cases where the PIP channel is sending images that are easy to compress, the output from this channel may fall to zero for long periods of time (literally seconds). This poses a challenge for decoder manufacturers who must always produce output from the decoder. In these cases, you cannot blank the screen.
Of course, you could just repeat the last frame of video over and over. That takes care of the problem at the display end, but how do you keep the decoder synchronized and keep the memory buffer in a reasonable range when there is no input for an extended period of time?
The most reasonable alternative is to have the encoder send out packets at some nominal low bit rate, even if that means it has to pad the output of the encoder with nulls. This means that you will consume some marginal amount of bandwidth on the IP link, even if there is no need to send any data, but at least this provides an easy way for the decoder to maintain synchronization.
Compression has been a key enabling technology for IPTV, but it has not been without its challenges. The good news is that organizations such as SMPTE and the Video Services Forum are starting to address the issues.
Brad Gilmer is executive director of the Video Services Forum and the Advanced Media Workflow Association. He is also president of Gilmer & Associates.
Send questions and comments to:brad.gilmer@penton.com
