VBR encoding can reduce needed bandwidth while supporting multicast applications.
Last month, we explored various MPEG features, including constant bit rate (CBR) and variable bit rate (VBR) encoding. This month, we'll look at options for multiplexing video streams and dig a bit deeper into how VBR encoding can help with bandwidth utilization and multicast support.
Bit allocation is an n-dimensional process
When encoding video, bits are assigned to pictures in many dimensions. Intracoded (I) pictures (or macroblocks) are used as references for other pictures (or other macroblocks, as in MPEG-4). The allocation of bits when encoding these pictures is a 2-D distribution over a picture: Different blocks will receive a different number of bits, depending on the regional complexity of the picture.
Intercoded (or nonintra) pictures (or macroblocks) comprise P- and B- pictures (or macroblocks) that are predictively coded or bidirectionally predictively coded from other I or P pictures. Assigning bits to these pictures and to their corresponding motion vectors then expands the total bit allocation to a 3-D distribution across multiple pictures, the third dimension being time. Different pictures will have a different number of bits, depending on the complexity within a sequence of pictures; a sequence with a strong scene change, for example, will get more bits than one with little motion.
MPEG transport streams allow content providers to multiplex (mux) multiple video programs in one container that is sent within the transmission channel, usually as a transport stream. The simplest way to configure such a mux is to encode each program using CBR and to allocate a fixed bandwidth to each program. There is, however, a more efficient way to transmit a multichannel service by using statistical multiplexing (stat mux). By encoding each individual program using VBR, the bit rate of each program is allowed to vary, but the total bit rate across the program mux is held constant. (See Figure 1 on page 18.) Stat mux thus requires the distribution of bits over several programs — a 4-D bit allocation — and as such, the encoding algorithm is more complex than that for a single program or for a multiple-program CBR mux.
With CBR coding, more complex scenes get fewer bits than actually needed to avoid all artifacts, causing a related variability of picture quality. With VBR coding, all pictures are coded with a target of uniform quality, but with an associated variation in bit rate. This suggests that the combination of stat mux and VBR is a win-win situation. Research has shown that statistical multiplexing with VBR can provide the same video quality at 75 percent of the bit rate of a CBR mux. Put another way, for the same video quality, a stat mux can provide an increase of about 33 percent in the number of multicast channels available. This figure is called the statistical multiplexing gain (SMG), sometimes expressed in dB, and implies the number of channels available at peak bit rate demand vs. the number at the average (i.e., fixed) bit rate demand. Practice shows that this number is typically 30 percent to 40 percent, with the highest gain occurring when channels are subject to random insertion. This is to be expected, as the greatest gain happens when the demand is decorrelated among the programs.
Nonetheless, if the channel demand is too aggressive, picture quality can still suffer. Compression encoders (and stat muxes) base their decisions on how to allocate bits on meeting a target of different parameters. When quality is one of these parameters, the encoders use what is called rate-distortion theory. The quality is gauged by measuring the distortion in the video, usually by estimating the difference between the uncompressed and compressed video, weighted by an estimation of the visibility of the distortion by observers. Basically, the encoder (or stat mux) sets a target for the bit rate and attempts to stay within this target, while at the same time trying to exceed a minimum quality level for the video by minimizing the coding distortion. Because viewers are sensitive to time-varying effects, the distortion must also be managed in a smooth manner; a stat mux similarly needs to maintain fairness over the different programs, lest demand on one affect the quality of others.
Mixing and matching: fixed and mobile video
Multiplexing over broadcast channels (multicasting) is essentially a time domain multiplexing (TDM) operation, wherein the different services are switched in time over the transmission channel. In practice, however, this must be differentiated from pure transport stream multiplexing, where the different services are contained within different packets, each with a corresponding packet identifier (PID), and all within the same modulation “layer.” Because mobile services are inherently subject to a higher degree of multipath interference, programs destined for mobile reception must be delivered in a more robust transmission mode.
The various digital transmission systems in use throughout the world offer different modes for achieving this robustness improvement, but at a compromise in data throughput. When the main service and mobile services coexist on a single transmission channel, the various programs can be packaged within one stream, but the mobile services must be carried in a portion of the stream that is transmitted with a more robust modulation. (See Figure 2.)
With ATSC, mobile services are supported through a backward-compatible multiplexing scheme, called ATSC M/H or ATSC Mobile. Here, the main programs are carried within an MPEG-2 transport stream, and the mobile programs are carried within an IP stream. Both of these streams are then combined by means of a framing multiplexer that works in concert with the modulator so that the mobile services are modulated with more robust channel coding. The output of the framer, although not an MPEG-2 transport stream in the strict sense, nonetheless can be carried using standard transport interfaces.
DVB-H (for handheld) can similarly be combined with an existing DVB-T (terrestrial) service, with the main programs in an MPEG-2 stream, and the mobile programs encapsulated in an IP stream. Each stream is then modulated using different transmission parameters. With ISDB-T, the mobile stream is typically modulated onto a different set of carriers, with various modulation parameters, but these are interleaved with the carriers used for the main channel. ISDB-T also offers the use of one-segment (one-seg) services, where one group of contiguous carriers (out of 13 such groups) can be dedicated to a mobile service. The DVB and ATSC systems also provide what is called time slicing, a form of TDM, whereby the mobile data is transmitted in a way that allows the receiver to be switched off during the transmission of non-mobile data. The result is a significant power savings, an important feature for mobile (especially handheld) devices. (While ISDB-T does not use time slicing, the use of single-segment transmission will offer receiver power savings, as the transport stream data rate is lower.)
An important consideration is that when multiplexing the various programs, a stat mux usually will not be able to allocate bits across the fixed and mobile services; i.e., while stat muxes could be used in either or both services, they can only allocate bits within each service, and not over the combination of both. This is because the total bit rate within each of the fixed and mobile muxes must be constant for the modulation (and receivers) to work properly. (Nonetheless, technology evolves, and a completely — or partially — dynamic service bit allocation could eventually be practical.) Using a VBR stat mux in the mobile service mux is an important consideration when trying to maximize the number of low-bandwidth programs and is an interesting option for maximizing the value of mobile services.
The use of MPEG-4/AVC also adds to the options available for multiplexing, but that's a subject onto itself. Stay tuned.
Aldo Cugnini is a consultant in the digital television industry.
Send questions and comments to: email@example.com