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.
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.
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).
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
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.
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.
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,
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
- missing PID—There are no packets with
the PID value referred to in a PSI table present in the
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