DVB Overview

Organisation européenne de télécommunications par satellite
European Telecommunications Satellite Organization

70, rue Balard — 75502 PARIS Cedex 15 — France
Technical Guide
ANNEX B
OVERVIEW OF DVB
June 7, 1999
This document is provided for information purposes. Whilst every effort has been made to provide accurate information,
no responsibility is taken for errors or omissions. EUTELSAT reserves the right to change this information without notice.
Technical Guide
Annex B - Overview of DVB
CONTENTS
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Digital Versus Analogue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. The DVB Standard(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. DVB - A Mechanism for Data Broadcasting . . . . . . . . . . . . . . . . . . . . 2
1.4. Satellite Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Elements of A Satellite DVB System . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Baseband Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPEG-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Processing Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Programmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. The Transport Stream Multiplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Service Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6. Conditional Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Satellite Channel Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. Service Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2. System Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Contact Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
page II June 7, 1999 Annex B to technical guidesTDM.fm

Technical Guide
1. Introduction
1.1. Digital Versus Analogue

The potential advantages of digital television broadcasting over conventional
analogue broadcasting are numerous and well known.
For the broadcaster, digital technology offers significantly improved
operational flexibility, providing the means for new business development in
the form of completely new services that go beyond the scope of conventional
television programmes. For example, it enables the provision of interactive
services such as enhanced Internet access and home shopping. It also provides
an improved means for controlling access to these services, allowing targeted
programming and measurement of audience characteristics and preferences,
as well as protecting revenue streams from pay TV services. Other benefits
concern the broadcasting infrastructure, with better integration with the
increasingly all-digital studios and playout centres and, thanks to digital
compression, more efficient use of the broadcast spectrum.
The benefits for the user include generally improved video and audio quality,
improved programme and service choice, better navigational aids to facilitate
the choice between the various services on offer and greater control over
content delivery. The viewer should thus evolve from being a passive
recipient of pre-scheduled programming to an active participant in the
broadcasting process.
1.2. The DVB Standard(s)

Digital Video Broadcasting (DVB) is a term that is generally used to describe
digital television and data broadcasting services that comply with the DVB
“standard”.
In fact, there is no single DVB standard, but rather a collection of standards,
technical recommendations and guidelines. These were developed by the
Project on Digital Video Broadcasting, usually referred to as the “DVB
Project”.
page B1 June 7, 1999 Annex B to technical guides.fm

Technical Guide
The DVB Project is run on a voluntary basis and brings together experts from
more than 200 companies and organisations, representing the interests of
manufacturing industry, broadcasters and services providers, network and
satellite operators and regulatory bodies. Its main intent is to reap the benefits
of technical standardisation, whilst at the same time satisfying the commercial
requirements of the project members. Although a large part of the
standardisation work is now complete, work is still ongoing on issues such as
the Multimedia Home Platform.
Much of the output of the DVB Project has been formalised by the European
Telecommunications Standards Institute (ETSI). A guide to the relevant ETSI
documentation is given in Annex B, together with references to other useful
documents.
1.3. DVB - A Mechanism for Data Broadcasting

Broadly speaking, DVB technology allows the broadcasting of “data
containers”, in which all kinds of digital data can be transmitted. DVB simply
delivers compressed image, sound or data to the receiver within these
“containers”. No restrictions exist as to the kind of information that can be
transported in this way. The DVB “Service Information” acts like a header to
the container, ensuring that the receiver knows what it needs to decode.
A key difference of the DVB approach compared to other data broadcasting
systems is that the different data elements within the container can carry
independent timing information. This allows, for example, audio information
to be synchronised with video information in the receiver, even if the video
and audio information does not arrive at the receiver at exactly the same time.
This facility is, of course, essential for the transmission of conventional
television programmes.
The DVB approach provides a good deal of flexibility. For example, a 38
Mbit/s data container could hold, for example, eight standard definition
television (SDTV) programmes, four enhanced definition television
programmes (EDTV) or one high definition television (HDTV) programme,
all with associated multi-channel audio and ancillary data services.
Alternatively, a mix of SDTV and EDTV programmes could be provided, or
even multimedia data containing little or no video information. The content
of the container can be modified to reflect changes in the service offer over
time (e.g. migration to a widescreen presentation format).
At present, the majority of DVB satellite transmissions convey multiple
SDTV programmes and associated audio and data. DVB is also used for data
broadcasting services (e.g. access to the World Wide Web).

Technical Guide
1.4. Satellite Delivery

One of the earliest standards developed by the DVB Project and formulated
by ETSI was for digital video broadcasting via satellite (usually referred to as
the “DVB-S standard”). Specifications also exist for the retransmission of
DVB signals via cable networks and Satellite Master Antenna Television
(SMATV) distribution networks.
The techniques used for DVB via satellite are classical in the sense that they
have been used for many years to provide point-to-point and point-to-multi-
point satellite data links in “professional” applications. The key contribution
of the DVB Project in this respect has been the development of highly
integrated and low-cost chip sets that adapt the DVB baseband signal to the
satellite channel.
Data transmissions via satellite are very robust, offering a maximum bit error
rate in the order of 10-11.
In satellite applications, the maximum data rate for a data container is
typically about 38 Mbit/s. This container can be accommodated in a single 33
MHz satellite transponder. It provides sufficient capacity to deliver, for
example, 4 to 8 standard definition television programmes, 150 radio
channels, 550 ISDN channels, or any combination of these services. This
represents a significant improvement over conventional analogue satellite
transmission, where the same transponder is typically used to accommodate a
single television programme with far less operational flexibility.
A single modern high-power broadcasting satellite typically provides at least
twenty 33 MHz transponders, allowing delivery of about 760 Mbit/s of data
to large numbers of users equipped with a small (around 60 cm) satellite
dishes. Taking into account the existence of collocated satellite constellations,
such as EUTELSAT’s HOT BIRD™ system1, the potential for simultaneous
data delivery to multiple users is significantly enhanced to around 3 - 4 Gbit/s.
1.5. Nomenclature
Certain differences exist in the terminology used within the MPEG, DVB and
traditional broadcasting communities. These differences are reviewed below
to facilitate understanding of the remainder of this annex.
In MPEG terminology the word “programme” is used to refer to a collection
of elementary data streams that are logically related and belong together. A
simple example is a video stream and an audio stream that together form a
conventional television programme.
1. HOT BIRD™ is a trademark of EUTELSAT.

Technical Guide
In conventional (broadcast) terminology, the word “programme” is used to

refer to a time-limited transmission such as a film or a TV show. A sequence
of television programmes from the same service provider is usually referred
to as a “television channel”. However, in MPEG terminology, this sequence
of time-limited transmissions would still be referred to as a programme.
Because of the potential confusion that could occur through the adoption of
MPEG terminology, DVB chose to refer to a time-limited transmission as an
“event” and to a sequence of time-limited transmissions as a “service”. In
traditional broadcast terminology, a “service” is therefore equivalent to a
“television channel” and an “event” is equivalent to a “television
programme”.
2. Basic Elements of A Satellite DVB

System
Figure 1 is a simple generic model of a digital satellite transmission channel.

It comprises several basic building blocks, which include baseband
processing and channel adaptation in the transmitter and the complementary
functions in the receiver. Central to the model is, of course, the satellite
transmission channel. In a practical system the transmitter elements in Figure
1 would not necessarily be implemented at the same location. Channel
adaptation would be most likely be done at the transmit satellite earth station,
whilst the baseband processing would be performed at a point close to the
programme source.
Satellite Satellite Satellite

Service Baseband Baseband
Channel Transmission Channel
Content Processing
Adaptation Channel Adaptation
Processing
Transmitter Receiver
Figure 1 : Generic Model of the Digital Satellite Transmission Channel
The service content could be any mixture of video, audio and data. Delivery
could be to a conventional television set via a set-top box or even to a personal
computer.
An overview of the baseband processing and satellite channel adaptation
blocks is given in section 3. and section 4. respectively.

Technical Guide
3. Baseband Processing
3.1. MPEG-2
The established MPEG-2 standard was adopted in DVB for the source coding
of audio and video information and for multiplexing a number of source data
streams and ancillary information into a single data stream suitable for
transmission. Consequently, many of the parameters, fields and syntax used
in a DVB baseband processor are specified in the relevant MPEG-2 standards
(See Annex C).
MPEG stands for Moving Picture Experts Group, a group of experts drawn
from industry who contribute to the development of common standards
through an ITU-T and ISO/IEC joint committee.
The MPEG-2 standards are generic and very wide in scope and consequently
some of the parameters and fields of MPEG-2 are not used in DVB. These
restrictions are described in an ETSI Technical Report (ETR 154).
3.2. Processing Functions

Figure 2 is a conceptual block diagram of a DVB (MPEG-2) baseband
processor.
Note that DVB baseband processors do not necessarily physically implement
all of the blocks shown in Figure 2, which serves simply as a basis for
discussion. For example, ETR 154 states that physical implementation of
Packetized Elementary Streams (PES) is not required.
As can be seen from Figure 2, the input to the processor consists mainly of a
number of programme sources. Each programme source comprises any
mixture of raw data and uncompressed video and audio, where the data can
be, for example, teletext and/or subtitling information and graphical
information such as logos.

Technical Guide
Each of the video, audio and programme-related data inputs is encoded and
formatted into a Packetized Elementary Stream (PES). Thus each PES is a
digitally encoded component of a programme.
access units a programme, comprising

related elementary streams
Video PES
Packetizer
Encoder
Programme Source
Transport Multiplexer
Audio PES
Packetizer To
Encoder PESs from
TS Satellite
other
PES programmes Channel
Data
Packetizer Adaptor
Encoder
Clock
Key
Timing SI/ Private
CA PES = Packetized Elementary Stream
Data PSI Data
TS = Transport Stream
SI = Service Information
PSI = Programme-Specific Information
Control/Other Data
CA = Conditional Access
Figure 2 : Conceptual Model of a DVB (MPEG-2) Baseband Processor
The simplest type of service is a radio programme, which would consist of a

single audio elementary stream. A traditional television broadcast would
comprise three elementary streams: one carrying coded video, one carrying
coded stereo audio and one carrying teletext.
Following packetization, the various elementary streams of a programme are
multiplexed with packetized elementary streams from other programmes to
form a Transport Stream (TS).
Each of the Packetized Elementary Streams can carry timing information, or
“time stamps”, to ensure that related elementary streams, for example, video
and audio, are replayed in synchronism in the decoder. Programmes can each
have a different reference clock, or can share a common clock. Samples of
each “Programme Clock”, called Programme Clock References (PCRs), are
inserted into the Transport Stream to enable the decoder to synchronise its
clock to that in the multiplexer. Once synchronised, the decoder can correctly
interpret the time stamps and can determine the appropriate time to decode
and present the associated information to the user.

Technical Guide
Additional data is inserted into the Transport Stream, which includes

Programme Specific Information (PSI), Service Information (SI), Conditional
Access (CA) data and Private data. Private data is a data stream whose content
is not specified by MPEG.
The output of the transport multiplexer is a single data stream that is suitable
for transmission or storage. It may be of fixed or variable data rate and may
contain fixed or variable data rate elementary streams. There is no form of
error protection within the multiplex. Error protection is instead implemented
within the satellite channel adaptor (See section 4.2.2.).
Each of the elements of the conceptual block diagram of Figure 2 is described
in more detail in the following sections.
3.3. Programmes
3.3.1. Elementary Streams

A programme essentially consists of a number of related elementary streams
that usually require time-synchronisation in the decoder. Elementary streams
may consist of coded video or audio information, or data such as teletext.
These three types of elementary stream are discussed below.
3.3.1.a Video
3.3.1.a.1 Compression Algorithms

A digital video signal created in a TV studio has a bit rate of 166 Mbit/s (ITU-
R Recommendation BT.601-5). Since, as indicated previously, the bit rate of
the Transport Stream is typically about 38 Mbit/s, then clearly a significant
degree of data compression is required in order to transmit this video
information in the MPEG-2 multiplex. This data compression is possible
because video sequences typically contain a significant amount of statistical
and subjective redundancy within and between video frames.
In DVB, the data compression is implemented using the international MPEG-
2 video standard. The standard specifies a data stream “syntax” and the
system designer is given a “tool box” that may be used to construct systems
with different degrees of sophistication. The video encoder itself is not
specified, leaving encoder manufacturers the freedom to perform their own
trade-offs of cost and complexity against picture quality.

Technical Guide
MPEG-2 encoding exploits the fact that picture elements that are physically
adjacent in the same frame (image) may be identical or very similar. In this
case, the picture elements are said to be “spatially correlated” and it is
assumed that the magnitude of any particular picture element can be predicted
from the nearby picture elements in the same frame. Redundant information
can therefore be removed by “intra-frame” coding. The MPEG-2 compression
algorithms employ Discrete Cosine Transform (DCT) coding techniques for
this purpose. This mathematical transformation is performed on small blocks
of 8 x 8 pixels to produce a series of coefficients. The image information tends
to be concentrated into the first few coefficients and many of the “higher
frequency” coefficients are often close to zero. Bit rate reduction is achieved
by discarding the higher frequency elements, which typically carry redundant
information that need not be transmitted. With DCT coding, the image can be
reconstructed from data corresponding to a single video frame.
Picture elements can also be correlated in time (temporal correlation), that is,
the magnitude of a particular picture element can be predicted from picture
elements in a nearby frame. “Inter-frame” coding techniques in the form of
Differential Pulse Code Modulation (DPCM) can be used to remove temporal
redundancy from the video sequence. In this case, data corresponding to more
than one video frame is required in the decoder in order to reconstruct the
image. Inter-frame coding therefore requires more decoder memory.
MPEG-2 video coding employs an adaptive combination of temporal
prediction followed by transform coding of the remaining spatial information
(hybrid DPCM/DCT).
Other techniques are employed in order to obtain better compression
performance. The resolution of the input video is often reduced by sub-
sampling prior to encoding. Clearly, this helps by reducing the number of
picture elements to be coded. Sub-sampling can also be performed in the
temporal domain in order to reduce the frame rate before coding, thus
reducing the number of picture elements that need to be processed per second.
The picture sequence is reconstructed in the decoder at the correct frame rate
by interpolation between frames.
A technique called motion compensation is also employed. This is based on
the estimation of motion between frames. If, for example, the content of a
particular video frame were simply a spatially displaced version of the content
of the previous video frame, then the image could be reconstructed from the
previous image and a “motion vector” describing the direction of movement.
A video sequence processed by an MPEG-2 encoder can consist of three types
of picture: “I”, “P” and “B”.

Technical Guide
I (Intra) pictures are encoded without reference to other pictures in the video
sequence. They provide access points in the bit stream for random access or
switching and are thus used at the start or re-start of a decoding sequence.
However, the inherent data compression is low. “I” pictures can also be used
to limit the degradation introduced by the compression coding, at the expense
of an increase in the output bit rate.
Inter-frame Predicted (“P”) pictures are coded with reference to the nearest
previously-coded I picture or P picture, usually incorporating motion
compensation to increase coding efficiency. Since they are usually used as a
reference for prediction of future or past pictures, they cannot be used as
random access points.
Bi-directional predicted/interpolated (“B”) pictures are coded with reference
to past and future frames using motion compensation to achieve high
compression. “B” frames add complexity to the system but also produce a
significant saving in bit-rate.
The video encoding algorithm is lossy in the sense that the quality of the
decoded image can never be the same as the quality of the original image,
because some of the image information is discarded in the encoding process.
Clearly, the lower the bit rate used to transmit the video information, the more
information must be discarded and hence the lower the quality of the
reconstructed image. Thus there is a basic trade-off between multiplex
capacity (number of programmes) and video quality. Furthermore, MPEG-2
encoder manufacturers are free to determine their own mix of I, P and B
pictures to suit the application and to achieve an appropriate trade-off between
coding efficiency and complexity. The resulting image quality will therefore
depend upon the degree of sophistication of the compression technique and
the allocated transmission capacity, but also upon the complexity of the image
or video scene (i.e. the amount of temporal and spatial redundancy that can be
exploited).
3.3.1.a.2 MPEG-2 Profiles and Levels

MPEG-2 uses the joint concepts of “Profiles” and “Levels” to specify the
detail of the source material and the complexity of the compression algorithm.
They provide a means for defining subsets of the MPEG-2 syntax and the
decoder capabilities required to decode a particular bit stream.
Each “Profile” offers a collection of compression tools that together make up
the coding system. A different profile means that a different set of
compression tools is available.

Technical Guide
There are currently five profiles in the MPEG-2 system, as summarised in

Table 1. Each profile is progressively more sophisticated and adds additional
tools to the previous profile. Backward-compatibility applies to the
succession of profiles. For example, a Main Profile decoder will decode
pictures encoded by Simple Profile encoders, as well as pictures encoded by
Main Profile encoders.
MPEG-2 Description Used in

Profile DVB?
Simple Basic set of compression tools, with processing of line- Yes
sequential colour-difference signals (4:2:0).
Main Adds bi-directional prediction capability. Yes
SNR Allows for a layered bit stream, comprising a base layer and No
Scaleable supplementary signals. The supplementary signals improve the
SNR with respect to base layer decoding only.
Spatially The supplementary signals improve the picture resolution with No

Scaleable respect to base layer decoding only.
High Adds processing of line-simultaneous colour-difference signals No

(4:2:2).
Table 1: Summary of MPEG-2 Profiles

The Simple Profile provides a basic set of compression tools.
The Main Profile has all of the tools of the Simple Profile, plus one more
(bi-directional prediction). A refinement of the Main Profile, sometimes
known as Main Profile Professional Level, allows line-sequential colour
difference signals (4:2:2) to be used, but not the scaleable tools of the higher
profiles.
The two Scaleable Profiles, SNR Scalable and Spatially Scalable, add tools
that allow the coded video data to be partitioned into a base layer and one or
more supplementary signals. The supplementary signals can be used to either
improve the signal-to-noise ratio (SNR Scaleable) or the picture resolution
(Spatially Scaleable). These tools are intended to support applications beyond
those addressed by the Main Profile. For example, support could be provided
for receivers having different display capabilities, where receivers that are not
capable of reconstructing the full resolution video can decode subsets of the
layered bit stream to display video at lower spatial or temporal resolution, or
at lower quality.
The first four profiles code the colour difference signals line-sequentially
(4:2:0). The High Profile includes all the tools of the lower levels, plus the
ability to code line-simultaneous colour-difference signals (4:2:2). In effect,
the High Profile is a “super-system”, designed for the most sophisticated
applications where there is no constraint on bit rate.
Because of their complexity, the two Scaleable Profiles and the High Profile
are not supported by DVB.

Technical Guide
A “Level” specifies the range of parameters that are supported by the encoder/
decoder (i.e. image size, frame rate and bit rates). The four MPEG-2 levels are
summarised in Table 2.
Generally speaking, MPEG-2 encoders for broadcast applications operate at
Main Profile, Main Level and are capable of encoding 4:3 format television
at a quality comparable to that achieved with existing PAL and SECAM
standards, at bit-rates from 1.5 Mbit/s to around 15 Mbit/s.
MPEG-2 Picture Resolution Max. Bit Rate Equivalent

Level samples/line: lines/frame (Mbit/s) Quality (approx.)
(25 frame/s)
Low 352 : 288 4 VHS
Main 720 : 576 15 PAL/SECAM
High 1440 1440 : 1152 60 EDTV/HDTV
High 1920 : 1152 80 HDTV
Table 2: Summary of MPEG-2 Levels
3.3.1.a.3 DVB Requirements

Implementation guidelines for the use of the MPEG-2 video encoding
standard are given in ETR 154. Four different classes of IRD and bit stream
are considered therein: Standard Definition Television (SDTV) with frame
rate of 25 Hz, High Definition Television (HDTV) with frame rate of 25 Hz,
SDTV with frame rate of 30 Hz and HDTV with frame rate of 30 Hz.
All DVB IRDs are required to ignore data structures that are currently
“reserved” or which correspond to functions not implemented in the IRD.
This is to ensure full compliance with the MPEG-2 standard and to ensure
upward compatibility with future enhancements.
SDTV DVB bit streams are required to comply with the Main Profile, Main
Level restrictions of MPEG-2. Simpler profiles and/or levels are permitted.
SDTV DVB IRDs are required to support the decoding of Main Profile, Main
Level bit streams as a minimum. Support for higher profiles and levels is
optional. They are also required to support different picture aspect ratios (e.g.
4:3, 16:9) and the decoding and display of still pictures (i.e. video sequences
consisting of a single intra-coded picture).
Further detailed requirements for SDTV and the requirements for HDTV can
be obtained from ETR 154.

Technical Guide
3.3.1.b Audio
3.3.1.b.1 Compression Algorithms

High quality digital audio is already widely available in the form of the
compact disc. However, the audio coding used is 16-bit linear PCM, which
leads to a bit rate in excess of 1 Mbit/s. This is too high for efficient
transmission and consequently, as for video, data compression is required.
MPEG has developed and standardised a more efficient audio coding method.
The MPEG audio standard uses a technique called perceptual coding. A
perceptual audio coder exploits a psychoacoustic effect known as masking,
where a tone that is close in frequency to another tone, but lower in level,
cannot be heard. The lower level tone is thus “masked” by the higher level
tone. Data compression is achieved by discarding sound elements that would
not be heard even if the original signal were faithfully reproduced in the
decoder.
Every sound has a masking curve that is a function of frequency. Another
sound appearing under the curve cannot be detected by the human auditory
system. As the spectrum of the sound changes, so does the masking curve.
All digital audio systems are subject to quantisation noise. Increasing the
number of quantisation levels decreases the quantisation noise and improves
the subjective quality, but increases the number of bits that need to be
transmitted every second.
Perceptual coders operate by shaping the spectrum of the quantisation noise,
so that it is kept under the masking curve. This is done for a number of
frequency bands, called sub-bands. The signal in each sub-band signal is
scaled and then quantised so that the quantisation noise introduced by the
coding will not exceed the masking threshold for that sub-band. The
quantisation noise spectrum is thus dynamically adapted to the signal
spectrum and the minimum number of quantisation bits is used to represent
the audio signal.
3.3.1.b.2 MPEG-1, MPEG-2 and Layers

MPEG audio coding standards are known as MPEG-1 and MPEG-2.
MPEG-1 audio encoding, otherwise known as MUSICAM, was intended for
storage applications with an overall maximum bit rate of about 1.5 Mbit/s. It
provides a means for high quality coding of mono and two-channel stereo
signals at sampling frequencies appropriate for high quality audio (48, 44.1
and 32 kHz).

Technical Guide
MPEG-2 audio is a compatible extension of MPEG-1 audio. It provides

methods for encoding multiple channel surround sound at between 384 kbit/s
and 512 kbit/s. It supports up to five high fidelity channels (left, centre, right,
left surround, right surround), plus a low frequency enhancement (LFE)
channel and up to seven commentary channels in one bit stream. This multi-
channel extension is both forward and backward compatible. Forward
compatibility means that means that a multi-channel (MPEG-2) decoder can
properly decode a stereo (MPEG-1) bit stream. Backward compatibility
means that a standard (MPEG-1) stereo decoder will produce a compatible
stereo signal when decoding a multi-channel (MPEG-2) bit stream. With
MPEG-2, it is also possible to encode Dolby Prologic surround sound signals.
MPEG-2 also uses more advanced encoding to extend MPEG-1 audio to
lower sampling frequencies. The range of possible bit rates has consequently
been adapted to offer more choice at the lower bit rates.
The MPEG-1 and MPEG-2 standards both follow a three-layer model: Layer
I, Layer II and Layer III (layers are analogous to levels in the MPEG-2 video
coding standard). The highest layer provides the highest compression ratio,
but at the expense of complexity, delay and sensitivity to transmission errors.
Layer II is the layer optimised for broadcast applications. Bit rates range from
32 to 192 kbit/s for mono and from 64 to 384 kbit/s for stereo. It has
demonstrated excellent performance at 256 kbit/s and, when using joint
stereo, also at 192 kbit/s. At 128 kbit/s (stereo) the performance is still
acceptable for many applications. Layer I audio is also in regular use.
The MPEG-2 working groups are also developing the Advanced Audio
Coding (AAC) algorithm. AAC will not be backward compatible with
MPEG-1 and MPEG-2 systems.
3.3.1.b.3 DVB Requirements

Implementation guidelines for the use of the MPEG audio encoding standard
are given in ETR 154.
As is the case for video, all DVB IRDs are required to ignore data structures
that are currently “reserved”, or that correspond to functions not implemented
in the IRD.
Audio may be encoded in one of the MPEG-1 single channel, dual-channel,
joint stereo or stereo modes. Alternatively, multi-channel MPEG-2 audio is
permitted, provided that it is backward compatible to MPEG-1 (i.e. it is
compatible with a stereo receiver). The DVB IRD is required to decode all
four MPEG-1 audio modes and at least the basic stereo information from an
MPEG-2 multi-channel bit stream.
Both MPEG Audio Layer I and Layer II may be used for audio encoding, but
Layer II is recommended. IRDs are required to be compatible with both Layer
I and Layer II. Support for Layer III decoding is optional.

Technical Guide
The full range of bit rates for each layer is supported. The three sampling
frequencies, 32, 44.1 and 48 kHz, are supported for primary sound services.
Other sampling rates may be used for secondary sound services, but support
of these rates in the DVB IRD is optional.
3.3.1.c Data
With reference to Figure 2, it can be seen that certain non-video and non-
audio data is processed before being input to the transport multiplexer,
whereas other data, such as the Service Information, is input directly to the
transport multiplexer.
The reason for this is that some data needs to be synchronised with the video
and audio content of a specific programme. This data is encoded into
Programme Elementary Stream (PES) packets in order to take advantage of
the in-built time stamp and synchronisation facilities of the PES.
Two specific examples of this type of data are teletext and subtitling. Standard
methods exist for transporting this information in DVB bit streams and are
reviewed in the following sections.
3.3.1.c.1 Teletext
The ETSI standard EN 300 472 specifies the method by which ITU-R System
B Teletext2 may be carried in DVB bit streams.
The transport mechanism is intended to support the transcoding of the teletext
data into the Vertical Blanking Interval (VBI) of analogue video, such that it
is compatible with existing TV receivers equipped with teletext decoders. It
is specified to be capable of transmitting subtitles with accurate timing with
respect to the video (i.e. to within or near frame accuracy).
Teletext data are conveyed in Packetized Elementary Stream (PES) packets
as private data. The PES packets are in turn carried by Transport Stream
packets.
The Packet Identifier (PID) of a teletext stream associated with a particular
service (programme) is identified in the Service Information, or more
specifically in the Program Map Table (PMT) of the Program Specific
Information (PSI) for that service (see Section 3.5 for a discussion on the PSI
and the PMT).
A service may include more than one teletext data stream, provided that each
stream can be uniquely identified.
2. ITU-R Recommendation 653, also known as EBU Teletext (EBU SPB 492).

Technical Guide
3.3.1.c.2 Subtitling and Graphics

The ETSI standard ETS 300 743 specifies the method by which subtitles,
logos and other graphical elements may be efficiently coded and carried in
DVB (MPEG-2) bit streams.
Subtitling data is carried in Programme Elementary Stream (PES) packets,
which are in turn carried by Transport Packets. All the data of a subtitle stream
is carried by a single transport packet stream, that is, with a single Packet
Identifier (PID).
A single transport packet stream can carry several different streams of
subtitles.
The different subtitle streams could be subtitles in different languages for a
common programme, or could be subtitles for different programmes
(provided that the programmes share a common programme clock reference).
Different subtitle streams could also be used to address different receiver
types (e.g. 4:3 and 16:9 aspect ratio displays), or to address special needs such
as subtitling for viewers with impaired hearing.
Different subtitling streams are identified within a transport packet stream by
their Page Identifiers.
The Programme Map Table (See section 3.5.2.a) describes the available
subtitling streams and specifies the Packet Identifier and the Page Identifier
that uniquely identify each subtitling stream.
The Presentation Time Stamp (PTS) in the PES packet provides the necessary
timing information for the subtitling data.
3.3.2. Packetized Elementary Streams

The Packetized Elementary Stream (PES) is designed for real-time data such
as video and audio and provides all the necessary mechanisms for the
transport and synchronisation of video and audio elementary streams.
The PES is described in this section using the specific example of an MPEG-
2 encoded video stream. Similar considerations apply for other types of data,
such as audio.

Technical Guide
The formation of a video Packetized Elementary Stream is illustrated in

Figure 3.
SOURCE VIDEO
fixed length
830 kbytes 830 kbytes 830 kbytes 830 kbytes Presentation Units
(uncoded pictures)
MPEG-2 Coding
variable length
Access Units
(coded pictures)
Packetization
packet header
fixed or variable
payload length PES
packets
PACKETIZED ELEMENTARY STREAM
Figure 3 : Constructing a Packetized Elementary Stream
The input to the MPEG-2 encoder is assumed to be at Main Level. From Table
2, this means that the luminance component is sampled 720 times per line.
Given that there are 576 active lines per frame, each picture (frame) consists
of 720 x 576 luminance samples. The two colour difference signals are each
sampled at half this rate, producing the same amount of data per frame for the
chrominance information. Consequently, since all samples are represented
with 8 bits, each picture in the uncompressed video input represents
approximately 830 kbytes of data.
Each picture in its uncompressed form is referred to as a Presentation Unit.
The coder compresses each presentation unit to give a coded picture. A coded
picture is known as an “Access Unit”.
The video access units are not all of the same size. The size depends upon the
degree of redundancy in the picture and upon whether they represent an “I”,
“P” or “B” picture (see Section 3.3.1.1.1). The approximate size of a video
access unit is 100 kbytes, 33 kbytes and 12 kbytes for “I”, “P” and “B”
pictures respectively, although the size can vary considerably from these
typical values due to the varying complexity of the picture.
The output of the MPEG-2 encoder is a succession of access units that
comprise a video elementary stream. Although the input to the video coder is
at a constant bit rate, the video elementary stream at the output of the coder is
not.
The next step in the creation of the MPEG-2 multiplex is to convert each
elementary stream into a Packetized Elementary Stream (PES). A Packetized
Elementary Stream consists entirely of PES packets.

Technical Guide
The PES packets consist of a payload and a header. The payload of

consecutive packets is filled with data bytes taken sequentially from the video
elementary stream. The start of a new access unit need not coincide with the
start of a PES packet payload, but may occur anywhere within the payload.
Multiple access units may be carried in the payload of a single PES packet.
Access units can also be split across PES packet boundaries. The PES packets
may be of variable length, the length being indicated in the packet header.
The header of each PES packet includes information that distinguishes PES
packets belonging to one elementary stream from those of another within the
same programme. Up to 32 audio elementary streams and 16 video
elementary streams can be uniquely identified within a single programme.
The header also provides other information, such as the length of the PES
packet and whether or not the payload is scrambled.
The PES packet header periodically contains timing information that is
necessary to ensure correct synchronism between related elementary streams
in the decoder. These are the “time stamps” referred to in section 3.2. MPEG
stipulates that a time stamp must occur at least every 0.7 seconds in a video
or audio packetized elementary stream.
3.3.3. The Programme Stream

An MPEG-2 Programme Stream is a multiplex of elementary streams that
share a common time-base. It has essentially the same features as an MPEG-
1 data stream, but additionally supports scrambling, trick modes, a directory
of the contents of the multiplex and a map describing the features of the
streams.
The programme stream is intended for use in storage-based interactive
systems. The packet size is flexible and is normally chosen to be relatively
large to suit the software processing inherent in such systems. However, it is
not well suited to an environment where data errors are common.
Programme streams are not used in DVB and are mentioned here for the sake
of completeness. DVB utilises the Transport Stream to convey information
relating to multiple programmes.
3.4. The Transport Stream Multiplex

The transport stream protocol provides mechanisms for the fragmentation and
re-assembly of higher-level protocols and for error detection.

Technical Guide
The Transport Stream is intended for broadcast systems where error resilience
is one of the most important properties. It supports multiple programmes with
independent time-bases, carries an extensible description of the contents of
the programmes in the multiplex and supports re-multiplexing and scrambling
operations.
A transport stream multiplex always consists entirely of short, fixed length
transport packets. A transport packet is always 188 bytes long and comprises
a “header”, followed by “adaptation field” or a “payload”, or both.
The mapping of PES packets into transport packets is illustrated in Figure 4.
The transport packets are usually shorter in length than the PES packets of an
elementary stream. Consequently, each PES packet is divided among the
payload parts of a number of transport packets. The start of the PES packet
must occur at the start of a transport packet payload and a transport packet
may only carry data taken from one PES packet. Since a PES packet is
unlikely to exactly fill the payloads of an integer number of transport packets,
the payload of the last transport packet will be left partially empty. This
excess capacity is deliberately wasted by including an adaptation field of the
appropriate length in this transport packet.
PES Packets
fixed or variable
length
fixed length
(188 bytes)
Transport Packets
packet header adaptation field payload
Figure 4 : Dividing a PES Packet into a Number of Transport Packets
All the packetized elementary streams that are to be multiplexed together are
converted to transport packets. The resultant transport packets are output
sequentially in any order to form an MPEG-2 Transport Stream, so long as the
chronological order of packets belonging to the same elementary stream is
preserved. Transport packets carrying other information, such as Service
Information or Conditional Access data, are also added to the multiplex,
together with “null” packets that fill up any spare multiplex capacity.

Technical Guide
A single transport stream can carry many different programmes, each

comprising many packetized elementary streams. A 13-bit Packet Identifier
(PID) field is used in the header of each transport packet to distinguish
transport packets containing data from one elementary stream from those
carrying data from other elementary streams. The PID is also used to
distinguish transport packets carrying other data, such as service information,
from those carrying data from elementary streams. The MPEG-2 syntax
allows for up to 8175 uniquely identifiable data streams to be accommodated
in a single transport stream.
The PID is used in the first stage of transport stream de-multiplexing. MPEG-
2 demultiplexers usually pipe all information carried in transport packets with
a video PID directly to the video decoder chip. Similarly, all information
carried in transport packets with an audio PID is routed directly to the audio
decoder chip.
The transport packet header also includes a continuity counter, which is
incremented for successive transport packets belonging to the same
elementary stream. This enables a decoder to detect the loss of a transport
packet and to take the necessary action to conceal any errors that this loss
would otherwise produce.
3.5. Service Information

As can be seen in the illustration of Figure 2, Service Information (SI) data
forms a part of the DVB Transport Stream. It is included for two main
reasons: so that an Integrated Receiver Decoder (IRD) can automatically
configure itself for the selected service and so that the user can be provided
with information to assist in selection of services and/or events within the bit
stream.
SI data for automatic configuration of the IRD is mostly specified within
MPEG-2 as Program Specific Information (PSI).
Additional SI data is specified within DVB to complement the PSI by
providing data to aid the automatic tuning of IRDs and additional information
intended for display to the user. This is usually referred to as “DVB-SI”. The
relevant information is given in the ETSI standard EN 300 468.
The manner of presentation of the information is not specified and IRD
manufacturers have freedom to choose appropriate presentation methods. The
data contained within the DVB-specified SI may be used as the basis for an
Electronic Programme Guide (EPG).
Rules of operation for the implementation of DVB-SI are given in the ETSI
Technical Report ETR 211.

Technical Guide
The MPEG-2 PSI and the DVB-SI are based on MPEG-2 “Sections” and
“Tables”. These are briefly described in the following section.
3.5.1. MPEG-2 Sections and Tables

The MPEG-2 standard uses sections for the encapsulation of non-real-time
data. Sections are also used to support features such as fragmentation and re-
assembly of information, enhanced addressing and version control.
Due to their flexibility in terms of addressing, MPEG-2 sections are also the
basis for parts of the MPEG-2 Digital Storage Media Command and Control
(DSM-CC) system, which has become an integral part of the MPEG-2
standard. DSM-CC is the basis for several of the DVB data broadcasting
protocols, which will not be described further in this annex.
An MPEG-2 table is a kind of database that carries, for example, the
parameters of all digital transponders at a given orbital location (a NIT -(See
section 3.5.3.a)), or a description of a number of audio-visual services (an
SDT - (See section 3.5.3.c)).
Figure 5 is a summary of the various tables that comprise the PSI and the
DVB-SI. It is based on a similar diagram given in the ETSI Standard EN 300
468.
To facilitate the handling of databases containing several thousand bytes, an
MPEG-2 table is split into a number of MPEG-2 sections. A table can consist
of one or more sections, up to a maximum of 256.
The reason for this section-oriented approach is that the MPEG-2 system was
designed for decoders having a limited buffer size for high-speed data
reception. Consequently, the length of a section is limited to 1024 bytes (or
4096 bytes in the particular case of an EIT). Dividing the database up in this
way allows the table to be reconstructed in the receiver using low-speed data
storage.
In contrast to the MPEG-2 Transport Packets, which have a fixed length of
188 bytes, a section is a data container of variable length. It basically consists
of a header, a payload and a cyclic redundancy check (CRC) component. The
structure of a section is illustrated in Table 3.
The MPEG-2 standard defines two types of section, which are referred to here
as “long” and “short”.
Sections with the section_syntax_indicator field of their header set to “0”
have the simplified short section structure indicated in Table 3. In this case,
the section only carries a table_id, some reserved fields and the
section_length field. As the name suggests, the section_length field indicates
how many data bytes will be contained in the payload that follows the header.

Technical Guide
If the section_syntax_indicator field is set to “1” the section will be structured

in accordance with the long syntax. This enables the implementation of
databases of arbitrary length, up to 1 Mbyte, and provides mechanisms for
database version control and updating.
MPEG-2 PSI DVB SI DVB SI
(mandatory) (optional)
Program Network Network

Association Information Information
Table Table Table
(for actual (for other
PAT* NIT delivery NIT delivery
system) system)
Conditional Bouquet
Access Association
Table Table
CAT BAT
Program Service Service

Map Description Description
Tables Table Table
(for actual (for other
PMT SDT transport SDT transport
stream) stream)
Event Event Event

* indicates where the
Information Information Information
NIT may be found
Table Table Table
(for actual (for actual (for other
Transport Stream EIT transport transport EIT EIT transport
stream) stream) stream)
Description Table
present/following schedule present/following
schedule
TSDT
Time and Running
Date Status
Table Table
TDT RST
Time
Offset
Table
TOT
Stuffing
Table
ST
Figure 5 : Overview of the DVB/MPEG-2 Service Information

Technical Guide
Syntax
“Short” “Long”
Field Component Length (bits) Length (bits)

table_id 8 8
section_syntax_indicator 1 1
private_indicator 1 1
reserved 2 2
section_length 12 12
table_id_extension HEADER not used 16
reserved not used 2
version_number not used 5
current_next_indicator not used 1
section_number not used 8
last_section_number not used 8
payload PAYLOAD 8 * section_length 8 * (section_length - 4)
CRC32 CHECKSUM not used 32
Table 3: Structure of an MPEG-2 Section
All MPEG-2 PSI sections and the most important DVB-SI sections follow the
long syntax.
All sections of a table carry the same table_id, an 8-bit field. In order to allow
for more than 256 tables, there is also a 16-bit table_id_extension field (long
syntax). This allows for up to 16.8 million tables, each having a length of
about 256 kbytes (or about 1 Mbyte for EITs).
The section_number and last_section_number fields of the section header
support the re-assembly of the table in the receiver. The section_number is a
simple counter to identify the place of the section within a sequence of
sections. The last_section_number identifies the last section of a table. If a
receiver has loaded all sections having the same table_id with section
numbers up to and including the last_section_number, then it knows that it
has loaded the entire table.
The version_number field is used to inform a receiver that a new version of a
database (Table) needs to be downloaded. The version_number field is
incremented each time new data is transmitted within a table. Since this field
is only five bits wide, the version number repeats every 16 tables. It is very
important that the version_number field is updated following each table
update, otherwise the receiver may become confused.

Technical Guide
The current_next_indicator field can optionally be used to validate a new

version of a table. In practice, this mechanism is not used and consequently it
is not further described in this annex.
3.5.2. Programme Specific Information (MPEG-2)

The PSI data consists of three types of table: the “Program Association Table”
(PAT), the “Program Map Table” (PMT) and the “Conditional Access Table”
(CAT), as shown in Figure 5. The PAT and the PMT are mandatory and must
be contained in every DVB-compatible data stream. The CAT must be
contained in the data stream if a Conditional Access (CA) system is
employed.
The PSI tables are used to physically describe the content of an MPEG-2
Transport Stream.
Each packet of a transport stream is tagged with a PID value to indicate to
which elementary stream its payload belongs. In order to determine which
elementary streams belong to a particular programme, the IRD needs
additional information that relates the PID values of the elementary streams
to programmes. This information is relayed in the PSI. Figure 6 shows how
the PAT and the PMT are used to associate the programmes to elementary
streams.
The PAT, PMT and CAT of the PSI provide information only for the
multiplex in which they are contained. They do not give any information on
programmes carried in other transport streams, even if these are delivered by
the same physical network.
As indicated previously in Section 1.5, MPEG terminology differs from DVB
terminology. In this context, it should be noted that the MPEG-2 “programme
number” used in the PAT and in the PMT corresponds to the “service id” in
the DVB-SI.
The three PSI tables are described in more detail below.

Technical Guide
Note that a fourth MPEG-2 table is shown in Figure 5. This is the Transport
Stream Description Table (TSDT). Its purpose is to provide compatibility
with other delivery systems such as SNG (Satellite News Gathering) and
ATSC (North American television standard). It is not described further in this
document.
PID = 0
Network Information Table
(NIT)
Programme PID Value
No.
0 16
1 83
3 76
7 93
5 93
etc. etc.
Stream PID Value
(other data)
PCR 56
Programme Association Table
video 63
(PAT)
audio 1 64
audio 2 71
subtitling 95
transport packets
etc. etc.
containing the
(other data) video elementary
stream for programme
Programme Map Table no. 3
(PMT)
Figure 6 : Referencing Elementary Streams with PSI Tables
3.5.2.a Program Map Table (PMT):

Each programme (service) carried by the transport stream has an associated
PMT.
The PMT identifies the elementary streams that comprise the programme. It
also provides other descriptive information concerning the programme, such
as information on the video and audio encoding parameters, language
identification, conditional access information, and so on. It also indicates
where the Program Clock Reference (PCR) for that programme can be found
in the transport stream, so that the various elementary streams can be properly
synchronised in the decoder.
The programme’s elementary streams and PCR are identified in the PMT by
their transport packet PID values.
It is possible for a single PMT to describe more than one programme.

Technical Guide
A uniquely assigned PID value identifies which transport packets carry a

particular PMT.
3.5.2.b Program Association Table (PAT)

The PAT always has the PID value zero so that it can easily be found.
The PAT provides a complete list of all of the programmes (services) that are
available in the transport stream. The programmes are identified by their
programme number.
The PAT indicates where the Program Map Tables can be found in the
transport stream for each of the identified programmes. The Program Map
Tables are identified by means of their PID values.
Programme number zero always points to the Network Information Table
(NIT). The Network Information Table provides information about the
physical network carrying the transport stream, such as channel frequencies,
satellite transponder details, modulation characteristics, service name, service
originator, etc.
Strictly speaking, the NIT is part of the MPEG-2 PSI. However, MPEG-2
only defined its existence, stipulated that its use was optional and left the
related syntax and semantics open. DVB subsequently made the transmission
of a NIT mandatory and specified its characteristics. Consequently, the NIT
is usually considered to be part of the DVB-SI (See section 3.5.3.a).
3.5.2.c Conditional Access Table (CAT):

The Conditional Access Table provides information on the CA systems used
in the multiplex. The information held in the CAT is private and is dependent
on the CA system used.
A CAT must be present if any elementary streams in the transport stream are
scrambled and it must list the relevant Entitlement Management Message
(EMM) streams. The MPEG-2 standard also requires that EMMs and
Entitlement Control Messages (ECMs) be sent in transport stream packets.
The contents of transport stream packets that contain such data will, if present,
usually be encrypted (scrambled).
Note that the allocation of “CA_system_id” codes, which are used to identify
the kind of encryption employed, may be found in ETSI Report ETR 162.
3.5.3. DVB Service Information

In addition to the PSI, data is needed to provide identification of services and
events for the user.

Technical Guide
Unlike the MPEG-2 PSI, the DVB-SI provides information on services and
events carried by different multiplexes, and even on services and events
carried by other networks.
The DVB-SI data is structured as nine tables:
n the Bouquet Association Table (BAT),
n the Service Description Table (SDT),
n the Event Information Table (EIT),
n the Running Status Table (RST),
n the Time and Date Table (TDT),
n the Time Offset Table (TOT),
n the Stuffing Table (ST),
n the Selection Information Table (SIT), and
n the Discontinuity Information Table (DIT).
In addition, as discussed previously, the structure of the NIT is defined by
DVB.
The various DVB-SI tables are briefly described in the following sections.
Guidelines for processing the Service Information at delivery media
boundaries (e.g. from satellite to cable or SMATV systems) can be found in
ETSI Report ETR 211.
3.5.3.a Network Information Table (NIT)

The NIT is used to transmit technical information about the delivery network,
which could be a satellite network, a cable network or a terrestrial network.
Since a network typically carries more than one transport stream, the NIT of
one transport stream can be used to provide the information that is necessary
to locate other transport streams within the same network.
Sometimes it is difficult to describe the boundaries of a network. For example,
a satellite delivery network could consist of all satellites in geostationary
orbit, or just a single satellite at a single orbital location. Clearly, if the
network were to consist of very many satellites, then the databases required
to describe all of the transport streams delivered by these satellites would be
unmanageably large. The common understanding is that a satellite network
comprises one or more satellites located at a single orbital position. The
satellites of the HOT BIRD™ system at the 13ºE orbital position therefore
constitute a satellite network.
Networks are assigned individual network_id values. The allocation of these
codes may be found in the ETSI Report ETR 162. For example, a unique code
is allocated for the HOT BIRD™ satellite system at 13ºE.

Technical Guide
It is possible to transmit a NIT for other networks in addition to the actual

network (the one carrying the NIT). Differentiation between the NIT for the
actual network and the NIT for other networks is achieved using different
table_id values.
IRDs may be able to store the NIT information in non-volatile memory in
order to minimise the access time when switching between channels (i.e.
when “channel hopping”).
The syntax and semantics of the NIT are defined in the DVB specification
EN 300 468.
3.5.3.b Bouquet Association Table (BAT)

The BAT provides information regarding service “bouquets”. A bouquet is a
collection of services marketed as a single entity. The information provided
by the BAT includes the name and a list of services for each bouquet.
The BAT can be the basis on which an IRD presents the services to the user.
Bouquet operators might use this tool to re-group their services at the user
interface (e.g. “children’s channels”, “sports channels”, etc.). EUTELSAT
intends to use the BAT to provide a EUTELSAT Service Guide to facilitate
the reception of free-to-air services.
Multiplexes that are delivered by different distribution media (e.g. satellite
and cable networks) can belong to the same bouquet.
The allocation of bouquet_id codes can be found in ETR 162.
3.5.3.c Service Description Table (SDT)

The Service Description Table contains data describing the services that are
contained within a particular transport stream. The services may be part of the
actual transport stream (the one carrying the SDT) or part of another transport
stream.
The SDT provides information such as the name of the service and the name
of the service provider. This information is used by the receiver to compile
and display a list of available services.
3.5.3.d Event Information Table (EIT)

The EIT provides information in chronological order regarding the events
contained within each service. This includes information such as event name,
start time, duration, etc.

Technical Guide
There are two basic types of event data held in the EIT: “present/following”
and “schedule”. Present/following data refers to the currently running
(“present”) event and the next (“following”) event of a given service.
Schedule data consists of a list of events that will take place at some time after
the next event. The EIT schedule tables are optional.
The present/following EIT can be used to implement a simple user interface
in the receiver. The schedule EIT can be used to implement a more complex
EPG.
The EIT can contain event information concerning the actual transport stream
(the one carrying the SDT) or other transport streams.
3.5.3.e Running Status Table (RST)

The RST allows accurate and rapid updating of the timing status (running/not
running) of one or more events. This may be necessary when an event starts
early or late due to scheduling changes. The use of a separate table provides
a fast updating mechanism.
3.5.3.f Time and Date Table (TDT)

The TDT is one of two tables that can be used to transmit time information.
The TDT carries the present time and date information in UTC format. This
information is given in a separate table because the information is frequently
updated.
No information on summer/winter time is transmitted in this table.
Consequently, if the TOT is not used (see below), user intervention will be
required whenever there is a summer-winter time change.
3.5.3.g Time Offset Table (TOT)

The TOT conveys additional information about summer and winter time
periods and gives the local time offset with respect to UTC for different
countries and regions. If the TOT is used, the only user interaction required is
to define the country or region in which the receiver is operated.
This information is also given in a separate table because the information is
frequently updated.
3.5.3.h Stuffing Table (ST)

The Stuffing Table is used to invalidate existing tables at a delivery system
boundary (e.g. at a cable head-end, where signals delivered by satellite need
to be re-formatted for cable distribution).

Technical Guide
3.5.3.i Selection Information Table (SIT) and Discontinuity Information Table

(DIT)
The presence of the SIT in a bit stream identifies the bit stream as a “partial”
transport stream coming from a digital interface. In this case the receiver
should not expect to receive all the SI information that is normally present in
a broadcast transport stream. It should instead rely on the SI carried by the
SIT, which contains a summary of all relevant SI information conveyed in the
broadcast stream. A DIT is inserted at transition points where SI information
is discontinuous.
The use of the SIT and DIT is restricted to partial transport streams. They are
not used in broadcasts.
3.6. Conditional Access

In many cases DVB-based services will include some elements that are not
freely available to the public at large. The term “Conditional Access” (CA) is
used to describe systems that control access to programmes and services.
CA systems consist of several blocks, including:
n the mechanism to scramble the programme or service and to convey the
necessary CA data to the receiver,
n the “Subscriber Management System” (SMS), in which all customer data
is stored,
n the “Subscriber Authorisation System” (SAS), which encrypts and delivers
code words to enable the programme or service to be correctly
descrambled.
Neither the SMS nor the SAS have been standardised by DVB and are
implemented in proprietary systems.
3.6.1. Common Scrambling Algorithm

DVB has specified common elements of CA systems in the ETSI Report ETR
289. The purpose of this specification is to provide support for a wide range
of CA systems that are based on the MPEG-2 and DVB specifications. It
defines those aspects that are required for the coexistence of multiple
conditional access systems within a single data stream.

Technical Guide
A key part of the DVB specification is the “Common Scrambling Algorithm”

(CSA), which has been designed to minimise the likelihood of piracy attack
over a long period of time. It is a tool for the secure scrambling of Transport
Streams (TS) or Programme Elementary Streams (PES). For security reasons,
ETR 289 does not provide detailed information on the scrambling algorithm
itself, but rather describes the principles of operation and the use of the
scrambling algorithm in the MPEG-2 environment.
DVB also specifies, by way of ETSI Report ETR 289, an MPEG-2 compatible
method for the transport of CA information, such as ECMs, EMMs and future
entitlement data, and addresses transcontrol issues at distribution media
boundaries (e.g. at the transition between satellite and cable systems).
3.6.2. Multicrypt, Simulcrypt and the Common Interface

There are two basic ways to allow viewers to access programmes that have
been processed by different CA systems. These are commonly referred to as
“MultiCrypt” and “SimulCrypt”.
In order to receive pay-TV services or other services with controlled access,
the IRD needs to be equipped with a conditional access module. The function
of this module is to receive and interpret the CA information contained in a
transport stream and to descramble those programmes that have been
authorised.
The MultiCrypt approach requires the CA module in the IRD to be
standardised to a certain extent, in particular, through the provision of a
“common interface”.
With SimulCrypt, the CA module can be entirely proprietary and can be
embedded within the IRD so that physical access to the unit is difficult.
In MultiCrypt applications, the descrambling of programmes controlled by
different CA systems requires insertion of the appropriate CA module into the
common interface. It is inconvenient in the sense that multiple CA modules
and interfaces may be required if the viewer wishes to receive services
delivered by multiple CA systems, which potentially makes the IRD more
expensive and difficult to use. The CA module is also physically more
accessible than is the case with SimulCrypt, which can give rise to security
concerns. However, MultiCrypt has two important benefits. Firstly, it allows
service providers to operate entirely independently, with no need to share CA
information and no need to enter into a commercial agreement with other
service providers who are addressing the same market with different CA
systems. Secondly, the architecture of the IRD is more “open”. Consequently,
the IRD is less likely to become obsolete as services evolve or if the viewer
wishes to subscribe to a different package controlled by a different CA
system. Such changes can be accommodated simply by insertion of a new CA
module into the common interface. MultiCrypt therefore provides a degree of
protection of the viewer’s hardware investment.

Technical Guide
DVB has specified a common interface for conditional access (and other DVB
decoder applications) that is suitable for use in MultiCrypt applications. It
provides a means for the IRD to descramble programmes that have been
broadcast in parallel using different CA systems through the insertion of a
PCMCIA module into the common interface.
In SimulCrypt applications, the viewer is able to use a single CA system built
into his IRD to watch all programmes, irrespective of the CA system used to
scramble each programme. This has some security benefits with respect to
MultiCrypt because the CA module is not usually physically accessible to the
user. Furthermore, there is potentially some cost saving in the manufacture of
the IRD since the common interface need not be provided, although the cost
of implementing this interface has fallen considerably and continues to fall.
In contrast to MultiCrypt, the Simulcrypt approach requires CA system
operators to establish commercial agreements amongst themselves, which can
sometimes be difficult. It also implies dedicated IRD hardware that cannot be
upgraded or adapted for use with other CA systems and therefore may become
obsolete with time.
Both MultiCrypt and SimulCrypt have their advantages and disadvantages, as
described above. With these in mind, service providers will choose the
approach that best meets their commercial objectives. Both approaches can
and do coexist in satellite-based delivery systems.
4. Satellite Channel Adaptation
The ETSI EN 300 421 standard specifies the modulation and channel coding
system for satellite digital multi-programme TV services, both for primary
and secondary distribution and for use in the Fixed Satellite Service (FSS) and
in the Broadcast Satellite Service (BSS) frequency bands. This is commonly
referred to as the “DVB-S” standard.
The standard is intended for Direct-To-Home (DTH) services to consumer
Integrated Receiver Decoders (IRD), as well as for reception via collective
antenna systems (Satellite Master Antenna Television (SMATV)) and at
cable television head-end stations. It can support the use of different satellite
transponder bandwidths, although a bandwidth of 33 MHz is commonly used.
All service components (“programmes”) are Time Division Multiplexed
(TDM) into a single MPEG-2 transport stream, which is then transmitted on
a single digital carrier.

Technical Guide
The DVB-S system was intended primarily for single-carrier-per-transponder

applications, where the carrier conveys multiple programmes time-
multiplexed together in a transport stream. This configuration is often referred
to as Multiple-Channel-Per-Carrier (MCPC). However, DVB-S can also be
used for multiple-carrier-per-transponder applications, where each carrier
usually conveys a single programme (service). This configuration is usually
referred to as Single-Channel-Per-Carrier (SCPC).
The modulation is classical Quaternary Phase Shift Keying (QPSK). A
concatenated error protection strategy is employed based on a convolutional
“inner” code and a shortened Reed-Solomon (RS) “outer” code. Flexibility is
provided so that transmission capacity can be traded off against increased
error protection by varying the rate of the convolutional code. Satellite links
can therefore be made more robust, at the expense of reduced throughput per
satellite transponder (i.e. fewer DVB services).3
The standard specifies the characteristics of the digitally modulated signal to
ensure compatibility between equipment developed by different
manufacturers. The processing at the receiver is, to a certain extent, left open
to allow manufacturers to develop their own proprietary solutions. It also
defines service quality targets and identifies the global performance
requirements and features of the system that are necessary to meet these
targets.
4.1. Service Objectives

The DVB-S system is designed to provide so-called “Quasi Error Free” (QEF)
quality. This means less than one uncorrected error event per transmission
hour, corresponding to a Bit Error Rate (BER) of between 10-10 and 10-11 at
the input of the MPEG-2 demultiplexer (i.e. after all error correction
decoding)4. This quality is necessary to ensure that the MPEG-2 decoders can
reliably reconstruct the video and audio information.
This quality target translates to a minimum carrier-to-noise ratio (C/N)
requirement for the satellite link, which in turn determines the requirements
for the transmit earth station and the user’s satellite reception equipment for a
given satellite broadcasting network. The requirement is actually expressed in
Eb/No (energy per bit to noise density ratio), rather than C/N, so that it is
independent of the transmission rate.
3. The ETSI standard EN 300 421 gives several examples of the use of the DVB-S sys-
tem for 33 MHz and other transponder bandwidths and for different code rates.
4. This corresponds to a BER of approximately 2 x 10-4 at the output of the inner error
correction (Viterbi) decoder.

Technical Guide
The DVB-S standard specifies the Eb/No values at which QEF quality must
be achieved when the output of the modulator is directly connected to the
input of the demodulator (i.e. in an “IF loop”). An allowance is made for
practical implementation of the modulator and demodulator functions and for
the small degradation introduced by the satellite channel. The values range
from 4.5 dB for rate 1/2 convolutional coding to 6.4 dB for rate 7/8
convolutional coding.
As mentioned previously, the inner code rate can be varied to increase or
decrease the degree of error protection for the satellite link at the expense of
capacity. Table 4 illustrates this trade off with respect to the common case of
rate 3/4 inner coding, assuming a constant transmitted symbol rate (i.e. a fixed
satellite transponder bandwidth). It shows the reduction or increase in
capacity associated with a change in the code rate and the related increase or
reduction in the Eb/No requirement. The latter is also expressed as an
equivalent increase or reduction in the diameter of the receive antenna (the
size of user’s satellite dish), all other link parameters remaining unchanged.
Inner Code Rate Available Capacity Power Requirement Receive Antenna

(Eb/No) Diameter
1/2 -33.3 % -1.0 dB -11 %
2/3 -11.1 % -0.5 dB -6 %
3/4 reference
5/6 +11.1 % +0.5 dB +6 %
7/8 +16.7 % +0.9 dB +11 %
Table 4: Trade Off between Link Power Requirement and Capacity

Another way to exploit this flexibility is to vary the code rate to obtain greater
or less link availability (i.e. to increase or decrease the amount of time that
QEF quality or better is achieved, with all other link parameters remaining
constant).
4.2. System Description

The DVB-S system adapts the baseband digital signals at the output of the
MPEG-2 transport multiplexer to the satellite channel characteristics.
The processes involved in this adaptation are illustrated in Figure 7. They are:
n transport multiplex adaptation and randomisation for energy dispersal;
n outer coding (i.e. Reed-Solomon);
n convolutional interleaving;

Technical Guide
n inner coding (i.e. punctured convolutional code);baseband shaping for

modulation;
n modulation.
The complementary functions are implemented in reverse order in the
receiver.
Reed-Solomon block code convolutional code

rate = 1/2, 2/3, 3/4, 5/6 or 7/8
Mux to Satellite
MPEG-2 Adaptation Channel
Outer Inter- Inner Baseband QPSK
Transport and via
Coder leaver Coder Shaping Modulator
Stream Energy Transmit
Dispersal Earth
Station
Satellite Channel Adaptor
Figure 7 : Functional Block Diagram of the DVB-S System
4.2.1. Transport Multiplex Adaptation and Energy Dispersal

The input to the satellite channel adaptor is an MPEG-2 transport stream and
consequently it consists of a series of fixed length packets 188 bytes long.
The transport stream data is randomised so that the RF spectrum approximates
that generated by truly random data (i.e. it is “noise-like” and does not contain
significant spectral line components).
Randomisation is implemented by adding a Pseudo-Random Binary
Sequence (PRBS) to the transport stream data using the exclusive-or function.
It is performed over sequential groups of eight bytes. The PRBS is restarted
at the beginning of each new group.
The sync byte of the first transport packet in a group of eight packets is bit-
wise inverted to provide an initialisation signal for the descrambler in the
receiver. This process is referred to as “transport multiplex adaptation”. The
MPEG-2 sync byte is the first byte of a transport packet’s header.
The sync bytes or the other seven transport packets are not randomised in
order to aid other synchronisation functions. All remaining transport packet
data is randomised, including the rest of the transport packet headers.
The randomisation process is active even when there is no input signal so that
transmission of an unmodulated carrier is avoided.

Technical Guide
4.2.2. Error Correction (Channel) Coding

The three blocks labelled “outer coder”, “interleaver” and “inner coder” in
Figure 7 together provide a powerful error correction mechanism. The outer
code is a Reed-Solomon block code and the inner code is a convolutional
code.
A Reed-Solomon RS (204, 188, T = 8) shortened code, derived from an RS
(255, 239, T = 8) code, is applied to each of the randomised transport packets
(188 bytes). This outer code is applied across the whole of the transport
packet, including the sync byte. The result is an error-protected packet with a
length of 204 bytes, comprising the original transport packet data plus the
Reed-Solomon overhead bits (coding redundancy). The output of the RS
(outer) coder is a packetized data stream that is in synchronism with the
MPEG-2 multiplex transport packets. The data rate is increased by a factor of
204/188 (8.5%) with respect to the transport stream data rate.
In the receiver, a Viterbi decoder precedes the RS decoder. The function of
the Viterbi decoder is to decode the inner (convolutional) code. The function
of the RS code is to correct any residual errors appearing at the output of the
Viterbi decoder.
Uncorrected errors at the output of the Viterbi decoder tend to occur in bursts.
However, the RS code is only effective if errors occur randomly, rather than
in groups. Consequently, to obtain an effective concatenated error correction
scheme, the output of the Viterbi decoder needs to be randomised.
Randomisation is performed by the de-interleaver in the receiver and the
interleaver in the transmitter.
The result of the interleaving process is an interleaved frame that remains in
synchronism with the original MPEG-2 transport packets. The interleaving is
performed in such a way that the transport packet sync bytes are unaffected
and act as delimiters to the interleaved frame. The data rate is unaffected by
the interleaving.
As already mentioned, the DVB-S system implements convolutional inner
coding with a variable code rate. Code rates of 1/2, 2/3, 3/4, 5/6 and 7/8 are
specified, although others are possible. The data rate is increased by a factor
of 8/7 (14.3%) to two (100%), depending upon the code rate chosen for any
given application.
The overall overhead that is added by the DVB-S coding system thus ranges
from 24% to 117%, depending upon the choice of the inner code rate.
It is possible for the DVB IRD to try each of the inner code rates until
synchronisation is achieved. This would allow the IRD to adapt to the
transmission parameters of different DVB multiplexes without user
intervention.

Technical Guide
4.2.3. Baseband Shaping and Modulation

Gray-coded QPSK modulation with absolute mapping (no differential
coding) is employed. This classical modulation scheme was chosen for its
ruggedness against noise and interference. It also provides reasonable
spectrum efficiency.
Prior to modulation, the baseband signal is square root raised cosine filtered
with a roll-off factor of 0.35.
Phase ambiguity in the demodulator can be resolved by means of the MPEG-
2 sync bytes that delimit the interleaved frame.

Technical Guide
5. Contact Details
For further information, please contact:
Guy Wilkinson Tel: + 33 1 53 98 37 07

E-mail: gwilkins@eutelsat.fr
Laurence Bailly Tel: + 33 1 53 98 46 42
E-mail: lbailly@eutelsat.fr
Network Development
70 rue Balard
F - 75502 PARIS CEDEX 15
France
Fax: + 33 1 53 98 40 23
Note: All documents are available on the EUTELSAT web site:

http://www.eutelsat.com/docs/tech
If you are not already receiving regular mailings, please remember to
complete the registration form name “Technical Information Service” on the
web site.

DVB Overview

Uploaded by

Document Information

Original Description:

Original Title

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

DVB Overview

Uploaded by

Copyright:

Available Formats

Organisation européenne de télécommunications par satellite

European Telecommunications Satellite Organization

page II June 7, 1999 Annex B to technical guidesTDM.fm

1.1. Digital Versus Analogue

1.2. The DVB Standard(s)

page B1 June 7, 1999 Annex B to technical guides.fm

1.3. DVB - A Mechanism for Data Broadcasting

page B2 June 7, 1999 Annex B to technical guides.fm

1.4. Satellite Delivery

1. HOT BIRD™ is a trademark of EUTELSAT.

page B3 June 7, 1999 Annex B to technical guides.fm

In conventional (broadcast) terminology, the word “programme” is used to

2. Basic Elements of A Satellite DVB

Figure 1 is a simple generic model of a digital satellite transmission channel.

Satellite Satellite Satellite

Figure 1 : Generic Model of the Digital Satellite Transmission Channel

page B4 June 7, 1999 Annex B to technical guides.fm

3.2. Processing Functions

page B5 June 7, 1999 Annex B to technical guides.fm

access units a programme, comprising

Figure 2 : Conceptual Model of a DVB (MPEG-2) Baseband Processor

The simplest type of service is a radio programme, which would consist of a

page B6 June 7, 1999 Annex B to technical guides.fm

Additional data is inserted into the Transport Stream, which includes

3.3.1. Elementary Streams

3.3.1.a.1 Compression Algorithms

page B7 June 7, 1999 Annex B to technical guides.fm

page B8 June 7, 1999 Annex B to technical guides.fm

3.3.1.a.2 MPEG-2 Profiles and Levels

page B9 June 7, 1999 Annex B to technical guides.fm

There are currently five profiles in the MPEG-2 system, as summarised in

MPEG-2 Description Used in

Main Adds bi-directional prediction capability. Yes

Spatially The supplementary signals improve the picture resolution with No

High Adds processing of line-simultaneous colour-difference signals No

Table 1: Summary of MPEG-2 Profiles

page B10 June 7, 1999 Annex B to technical guides.fm

MPEG-2 Picture Resolution Max. Bit Rate Equivalent

Main 720 : 576 15 PAL/SECAM

High 1440 1440 : 1152 60 EDTV/HDTV

High 1920 : 1152 80 HDTV

Table 2: Summary of MPEG-2 Levels

3.3.1.a.3 DVB Requirements

page B11 June 7, 1999 Annex B to technical guides.fm

3.3.1.b.1 Compression Algorithms

3.3.1.b.2 MPEG-1, MPEG-2 and Layers

page B12 June 7, 1999 Annex B to technical guides.fm

MPEG-2 audio is a compatible extension of MPEG-1 audio. It provides

3.3.1.b.3 DVB Requirements

page B13 June 7, 1999 Annex B to technical guides.fm

page B14 June 7, 1999 Annex B to technical guides.fm

3.3.1.c.2 Subtitling and Graphics

3.3.2. Packetized Elementary Streams

page B15 June 7, 1999 Annex B to technical guides.fm

The formation of a video Packetized Elementary Stream is illustrated in

Figure 3 : Constructing a Packetized Elementary Stream

page B16 June 7, 1999 Annex B to technical guides.fm

The PES packets consist of a payload and a header. The payload of

3.3.3. The Programme Stream

3.4. The Transport Stream Multiplex

page B17 June 7, 1999 Annex B to technical guides.fm

packet header adaptation field payload