Tandberg TT4000 Transportstream analysis

The MPEG transport stream

The digital data stream that enters the DVB-S modulator and leaves the DVB-S tuner is an ‘MPEG transport stream’. A transport stream (TS) can contain video, audio, teletext, service information, conditional access information, etcetera.
How is a transport stream constructed?

Elementary and Packetized Elementary Streams (ES/PES)

The MPEG encoder chip contains an audio and a video encoder. The video encoder produces an MPEG video data stream and the audio encoder produces an MPEG audio data stream. These streams are called ‘MPEG Elementary Streams’ (ES).
Both audio and video ES data streams are divided in packets (for the video encoder, each packet is a picture frame). The resulting streams are called ‘MPEG Packetized Elementary Streams’ (PES).
The audio and video PES packets are fed to the Transport Stream Multiplexer. This module produces a Transport Stream (TS) which contains the audio and video PES streams, together with clock reference information. The audio, video and clock reference data of one encoder is referred to as a ‘Program’.
The clock reference information is used to recover the encoder clock at the decoder and guarantees that the decoder decodes audio and video at exactly the same rate as the encoder. If the decoder playback rate differs from the encoder rate, this will result in buffer over- or underflow at the decoder. The clock references will also provide for exact lip-sync playback of audio and video.
The clock references are very precise; the resolution is 37 nanoseconds. This high precision is needed because the recovered decoder clock is also used to generate the PAL/NTSC color subcarrier. See also the measurements below.

Transport stream (TS)

A Transport Stream consists of TS packets. Each TS packet is 188 bytes long and contains a Header and a Payload section. The header of each packet contains information about the contents of that packet and is meant for the TS demultiplexer. The payload section contains the actual audio, video, teletext, etc. data. The header starts with a synchronisation word (47 hex) , used to recognize the start of the packet. Then two bytes follow which contain some flags and the Packet ID (PID).
This PID is very important. The PID can range from 0 to 8191 and is used to identify the contents of the packets.
For example: a TS can contain a video PES in packets with PID 100, an audio PES in packets with PID 101 and clock reference information belonging to these streams in packets with PID 102. But it can also contain a second video PES in packets with PID 200...
So, it is possible to transport more Packetized Elementary Streams using a single Transport Stream. But how wil the decoder know which PID’s belong to which program? For that purpose a Transport Stream should contain:

Service Information (SI)

The service information in a DVB transmitter is contained in a number of tables. These tables are transmitted as separate streams, like video and audio streams. Most SI table streams have a fixed, known ID, so that the decoder always can find them.

Here are the most important SI tables with their PID’s:

Most ‘basic’ are the PAT and PMT.

If you feed an unknown TS to a satellite receiver, it will first wait for TS packets with PID=0, containing the PAT.
The PAT then tells the receiver the PID’s of the PMT’s in the stream. Each program (a program can be audio+video, or audio only) has it’s own PMT. If you want to receive the 3rd program in the TS, the receiver will look for the 3rd PMT. The PMT then tells the receiver about the type of program and the PID’s of the audio, video, teletext, conditional access information etcetera belonging to that program.The other tables give additional information about the broadcaster, the transport stream, the programs and the events on the programs.

SI measurements

At the moment the transport stream of our D-ATV transmitter can contain the following information:

Always: PAT, SDT, NIT, EIT.
Per program: PMT, audio, video, program clock reference (PCR)

We had the opportunity to check the contents of the SI tables with a Tandberg TT4000, a Transport Stream Monitor. As you can see everything is O.K.
The Tandberg only complains about the TOT (time information), which is correct because no time information is inserted in the stream yet.


Figure 1. Tandberg TT4000 stream analyzer results for our design. Only TOT is at this moment not present which results in a error.

PCR measurements

The analyzer is also able to measure the precision of the PCR (program clock reference) packets. Each PCR packet contains a timestamp with a resolution of 37 nanoseconds. The timestamp is the value of a counter, running at the encoder clock, taken at the moment that the packet leaves the TS mux.
According to the DVB standards, the uncertainity of this timestamp must be less than 500 nanoseconds. This is one of the heaviest requirements in the DVB specifications and not all currently available amateur designs will reach this specification...
Why is this such a problem? Imagine two MPEG encoders producing 2 Mbit TS with correct PCR. If we want to combine these to a new stream of say, 4.1 Mbit, we can do that by taking a packet from encoder 1, then a packet from encoder 2 and so on. Sometimes we have to insert a dummy packet to fill the stream. But... the position of the PCR packets will change by this operation. Because the encoders are not synchronous, packets will get a variable delay between 0 and 188 bytes of the 4.1MHz bitclock, resulting in an error of up to 370 microseconds for the PCR value. It will be clear that we must provide for a means of recalculation of the PCR timestamps to fulfill the 500 ns requirement.

Figure 2. PCR jitter measurement with Tandberg TT4000 stream analyzer.

As you can see in the Tandberg measurements, the error on the PCR values is far below 500 ns. This ensures correct, lip-synchronous decoding with a constant latency and allows for remultiplexing and retransmission of the received TS stream!