1. MPEG2 Testing

MPEG2 Data Streams When talking about testing MPEG, there is no single, simple testing solution. The MPEG2 signal is very complex, and depending on what part of the MPEG chain you are interested in, the testing requirements will be different: elementary stream (ES), packetized elementary stream (PES), transport stream (TS), program-specific information (PSI) . . . . The terminology is new and confusing for those unaccustomed to digital video. So, how is an MPEG2 signal created and sent through a network? The basic digital video architecture, from the source to the viewer, is shown in Figure 1. The structure of the MPEG2 program and transport streams are shown in Figure 2. These will be described below.

ES

Starting with analog video and audio content, individual ESs are created in the MPEG2 encoder. It is the encoder's job to apply the MPEG2 compression algorithms to the source content. This results in an individual compressed ES for each audio and video stream. If the encoder has done its job properly, the resulting picture and audio will look good; when decoded in a set-top box and viewed on a TV. Just what determines a good ES depends on several factors:

• the quality of the original source material
• the bit rate of the encoded stream
• how well the encoder applies the MPEG2 compression algorithms within the allowable bit rate

MPEG2 compression consists of two main components:

• intraframe spatial compression
• interframe motion compression

Encoders use proprietary techniques to stay within the maximum allowed bit rate while at the same time allocating bits to both compression components, a balancing act which can sometimes be unsuccessful. It is a tradeoff between allocating bits for detail in a single frame and bits to represent the changes (motion) from frame to frame.

Researchers are currently investigating what constitutes a good picture. At the present time, there is no direct correlation between the data in the ES and subjective picture quality. For the time being, the only way of checking encoding quality is with the human eye, after decoding.

PES

Individual ESs are essentially endless. That is, the ES's length is as long as the program itself. Each ES is broken into variable-length packets. The resulting PES contains a header and payload bytes. The header contains information about the encoding process required by the MPEG decoder to be able to decompress the ES. Each individual ES results in an individual PES. At this point, audio and video information still reside in separate PESs. The PES is primarily a logical construct and is not really intended to be used for interchange, transport, and interoperability. The PES also serves as a common conversion point between TSs and PSs (covered below).

TS

Both the TS and PS (see below) are formed by multiplexing PES packets. During the formation of the TS, additional packets, containing tables needed to demultiplex the TS, are inserted. These tables are collectively called PSI. PSI is discussed in further detail below. Null packets, containing a dummy payload may also be inserted to fill the intervals between information-bearing packets. Some packets will contain timing information for their associated program, called the program clock reference (PCR). The PCR is inserted into one of the optional header fields of the TS packet. Recovery of the PCR allows the decoder to synchronize its clock to the same rate as the original encoder clock.

TS packets are fixed in length at 188 bytes with a minimum 4-byte header and a maximum 184-byte payload. The structure of the TS header is shown in Figure 3.

The key fields in the minimum 4-byte header are the sync byte and the packet ID (PID). The sync byte's function is indicated by its name. It is a long digital word used for delineating the beginning of a TS packet.

The PID is a unique address identifier. Every video and audio stream as well as each PSI table needs to have a unique PID. The PID value is provisioned in the MPEG multiplexing equipment. Certain PID values are reserved. Important reserved PID values are indicated in the table below. Other reserved PID values are specified by organizations such as the Digital Video Broadcasting Group (DVB) and the Advanced Television Systems Committee (ATSC) for electronic program guides and other table (see Table 1).

In order to reconstruct a program from all its video, audio, and table components, it is necessary to ensure that the PID assignment is done correctly and that there is consistency between PSI table contents and the associated video and audio streams. This is one of the main testing issues in MPEG.

Other important fields in the TS header include:

• continuity_counter—is a 4-bit field which repeatedly increments zero through 15 for each PID; used to determine if packets are lost or repeated
• program clock reference (PCR)
• discontinuity_indicator—indicates a time base (PCR) and continuity_counter discontinuity; allows the decoder to handle such discontinuities
• random_access_indicator—indicates that the next PES packet in the PID stream contains a video-sequence header or the first byte of an audio frame
• splice_countdown—indicates the number packets of the same PID number to a splice point (when a new PES packet begins)

The resultant MPEG TS output of a multiplexer may be either a single program TS (SPTS) or, more generally, a multiprogram TS. A program consists of one or more ESs with the same time reference (e.g., the audio and video of one movie). It may be helpful to think of an MPEG program as the digital equivalent of a channel in the analog TV world. A multiplexer may also be used to create a multiprogram TS from a number of SPTSs. When this is done, PID values may be changed, underscoring the need for verifying accurate provisioning.

PS

The TS is intended to be transported over lossy networks. For non-lossy transmission media, such as digital video disc (DVD) players, an alternative to the TS, called the PS, is used. The creation of the PS, like the TS, happens in an MPEG multiplexer. A PS contains only a single program and consists of long packets.

PSI

As mentioned previously, PSI is part of the TS. PSI is not one, but a set, of tables which are required for demultiplexing and sorting out which PID's belong to which programs. Figure 4 indicates the sequence of PSI table decoding required to assemble and decompress the contents of a program. Working backwards (in order to determine which audio and video PIDs contain the content of a particular program), a program map table (PMT) must be decoded. Each program required its own PMT with a unique PID value. In order to determine which PID contains the desired program's PMT, the PAT must be decoded. The PAT is the master PSI table with PID value always equal to zero (PID = 0). If the PAT cannot be found and decoded in the TS, then no programs can be found, decompressed, and viewed.

In order for a set-top box to go through the program recovery and decompression process, the PSI tables must be sent periodically and with a fast enough repetition rate that a channel-surfing viewer does not feel that program selection takes too long. Thus, checking the PSI tables for correct syntax and repetition rate is a vital part of MPEG testing.

Another PSI testing problem involves determining the accuracy and consistency of PSI contents. As programs change or multiplexer provisioning is modified the following may occur:

• unreferenced PID—Packets with a PID value are present in the TS that are not referred to in any table.
• missing PID—There are no packets with the PID value referred to in a PSI table present in the TS.

Another useful PSI test is a sanity check of program content. Just because there are no unreferenced or missing PIDs indicated does not mean that the viewer is receiving the correct program. There may also, for example, be a mismatch of the audio content from program A being delivered with the video content from program B. Since MPEG allows multiple audio channels for multiple languages, the sanity check can ensure that viewers are receiving the correct language. It is possible to use a set-top box and television to do the sanity check, but a better way would be to use an MPEG test set which incorporates all the PSI table checks plus a built-in decompressor with picture and audio display. This would allow testing personnel to correlate PSI contents and actual program content as well as allow a quick visual and aural check of ES quality.

TS Health Checks

In addition to the above-mentioned table checks and sanity check, a number of other health checks of MPEG TS packets should be done to ensure that multiplexing and transmission have been done correctly with little or no degradation. The DVB consortium has developed a list of standard TS health checks which are part of ESTI Technical Report ETR 290. These parameters have been grouped into three priority levels.

first priority: necessary for decodability (see Table 2, basic monitoring).

second priority: recommended for continuous or periodic monitoring (see Table 3).

third priority: application-dependent monitoring (see Table 4).

Full definitions of these parameters may be found in ETR290.

Additional TS Tests and Measurements

Other useful MPEG2 TS measurements include real-time monitoring of individual PID bandwidths and PCR jitter. The ability to transmit an MPEG TS may prove useful in debugging networks during installation and maintenance as well as manufacturing applications. For these applications, various pre-encoded MPEG TSs would be stored in the test set ready for recall. In addition, a TS containing a pseudo random bit sequence (PRBS) as a payload can be used to perform bit error rate (BER) tests.