Mpeg-2 Pocket Guide

COUVERTURE Wandel 27/03/00 22:11 Page 1
Wavetek Wandel Goltermann Worldwide VOL. 6
North America Asia-Pacific Eastern Europe
Digital Broadcast Systems

Picture: © Valery Hache
P.O. Box 13585 P.O. Box 141 Middle East/Africa
1030 Swabia Court
Research Triangle Park
NC 27709-3585
South Melbourne,
Victoria 3205
Australia
Postfach 13
Elisabethstrasse 36
A-2500 Baden
MPEG-2
USA Tel. +61 39 690 6700 Austria Pocket Guide
Tel. +1 919 941 5730 Fax +61 39 690 6750 Tel. +43 22 52 85 521 0
Fax +1 919 941 5751 Fax +43 22 52 80 727
Western Europe
Latin America Arbachtalstrasse 6 CIS Countries Digital Broadcast
Av. Eng. Luis Carlos Berrini D-72800 Eningen u.A. 1st Neopalimovskiy per.15/7
936-8/9 Andar Germany (4th floor) Systems
04571-000 Sao Paulo, SP Tel. +49 7121 86 2222 119121 Moscow
Brazil Fax +49 7121 86 1222 Russia
Tel. +55 11 5503 3800 Tel. +7 095 248 2508
Fax +55 11 5505 1598 Fax +7 095 248 4189
MPEG-2 Pocket Guide

Internet Address
http://mpeg.wwgsolutions.com
E-mail Address
mpeg@wwgsolutions.com
Nominal charge US$ 10 - DB/RN/PG01/0400/AE

Pocket Guide to MPEG-2 Fundamentals and Testing
Publishers: Wavetek Wandel Goltermann

Digital Broadcast Test Tools
9145 Balboa Avenue
San Diego, CA 92123, USA
Wavetek Wandel Goltermann

Digital Broadcast Monitoring Systems
15, rue du Chêne Germain
35510 Cesson Sévigné, FRANCE
e-mail: mpeg@wwgsolutions.com
Please ask for:
Vol. 1 Vol. 3 Vol. 5

SDH SONET E1
Pocket Guide Pocket Guide Pocket Guide
Fundamentals and SDH Testing Fundamentals and SONET Testing The World of E1
E 5.98/WG1/1006 E 7.98/WG1/1013 LL/PL/0018/0100/BE
Vol. 2 Vol. 4
GSM ATM
Pocket Guide Pocket Guide
Fundamentals in Mobile Radio Networks Fundamentals and ATM Testing
E 8.98/WG1/1015 E 2.99/WG1/1020
POCKET Guide (96 Pages) 23/03/00 15:02 Page 1
CONTENTS 1 Introduction ......................................................................................1

2 MPEG history ....................................................................................2
2.1 MPEG-1........................................................................................4
2.2 MPEG-4........................................................................................5
3 MPEG-2 Compression and Transport ..............................................5
3.1 Video Compression....................................................................7
3.1.1 Spatial Encoding ..................................................................8
3.1.2 Temporal Encoding ............................................................10
3.1.3 Decoding ............................................................................12
3.2 Audio Compression ................................................................14
3.2.1 AC-3 ....................................................................................16
3.3 From ES to PES and from PES to Transport Stream ..............16
3.4 Timing: PCR, PTS and DTS ......................................................18
3.5 PSI Tables..................................................................................20
3.5.1 PAT ......................................................................................21
3.5.2 CAT ......................................................................................22
3.5.3 PMT ....................................................................................23
3.5.4 NIT ......................................................................................23
3.6 Summary ..................................................................................24
4 Digital Video Broadcasting (DVB)..................................................25
4.1 DVB History ..............................................................................25
4.1.1 DVB System Information (SI) Tables ..................................27
4.2 DVB and Internet Protocol (IP) ..............................................33
5 Advanced Television Systems Committee (ATSC)..........................36

5.1 ATSC History ............................................................................36
5.1.1 ATSC Program and System Information Protocol
(PSIP) Tables ................................................................................37
6 Transport Stream Analysis/Simulation: Why, How and
What to Test....................................................................................43
6.1 Why Should I Test? ..................................................................43
6.1.1 Testing the Limits of the Protocol ....................................45
6.1.2 Interoperability ..................................................................46
6.1.3 Handling Errors ..................................................................48
6.2 How Do I Test? What Equipment Do I Need? ......................49
6.2.1 Emulation or Simulation .................................................. 49
6.2.2 Elementary Stream Analysis ..............................................53
6.2.3 Analysis of a Transmission System ....................................56
6.3 What Do I Look For?................................................................58
7 Glossary ..........................................................................................70
8 Reference Materials........................................................................86
8.1 MPEG Specifications ................................................................86
8.2 DVB Specifications ..................................................................87
8.3 ATSC Specifications ................................................................88
8.4 Other References ....................................................................89
8.5 Useful Websites ......................................................................89
Index ..................................................................................................90
1 Introduction
In 1936, the year of the Berlin Olympic Games, spectators crowded
into specially built viewing rooms called Fernsehstuben (literally, tele-
vision rooms) to catch a glimpse of one of the first-ever television
broadcasts. In black and white, 180 lines/frame, and 25 frames/second,
it would hardly compare to television by today’s standards; however,
it became the progenitor of modern-day broadcasting, one of the
most powerful tools of the Information Age.
Now, nearly seven decades later, the international community stands
at the dawn of a new millennium. The great technological advances
of the past century propel us toward the next great advancement or
invention at a frantic pace. More than ever before, international orga-
nizations of experts are pooling their resources—working together
for the greater good of the entire world. Digital broadcasting is one
of the newest technological advances to rest on the shoulders of inter-
national collaboration. In 1990, the Moving Pictures Experts Group,
commissioned by the ISO/IEC international standards organizations,
organized a multinational group of experts to begin work on the
MPEG-2 specification. This standard has become the backbone for
digital television as we know it.
1
This pocket guide will help you to become familiar with the basics of
digital broadcast transmission. It discusses, in some detail, MPEG-2
audio and video compression and the MPEG-2 system layer. It also
provides an overview of the DVB and ATSC standards, which are
extensions of MPEG-2. In addition to outlining the standards, it discusses
the need for test and verification in the digital broadcast environment,
provides several test scenarios, and discusses why and how to test
MPEG-2 transport streams in order to ensure the highest-quality
transmission now and in the future.
The pocket guide ends with a Glossary of Terms, a Reference Material
List and an Index. Because this guide is not exhaustive, we encourage
you to consult the Reference Material list for continued study.
2 MPEG History
In 1987 the International Electrotechnical Commission (IEC) and the
International Organisation for Standardisation (ISO) joined forces to
create JTC 1 (Joint Technical Committee 1). The JTC’s mission was to
coordinate international standardization for Information Technology
(IT). To handle this task, the Committee split its resources into various
subcommittees, one of which was Subcommittee 29 (SC 29), formed
to investigate the standardization of audiovisual coding. SC 29,
entitled “Coding of audio, picture, multimedia, and hypermedia
2
information”, was further divided into several working groups. Working

Group 11 (WG 11), “Coding of Moving Pictures and Audio,” later
became known as MPEG, or the Moving Pictures Expert Group.
When the first official MPEG meeting was held on 10 May 1988,
digital television broadcasting was no more than a vision. The
development of audio CDs had already proven that analog signals
could be digitized to produce better quality sound that required less
bandwidth than traditional analog storage methods. The implications
of digitization stretched as far as television, where the lower
bandwidth would make room for more programs, internet services
and interactive applications. Still, the compression and transmission
of digital sound and video together would require extensive research.
For broadcasters to make the transition from analog to digital, they
would need entirely new methods of broadcasting, including new
technology, new equipment and new international standards.
MPEG consists of a family of standards that specify the coding of video,
associated audio and hypermedia. These standards include MPEG-1,
MPEG-2 and MPEG-4. Though this guide deals mainly with MPEG-2,
the digital broadcasting standard, we will discuss MPEG-1 and
MPEG-4 briefly.
3
For more information about the Moving Pictures Experts Group or the
MPEG standards, see http://www.mpeg.org.
2.1 MPEG-1 MPEG-1 is the original MPEG standard for audio and video coding.
First published in 1993, this standard defines digital audio and video
compression for storage at up to approximately 1.5 Mbps. Like all
MPEG standards, MPEG-1 is flexible in that it defines only the syntax
and semantics of the encoded bit stream, and not the encoding
process itself. Common applications for MPEG-1 include the storage
of sound and pictures for interactive CDs such as video games and
movie CDs. MPEG-1 has also been used for digital radio broadcasts.
Soon after work on MPEG-1 began, champions of the “digital television”
concept realized that MPEG-1’s syntax and structure would not
support the complexity and versatility of digital TV. Hence, in 1990,
work began on MPEG-2, the standard that would make digital tele-
vision broadcasting a reality. We will discuss MPEG-2 in greater detail
in the next chapter.
4
2.2 MPEG-4 MPEG-4 represents the next breakthrough in audiovisual coding. It

allows for simultaneous coding of synthetic and natural objects and
sound, giving service providers more options for creating games and
other multimedia applications. It extends interactive possibilities by
allowing the user to manipulate, among other things, views and the
viewing perspective.
MPEG-4 also allows for the coding of arbitrarily shaped objects,
instead of the standard rectangle-shaped video frame. Because of this,
the standard allows even greater compression than MPEG-1 or MPEG-2
and will be used for applications with especially limited data capacity.
Though digital broadcast will continue to use the MPEG-2 standard,
MPEG-4 will serve a variety of applications including networked
video applications, computer games and wireless services.
3 MPEG-2 Compression and Transport

MPEG-2 refers to the set of standards developed by the Moving Pictures
Experts Group for audio and video compression, transportation of
multiple compressed programs in a single multiplex, and encapsulation
of data into the multiplex. It defines a mechanism to compress a video
signal to as much as 30 times less than its original size.
5
Because of MPEG compression, broadcasters no longer need as much

bandwidth to send a single TV program. This gives them the option
to include other programs and services in their commercial offering.
These programs and services might include high definition television
(HDTV), more channels to choose from, programming in different
languages, internet services and interactive TV.
The MPEG-2 standard defines the structure and syntax of the encoded
bit stream but does not specify the method for encoding the bit stream.
This flexibility gives manufacturers and content providers room to
develop improved solutions for specific applications with the knowledge
that their equipment or content is based on an international standard
that is unlikely to change. The goal of MPEG-2 video and audio
compression is to reduce redundancy without affecting quality.
However, compression involves compromise; therefore, it does not
necessarily produce an original-quality sound or image. The more
a signal is compressed, the lower the quality of the resulting signal.
To offer broadcasters and consumers flexibility to choose between
high compression (more available services—lower quality signal) and
high quality, MPEG specifies different profiles and levels, each
offering a different degree of compression vs. quality.
6
The following figure shows a simplified example of how MPEG-2

transport streams are created from audio and video signals.
Single Program
Stream #1
1 0 1 1 0 0 1 0 1
Single Program Multiple Program Stream
Stream #2
Multiplexer
Encoders
3.1 Video Video compression depends on (1) redundancy within and between
Compression pictures or frames and (2) the characteristics of the human visual
system. Two types of compression, spatial encoding and temporal
encoding, allow encoders to reduce redundant data significantly,
thereby greatly decreasing the bandwidth required to transmit a video
stream. Video compression also makes use of the eye’s inability
to detect certain visual degradations including noise in a “busy”
picture area and reduced color spatial frequency in a picture.
7
3.1.1 Spatial Spatial redundancy deals with similarities between adjacent pixels in
Encoding plain areas of a picture. For instance, a picture that contains a blue-
sky background will likely contain several rows of identical blue pixels.
Spatial encoding codes only one of these pixels, significantly reducing
redundancy in the bit stream. This type of encoding involves a series
of steps including Discrete Cosine Transform (DCT), weighting,
scanning and entropy coding.
The first step in spatial encoding, Discrete Cosine Transform (DCT),
requires that the video waveform be transformed into a matrix of
spatial frequencies. This matrix includes blocks of 8x8 pixels which,
when transformed, provide a series of coefficients that indicate the
prevalence of a given frequency in each pixel. Since the transform
requires multiplication by fractions, the resulting coefficients often
have a longer word length (or number of bits needed to express
a value) than the pixel values themselves. Hence, DCT itself does not
compress the picture block; rather, it actually expands it. However,
because of spatial redundancy, many coefficients end up with zero or
near-zero values, which means that the corresponding pixels can be
dropped from transmission as the differences are not visible to the
viewer. This allows for considerable compression with minimal
degradation in quality.
8
If even greater compression is needed, then the word length of the

remaining coefficients must be expressed in fewer bits. Reducing the
word length reduces the accuracy of these coefficients and introduces
degradation into the picture. With the process of weighting, degra-
dation in a picture can be strategically placed where the viewer is least
likely to notice it.
Weighting takes advantage of the fact that more noise can be tole-
rated at higher spatial frequencies. In other words, where the images
on the screen are more detailed or complex, imperfections in the video
transmission are less noticeable to the viewer. Weighting re-quantizes
DCT coefficients based on their perceptual importance to the viewer.
This process ensures that coefficients with the highest frequency are
accompanied by the greatest amount of noise. In this way, noise is
most likely to occur where it is least likely to be perceived by the viewer.
After quantization and weighting, the matrix is reorganized with the
most significant DCT coefficients placed in the top-left corner of the
matrix; coefficients with insignificant values are changed to zero.
Scanning makes use of this new organization to reorder coefficients
so they will be sent in order of importance. In this way, the most
significant coefficients are sent first, followed by an indication within
the code that the remaining coefficients are all zero.
9
The final step in spatial coding deals with entropy coding, which resizes
coefficients based on the number of times they occur. Frequently repeated
coefficients are expressed in the smallest word length, thus greatly
decreasing the total amount of bandwidth used to transmit a single frame.
3.1.2 Temporal Temporal encoding eliminates redundancy between individual frames

Encoding in the video stream. This can be accomplished through motion esti-
mation and inter-frame prediction. Imagine, for instance, that you
are encoding video that shows the bird’s-eye view of a soccer game.
Though the players move from frame to frame, the background
scenery - the field itself - doesn’t change. Temporal coding takes
advantage of the similarities between sequential frames and encodes
only the differences from one frame to the next. Two types of
temporal coding are Inter-frame Prediction and Motion Prediction,
which are discussed below.
❑ Inter-Frame Inter-frame prediction uses one complete frame, called an Intra-coded

Prediction frame (I-frame), as a basis from which to reproduce other frames in
the video stream. Redundant information is transmitted only once,
allowing for major bit rate reduction.
10
I-frames represent only one of three types of frames used in Inter-

frame prediction. Predicted frames, or P-frames, are predicted from
either a previous I-frame or a previous P-frame. Instead of transmitting
all the transform coefficients for a P-frame, the encoder transmits only
those coefficients that differ from the preceding I- or P-frame. At the
decoder, P-frames are re-created using the preceding I- or P-frame as
a reference, and applying the differentials. B-frames are bi-directionally
predicted in the same fashion from either preceding or subsequent I- or
P-frames. Where a P-frame generally requires 1/2 of the data
of an I-frame, a B-frame requires only 1/4.
Of course, using only one I-frame as a basis for creating all other frames
in a video stream would leave the stream extremely vulnerable to
error, since an error in the I-frame would propagate indefinitely. For
this reason, frames are divided into Groups of Pictures (GOPs),
usually 12-15 pictures long. GOPs always begin and end with
a complete I-frame, providing for rapid error correction when
the preceding I-frame has become corrupted. GOPs also contain P-frames
and B-frames. Below is one example of a Group of Pictures.
Encoding/
Presentation
sequence I1 ➙ B1 ➙ B2 ➙ P1 ➙ B3 ➙ B4 ➙ P2 ➙ B5 ➙ B6 ➙ I2
11
❑ Motion Though objects may change location on the screen, their appearance
prediction oftentimes remains the same. Motion Prediction takes advantage of
this similarity by measuring an object’s motion at the encoder. This
measurement is sent as a motion vector to the decoder. The decoder
then uses this vector to shift the specified image from its location in
the previous frame to a new location in the next frame. Typically,
motion continues across several frames, so even greater compression
can be attained when vectors are transmitted differentially. For
instance, if an object’s speed is constant, the motion vectors do not
change; only a vector differential of zero is transmitted.
3.1.3 Decoding The decoding of MPEG-2 audio and video streams reverses the encoding
process one for one. An inverse DCT process restores frequency
coefficients according to the accuracy of the encoder. The decoder
then uses transmitted macroblocks from I- and P-frames to replace
redundant macroblocks discarded from P- and B-frames during encoding.
Motion vectors specify the location of these macroblocks within the
predicted frames.
As explained above, in order to decode a B-frame, data from both the
previous and next pictures must be available in the decoder. Therefore,
inter-frame prediction requires that frames be sent out of sequence
12
and stored temporarily in the decoder. Consider the order in which

the frames in the above sequence must be decoded before they can
be presented to the viewer:
Transmission/
Decoding I1 ➙ P1 ➙ B1 ➙ B2 ➙ P2 ➙ B3 ➙ B4 ➙ I2 ➙ B5 ➙ B6
Order
Presentation
Order I1 ➙ B1 ➙ B2 ➙ P1 ➙ B3 ➙ B4 ➙ P2 ➙ B5 ➙ B6 ➙ I2
Decoding Time Stamps (DTS) and Presentation Time Stamps (PTS) within
the header of each frame ensure that the frames are decoded on time
and presented in the proper order. For more information about time
stamps, see section 3.4 Timing: PCR, PTS and DTS.
13
3.2 Audio Similar to the compression of video, MPEG audio compression also
Compression capitalizes on the characteristics of a human sensatory organ-this time,
it’s the human ear. The compression takes into account both auditory
masking, where a louder sound will hide a softer sound, and time
uncertainty, where a sound in the past or future will interfere with
the ear’s ability to hear a current sound. One example of auditory
masking occurs when you try to carry on a quiet conversation in
a train station. Passing trains drown out your conversation each time
they speed by. In the presence of the sound generated by the train,
the quiet voices in the conversation become imperceptible.
Auditory masking is most prevalent among sounds with similar
frequencies. Its effect depends on the frequency separation between
a loud sound and the quieter sound being masked. The closer two
signals are in frequency, the more likely it is that one sound will drown
out the other, though it may be only slightly louder. For example,
if two horns are playing at two similar high frequencies, the quieter
horn cannot be heard, but a bass drum playing at the same sound
level as the quieter horn will likely be heard, since its frequency is
significantly different from that of the louder horn. Since the sensitivity
of the ear is frequency dependent, the effect of masking is also
frequency dependent. Sounds at lower frequencies must be even closer
14
together in order to be masked than sounds at higher frequencies.

The dynamic range is also frequency dependent, and the area of
largest dynamic range is the range of normal speech.
In order for sounds to mask each other, they need to occur at the same
time or nearly the same time. In fact, there is a range of time several
milliseconds long before and after a loud masking sound during
which its masking effects will still be present.
In order to capitalize on these auditory characteristics, the audio com-
pression algorithms break the audio spectrum into many subbands.
The dynamic range in each subband is reduced separately such that
the effects of a dynamic range’s compression are not noticeable. This
means that instead of 16 bits per audio sample in each subband,
there might only be 2-4 bits per sample. A scaling constant for each
band is also used. The allocation of bits per subband is divided such
that the important frequency ranges receive more weighting. The size
of a subband also varies by frequency in order to match the masking
by frequency in the human ear.
An audio signal is compressed in blocks such that the allocation of
frequency information can be changed over time, and time masking
can be used effectively. The typical size of an audio block is 24 milli-
seconds.
15
3.2.1 AC-3 The Dolby AC-3 audio compression algorithms use the same humanear
characteristics described above, but the methods they use to divide
the frequencies and process the data are different than the ones used
by MPEG. The AC-3 algorithm also uses audio blocks of data.
3.3 From ES to PES Once an audio or video elementary stream has been compressed, it is
and from PES divided into variable-length packets and converted into a Packetized
to Transport Elementary Stream (PES). Video stream packets include one frame
Stream each, while audio stream packets usually include approximately 24
milliseconds of sound each. Each packet contains a header and a pay-
load. The header gives timing information so the decoder will know
at what time to decode and present the specified frame.
Image Video Elementary Stream

structure
Useful data
Fixed or variable
Header length
Packetized
Elementary Stream
16
From here, PESs are further divided into transport packets of 188 bytes
each and multiplexed with other elementary streams and data to form
a transport stream containing audio and video for multiple programs.
The transport stream also contains system information in the form of
PSI/SI/PSIP tables, which we will discuss later. It may also contain data
for interactive applications. The use of fixed-size transport packets
simplifies the multiplexing and transmission processes along the
broadcast chain.
MPEG-2 Video Image

Video Elementary Stream
Syntax structure
Header Useful data

Fixed or variable
length Packetized Elementary Stream
MPEG-2 System
Syntax
... Transport Stream
Header Useful Stuffing

data
Fixed length
(188 bytes)
17
Each packet in the transport stream, whether it contains audio, video,

system information, or data, is identified by a number called a PID, or
Packet Identifier. PIDs help the decoder find and sort information in
the transport stream. This will become more apparent when we
discuss MPEG-2’s system layer and the use of tables. These tables,
called PSI, SI, or PSIP tables, enable the decoder to locate the various
programs and their components in a multiple-program stream. They
also provide Electronic Program Guide (EPG) information. The tables
are organized into a hierarchical tree structure.
3.4 Timing: PCR, End-to-end synchronization, as well as synchronization between

PTS and DTS components in a transport stream, is based on the system clock of the
encoder. The encoder uses this clock to periodically send timing infor-
mation in the transport stream with a Program Clock Reference (PCR).
Elementary stream packets contain time stamps called Presentation
Time Stamps (PTSs) and Decoding Time Stamps (DTSs).
Since frames are not always transmitted in the order in which they
appear on the screen, the PTS allows the decoder to determine, based
on the PCR, the time at which a frame must be presented to the
viewer. As we mentioned earlier, MPEG-2 compression creates
dependencies between frames.
18
For instance, a B-frame cannot be decoded without referencing the

previous and next I or P frames. Because of this dependency, some
frames may need to be decoded well before their presentation time.
To manage this condition, a DTS in the header of each PES packet
notifies the decoder of the time at which a frame must be decoded.
If the DTS precedes the PTS for a specific frame, the frame is decoded
and held in a buffer until its presentation time arrives.
The following figure shows the timing sequence in the transport
stream. At the encoder, a stamp of the system clock is put into the PES
with a PTS and/or DTS. Samples of the system clock are added to the
transport stream via PCRs. On the decoder side, the PCRs are put
through a Phase Lock Loop (PLL) to recover the original system clock.
This ensures that the decoder is synchronized to the encoder so that
data buffers in the decoder do not overflow or underflow. Once the
original system clock is recovered, programs are then decoded and
presented as specified by the PTS and DTS time stamps for each
individual frame.
19
System Clock System Clock

based on 27 MHz based on 27 MHz
P.L.L.
P.L.L.
Presentation
Frequency
CODAGE PES DECODAGE
PCR
PES Time Stamp: P.L.L.
PTS and DTS MULTIPLEXAGE DEMUX
Presentation
Frequency
Transport
CODAGE PES
Time Stamp:
PCR
DECODAGE
PES Time Stamp:

PTS and DTS
3.5 PSI Tables MPEG-2 Program Specific Information (PSI) tables provide the data
required for a decoder to demultiplex a program from a transport
stream for presentation to a user. This information can include loca-
tion of audio and video for a certain program, access rights, and infor-
mation regarding the compression and characteristics of audio and
video signals. The tables are repeated periodically (for example,
10 times/second) in the transport stream to support random access
required by a decoder turning on or switching channels.
20
3.5.1 PAT Think of the Program Association Table (PAT) as a root directory for
the transport stream. This table lists all the programs in the stream
and provides the PID (Packet Identifier) value for the Program Map
Table (PMT) associated with each program. The PAT can also contain
the PID number for the Network Information Table (NIT), which pro-
vides access to other transport streams in the network. The decoder
is always able to find the PAT (if present in the stream) since it is always
in packets with a PID value of 00.
PAT (PID 00)

Prog. 1 PMT PID 65
Prog. 2 PMT PID 32
Prog. 3 PMT PID 56
Prog. 4 PMT PID 120
NIT PID 16
21
3.5.2 CAT The Conditional Access Table (CAT) provides a mechanism for decoders
to find Entitlement Management Messages (EMMs) in the transport
stream. EMMs update the subscription options or pay-per-view rights
for each subscriber or for groups of subscribers. The CAT lists the EMMs
in the transport stream and gives the associated PID values.
CAT (PID 01)
EMM A PID 61
EMM B PID 76
EMM C PID 38
EMM D PID 109
3.5.3 PMT The Program Map Table (PMT) provides a description for each program
in a transport stream. This table literally acts as the map for a program,
listing the PID values for its video, audio, clock reference and data
components. With this information, the decoder can locate the audio
and video for the program and display them synchronously.
22
PMT Program 1 (PID 65)

Components of Program 1
Video PID 131
Audio English PID 132
Audio German PID 133
3.5.4 NIT The Network Information Table (NIT) provides information regarding
other transport streams in the network. This table is not defined in
MPEG-2, but DVB and ATSC have either defined it or identified another
method for providing information similar to it.
23
3.6 Summary PAT (PID 00)

PMT Program #1 (PID 65)
Video Program #1 (PID 131)
Audio German Program #1 (PID 132)
Audio English Program #1 (PID 133)
...
PMT Program #N (PID XY)
Video Program #N (PID YZ)
Audio German Program #N (PID ZZ)
Audio French Program #N (PID XY)
Audio Italian Program #N (PID XZ)
The following steps outline the process followed by a decoder to

display a certain program, in this case, Program 1:
1. Locate the PAT (always found on PID 00) and use it to find the PMT
information for Program 1.
2. Use the PMT for Program 1 (defined as PID 65 in the PAT) to
locate the PIDs for the audio, video and clock reference in Program1.
The PID for the video stream often carries the PCR.
24
3. Find the packets that contain the video (PID 131) for Program 1.
4. Find the packets that contain the audio for Program 1. If the user
has selected the sound track in German, locate the audio track on PID
132. If the user has requested the English sound track, locate the audio
on PID 133.
5. Use the PTS and DTS in the header of audio and video packets to
decode and present them at the proper time.
4 Digital Video Broadcasting (DVB)
4.1 DVB History The DVB Project began in September 1993 when public and private
television organizations from across Europe signed an agreement to
work together for the creation of a digital broadcasting standard that
would bring digital television to the home. Because the DVB Project
united major players in the European broadcast market, it provided
a forum through which a truly unified digital television system could
be created. In time, the organization developed international
standards for satellite, cable and terrestrial transport.
25
The Project now includes over 220 participants in more than 30 nations
worldwide. Because the DVB standard applies to all types of trans-
mission links - satellite, cable and terrestrial - it eliminates redundancy
in research and design, reducing costs to manufacturers. Because the
standard is employed throughout Europe and in many countries across
the world, digital transmission to all countries under the DVB umbrella
need only be tested to fit DVB parameters. Even for terrestrial
broadcast, where information can be transmitted in multiple ways by
different service providers, the DVB standard limits the variations in
transmission from one provider to the next. This minimizes testing
costs for network operators, system integrators, service providers and
broadcasters.
Though this pocket guide focuses mainly on the System Information
specified by DVB, the standard also addresses other parts of digital
transmission, such as transmission mechanisms and data services.
For more information on these aspects of the DVB standard,
see http://www.dvb.org.
26
4.1.1 DVB System While MPEG-2 PSI tables organize the transmission of compressed
Information (SI) audio and video in a single transport stream, they are not designed
Tables to provide information for the large number of programs and services
available on a network of multiple transport streams. DVB Service
Information (SI) tables give service providers the tools they need to
offer programs and services across a large network that may include
many transport streams. SI tables function much like the Table of
Contents in a multi-chapter book. They enable receivers and set-top
boxes to access information anywhere in the MPEG/DVB network,
or bouquet of multiplexes, by providing information for events and
services available on all transport streams in the system. SI tables also
provide information for the Electronic Program Guide (EPG),
which supplies viewers with a list of all the programs and services
available, along with their duration and a description of their content.
SI tables have a specific structure similar to a file-management tree
structure on a PC with a root directory and subdirectories. They use
specific PID values for transmission and identification by any receiver.
There are four mandatory DVB SI tables: the Time and Date Table
(TDT), the Network Information Table (NIT), the Service Description
Table (SDT), and the Event Information Table (EIT).
27
❑ Time and Date This table provides the present UTC date and time, which can be adjusted
Table (TDT) according to time zone and presented on screen for the viewer.
❑ Network A Network is a system of one or more transport streams controlled by

Information a single content provider. The Network Information Table (NIT) contains
Table (NIT) information regarding the physical organization of the transport
streams carried on a single network, including the tuning parameters
that enable the receiver to change channels at the viewer’s command
with little or no delay. Tuning parameters are specific to the type of
transmission assigned to the network - terrestrial, cable or satellite.
This table also includes characteristics about the network itself.
28
The NIT defines tuning parameters for the channels in the network.
NETWORK A NETWORK B
Channel A1 Channel A2 Channel A3 Channel B1 Channel B2 Channel B3
❑ Service A Service is a sequence of programs under the control of a broadcaster,

Description which can be broadcast as part of a schedule. The Service Description
Table (SDT) Table (SDT) provides information about the services available in the
network, including the name of the service provider and the textual
description of the channel. Two types of SDTs, “Actual” and “Other”,
are required by DVB. The SDT Actual describes the services available on
the transport stream currently being accessed by the viewer, while the
SDT Other describes services available on other transport streams in the
network. This information is used in the Electronic Program Guide (EPG)
to provide the viewer access to all the services available on the network.
29
The SDT provides information about the services in the network.
NETWORK A NETWORK B
Service Service Service Service Service Service Service Service Service Service
A11 A12 A13 A31 A32 B11 B12 B13 B31 B32
❑ Event An event is a collection of elementary streams with a common time

Information base set to start and end at the same time. (We often refer to events
Table (EIT) as “TV programs”.) The Event Information Table (EIT) provides infor-
mation about events in the network, such as their start time and dura-
tion. Three different types of EITs can be transmitted at the same time:
EIT Present and Following and the EIT Schedule. The EIT Present
describes the events currently being broadcast on the transport
stream accessed by the viewer, while the EIT Following provides
30
information about the next events to be broadcast on that transport

stream. The EIT Schedule lists events available on the network for
anywhere from the next few hours to the next few days, depending
on the service provider’s implementation.
The EIT is used to create the EPG, which gives the viewer access
to all the events available on the network.
NETWORK A NETWORK B
Service Service Service Service Service Service Service Service Service Service
A11 A12 A13 A31 A32 B11 B12 B13 B31 B32
31
❑ Optional DVB Optional DVB tables include:

Tables
Bouquet Association Table (BAT)—A Bouquet is a commercial offering, or
a group of services that can be purchased as a single product. The Bouquet
Association Table (BAT) describes the services available in a given bouquet.
Running Status Table (RST)—This table carries information used to
update the timing status of events in the system when scheduling
changes occur. This saves broadcasters from having to retransmit an
entire table when only a portion of the content changes.
Timing Offset Table (TOT)—This table contains the UTC time and date,
along with the local time offset.
Stuffing Table (ST)—The Stuffing Table invalidates the remaining sec-
tions in a table when one section has been overwritten. This main-
tains the integrity of the section_number field.
32
4.2 DVB and Internet DVB’s recently developed Data Broadcasting specification allows for
Protocol (IP) high-speed data transfer via satellite, cable and terrestrial television
channels. Some potential applications for data broadcasting include
data-casting, downloading software, providing Internet services over
broadcast channels, and interactive TV. Data casting and surfing the
web via satellite offer consumers internet services at much greater
speeds than the typical telephone modem can offer. Where the trans-
mission of a 10MB file can take 30–45 minutes via telephone modem,
the same file can be downloaded via satellite to a high-performance
system in less than 20 seconds.
There are different implementations for data-broadcast over DVB.
The following figure summarizes the operation for multi-protocol
encapsulation (MPE) of IP as defined in the DVB standard, which uses
table section encapsulation into transport packets from MPEG-2.
33
IP datagrams
4 Kbyte
DVB table sections
Table_ ID xyz
1
130 byte 180 byte 188 byte 180 byte
MPEG-systems MPEG-systems MPEG-systems MPEG-systems
transport packets transport packets transport packets stuffing packets
PID 0x0400 PID 0x1234 Etc. PID 0xnnnn PID 0x1FFF
2
40 to 60 Mbit/s
MPEG-systems
multiplex
DVB-S
QPSK satellite modulation
34
❑ Fragmentation Step 1 benefits from a predefined data-fragmentation mechanism.

into MPEG Multi-kilobyte pieces of data, such as IP datagrams in DVB tables, are
Transport fragmented in fixed-size (188-byte) MPEG transport packets with mini-
Packets mal overhead. A series of transport packets for a given data stream
is identified by a user-defined PID (Packet ID) value, such as PID 0x0400,
as seen in the example. Notice that each packet will automatically
benefit from a standard Reed Solomon forward-error correction (FEC)
mechanism later during the digital modulation.
❑ Multiplexing Step 2 in the process is the multiplexing of the transport packets from
the various multiple data streams—possibly along with video and audio streams
Data-Streams for digital TV—in a single MPEG transport stream. A transport stream
is a flagged bit stream with a fixed bit-rate corresponding to the per-
formance of the digital modulation through the satellite transponder.
Null packets are used for stuffing as the total bandwidth is rarely used
for Quality of Service (QoS) reasons.
35
5 Advanced Television Systems Committee (ATSC)
5.1 ATSC History In 1987, the U.S. Federal Communications Commission (FCC) appointed
a special Advisory Committee as counsel regarding the technical and
political issues of Advanced Television (ATV). The formation of this
committee sparked a fierce competition among broadcast industry
leaders who hoped to propose to the Advisory Committee a system
that would be accepted as the nation’s standard. Twenty-three
proposals were originally brought before the Advisory Committee,
but by 1993, only four remained. The Committee tested these remaining
systems extensively and found deficiencies in each. In order to eliminate
these deficiencies and take advantage of the strengths found in each
system, the Advisory Committee encouraged the remaining competitors
to form a consortium by which they could work together to create
a U.S. standard for ATV broadcasting.
In response to this request, the remaining companies formed the HDTV
Grand Alliance in May of 1993. Within the Alliance, they worked
together to build a final prototype system based on specifications
approved by the Committee. The Committee called upon the
Advanced Television Systems Committee (ATSC) to develop and document
the detailed specifications of the new ATV standard based on
36
the Grand Alliance system. ATSC Digital Television Standard (A/53),

the document produced by the ATSC membership, was accepted in
1996 by the FCC for digital terrestrial television broadcast in the U.S.
Though ATSC was initially a North American organization, its charter
has been modified to include members from other countries. It now
serves more than 200 members in several nations worldwide.
5.1.1 ATSC Program Like DVB SI tables, ATSC PSIP tables act as extensions to the MPEG-2
and System system layer, allowing broadcasters to make a larger number of
Information products and services available to the viewer. Unlike DVB, however,
Protocol (PSIP)
ATSC was created mainly for terrestrial broadcast where services are
Tables
made available through local TV stations that offer a limited number
of programs. Up to this point in time, the ATSC standard has been
used mainly for terrestrial applications, though it also provides parameters
for Cable TV (CATV) transmission.
PSIP tables are organized in a hierarchy similar to their DVB counter-
parts. They are identified by specific PID values and can thus be
identified by any ATSC receiver. PSIP tables include: the Master Guide
Table (MGT), the Virtual Channel Table (CVCT for cable, TVCT for
terrestrial), the System Time Table (STT), the Rating Region Table (RRT),
the Event Information Table (EIT), and the Extended Text Table (ETT).
37
These tables are organized into three types:

• Base tables, which are always found on PID 0x1FFB. These include
the MGT, the VCT, the STT and the RRT;
• EITs whose PID values are defined in the MGT;
• ETTs whose PID values are also defined in the MGT.
❑ System Time The System Time Table consists of only one packet that serves as a
Table (STT) reference for the current time of day. This information enables the
receiver to start advertised events on schedule.
PID 0x1FFB
STT
Current time
38
❑ Rating Region This table transmits program-rating systems for each country that uses
Table (RRT) a rating standard. The information in this table allows viewers to
filter certain programs based on their content.
PID 0x1FFB
STT
Current time
RRT
Rating standards
per country
39
❑ Master Guide The Master Guide Table acts as an index for all other tables in the PSIP
Table (MGT) standard. It defines table sizes (necessary for proper decoding),
version numbers (which help to identify the tables that need to be
updated), and PID values (which enable the decoder to locate the EITs
and ETTs in the system).
PID 0x1FFB
STT
Current time
RRT
Rating standards
per country
MGT
Table type, ID, PID “xyz”
version and size
VCT EIT-0 EIT-1 Etc. EIT-n

Source_id
news channel
sport 1
sport 2
radio
movies
40
❑ Virtual This table lists all the channels in the transport stream and defines
Channel Table their characteristics. It includes information such as channel name,
(TVCT - terrestrial, stream components and types, and navigation identifiers. It identifies
CVCT - cable)
a source_id for each program, which the EIT uses to locate and
display information for the Electronic Program Guide.
PID 0x1FFB
STT
Current time
RRT
Rating standards
per country
MGT
version and size
VCT EIT-0 EIT-1 Etc. EIT-n

Source_id
news channel
sport 1
sport 2
radio
movies
41
❑ Event The Event Information Table defines the events (TV programs) asso-
Information ciated with each of the virtual channels listed in the VCT. Information
Table (EIT) contained in this table might include an event’s start time and dura-
tion. According to the PSIP specification, between 4 and 128 EITs must
be in the transport stream at any given time. Each EIT provides event
information for a three-hour time period, so up to 16 days of pro-
gramming can be advertised in advance. EIT-0 always contains infor-
mation for the current 3-hour time block, while EIT-1 defines
programming for the next 3 hours.
PID 0x1FFB
STT
Current time
RRT
Rating standards
per country
MGT
version and size
Min. 3
VCT EIT-0 EIT-1 Etc. EIT-n Max. 127
Source_id
9:00 news
news channel weather etc. Tab_id 0xCB
sport 1
9:30 World
sport 2 cup finals
radio
11:30
movies Casablanca
3 hour period
42
❑ Extended Text Extended Text Tables carry text messages describing both channels
Table (ETT) and events; hence, there are two types of ETTs: Channel ETTs and Event
ETTs. ETTs give the viewer more detailed information than is available
in the EIT. For example, Channel ETTs may contain information about
the price of a channel or its coming attractions. Event ETTs might
include a short paragraph describing a specific event, such as a movie.
As with EITs, the PID number for ETTs is also identified in the MGT.
ETTs are optional.
6 Transport Stream Analysis/Simulation: Why, How and What to Test?
6.1 Why Should So, why should you test? The answer should be simple enough, right?
I Test? You test to make sure that the quality of your products will withstand
the rigors of the real-world environment. It seems simple enough, but
because testing can be costly and time consuming, validation teams
often limit the scope of their testing to include only those parameters
and events that are most likely to occur with their systems. Naturally,
these test scenarios are the easiest to create. But the constantly
changing digital broadcast environment forces all players to be much
43
more broad-minded in their testing procedures. They must test the

limits of their equipment based on all possible permutations of the
MPEG-2, DVB or ATSC standards. They must also ensure their systems’
interoperability with other manufacturers’ equipment and have confi-
dence that their products will resolve error conditions successfully.
Rigorous testing under both standard and extreme conditions allows
companies to keep pace with the market and consistently outperform
the competition.
Testing to this degree allows companies to:
• Ascertain that their equipment is robust enough to handle broader
use of the specified standards as the industry evolves.
• Avoid expensive recall and customer service issues when equipment
fails to meet protocol standards.
• Ensure that their equipment can be trusted to work effectively in
integrated systems with equipment from several different manu-
facturers.
• Earn and keep their customers’ respect by supplying equipment that
continues to perform in spite of error conditions.
• Maintain their reputation for quality in the industry.
44
• Improve their processes to ensure that their equipment outperforms

the competition.
The following sections use the creation and implementation of the
Electronic Program Guide as one example of why testing under
extreme conditions is absolutely necessary in the digital broadcast
environment. Though the examples deal mainly with the EPG, they
can be applied to many test scenarios.
6.1.1 Testing the Because digital-broadcasting technology is relatively new, current

Limits of the transmissions don’t even approach many of the limits specified by the
Protocol protocol—but this may soon change as the industry evolves rapidly to
support a growing number of available services and potential custo-
mers. In order to develop equipment that will be compliant in a year
or more, manufacturers must test their products according to all the
boundaries and limits of the specification. Take for example the crea-
tion and implementation of software for the Electronic Program Guide
(EPG).
Since it is not easy to upgrade the software in digital televisions within
the home, developers need to be confident that their EPG software
will provide top-quality service both now and several years from now,
as more advanced features of SI/PSIP are implemented in broadcast
45
SI/PSIP generators. In order to have high confidence in their EPG soft-

ware, developers must test the software with transport streams that
include all permutations of the different DVB and ATSC tables that
make up the EPG. This also extends to the many descriptors defined
by the standards. These may require support for decompression of
text strings, handling of text from many different character formats,
and reading the ratings values for each program. Because the tables
are linked, the permutations between tables must also be tested.
Current real-world streams are not complex enough to offer suffi-
ciently extreme test inputs, so many developers use emulation devices
that allow them to simulate transport streams with a maximum
number of permutations. For more information on test emulators, see
section 6.2.1 Emulation or Simulation.
6.1.2 Interoperability Because MPEG-2, DVB and ATSC are open systems, they specify only
the syntax of the output transport stream, not the manner in which
the stream is generated. This means that different manufacturers often
have different methods of encoding, modulating, or multiplexing the
input, while still remaining within the specification. Because complex
broadcasting systems often use equipment provided by different manu-
facturers, these manufacturers must be sure their systems can
46
properly transmit, receive and interpret data from many different

brands of equipment.
Testing for interoperability becomes especially critical when it comes
to the Electronic Program Guide (EPG). In the ATSC world, information
for the PSIP data is usually created by each local television station from
information it receives from the national network feed or from local
programming. A given station might use any brand of PSIP generator,
and every home viewer may select from a number of brand names of
ATSC-compliant digital televisions. Because of this, digital television
manufacturers must be sure their systems can properly receive and
interpret PSIP data from many different manufacturers’ PSIP generators.
This makes the task of developing the EPG more difficult for an open
system since the digital television must handle all possibilities within
the A/65 protocol. In order to test for interoperability, the developer
of the EPG for a digital television must either have all PSIP generators
available for testing or have a piece of test equipment that can
emulate all the possible scenarios within the A/65 specification.
47
6.1.3 Handling Errors Because digital transmission is especially vulnerable to errors, developers and
manufacturers must produce equipment that effectively handles dropped
packets or erroneous bits without crashing. In the case of the EPG, developers
need to make sure that their software can not only parse all possible
variations to the specification, but also resolve any error conditions that may
be present in a stream. This means making sure that the software does not
crash when an error occurs, thereby causing interruption in the video or audio
or forcing the user to turn the power off and on to recycle the system.
One common example of such an issue arises for ATSC systems when an error
occurs in the MGT. The MGT includes the length of the PSIP tables being
transmitted. However, if the value in the MGT does not match the true length
of a table, and the EPG software uses the length value from the MGT, the
table referred to in the MGT may not fit in the memory allocated. If this occurs,
the software might either discard it or overwrite other critical memory. Either
of these results could cause the software to crash or provide erroneous
information to the user. A reasonable EPG software package would detect
this problem and work around it, causing minimal impact to the EPG display.
In order to avoid this and other similar problems, the software developer
must test the digital television with as many erroneous transport streams as
possible. Again, a test PSIP simulator would allow you to easily simulate this
and many other error conditions.
48
6.2 How Do I Test? What Equipment Do I Need?
Testing relies on two complementary functions: emulation or simulation

and analysis. Emulation of a transport stream refers to embedding
the audio/video components and data. Analysis of a transport stream
involves checking the output transport stream for proper timing,
PSI/SI/PSIP, and elementary stream information.
6.2.1 Emulation or The test and verification of a digital television or set-top box includes
Simulation the feeding of many different variations of transport streams into the
equipment over time. This is a time-consuming process, and if any
changes are made to the hardware or software in the receiver during
the process, the testing must be repeated to test the areas affected
by the changes. Because the MPEG-2/DVB/ATSC specifications are so
complex, the number of different test scenarios required to test a digi-
tal television or receiver to a sufficient degree of confidence is quite
large. In order to obtain a collection of transport streams for testing,
manufacturers generally use one of three methods: live transmissions,
captured transport streams stored on disk, or simulated test streams.
Over the air (live) transmissions - Continuous feed is the main advan-
tage to using live transport streams for testing purposes. You can
49
connect a TV or IRD to an input source and let it run for days or weeks
without the cost of storing huge amounts of data on a hard drive.
The problem with this method, however, is that you cannot determine
the conditions of the test stream. And with live feed, these conditions
probably do not test the limits of what the equipment will be
required to do either now or in the future, according to the specification.
Captured transport streams - In the past, testing has generally been
accomplished with transport streams stored on a disk and played out,
repeating once they ended in order to mimic continuous feed. Unlike
over-the-air transmissions, broadcasters using captured transport
streams can select and store any number of test streams, each repre-
senting a different test scenario.
These captured streams can then be run through a transport stream
generator or other emulation device that sends the stream as input
to the unit under test. In spite of the possible variety available with
this method, however, the storage space required to keep these streams
severely limits the number of test scenarios that most manufacturers
store and use. For example, reasonable test coverage would require
10s to 100s of transport streams, each one occupying 100s of megabytes
or more of disk space. This database of streams is not only
difficult to obtain, but also time-consuming to manage.
50
Further, most captured streams do not test the limits of the specified
standards for items such as output rate, table size and repetition rate.
For example, U.S. terrestrial markets only transmit at 19.3 Mbps, so
most ATSC streams will be transmitted at this rate. But the future may
quite possibly see ATSC streams broadcast at 50 or 100 Mbps, as
specified by the standard. Manufacturers must know how their equipment
will react to these output rates. Table section lengths provide another
example. These days, most table sections are only 100 to 200 bytes long,
but according to the ATSC specification, they can be up to 1024 bytes
long. Actual transport streams with table sections of this size are
difficult to obtain, but manufacturers must test this condition for the
future.
Valid test streams should also present the unit under test with changing
conditions, such as changes in PID or PCR values. In order to test these
scenarios with real-world streams, manufacturers must encode and
multiplex a multitude of test streams that represent extreme conditions.
This requires expensive video compression equipment and multiplexers.
Once the stream has been created and sent as input to the unit under
test, a transport stream generator may be used to record erroneous
portions of the stream for analysis or testing.
51
Simulated test streams - The emergence of test multiplexers has largely

changed the process for gathering test streams, since these machines
can create multiplexes that cover the complete range of parameters
specified by the standards. With test multiplexers, the possibility for
creating different test parameters is virtually limitless. Manufacturers
can easily create test streams with output rates of 100 Mbps and/or
table section lengths of 1024 bytes. Simulated test streams can also
include error conditions and on-the-fly changes to System Information
so they represent near-to-real-life scenarios that test the equipment’s
reaction to extreme situations. Some test multiplexers even simulate
days or weeks of continuous feed by replaying a relatively small
piece of audio and video and updating timing and table information
continuously. There can be 100s or 1000s of such test streams in the
disk space required by just one captured stream. This allows
manufacturers to test the robustness and longevity of their systems
without requiring the large amounts of disk space necessary for
captured streams.
This real-time creation of streams also permits time discontinuities,
allowing the emulation of a day passing in just a few minutes. For
example, in ATSC, the STT time can increase for 3 minutes and then
jump to just under 3 hours later to test the changing of the EIT/ETT
52
information every three hours. These tests can also be run one after
another, in an automated fashion, to reduce the time and effort
needed to perform the tests. A test multiplexer allows you to create
a limited number of test streams that cover the range of conditions
for which you want to test.
6.2.2 Elementary For broadcasters, developers and manufacturers, it often becomes

Stream Analysis necessary not only to analyze the multiplexed transport stream, but
also the various components that make up the stream.
These may include compressed audio and video, data and interactive
applications.
Specific test tools have been developed for the validation of audio
and video elementary streams. These tools enable verification teams
to isolate and troubleshoot errors efficiently by fully validating video
and audio data before transmission or distribution.
Elementary stream analyzers can help validate GOP structures, slices
and macroblocks.
53
They can also be used to check the size, quantizer scale, and motion
vectors for any macroblock in the video stream.
54
Elementary stream analyzers also provide buffer models used to validate

encoders. The validation against a model ensures that the buffers in
decoders and set-top boxes will not overflow or underflow due to
encoding or multiplexing issues when receiving the transport stream.
55
On the other hand, if a stream is not compliant to the buffer model,

a decoder is not required to display the video or play the audio to
match the original encoded program material, and the decoder could
show discontinuous jumping or blocking video or have discontinuities
in the audio.
6.2.3 Analysis of a Validating any one of the different parts of the digital transport chain
Transmission requires not only the rigorous equipment testing discussed above, but
System also high-to-low-level transport stream analysis and validation. For
system integrators, this includes checking and rechecking the output
of the various pieces of equipment that make up a system. Transport
stream analysis helps system integrators verify that a particular com-
bination of encoders, modulators, multiplexers, and decoders can
effectively reproduce the input signal at the required level of quality.
Broadcasters who control large networks of programs and services
must be able to constantly monitor the output of their systems for
Quality of Service. Essentially all players in the digital transmission
chain must verify the output of their systems or services in order to
ensure quality performance for their customers. This kind of verifica-
tion requires some type of transport stream analyzer.
56
Transport stream analyzers allow testers to view and verify everything

from transport stream syntax to system-level information, timing rela-
ted issues, and audio and video information. Test analyzers can also
identify errors in the transport stream and capture parts of the stream
for later analysis off line. Manufacturers and system integrators use
transport stream analyzers to print reports regarding PIDs, Tables,
Timing, Programs and Errors detected on the stream.
57
Transport stream generators are also used during validation for recor-
ding erroneous segments of a transport stream for off-line analysis.
This allows users to isolate problems in a system and resolve them
without delay. Transport stream generators can also be used in the
absence of a test multiplexer to play captured transport streams as
input to the unit under test.
6.3 What do I Look Many equipment manufacturers recognize the need to test their equipment
For? and even have the test tools necessary to do so, but are unsure exactly
what to look for during testing and validation. Because testing
requirements are often application specific, we’ve divided our answer
to this question into a few different test scenarios. Of course,
the information provided here is not all inclusive, but we hope this section
will give you a better idea of some of the most important issues involved
in testing the different elements of the digital broadcast system.
❑ Television or Manufacturers of receivers, whether they be television sets or set-top

Set-top-box boxes, are primarily concerned with two issues: (1) Can my equipment
Manufacturer receive and decode MPEG-2/DVB/ATSC transport streams? and (2) Is
the output free of errors? Does it match expected video, audio and
EPG results?
58
Compliance issues Compliance with the standards is essential when building digital
broadcast equipment of any kind. Because a single system often uses
equipment from different manufacturers, each piece of equipment
must be governed by the same protocol—and each must be able to
perform up to the limits specified by that protocol. The following
questions will help you create a more complete set of testing requirements.
Can the equipment handle the specified boundaries for items such as
output rate, table section size and PID number? If a high-definition
stream arrives at 45 Mbps, will the equipment process it properly?
What about table section sizes of 1024 bytes or PID values of 8190?
These and other protocol limits may become commonplace in the future,
so you will want to know how your equipment reacts to these
conditions.
After you have tested all boundary limits, consider possible changes
to the transport stream, both expected and unexpected. For example,
what if an audio or video stream changes PIDs? How will that affect
your system? What will happen if the PCR value changes unexpectedly?
What if extra bytes appear in the stream—will synchronization be
lost? For DVB systems, what happens when a new transport stream is
added to the network (or to the NIT)? How will that affect your system?
This event might be rare, but you want to know what effect it will
have on your system when and if it does occur.
59
The EPG represents the intermediary between service providers and

their customers, so its quality is critical. To verify EPG software, you
need to make sure the information you input is displayed correctly on
the screen (channel name, event description, start time). Can the
viewer use the EPG to navigate through the entire network? Does
the receiver have all the tuning information it needs to change
channels without delay? Can event information be displayed in
different languages?
For ATSC systems, you need to ensure that rating filters function
properly. Does the receiver handle information about ratings
in the EPG? Does it allow the viewer to customize the rating filters?
Error conditions Of course, when you develop broadcast equipment your main concern
is that your equipment produces an error-free transmission stream.
Knowing your system’s limits can help you avoid unnecessary errors.
The main question here is, “What will it take to make the system fail?”
60
Some questions that might help you understand your systems’

limitations include: Bit errors - How does my receiver handle bit errors?
What if bits become corrupted? What if they are dropped? What if
the bit errors occur in tables? What if they occur in audio or video?
How does my receiver handle Forward Error Correction (FEC)?
Timing - How does the unit handle bit errors that affect timing? How
does it handle incorrect timing values in general? For instance, what
happens when the transport stream indicates discontinuity in the PCR
and the time base changes? What happens when the application
discontinuity bit (which notifies the system of a PCR change) is lost or
corrupted and the time changes unexpectedly? How does my
system react to this condition? Does it reset the clock? Does it ignore
the discontinuity? How does your system handle PCR jitter? How much
can it handle before failure occurs? What are its limits? In these
situations, a test analyzer can be especially helpful in determining
time discontinuities and measuring jitter.
61
Tables - What happens when a CRC error occurs? For instance, what
if the PMT says the video PID is 50, but there is a bit error in the table?
Does the system process the table or discard it?
What happens when extra bytes are inserted every now and then?
Does the system maintain synchronization?
62
❑ Encoder or When verifying a joint encoder/multiplexer system, you want to confirm

Multiplexer that the system performs according to your expectations. Is it doing
Joint System what you designed it to do? Other helpful questions include:
Testing
Are all the pieces in the transport stream as they should be? For ins-
tance, are all the tables present in the stream? Are they on the right
PIDs? Do they reference the right PIDs? Are they being sent fast
enough? Are the data rates correct? Are the rates for video and audio
correct? Are PCR values correct?
Does the transport stream syntax conform to the MPEG-2/DVB/ATSC
specifications? For instance, does a sync byte come every 188 bytes?
Are the bits ordered properly for table decode? Does the table start
with a unit start indicator and include a table offset value and table
length field? This is one area where a transport stream analyzer will
perform the test for you. For instance, it will check for synchronization
and verify that table bits and sequences match the specification.
It will also check table structure and descriptor size and look for
adaptation field errors and PCR bit errors. Depending on your test
analyzer, it may also generate error warnings if these conditions are
not met.
63
You will want to verify that system-level information is consistent. For

instance, are all the PIDs referenced in the PMT present in the stream?
Does the information in the SI/PSIP tables match the information in
the PMT? For DVB systems, are the NIT and SDT Actual in the stream?
Is the TSID in the SDT Actual the same as the one referenced by the
PAT? Again, a test analyzer can verify this information for you.
64
You will also want to verify rate- and timing-related issues that mea-
sure the statistical parameters of the transport stream. For instance,
do tables occur as often as expected? Does video arrive at the expected
speed? How many transport errors does the stream contain per second?
Some of these parameters are not exactly specified, so they must
be monitored and controlled by the broadcast equipment to ensure
proper decode and presentation. You can customize some transport
stream analyzers to identify unspecified errors that may affect your
system.
65
Check for basic structural consistency within the tables. If a descrip-

tor_length indicates that the descriptor is 10 bytes long, is that value
correct? This verifies consistency in the Cyclic Redundancy Check (CRC).
Are the raw bits in the tables transformed into a message the user
can identify? For instance, is the value in the time field decoded and
displayed in a format the user will understand?
If you are writing software that creates tables, look at the tables and
descriptors to confirm that the data was produced correctly from the
software. For instance, do they produce the correct channel name and
event description in the EPG? Is the tuning information correct?
You may also want to test the transport stream to see how data flows
on the decoder. Do the PCRs occur with acceptable accuracy? Is the
buffer model accurate? For DVB systems, do MIP packets contain the
correct information?
In reality, there are a myriad of parameters that must be tested to
ensure a system’s reliability and longevity in the digital broadcast
market. Test equipment can help you by checking rates and
consistency to the specification. It can also help you check for
consistency within your system’s setup.
66
❑ System In order to integrate complex systems, such as MPEG-2 digital television

Integration delivery systems, you need the proper tools to isolate and solve
Verification problems quickly and easily in order to reduce integration time. These
same tools can be applied to smaller subsets of integration,
such as verification of the output of an MPEG-2 compression system.
In testing integrated systems, you should consider the following:
First you want to verify that your system is programmed properly. To
do this, confirm that the output from the modulator to the multi-
plexer is generally correct. Look at each stream to verify the Transport
Stream IDentifier (TSID). Are the services correct in each TSID? Are the
ratings there? Is the configuration set up properly? Does it have the
correct settings so that the table and descriptor information will
emerge from the multiplexer correctly? From a customer standpoint,
these questions are vital, since the decoder uses this information
to create the EPG. Does the EPG contain the correct information (was
the information entered correctly)? Are the tuning parameters right?
Does the system channel hop without delay?
You will also want to check your configuration over time. Are changes
to the system implemented correctly?
67
As an integrator, you can’t assume that the equipment in your confi-

guration will function as expected. Since you are often testing equip-
ment produced by different manufacturers, you must verify
interoperability between different pieces in the system. Does the
equipment in your system work together? If not, which piece of equip-
ment is causing the problem? Is it a stream problem? An interface
problem? As you test an integrated system, different individual pieces
of the system may also malfunction or fail. When this occurs, you must
effectively isolate and resolve the problem as quickly as possible.
If a piece of equipment has failed, it must be repaired or replaced
immediately.
Is the video correct? To verify this, you will need to run the transport
stream through a decoder. Are the rates right? Does the audio/video
quality match your expectations? Are there lip sync issues? If so, you
can use specialized software to help you determine which piece of
equipment is causing the error.
Video/audio, IP data, Java data, OpenTV and other components of a
multiplex have their own protocol and syntax issues, and each has its
own buffer model. System integrators must be sure that each piece
of the multiplex meets the expectations outlined in its individual
specification. For instance, with video, you may want to measure the
68
quality of the video or look for statistics about motion vectors. With IP
you may want to know what IP traffic is occurring in the transport
stream, or what data addresses are being transmitted.
Test equipment can help you quickly isolate hardware and software
failures in integrated systems. Transport stream analysis helps you
identify errors at the output. Emulation devices allow you to feed
known good streams to the different pieces of your system in order
to test their functionality and isolate errors. You may also need to
capture streams and send them back to a manufacturer for analysis
and repair of faulty equipment.
Test equipment can also be useful to system integrators when it comes
to acceptance testing. During acceptance testing, you must prove to
the customer that the system is set up properly and performs as expected.
The customer will want to know that output transport streams meet
the required specifications, that the program guide is set up properly,
and that the streams are transmitted at the correct rate. Test analyzers
allow integrators to print reports based on the content of the output
transport stream. These reports verify the PIDs and tables in the stream
at any given time and display their individual rates. They can be run
periodically over time to prove that a system can run without error
for days or weeks at a time.
69
7 Glossary AC-3—Audio compression standard adopted by ATSC and owned by

Dolby.
ADC—Analog to Digital Converter.
ASCII—American Standard Code for Information Interchange.
ASI—Asynchronus Serial Interface. A standard DVB interface for a
transport stream.
ATM—Asynchronous Transfer Mode.
ATSC—Advanced Television Systems Committee. Digital boadcasting
standard developed in North America.
ATV—Advanced Television. North American standard for Digital
Broadcasting.
BAT—Bouquet Association Table. This DVB table describes a set of
services grouped together by a broadcaster and sold as a single entity.
It is always found on PID 0x0011.
BER—Bit Error Rate.
B-frames—Bidirectionally predicted pictures, or pictures created from
references to past and future pictures.
Bitrate—The rate at which a bit stream arrives at the input of a decoder.
70
Block—A set of 8x8 pixels used during Discrete Cosine Transform (DCT).
Bouquet—A set of services sold as a single entity.
Broadcaster—Someone who provides a sequence of scheduled events
or programs to the viewer.
CA—Conditional Access. This system allows service providers to control
subscriber access to programs and services via encryption.
CAT—Conditional Access Table. This table identifies EMM streams with
a unique PID value. The CAT is always found on PID 0x0001.
CATV—Community Access Television, otherwise known as Cable TV.
Channel—A digital medium that stores or transports an MPEG-2
transport stream.
COFDM—Coded Orthogonal Frequency-Division Modulation.
Compression—Reduction of the number of bits needed to represent
an item of data.
Conditional Access—A system used to control viewer access to
programming based on subscription.
CRC—Cyclic Redundancy Check. This 32-bit field is used to verify the
correctness of table data before decoding.
71
CVCT—Cable Virtual Channel Table. This ATSC table describes a set of

one or more channels using a number or name within a cable
network. Information in the table includes major and minor numbers,
carrier frequency, short channel name, and information for
navigation and tuning. This table is located on PID=0x1FFB.
D/A—Digital to Analog Converter.
DAVIC—Digital Audio Visual Council.
DBS—Direct Broadcasting Satellite or System.
DCT—Discrete Cosine Transform. Temporal-to-frequency transform
used during spatial encoding of MPEG video.
Decoding Time Stamp—Decoding Time Stamp. This stamp is found in
the PES packet header. It indicates the time at which a piece of audio
or video will be decoded.
DigiTAG—Digital Television Action Group.
Downlink—Communication link from a satellite to earth.
DTV—Digital Television. A general term used to describe television
that has been digitized. It can refer to Standard-definition TV or
High-definition TV.
DTS—See Decoding Time Stamp.
72
DVB—Digital Video Broadcasting. The DVB Project is a European

consortium that has standardized digital TV broadcasting in Europe
and in other countries.
DVB ASI—Asynchronous Serial Interface. This is a standard DVB
interface for a transport stream.
DVB-C—Digital Video Broadcasting-Cable. The DVB standard for
broadcasting digital TV signals by cable. The RF spectrum in digital
cable TV networks has a frequency range of (approx) 46MHz to 850MHz.
DVB-S—Digital Video Broadcasting-Satellite. The DVB standard for
broadcasting digital TV signals via satellite.
DVB SPI—Synchronous Parallel Interface. This is a standard DVB
interface for a transport stream.
DVB-T—Digital Video Broadcasting-Terrestrial. The DVB standard for
broadcasting digital terrestrial TV signals.
ECM—Entitlement Control Message. ECMs carry private conditional
access information that allows receivers to decode encrypted
information.
EIT (ATSC)—Event Information Table. This table is part of the ATSC
PSIP. It carries the TV guide information including titles and start times
73
for events on all the virtual channels within the transport stream. ATSC
requires that each system contain at least 4 EIT tables, each
representing a different 3-hour time block. The PIDs for these tables
are identified in the MGT.
EIT Actual (DVB)—Event Information Table. This table is part of the
DVB SI. It supplies the list of events corresponding to each service and
identifies the characteristics of each of these events. Four types of EITs
are defined by DVB : 1) The EIT Actual Present/Following supplies
information for the present event and the next or following event of
the transport stream currently being accessed. This table is mandatory
and can be found on PID=0x0012. 2)The EIT Other Present/Following
defines the present event and the next or following events of other
transport streams in the system that are not currently being accessed
by the viewer. This table is optional. 3) The EIT Actual Event Schedule
supplies the detailed list of events in the form of a schedule that goes
beyond what is currently or next available. This table supplies a schedule
of events for the transport stream currently being accessed by the
viewer. 4) The EIT Other Event Schedule supplies the detailed schedule
of events that goes beyond what is currently or next available. This
table supplies a schedule of events for other transport streams in the
system that are not currently being accessed by the viewer. The EIT
Schedule tables are optional.
74
EMM—Entitlement Management Message. EMMs specify authorization

levels or services of specific decoders. They are used to update the
subscription options or pay-per-view rights for an individual subscriber
or for a group of subscribers.
EPG—Electronic Program Guide. This guide represents a broadcasting data
structure that describes all programs and events available to the viewer.
It functions like an interactive TV guide that allows users to view a
schedule of available programming and select what they want to watch.
ES—Elementary Stream. A bit stream that includes video, audio or
data. It represents the preliminary stage to the Packetized Elementary
Stream (PES).
ETR—ETSI Technical Report.
ETR 290—ETSI recommendation regarding measurement of
MPEG-2/DVB transport streams.
ETSI—European Telecommunication Standard Institute.
ETT—Extended Text Table. This table is part of the ATSC PSIP.
It carries relatively long text messages for additional descriptions of
events and channels. There are two types of ETTs, the Channel ETT,
which describes a channel, and the Event ETT, which describes indivi-
dual events in a channel. The PID for this table is identified in the MGT.
75
Event—A collection of elementary streams with a common time base

and an associated start time and end time. An event is equivalent to
the common industry usage of “television program.”
FEC—Forward Error Correction. This method adds error control bits
before RF modulation. With these bits, errors in the transport stream
may be detected and corrected prior to decoding.
Frame—Lines of spatial information for a video signal.
GOP—See Group Of Pictures
Group of Pictures—a set of pictures usually 12-15 frames long used
for temporal encoding of MPEG-2 video.
HDTV—High Definition Television. HDTV’s resolution is approximately
twice as high as that of Standard Definition Television (SDTV) for both
horizontal and vertical dimensions. HDTV has an aspect ratio of
16x9 as compared to the 4x3 aspect ratio of SDTV.
IEC—International Electrotechnical Commission.
IEEE—Institute of Electrical and Electronics Engineers.
I/F—Interface.
I-frame—Intra-coded frame, or a picture encoded without reference
to any other picture. I-frames provide a reference for Predicted and
Bidirectionally predicted frames in a compressed video stream.
76
IRD—Integrated Receiver Decoder. This is a receiver with an MPEG-2

decoder, also known as a set-top box.
ISO—International Standardization Organization.
ITU—International Telecommunications Union (UIT).
LVDS—Low Voltage Differential Signal. An electrical specification used
by some manufacturers, usually on a parallel interface. It is a balanced
interface with a low signal voltage swing (about 300mV).
Macroblock—A group of 16x16 pixels used for motion estimation in
temporal encoding of MPEG-2 video.
MFN—Multiple Frequency Network (DVB-T).
MGT—Master Guide Table. This table is part of the ATSC PSIP. It defines
sizes, types, PIDs, and version numbers for all of the relevant tables
within the transport stream. The PID value for this table is 0x1FFB.
MHEG—Multimedia & Hypermedia Expert Group.
MIP—Megaframe Initialization Packet. This packet is used by DVB-T
to synchronize the transmitters in a multi-frequency network.
MP@HL—Main Profile at High Level. MPEG-2 specifies different degrees
of compression vs. quality. Of these, Main Profile at High Level is the
most commonly used for HDTV.
77
MP@ML—Main Profile at Main Level. MPEG-2 specifies different

degrees of compression vs. quality. Of these, Main Profile at Main
Level is the most commonly used.
MPEG—Moving Picture Experts Group, also called Motion Picture
Experts Group.
MPEG-2—ISO/IEC 13818 standard defining motion video and audio
compression. It applies to all layers of transmission (video, audio and
system).
MPTS—Multiple Program Transport Stream. An MPEG-2 transport
stream containing several programs that have been multiplexed.
Multiplex (n)—A digital stream including one or more services in a
single physical channel. (v)—To sequentially incorporate several data
streams into a single data stream in such a manner that each may later
be recovered intact.
Network—The set of MPEG-2 transport streams transmitted via the
same delivery system.
NIT—Network Information Table. This DVB table contains information
about a network’s orbit, transponder etc. It is always located on PID
0x0010. DVB specifies two types of NITs, the NIT Actual and the NIT
Other. The NIT Actual is a mandatory table containing information
78
about the physical parameters of the network actually being accessed.

The NIT Other contains information about the physical parameters of
other networks. The NIT Other is optional.
NTSC—National TV Standard Committee Colour TV System (USA and
60 Hz countries).
NVoD—Near Video on Demand. This service allows for a single TV program
to be broadcast simultaneously with a few minutes of difference in
starting time. For example, a movie could be transmitted at 9:00,
9:15 and 9:30.
Packet—See Transport Packet.
PAL—Phase Alternating Line.
PAT—Program Association Table. This MPEG-2 table lists all the
programs contained in the transport stream and shows the PID value
for the PMT associated with each program. The PAT is always found
on PID 0x0000.
Payload—All the bytes in a packet that follow the packet header.
PCR—Program Clock Reference. A time stamp in the transport stream
that sets the timing in the decoder. The PCR is transmitted at least
every 0.1 seconds.
79
PES—Packetized Elementary Stream. This type of stream contains

packets of undefined length. These packets may be comprised of video
or audio data packets and ancillary data.
PES Packet—The structure used to carry elementary stream data (audio
and video). It consists of a header and a payload.
PES Packet Header—The leading bytes of a PES packet, which contain
ancillary data for the elementary stream.
PID—Packet Identifier. This unique integer value identifies elements in the
transport stream such as tables, data, or the audio for a specific program.
PLL—Phase Lock Loop. This locks the decoder clock to the original
system clock through the PCR.
PMT—Program Map Table. This MPEG-2 table specifies PID values for
components of programs. It also references the packets that contain
the PCR.
P-frame—Predicted frame, or a picture coded using references to the
nearest previous I- or P- picture.
Program—See Service.
PSI—Program Specific Information. PSI refers to MPEG-2 table data
necessary for the demultiplexing of a transport stream and the
regeneration of programs within the stream. PSI tables include PAT,
CAT, PMT and NIT.
80
PSIP—Program and System Information Protocol. The ATSC protocol

for transmission of data tables in the transport stream. Mandatory
PSIP tables include MGT, STT, RRT, VCT and EIT.
PTS—Presentation Time Stamp. This stamp indicates the time at
which an element in the transport stream must be presented to the
viewer. PTSs for audio and video are transmitted at least every
0.7 seconds. The PTS is found in the PES header.
QAM—Quadrature Amplitude Modulation. This is a type of modulation
for digital signals used in CATV transmission (DVB-C). Amplitude and
phase of a carrier are modulated in order to carry information.
QPSK—Quadrature Phase Shift Keying. A type of modulation for digital
signals used in satellite transmission (DVB-S).
RRT—Rating Region Table. An ATSC PSIP table that defines ratings
systems for different regions or countries. The table includes parental
guidelines based on Content Advisory descriptors within the
transport stream.
RS—Reed-Solomon Protection Code. This refers to the 16 bytes of
error control code that can be added to every transport packet during
modulation.
81
RST—Running Status Table. A DVB-SI table that indicates a change of

scheduling information for one or more events. It saves broadcasters
from having to retransmit the corresponding EIT. This table is
particularly useful if events are running late. It is located on PID 0x0013.
SDT—Service Description Table. This DVB SI table describes the
characteristics of available services. It is located on PID 0x0011. Two
types of SDTs are specified by DVB, the SDT Actual and the SDT Other.
The SDT Actual is a mandatory table that describes the services within
the transport stream currently being accessed. The SDT Other describes
the services contained in other transport streams in the system.
SDTV—Standard Definition Television. SDTV refers to television that
has a quality equivalent to NTSC or PAL.
Section—A syntactic structure used for mapping PSI/SI/PSIP tables into
transport packets of 188 bytes.
Service—A collection of one or more events under the control of a
single broadcaster. Also known as a Program.
SFN—Single Frequency Network (DVB-T).
SI—Service Information. This DVB protocol specifies all the data required by
the receiver to demultiplex and decode the programs and services in the
transport stream. Mandatory DVB SI tables include TDT, NIT, SDT and EIT.
82
SMPTE—Society of Motion Picture and Television Engineers.

SNG—Satellite News Gathering. This refers to the retransmission of
events using mobile equipment and satellite transmission.
SNMP—Simple Network Management Protocol. This is the standard
protocol for system and network administration.
SPI—Synchronous Parallel Interface. This is a standard DVB interface
for a transport stream.
SPTS—Single Program Transport Stream. An MPEG-2 transport stream
that contains one unique program.
ST—Stuffing Table. An optional DVB-SI table that authorizes the replace-
ment of complete tables due to invalidation at a delivery system boun-
dary such as a cable headend. This table is located on PID 0x0014.
STB—Set-top box. A digital TV receiver (IRD).
STD—See System Target Decoder.
STT—System Time Table. An ATSC PSIP table that carries time information
needed for any application requiring schedule synchronization.
It provides the current date and time of day and is located on PID 0x1FFB.
System Target Decoder (STD)—A hypothetical reference model of the
decoding process defined by MPEG-2.
83
Table—Service Information is transmitted in the form of tables, which

are further divided into subtables, then into sections, before being
transmitted. Several types of tables are specified by MPEG, DVB and
ATSC. Refer to the Pocket Guide for more information on the different
types of Service Information tables and their functions.
TDT—Time and Date Table. This mandatory DVB SI table supplies the
time reference expressed in terms of UTC time/date. This enables joint
management of the events corresponding to the services accessible
from a single reception point. The PID for this table is 0x0014.
Time-stamp—An indication of the time at which a specific action must
occur in order to ensure proper decoding and presentation.
TOT—Time Offset Table. This optional DVB SI table supplies the UTC
time and date and shows the difference between UTC time and the
local time for various geographical regions. The PID for this table is
0x0014.
Transponder—Trans(mitter) and (res)ponder. This refers to the equip-
ment inside a satellite that receives and re-sends information.
Transport Packet—188-byte packet of information in a transport stream.
Each packet contains a header and a payload.
84
Transport Stream—A stream of 188-byte transport packets that contains

audio, video, and data belonging to one or several programs.
T-STD—See System Target Decoder.
TV—Television.
TVCT—Terrestrial Virtual Channel Table. This ATSC table describes a
set of one or more channels or services using a number or name within
a terrestrial broadcast. Information in the table includes major and
minor numbers, short channel name, and information for navigation
and tuning. This table is located on PID=0x1FFB.
Uplink—Communication link from earth to a satellite.
UTC—Universal Time, Co-ordinated.
VCT—Virtual Channel Table. This ATSC table describes a set of one or
more channels or services. Information in the table includes major and
minor numbers, short channel name, and information for navigation
and tuning. There are two types of VCTs, the TVCT for terrestrial
systems and the CVCT for cable systems.
VLC—Variable Length Coding. This refers to a data compression method
(Huffmann).
VoD—Video on Demand.
85
VSB—Vestigial Sideband Modulation. This is the terrestrial modulation

method used in the ATSC. It can have either 8 (8 VSB) or 16 (16 VSB)
discrete amplitude levels.
8 Reference Materials
8.1 MPEG ISO/IEC 13818-1 - Information Technology - Generic Coding of Moving

Specifications Pictures and Associated Audio: Systems, Recommendation H.222.0,
15 April 1996.
ISO/IEC 13818-2 - Information Technology - Generic Coding of Moving
Pictures and Associated Audio: Video, 15 May 1996.
ISO/IEC 13818-3I - Information Technology - Generic Coding of Moving
Pictures and Associated Audio: Audio, 15 May 1995.
Pictures and Associated Audio: Compliance, 24 March 1995.
Pictures and Associated Audio: Real-time jitter, 12 December 1996.
86
8.2 DVB European Standard (Telecommunications Series): Digital Video

Specifications Broadcasting (DVB); Specification for Service Information (SI) in DVB
Systems, EN 300 468 V1.3.1, February 1998.
European Telecommunication Report: Digital broadcasting systems for
television, implementation guidelines for the use of MPEG-2 systems;
Guidelines on implementation and usage of service information,
ETR 211, August 1997.
European Telecommunication Report: Digital broadcasting systems
for television, sound and data services; Allocation of Service Information
(SI) codes for Digital Video Broadcasting (DVB) systems, ETR 162,
October 1995.
European Telecommunication Report: Digital Video Broadcasting (DVB);
Implementation guidelines for the use of MPEG-2 systems, video and
audio in satellite, cable and terrestrial broadcasting applications, ETR
154, September 1997.
European Telecommunication Report: Digital Video Broadcasting (DVB);
Measurement guidelines for DVB systems, ETR 290, May 1997.
Digital Video Broadcasting document: Interfaces for CATV/SMATV
Headends and Similar Professional Equipment, A010, August 1996.
87
8.3 ATSC ATSC Digital Television Standard, A/53, September 1995.

Specifications
Guide to the Use of the ATSC Television Standard, A/54, October 1995.
Program/Episode/Version Identification ID Standard, A/57, August 1996.
Harmonization with DVB SI in the use of the ATSC Digital Television
Standard, A/58, September 1996.
Program and System Information Protocol for Terrestrial Broadcast
and Cable, A/65, December 1997.
Amendment No. 1 to ATSC Standard: Program and System Information
Protocol for Terrestrial Broadcast and Cable, T3-502, June 1999.
Technical Corrigendum No. 1 to ATSC Standard: Program and System
Information Protocol for Terrestrial Broadcast and Cable, T3-498, June 1999.
88
8.4 Other Nielsen, Ole Stender and Nanna Eriksen. A Broadcaster’s Guide to
References MPEG. RE Technology AS, September 1996.
NVision. The Book: An Engineer’s Guide to the Digital Transition.
Nvision: Grass Valley, CA.
NVision. The Book II: More Engineering Guidance for the Digital
Transition. Nvision: Grass Valley, CA, 1999.
Philips Key Modules. MPEG Questions and Answers. Philips: Eindhoven,
The Netherlands, 1996.
Symes, Peter D. Video Compression. McGraw Hill: New York, NY, 1998.
Whitaker, Jerry. DTV: The Revolution in Electronic Imaging. McGraw Hill:
New York, NY, 1998.
8.5 Useful Websites www.mpeg.org

www.dvb.org
www.atsc.org
www.current.org/dtv
www.mpeg1.de
www.cselt.stet.it/ufv/leonardo/paper/isce96.htm
89
Index Analysis
elementary streams............................................................................53
transport streams ..............................................................................56
ATSC......................................................................................................36, 46
history ................................................................................................36
PSIP tables ..........................................................................................37
audio compression ....................................................................................14
Auditory masking ......................................................................................14
BAT ............................................................................................................32
B-frame.......................................................................................................11
Bi-directionally predicted frame ..............................................................11
Bit errors.....................................................................................................61
Bouquet Association Table........................................................................32
CAT ............................................................................................................22
compliance ................................................................................................59
compression
audio compression ............................................................................14
video compression ..............................................................................7
Conditional Access Table ..........................................................................22
CRC ...............................................................See Cyclic Redundancy Check
CVCT ..........................................................................................................41
Cyclic Redundancy Check ..........................................................................66
DCT ..............................................................See Discrete Cosine Transform
Decoding ....................................................................................................12
Decoding Time Stamp ........................................................................13, 18
Digital Video Broadcasting..............................................................See DVB
Discrete Cosine Transform ..........................................................................8
DTS ....................................................................See Decoding Time Stamp
90
DVB ......................................................................................................25, 46
Internet Protocol (IP) ........................................................................33
SI tables ..............................................................................................27
DVB history ................................................................................................25
DVB Project ................................................................................................25
dynamic range ..........................................................................................15
EIT ......................................................................................................30, 41
Electronic Program Guide ............................................................27, 45, 66
Elementary Stream Analysis......................................................................53
Emulation ............................................................................................46, 49
Encoder ......................................................................................................63
entropy coding ..........................................................................................10
EPG ..............................................................See Electronic Program Guide
equipment............................................................................................49, 69
Errors in transmission ................................................................................48
ETT ............................................................................................................43
Event Information Table ....................................................................30, 41
events ........................................................................................................63
Extended Text Table ..................................................................................43
Grand Alliance ..........................................................................................36
History
ATSC ....................................................................................................36
DVB ....................................................................................................25
MPEG ....................................................................................................2
I-frame........................................................................................................10
Inter-frame prediction ..............................................................................10
Internet Protocol ......................................................................................33
Interoperability..........................................................................................46
91
Intra-coded frame......................................................................................10
Java data ....................................................................................................68
manufacturer ............................................................................................58
masking ......................................................................................................14
Master Guide Table ..................................................................................40
MGT ............................................................................................................40
Motion prediction ....................................................................................12
motion vectors ..........................................................................................12
Moving Pictures Experts Group ..................................................................5
MPEG
history ..................................................................................................2
MPEG-1 ........................................................................................................4
MPEG-2 ..................................................................................................5, 46
audio compression ............................................................................14
PSI tables ............................................................................................20
standard................................................................................................6
video compression ..............................................................................7
MPEG-4 ........................................................................................................5
Multiplexer ................................................................................................63
Network Information Table ................................................................23, 28
NIT ............................................................See Network Information Table
Packet Identifier ........................................................................................18
Packetized Elementary Stream ................................................................16
PAT ............................................................................................................21
PCR ................................................................See Program Clock Reference
PES ......................................................See Packetized Elementary Stream
P-frame ......................................................................................................11
Phase Lock Loop ........................................................................................19
92
PID ..............................................................................See Packet Identifier

PLL ..............................................................................See Phase Lock Loop
PMT ............................................................................................................23
Predicted frame ........................................................................................11
Presentation Time Stamp ....................................................................13, 18
Program Association Table........................................................................21
Program Clock Reference..........................................................................18
Program Map Table ..................................................................................23
PSI Tables ....................................................................................................20
PSIP tables ..................................................................................................37
PTS ................................................................See Presentation Time Stamp
quantization ................................................................................................9
Rating Region Table ..................................................................................39
receiver ......................................................................................................58
RRT ............................................................................................................39
RST ......................................................................See Running Status Table
Running Status Table ................................................................................32
Scanning ......................................................................................................9
SDT ................................................................See Service Description Table
Service Description Table ..........................................................................29
set-top box ................................................................................................58
SI tables ......................................................................................................27
Simulation ......................................................................................46, 49, 51
Spatial encoding ..........................................................................................8
ST ............................................................................................................32
STT ............................................................................................................38
Stuffing Table ............................................................................................32
subband......................................................................................................15
93
system information....................................................................................17
System Information ..................................................................................27
System Integration ....................................................................................67
System Time Table ....................................................................................38
TDT ............................................................................................................28
Temporal encoding....................................................................................10
test equipment ..........................................................................................49
testing
compliance ........................................................................................59
equipment ....................................................................................45, 69
errors ..................................................................................................60
how? ..................................................................................................49
what to look for ................................................................................58
Testing
why?....................................................................................................43
Time and Date Table..................................................................................28
Timing....................................................................................................18,61
Timing Offset Table ..................................................................................32
TOT ............................................................................................................32
transport packet ........................................................................................17
TVCT ..........................................................................................................41
VCT ............................................................................................................41
video compression ......................................................................................7
Virtual Channel Table ................................................................................41
Weighting ....................................................................................................9
94
Wavetek Wandel Goltermann Worldwide VOL. 6
North America Asia-Pacific Eastern Europe
Digital Broadcast Systems

Picture: © Valery Hache
P.O. Box 13585 P.O. Box 141 Middle East/Africa
1030 Swabia Court
Research Triangle Park
NC 27709-3585
South Melbourne,
Victoria 3205
Australia
Postfach 13
Elisabethstrasse 36
A-2500 Baden
MPEG-2
USA Tel. +61 39 690 6700 Austria Pocket Guide
Tel. +1 919 941 5730 Fax +61 39 690 6750 Tel. +43 22 52 85 521 0
Fax +1 919 941 5751 Fax +43 22 52 80 727
Western Europe
Latin America Arbachtalstrasse 6 CIS Countries Digital Broadcast
Av. Eng. Luis Carlos Berrini D-72800 Eningen u.A. 1st Neopalimovskiy per.15/7
936-8/9 Andar Germany (4th floor) Systems
04571-000 Sao Paulo, SP Tel. +49 7121 86 2222 119121 Moscow
Brazil Fax +49 7121 86 1222 Russia
Tel. +55 11 5503 3800 Tel. +7 095 248 2508
Fax +55 11 5505 1598 Fax +7 095 248 4189
MPEG-2 Pocket Guide

Internet Address
E-mail Address
mpeg@wwgsolutions.com
Nominal charge US$ 10 - DB/RN/PG01/0400/AE

Mpeg-2 Pocket Guide

Uploaded by

Copyright:

Available Formats

Mpeg-2 Pocket Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mpeg-2 Pocket Guide

Uploaded by

Copyright:

Available Formats

COUVERTURE Wandel 27/03/00 22:11 Page 1

Wavetek Wandel Goltermann Worldwide VOL. 6

North America Asia-Pacific Eastern Europe

Digital Broadcast Systems

MPEG-2 Pocket Guide

Nominal charge US$ 10 - DB/RN/PG01/0400/AE

Pocket Guide to MPEG-2 Fundamentals and Testing

Publishers: Wavetek Wandel Goltermann

Wavetek Wandel Goltermann

Please ask for:

Vol. 1 Vol. 3 Vol. 5

CONTENTS 1 Introduction ......................................................................................1

5 Advanced Television Systems Committee (ATSC)..........................36

information”, was further divided into several working groups. Working

2.2 MPEG-4 MPEG-4 represents the next breakthrough in audiovisual coding. It

3 MPEG-2 Compression and Transport

Because of MPEG compression, broadcasters no longer need as much

The following figure shows a simplified example of how MPEG-2

If even greater compression is needed, then the word length of the

3.1.2 Temporal Temporal encoding eliminates redundancy between individual frames

❑ Inter-Frame Inter-frame prediction uses one complete frame, called an Intra-coded

I-frames represent only one of three types of frames used in Inter-

and stored temporarily in the decoder. Consider the order in which

together in order to be masked than sounds at higher frequencies.

Image Video Elementary Stream

MPEG-2 Video Image

Header Useful data

... Transport Stream

Header Useful Stuffing

Each packet in the transport stream, whether it contains audio, video,

3.4 Timing: PCR, End-to-end synchronization, as well as synchronization between

For instance, a B-frame cannot be decoded without referencing the

System Clock System Clock

CODAGE PES DECODAGE

PES Time Stamp:

PAT (PID 00)

Prog. 2 PMT PID 32

Prog. 3 PMT PID 56

Prog. 4 PMT PID 120

CAT (PID 01)

PMT Program 1 (PID 65)

3.6 Summary PAT (PID 00)

The following steps outline the process followed by a decoder to

4 Digital Video Broadcasting (DVB)

❑ Network A Network is a system of one or more transport streams controlled by

Channel A1 Channel A2 Channel A3 Channel B1 Channel B2 Channel B3

❑ Service A Service is a sequence of programs under the control of a broadcaster,

The SDT provides information about the services in the network.

Channel A1 Channel A2 Channel A3 Channel B1 Channel B2 Channel B3

❑ Event An event is a collection of elementary streams with a common time

information about the next events to be broadcast on that transport

Channel A1 Channel A2 Channel A3 Channel B1 Channel B2 Channel B3

❑ Optional DVB Optional DVB tables include:

❑ Fragmentation Step 1 benefits from a predefined data-fragmentation mechanism.

5 Advanced Television Systems Committee (ATSC)

the Grand Alliance system. ATSC Digital Television Standard (A/53),

These tables are organized into three types:

VCT EIT-0 EIT-1 Etc. EIT-n

VCT EIT-0 EIT-1 Etc. EIT-n

6 Transport Stream Analysis/Simulation: Why, How and What to Test?