How Do You Test MPEG-2 Transport Streams?
Testing MPEG video products requires generating and analyzing bits, bytes, packets, and protocols.
Martin Rowe, Technical Editor -- Test & Measurement World, 1/1/1997
|
Video is now following the path that voice communications has already traveled--the path from analog to digital. Bits that represent voices have traveled through telecom networks for years, and those bits have required digital, rather than analog, test equipment. Now it's video's turn. A popular technique for encoding digital video and audio programs is based on the MPEG-2 standard (ISO/IEC 13818). (See Footnote 1 below.) Encoders compress digitized video and audio signals into packets for transport to an MPEG-2 compliant decoder. The decoder will decode the video and audio programs and convert them back to analog for use with traditional TV sets. Most decoders will be set-top boxes that receive MPEG-2 data--called transport streams--and produce standard NTSC analog outputs. Other decoders used in video servers will convert a stored encoded program to analog for distribution over a cable-TV network. The MPEG-2 test equipment available today is designed for testing bits, packets, and protocols, but it doesn't test for video or audio quality. So, you can have a perfectly delivered transport stream that carries unacceptable video and audio. The next generation of test equipment will have to measure the quality of compressed digital video and audio programs. In the meantime, you'll have to settle for testing the quality of data transmissions and the MPEG-2 transport stream. |
Figure 1 shows the path that digitized data take from a signal source to a delivery system. After a complex spatial and temporal compression process, encoded video and audio elementary streams (ESs) are packetized into packetized ESs (PESs). If the program is headed for an editing workstation, perhaps one in a TV studio, then the program's audio and video PESs are multiplexed into a program stream. For broadcast, PESs from many programs are packetized into 188-byte packets; that's the transport stream. These packets may then be encoded for transport over a fiber-optic delivery system such as an ATM network or RF modulated for broadcast over a satellite network or a cable-TV system.
 |
|
| Figure 2 shows the structure of a transport-stream packet. Each header and its payload occupy 188 bytes. An important field in the header is the program ID (PID). The PID is a 13-bit field that tells the decoder to which program each packet belongs. Every audio, video, and data PES in a transport stream has a unique PID. | ||
|
| MPEG-2 analyzers are test systems that monitor the PIDs; you can program the analyzers to capture data from any or all PIDs. The screen in Figure 3 shows how MPEG-2 analyzers give you a picture of a transport stream's structure and contents. Companies that manufacture MPEG-2 analyzers are Digital Transport Systems (San Diego, CA), Hewlett-Packard (Santa Clara, CA), Symbionics (Cambridge, UK), and Tektronix (Beaverton, OR). | ||
|
| MPEG-2 analyzers can verify that the PIDs in a transport stream are consistent with those presented in the transport stream's program association table (PAT). As programs begin and end, a transport stream's PIDs will change. Therefore, an encoder transmitting a stream must update the stream's PAT on a regular basis, typically once every 0.5 s. (See Footnote 2 below.) MPEG-2 analyzers measure the frequency of the table updates from an encoder's output. A PAT containing illegal PIDs or PIDs from a program that has ended will consume unnecessary processing time at the decoder, as will an encoder that sends table updates too frequently.
A transport stream's PAT, which is always located in PID 0, contains a listing of which PIDs contain the program map tables (PMTs). The PMTs describe the programs in the transport stream by providing a listing of the video and audio PIDs that make up a particular program--such as 1431 and 1432 in Figure 3. The PMT also tells the decoder which PID contains the program clock reference (PCR) for each program. The transport stream's adaptation field (see Fig. 2) contains 42 PCR bits. These bits synchronize data transmissions between an encoder and a decoder and compensate for the varying delays in delivery. Without that synchronization, viewers will see choppy video or out-of-sync audio and video. Encoders and decoders have 27-MHz clocks that require synchronizing. The PCR field periodically transmits time information that the decoder uses as a software PLL to keep its clock synchronized to the sender's clock. The amount of PCR jitter is an indication of a system's overall multiplex jitter; multiplex jitter can produce video that is unacceptable to viewers. Pearse Ffrench, vice president of Digital Transport Systems, notes that the MPEG-2 specs (ISO/IEC 13818-9) call for low-jitter applications to have jitter that is less than 25 ms. According to Ffrench, the jitter introduced by satellite transmission is typically a few microseconds, while transmission through an ATM network can create jitter as high as 2-3 ms. The transport stream analyzed in Figure 4 shows an average jitter of 90 ms (0.00009 ms) and a maximum PCR jitter of 270 ms. Cure the Jitters |
||
|
| Transport buffers are fixed at 512 bytes; depending on the spacing of the packets and the drain rate, they can quickly overflow. The size of all other buffers is up to the decoder designer and can vary depending on the intended use of the decoder. When verifying a decoder design, you should monitor the status of each buffer to be sure that the buffer size is adequate for your intended application. The MPEG-2 specification defines a method for calculating buffer size. (See Footnote 3 below.)
If the decoder is designed for a digital set-top box intended for home use, then cost is a critical factor in a design. Too much buffering can increase the cost of a decoder and price it out of the market. But too little buffering will cause buffer overruns that produce artifacts in the picture. In addition to testing encoders and decoders, an MPEG-2 analyzer can also test delivery systems. Testing at the system level will help you verify that the transported packets arrive at their destination. To test delivery systems and decoders, you need to feed them known MPEG-2 transport streams. To store those test patterns and play them, you need a transport-stream player (sometimes called a generator). With a transport-stream player, you can send a transport stream to a decoder and view the encoded video on a TV monitor or measure the decoder's analog output. Transport-stream analyzers from Symbionics and Tektronix double as transport-stream generators. A transport-stream generator is also available from Logic Innovations (San Diego, CA). To test a delivery system, feed it a known MPEG-2 transport stream, and analyze the system's outgoing stream. Some analyzers let you analyze the transport stream in real time, while others require you to record the stream and analyze it off-line. Because you can start with a known transport stream, you can introduce impairments into the delivery system and analyze their impact on the delivery of the data. Standard Test Streams While testing with standard bit streams is useful, you really want to be sure that a decoder can decode streams created with any encoder. The MPEG-2 specification defines decoders, not encoders. But, decoder users expect their decoder to decode any program. Vela Research (St. Petersburg, FL) manufactures decoder cards for use in video servers. The cards plug into PCI bus, EISA bus, SCSI bus, or VMEbus computers and decode MPEG-2 encoded programs from a local storage medium; the cards also provide NTSC analog video and audio programs to cable-TV system headends. Paul Mears, Vela's vice president of engineering, says that his company verifies new decoder designs by creating data streams encoded with as many encoders as possible and then feeding the data streams into the decoders under test. In production, Vela's technicians test decoders by installing several cards at a time and using a Tektronix VM700A video analyzer to test the cards' NTSC outputs. To test any MPEG-2 decoder, encoder, or delivery system, you need to store test streams and play them back. Some MPEG-2 test equipment gives you storage and playback capability. For example, the analyzers from Symbionics and Tektronix can store incoming transport streams, and you can play them back when testing decoders and delivery systems. A system from Logic Innovations can store any digital data stream and play it back; the system is useful when you don't need the analyzer, such as when testing decoders with NTSC outputs. You can use this system to store MPEG-2 transport streams for testing decoders and delivery systems, but you can also store uncompressed digitized video and audio signals for testing an encoder. You can also use your own PC with Digital Transport Systems' transport stream analyzer, generator, and capture cards. For analyzing MPEG-2 transport streams carried on ATM networks, look to Hewlett-Packard's E6271A ATM analyzer with the E42266B MPEG-2 protocol-viewer software. To use MPEG-2 test equipment, you must connect it to an encoder, a decoder, or a delivery system through a physical interface. Transport-stream test equipment must support several physical interfaces. Because standards for physical interfaces were not adopted before equipment was developed, encoder and decoder manufacturers were free to choose any physical interface. So, MPEG-2 test equipment must support a myriad of physical interfaces--some encoders or decoders use serial interfaces with ECL ports, some use serial ports compliant with ITU-T recommendation G.703, others use parallel ports, while still others use LAN ports. Until recently, no standard existed for the physical interfaces of encoders and decoders. Now, the digital video broadcast (DVB) committee--made up of manufacturers, telecom companies, and broadcasters--has settled on three physical-interface standards. Those standards define an asynchronous serial interface, a synchronous serial interface, and a synchronous parallel interface. Some test-equipment data sheets refer to the synchronous parallel interface as DVB TM1449--a 25-pin D-type connector that carries parallel differential signals. Encoder and decoder manufacturers are not required to follow these standards, but some will. Video Quality Still Not Tested Test systems for video quality may one day be based on vision systems rather than electronic measurements. These vision systems will have to emulate how the human eye perceives TV pictures. Once such a system is developed, engineers will have a way to test video quality more accurately and more quickly than people can--and with more repeatable test results. A vision-based test method called "just-noticeable differences" is already in the works. This method uses a vision system that tries to emulate a person's ability to distinguish between a reference image--one with no compression or transport impairments--and a compressed and impaired image. The method will assign a numerical value to the test result. A value of 1 indicates that there's a 75% probability that a person will correctly identify which of two images is the original and which is the impaired copy. Test results of less than 1 indicate that the probability is less than 75%. If a person can tell the difference, then enough video quality was lost in the encoding, transport, and decoding of the original signal to catch the person's eye. Although test methods such as the "just-noticeable-difference" test are still in their infancy, they will soon be essential. Many consumers won't tolerate a degradation in video quality to get the higher channel count that digital video promises. By starting to develop your MPEG-2 test strategy now, you'll be better prepared to meet your customers' needs. T&MW FOOTNOTES Learn More About MPEG Technology & Test Equipment Hewlett-Packard and Tektronix gave seminars around the country last year. I recommend either one. Both companies expect to offer their seminars again in 1997. On the Internet, start with the MPEG Web site (www.mpeg.org) for links to technical papers, software, test elementary streams, company sites, and industry news.--Martin Rowe Books and papers that describe MPEG-2 technology. Chiariglione, Leonardo, MPEG and Multimedia Communications, Web: www.cselt.stet.it/ufv/leonardo/paper/isce96.htm. Facilitating MPEG-2 Digital Television System Integration, Jack, Keith, Video Demystified, 2nd ed., HighText Interactive, San Diego, CA, ISBN 1-878707-23-X, 1996. For a review of this book, see T&MW TestLit Review, October 1996. MPEG-2 Digital Video Technology & Testing, BSTS Solution Note 5963-7511E, Hewlett-Packard, Santa Clara, CA, 1995. MPEG-2 Frequently Asked Questions, Web: bmrc.berkeley.edu/projects/mpeg/faq/MPEG-2-FAQ.html. Ramaswamy, Arun, Understanding MPEG for Video For more information about MPEG test equipment, contact these companies: Digital Transport Systems, San Diego, CA, 619-675-1410; Hewlett-Packard, Santa Clara, CA, 800-452-4844; Logic Innovations, San Diego, CA, 619-455-7200; Symbionics, Cambridge, UK +44-1223-421025; Tektronix, Beaverton, OR, 800-826-2200; Acronyms Used in This Article: ES ITU-T MPEG NTSC PAT PCR PES PID PLL PMT PSI |
