an introduction to digital tv technology

7/28/2019 An Introduction to Digital TV Technology

1/16

4/9/13 An Introduction To Digital TV Technology | www.tvwithoutborders.com

www.interactivetvweb.org/tutorials/dtv_intro/dtv_intro

An Introduction To Digital TV

TechnologyThis page is for people who need to understand whathappens in a digital TV system, but who don't know thedetails of how a digital TV signal is put together.

This is not an introduction to MPEG, and if you don'tknow what MPEG is, take a look at the Tektronixguide to MPEG. Instead, this tutorial will concentrateon what makes a digital TV signal special, theterminology used to describe a DVB digital TV signaland generally helping you to understand what the hellpeople talking about digital TV actually mean.

It's also not an introduction to broadcast engineering.Another page describes the basics of broadcastengineering, and shows you how an MPEG streamgets from the encoder to the viewer.

Disclaimer: some of this information is specific tothe DVB standard. The map below (originally from the

DVB web site) shows which parts of the world currentlyuse one of the DVB standards - if you're interested inthe systems used in the US or Canada, the ATSC(Advanced Television Systems Committee ) website is a good place to start. The ATSC serviceinformation tutorial else where on this site describesthe major differences between DVB services and digitalservices in the USA or Canada, but does not includeinformation about the basic details of the transmissionmechanism.

Anatomy of an MPEG-2 streamOK, now that we've got that out of the way, lets starttalking TV. A digital TV signal is transmitted as a streamof MPEG-2 data known as a transport stream. Eachtransport stream has a data rate of up to 40megabits/second for a cable or satellite network, whichis enough for seven or eight separate TV channels, orapproximately 25 megabits/second for a terrestrialnetwork.

Each transport stream consists of a set of sub-streams
http://www.interactivetvweb.org/tutorials/dtv_intro/atsc_psip/http://www.interactivetvweb.org/tutorials/dtv_intro/atsc_psip/http://www.atsc.org/http://www.atsc.org/http://www.interactivetvweb.org/tutorials/dtv_intro/broadcast_engineering_basicshttp://www.interactivetvweb.org/tutorials/dtv_intro/broadcast_engineering_basicshttp://www.tektronix.com/Measurement/App_Notes/mpegfund/25W_11418_3.pdfhttp://www.interactivetvweb.org/http://www.interactivetvweb.org/http://www.interactivetvweb.org/tutorials/dtv_intro/atsc_psip/http://www.atsc.org/http://www.interactivetvweb.org/tutorials/dtv_intro/broadcast_engineering_basicshttp://www.tektronix.com/Measurement/App_Notes/mpegfund/25W_11418_3.pdf


2/16


www.interactivetvweb.org/tutorials/dtv_intro/dtv_intro 2

(known as elementary streams), where each elementarystream can contain either MPEG-2 encoded audio,MPEG-2 encoded video, or data encapsulated in anMPEG-2 stream. Each of these elementary streams hasa 'packet identifier' (usually known as a PID) that acts asa unique identifier for that stream within the transportstream.

The only restriction on the number of elementary

streams in any transport stream is that each elementarystream must have a unique PID value within itscontaining transport stream. Since this is stored as a13-bit value, this is not a major restriction. In practise,the number of elementary streams is limited by the totalbitrate of the transport stream. Transmission issuesmean that transport streams with bitrates much above40 megabits/second can't usually be transmittedreliably.

A transport stream consists of a number of audio andvideo streams that are multiplexed together. First, eachservice in the transport stream will have its audio andvideo components encoded using MPEG-2compression. The result of this process is a set ofMPEG-2 elementary streams, each containing one videochannel or one (mono or stereo) audio track. Thesestreams are simply a continuous set of video frames oraudio data, which is not really suitable for multiplexing.Therefore, we split these streams into packets in orderto make the multiplexing process easier. The result ofthis is apacketized elementary stream, or PES.

To create a transport stream, each of these packetizedelementary streams is packetized again and the data

from the stream is stored in transport packets. Eachtransport packet has a length of 188 bytes, which ismuch smaller than a PES packet, and so a single PESpacket will be split across several transport packets.This extra level of packetization allows the stream tosupport much more powerful error correcting techniques- PES packets are used to provide a way of multiplexingseveral elementary streams into one bigger stream, andare more concerned with identifying the type of datacontained in the packet and the time and which it shouldbe decoded and displayed. Transport packets, on theother hand, are almost purely concerned with providing

error correction.

So far, we have just considered audio and video data.We may also want to include data streams as part of ourservice, for applications, Teletext information or otherreasons. This is not too hard, because MPEG providesa well-defined way of carrying non-AV data insidetransport packets. These are calledprivate sections,and we will look at them in more detail little later. Sincemost of the equipment that generates this data willproduce a stream of transport packets containingprivate sections, multiplexing them in to our transport


3/16



stream is easy.

Once we have a complete set of transport packets forthe different parts of our services, we can insert theminto our final transport stream. When doing this, wehave to be careful to insert packets in the correct order.This is not just a case of ensuring that all of the packetswithin the stream come in the right order - MPEGdefines a strict buffering model for MPEG decoders, and

so we have to take care that each elementary stream inour transport stream is given a data rate that is constantenough to ensure that the receiver can decode thatstream smoothly, with no buffer underruns of overruns.We al so have to take care because video streams willuse a much larger proportion of the final transportstream than audio streams, and so we can't simplyinsert a packet from each stream in turn. A ratio of tenvideo packets to every audio packet is fairly close towhat we would likely see.

If we just multiplexed these transport packets together,we would have a transport stream that contains anumber of elementary streams with no indication of whattype of data is in these streams or how to reconstructthese streams into something that a receiver canpresent to the user. To solve this problem, MPEG andDVB both specify that other information should beadded to the transport stream. This data is encoded in anumber of elementary streams that are added to thetransport stream during the multiplexing process, and isknown as service information.

So what does this service information look like?Basically, it's a fairly simple database that describes the

structure of the transport stream. We will examine this inmore detail later, but at the simplest level it contains anumber of tables that each describe one service in thetransport stream. These tables list each stream in theservice and give its PID and the type of data containedin the stream.

The anatomy of a DVB transport stream.


4/16



Information about the types of stream in a service allowthe receiver to not only identify which streams are audioand video, but also to identify different types of datastream - separating teletext information from serviceinformation from broadcast filesystems for instance. Thismakes it easy for the receive to know which streams itshould pass on to different parts of its software stack fordecoding.

Describing the structure in this way, rather thanembedding it into the elementary streams, means thatwe can re-use elementary streams across services. Thisis shown in the example in the next section of a realtransport stream - two elementary streams (the streamswith PID values of 32 and 1102) appear in more thanone service. This allows efficient re-use of streamsacross services, and is most commonly used for datastreams.

If our transport stream was to contain more than oneservice, we can simply multiplex all the audio, video and

data streams for all the services together. The serviceinformation describes which elementary streambelonged to which service, as well as carrying someother information that is more for the benefit of theviewer than the receiver. This may include channelnames and descriptions, information about the TVschedules, and parental ratings information.

So, if we take a look at this from a different perspective,we get this picture:
http://www.interactivetvweb.org/tutorials/dtv_intro/dtv_intro#rtlmultiplex


5/16



In this case, we have a transport stream containing eightelementary streams, split across two services. PIDs 100,200 and 201 contain video, while the other elementarystreams contain audio tracks in different languages. PID204 contains an MHP application.

As we can see, for both services, the elementarystreams containing the video and one audio trackcontinue across services - this is typically done simply tomake life easier for the broadcaster and is not required.

When there are multiple audio tracks, (or multiplecamera angles, as in the case of service 2), then therewill be several different elementary streams on otherPIDs.

This does not have to happen at an event boundary. Aswe can see from the case of the MHP application, thisapplication is only available for part of the event. Whenit is no longer available, the elementary stream thatcontains it need not be broadcast any more. The abilityto update the contents of a transport stream in this wayoffers a great deal of flexibility to the broadcasters.

A transport stream is different from the type of streamused in DVDs (which is known as aprogram stream).They are both MPEG-2 streams, and both of themcontain multiplexed MPEG-2 audio and video data.However, there are two major differences between them.

The first difference is that a program stream does notcontain as much service information as a transportstream. The reason for this is that a program streamhas a simpler structure, and can't contain more thanone service. Every elementary stream in an MPEG

Elementary streams within a transport stream.


6/16



program stream belongs to the same service.

Secondly, transport streams are used in environmentswhere there is much more chance of data corruption.Program streams don't have to worry about this sincethey are usually stored on optical disks or hard drives.Transport streams, on the other hand, may betransmitted to and from satellites, over terrestrial TVnetworks or over cable TV networks. This means that

they have to be much more resilient, and so transportstreams have extra levels of packetization and error-correcting information to help cope with the challengesof the environment that they are used in.

We've skipped a number of points in this discussion ofMPEG and transport streams, especially issues such assynchronization and timing. For a more thoroughdiscussion of these and the rest of the MPEG standard,take a look at the guide to MPEG from Tektronix.

Networks, bouquets, services,events & multiplexes

In DTV-speak, each transport stream is also known as amultiplex, because it consists of a number of servicesmultiplexed together. Every multiplex is broadcast on asingle frequency, and only one multiplex can bebroadcast on each frequency. As I said earlier, eachmultiplex typically has a data rate of around 40megabits/second for satellite or cable systems, andaround 25 megabits/second for terrestrial networks.

Within a multiplex, each group of elementary streamsthat makes up a single TV channel is called a service.The number of elementary streams in a service doesn'thave to stay constant. This can vary between TV showson that service (for instance, some shows may bebroadcast in multiple languages or with multiple cameraangles), or it may even change within an TV show.These changes are all perfectly legal in MPEG - notcommon, but legal.

In digital TV systems, each TV show is known as anevent. Thus, from one point of view each service

consists of a number of elementary streams that aretransmitted simultaneously, but from another point ofview the service consists of a series of individual eventsbroadcast one after another.

The image below should give you an idea of what a realtransport stream looks like. This is a screen grab takenfrom a transport stream analyzer, showing one of themultiplexes being broadcast on the Astra satellite:

An example of a real transport stre am.
http://www.tektronix.com/Measurement/App_Notes/mpegfund/25W_11418_3.pdf


7/16



One thing that you will notice is that in this screenshot,services are referred to asprograms. This is an MPEGterm, and basically means the same thing as a service.One of the reasons an MPEG-2 program stream is sonamed is the fact that it only contains a single program.

As you can see from this image, the multiplex contains anumber of different services, where each servicecontains at least one audio stream, at least one videostream and usually several data streams. The firstcolumn indicates the type of the stream (some can't beidentified by the software in this case) - the number thatprefixes the type is the number of the service (orprogram).

The second column shows the PID value for eachelementary stream. Although it's not obvious in thisscreenshot, it's normally good practise to giveelementary streams belonging to the same servicesimilar PID values. That way, it's easy to identify whichservice a given stream belongs to. The final twocolumns show (graphically and numerically) the bit-rateof each elementary stream in megabits/sec.

As the screenshot shows, digital TV video signals areusually coded at 3-5 megabits/sec for standard-definition video , with the total data rate of a service


8/16



being 4-6 megabits/sec. This is a little less than DVD-quality, but it does allow the broadcaster to fit areasonable number of services in each multiplex.Broadcasters like to fit as many services as possible intoa multiplex, since this means that they can fit morechannels into every frequency band (remember, everymultiplex is broadcast on a single frequency band) andso they can use fewer transponders on a satellite to

broadcast the same number of services.

OK, so now we know what goes into a transport stream.There are some other things that are worth knowing,however. The transport stream physically groups a setof services together, but services in DVB systems canalso be logically grouped as well. A logical group ofservices is called a bouquet. Why do we need this?

Assume for a minute that you work at a largebroadcaster, where you broadcast 50 channels. Youbroadcast over satellite, so each of your transportstreams is limited to 40 megabits/sec (around 8channels). So, you need 7 transport streams to contain

all your services.

You sell access to these services in packages, so that aconsumer can choose to buy your basic package (whichcontains 13 channels) sports package (which contains 8sports channels) or your movie package (which contains5 movie channels). How can you identify in a machine-readable way which channels are part of whichpackage? You could group them in transport streams,but your basic package is too big to fit in one TS.Instead, by assigning a bouquet to each package, youcan group the services into transport streams in themost efficient way while still having a mechanism forgrouping the services in a logical way.

Digital TV systems also have the concept of a network.This is not a computer network: instead, it is a set oftransport streams that share some common serviceinformation. These transport streams will often bebroadcast by the same company (e.g. your satellite orcable operator), and more than one network may beavailable at any time. This is especially true in terrestrialsystems, where there may be several networksoperating at the same time in the same area (e.g.several national networks, plus one or more regional

operators depending on coverage). In this case, thereceiver will normally use automatic channel scanning tofind all of the available channels, rather than relying onservice information.

The company that owns the network may or may notown the actual delivery medium - in the case of a cableTV system, for instance, the owner of the cableinfrastructure is usually also the network operator. In thecase of a satellite TV system, however, the networkoperator (e.g. SES Astra) is typically does not run any ofthe TV networks that are broadcast over that satellite.


9/16



Similarly in terrestrial systems, a network (e.g. Freeview)may not own any of the transmitters or distributionmechanism that are used to get its signals to theviewer's home.

So, what we have is:

Every service in a DVB network can be uniquelyidentified by three values. These values are the originalnetwork ID (the ID of the network that originallybroadcast the service), the transport stream ID (toidentify a particular transport stream from that network)and a service ID to identify a service within that

transport stream. We can actually go further than this.Each elementary stream in a service may have acomponent tag, that allows the unique identification of agiven elementary stream. This is used by the receiversto decide what service to play, and by interactiveapplications that want to switch the receiver to decode adifferent audio or video stream.

DVB transport streams will have both an original networkID and a network ID, which identify the network thatoriginally produced the transport stream (e.g. the BBC)and the one that is currently transmitting it (e.g. BSkyB).

A network consists of one or more transport streamsthat are broadcast by the same entity

A transport stream is an MPEG-2 stream containingseveral servicesEach service is a TV channel, and consists of a seriesof events one after the otherEach event is a single TV show, and consists of anumber of elementary streamsEach elementary stream is a packetized MPEG-2stream containing MPEG-2 encoded audio, video orbinary data.Several services (possibly from several differenttransport streams) can be grouped together logicallyin a bouquet.

The structure of a DVB transport stream.


10/16



ATSC systems use a combination of the transportstream ID and the source ID to identify a particularservice. Depending on the value of the source ID, it maybe unique only within the current transport stream or itmay be unique at a regional level (or at the networklevel for satellite signals). This allows some co-ordination of source IDs across different terrestrialnetworks.

Service informationSo, you have a transport stream, which contains severalservices, where each service contains severalelementary streams. How do we tell what services we'rebroadcasting? How do we tell which elementary streambelongs to which service? How do we even tell whattypes of elementary stream we're broadcasting?

As we saw briefly above, the answer is a special set ofelementary streams that contain a set of databasetables describing the structure of transport stream, the

services within it and some useful information that digitalTV receivers can show the user, such as the name ofthe service and schedule information for the services.These tables are collectively known as serviceinformation (SI). Every transport stream (DVB or not)has some service information that the MPEG standarddeclares mandatory, but DVB defines several extra SItables in addition to the standard ones.

These tables are broadcast as elementary streamswithin the transport stream. Some of them are tied tospecific services within the transport stream, while some

are more general and describe either the structure ofthe transport stream itself or properties of the network.In some cases, elementary streams containing SI arebroadcast on a fixed PID to make it easier for decodersto find it, while in other cases the PID on which an SItable is broadcast is stored in another SI table.

ATSC service information is covered in a separatetutorial, and so we won't consider it here. The SI tablesthat are commonly found in a DVB transport stream are:

The Program Association Table is the fundamental table

Program Association table (PAT) - defined by the

MPEG standardProgram Map Table (PMT) - defined by the MPEGstandardNetwork Information Table (NIT)Service Description Table (SDT)Event Information Table (EIT)Conditional Access Table (CAT)Bouquet Association Table (BAT)Time and Date Table (TDT)Time Offset Table (TOT)
http://www.interactivetvweb.org/tutorials/dtv_intro/atsc_psip


11/16



for service information. It describes which PID containsthe Program Map Table for each service (see below) aswell as the Network Information Table for the transportstream in those networks that use it.

The Network Information Table describes how transportstreams are organized on the current network, and alsodescribes some of the physical properties of the networkitself. The NIT also contains the name of the network,

and the network ID. This is a value that uniquelyidentifies the network that is currently broadcasting thetransport stream, and may be different from the originalnetwork ID that we discussed earlier, if the transportstream is being rebroadcast.

The Conditional Access Table describes the CAsystems that are in use in the transport stream, andprovides information about how do decode them.

The Program Map Table is the table that actuallydescribes how a service is put together. This tabledescribes all the streams in a service, and tells thereceiver which stream contains the MPEG ProgramClock Reference for the service. The PMT is notbroadcast on a fixed PID, and a transport stream willcontain one PMT for each service it contains.

Together, the PAT, PMT, and CAT are known asProgram Specific Information (PSI) and are defined byMPEG. All other tables are specific to DVB systems.

The Service Description Table gives more user-orientedinformation about services in a transport stream. Unlikethe PMTs, there is only one SDT in a transport stream,

and that contains the information for every service. TheSDT typically contains information such as the name ofthe service, the service ID, the status of the service (e.g.running/not running/starting in a few seconds) andwhether the service is scrambled or not.

The Event Information Table provides scheduleinformation about events on a service. This includes theevent name, start time duration and the status of theevent. This table is actually split in to two separatetables: the EIT-present/following, which containsinformation about the current and next events, and the

EIT-schedule, which contains other scheduleinformation. These in turn can be split into tablesdescribing the current (actual) transport stream andother transport streams. It is mandatory for the transportstream to contain the EIT-present/following for theactual transport stream, while other EIT tables areoptional.

The Bouquet Association Table lists and describes theservices in a bouquet. This does not provide verydetailed information, since this can be gained from otherSI tables. Instead, it just provides a list of the services


12/16



contained in a bouquet.

The Time and Date Table and the Time Offset Tableprovide a time reference for the stream. The TDTcontains the current UTC (Universal/GMT) time, whilethe TOT contains both this and the offset from UTC forlocal time. This can be used to calculate scheduleinformation accurately, if needed.

Some of these tables may contain information aboutother transport streams, as well as information about thecurrent transport streams. The NIT, SDT and EIT mustcontain information about the current transport stream(and these tables are known as the NIT-actual, SDT-actual and EIT-actual respectively), but the transportstream may also contain versions of these tables thatrefer to other transport streams. These are known asthe NIT-other, SDT-other and EIT-other.

The table below describes which of these tables inmandatory and which is optional.

Of course, life is not as simple as it appears. AlthoughDVB requires that the mandatory tables arepresent, itdoesn't require that they arepopulated. That would betoo easy. So, it's not entirely unusual to see transportstreams containing empty SI tables, either because thebroadcaster was too lazy to add the information, orbecause they are squeezing every last drop ofbandwidth from a broadcast. The contents of an SI tablemay change over time - for instance, the contents of theEIT will change when the current event changes. EachSI table has an associated version number, which isincremented with every change. The receiver will track

Mandatory

(MPEG)

Mandatory

(DVB)

Optional

(DVB)

Reserved

PID

PAT 0x0000

PMT (one

per service)

CAT 0x0001

NIT-actual NIT-other 0x0010

SDT-actual SDT-other 0x0011

EIT-

present/following

(actual)

EIT-schedule

(actual & other)

EIT-

present/following

(other)

0x0012

TDT 0x0014

TOT 0x0014

BAT 0x0011

Serv ice information tables in a DVB system.


13/16



these version numbers, and load new versions of thetables when they are broadcast.

Structure of an SI table

Each SI table is fairly similar in structure. They allconsist of a header, followed by zero or more descriptorloops. Each descriptor loop contains one or more

descriptors that provides the information for one row inthe table. Each descriptor may only contain someinformation for a given row in the table, and somedescriptors that contain more generic information mayappear in different types of table. This re-use ofdescriptors makes SI parsers slightly simpler, since eachdescriptor has its own header (which includes thedescriptor ID), as well as the actual information itcontains.

A full list of descriptors can be found in the MPEG-2systems specification, the DVB SI specification, and the

ATSC PSIP specification, depending on the system inuse, but some of the most common and useful DVBdescriptors are:

MPEG Sections

Since these tables can sometimes be quite large, thereis a need to split them to fit inside a transport packet.Each chunk of data is knows as a section, and thesecan be used to hold any type of binary data, not just SItables.

The service_descriptor, which is found in the SDT

and gives the name and type of a service.The linkage_descriptor, which is found in several

of the tables and provides a reference to a source ofmore information about an element of the serviceinformation, as well as a reference to a replacementservice if the current service is not running or isscrambled.

The component_descriptor, which is found in theEIT and gives information about an elementary streamsuch as the content type and format and in somecases (e.g. audio streams) the language of thestream.The data_broadcast_id_descriptor is found in

the PMT and gives information about the type ofencoding used for a data stream.The stream_identifier_descriptor is also found

in the PMT and is used to attach a component tag toan elementary stream so that individual streams maybe uniquely identified.

The CA_identifier_descriptor appears inseveral tables and identifies the scrambling system (ifany) that is used for a given service or event


14/16



Sections that contain data and not audio or videostreams are typically known asprivate sections, evenwhen the data format is publicly known. These sectionsmostly follow a standard format:

The table ID is used to identify the contents of theelementary stream (whereas the stream type listed inthe PMT only describes the type of stream - the PMT willtell you it's a data stream, but the table ID may help tellyou what the data actually is). In the case of SI tables,this identifies which table is being broadcast (as you'dexpect) but it is also used for identifying other privatedata streams.

SyntaxNo. of

bitsIdentifier

private_section() {

table_id 8 uimsbf

section_syntax_indicator 1 bslbf

private_indicator 1 bslbf

Reserved 2 bslbf

private_section_length 12 uimsbf

if(section_syntax_indicator == '0')

{

for(i=0; i


15/16



The table ID extension is used to sub-class thisinformation, where the table ID may identify a givenclass of data,and the table ID extension may identify aparticular data stream within that class. In the case of SItables, this is used to identify those tables which cancontain information about the current transport streamand others. For instance, the table ID for the SDT-actualis different from the table ID for the SDT-other, and inboth cases, the table ID extension contains the transport

stream ID, identifying which transport stream the SDTrefers to.

Presenting video - decoder format

conversionMPEG-2 video will typically be encoded at PAL or NTSCresolutions (depending on the country of origin). Ineither case, the encoded video may have an aspectratio of 4:3, 16:9, or some other aspect ratio, (with theformer being more common at the time of writing). This

aspect ratio, together with other information, isbroadcast in the MPEG stream as part of the data. Thisdata is known as the active format description.

There is no guarantee, however, that a TV used to viewthe signal will have the same aspect ratio as theencoded video. This is where decoder formatconversion comes in. Basically, this is a conversionoperation carried out within the receiver to convert thevideo signal from the original aspect ratio to the aspectratio of the display. Usually, this is carried out in theanalogue stage of the receiver, after the signal has

been generated but before it is sent to the TV.

Although the conversion from 16:9 to 4:3 (or vice versa)is most common, there are other common conversionoperations to support the different types of conversionsuch as letterboxing, shoot-and-protect and pillarboxing.The UK Digital Terrestrial Group has published a set ofimplementation guidelines in PDF format detailinghow receivers can handle these conversions. Theseconversions are also covered in the EACEM E-Book.

This article at TVTechnology.com describes a little

more about decoder format conversion and activeformat descriptions from a US perspective - it's not quiteidentical to the DVB situation, but it does discuss DVBand the similarities are far more important than thedifferences.

DSM-CCDSM-CC is a standard for data broadcasting (amongstother things) based on MPEG streams. It provides agreat deal of functionality that is used in MHP and OCAP- as well as being one of the main methods for
http://www.tvtechnology.com/features/Tech-Corner/f-rh-aspect-ratio.shtmlhttp://www.ueberall-tv.de/download/AG_DVBT2/MinAnfor/A1_E-Book2-02.pdfhttp://www.dtg.org.uk/publications/books/afd.pdf


16/16


transmitting applications to a receiver, it can providedata streaming, timecode information for MPEG streams

and a host of other functionality.

DSM-CC is a complex topic, and so it is covered in aseparate DSM-CC tutorial. While only middlewaredevelopers need to know the gory details of DSM-CC,application developers and head-end manufacturerscan also benefit from knowing something about its inner

workings.

Copyright Steven Morris 2002-2011. All Rights

Reserved
http://www.interactivetvweb.org/tutorials/dtv_intro/dsmcc

an introduction to digital tv technology

Documents