Digital Video Broadcasting
A new test frontier
Click here to go back to my Technical Page
Digital technology is the state of the art in the studio and in domestic receivers. With the introduction of Digital Video Broadcasting (DVB) and MPEG2, changeover to digital video and audio signals is now also being made on the transmission link. The previous analogue coding is replaced by a coding with data compression in accordance with MPEG2. Video and audio source signals are separately processed to form digital data streams. This fundamental change in signal representation in the base band also affects TV measurement technology. Measurements of the amplitude frequency response and the signal-to-noise ratio are not directly applicable to digital data streams.
Protocol analysis, developed for data streams in a DVB system, allows checking of the coding and the transmission. Received data streams can be checked for conformity to relevant standards to prove the correct functioning of a system.
Transport Stream in a DVB Distribution Network
Program distribution in a DVB system has basically the same structure as previously in analogue TV. Subscribers continue to receive their programs directly via satellite, via a broadband communications network or a terrestrial network (Figure 1). Transmission of the signal however is by means of the MPEG2 transport stream (TS), which was standardised by the Moving Pictures Expert Group (MPEG) in ISO/IEC International Standard IS 13818.
In the transport stream, several programs are combined in time multiplex. To this end, the video and audio source signals are processed to form digital data streams by means of codecs effecting data compression and are then multiplexed. Further data streams, ea. for teletext or subtitles, may be added. Each of these data streams belongs to a specific program of the transport stream. There are further elements that contain information relevant for the transport stream as a whole. These elements are headed by the Program Specific Information (PSI). It is organised in the form of a table and transmitted periodically. The PSI includes the Program Association Table (PAT) and the Program Map Tables (PMTs). They provide information on the programs of the transport stream and the data streams making up these programs.
The Conditional Access Table (CAT) holds information relating to the scrambling of the programs. The Service Information (SI) is likewise transmitted in the form of tables. This information was defined by the DVB project in conformance with MPEG and essentially contains data for the convenient user guidance through the Electronic Program Guide (EPG).
The transport stream is made up of packets with a length of 188 bytes. The first four bytes represent the header with control information enabling, for example, synchronisation of the receiver and the access to specific data streams. The following bytes normally contain the payload of the video, audio and data streams.
Ahead of the satellite up link, the elementary streams and the additional information are multiplexed to form the transport stream (Figure 1). Transmultiplex will often take place in feeding broadband communications networks and terrestrial transmitters. It is required for the reconfiguration of programs or the integration of further services such as Video-on-Demand (VoD) or data services from telecommunications networks. Transmultiplex however also means that the time stamps of the transport stream will in part have to be recalculated and that the program specific information as well as the service information will have to be adapted to match the new configuration of the transport stream.
The transport stream thus plays a key role in DVB systems. All data, which are encoded to a wide variety of standards, are combined in the transport stream. Moreover, access to payload is possible only if a receiver is able to extract, ie demultiplex, the desired elementary stream(s) from the transport stream.
By means of protocol analysis of the transport stream it can be checked if the data stream was generated in accordance with standards and transmitted without errors and is thus capable of being decoded. Protocol analysis is therefore first made on the equipment that generates and outputs a transport stream. From a technical point of view, it is of particular interest to check the transport stream at the output of a multiplexer or transmultiplexer. Problems arising from the incompatibility of units of different make may be a problem especially in the introduction phase of digital TV. Hardware development is often less problematic if the possibilities offered by the standards are not utilised to the full. In this respect, protocol analysis can supply valuable information as to the cause of a problem.
The need for legal security and control is another chief purpose of protocol analysis. From the studio to the terminal equipment, the data are routed and processed by a variety of organisations and companies. Each ofthem has an interest in monitoring the incoming signals and furnishing evidence that the signals available at the output are in error-free condition. Thus, continuous monitoring of the transport stream is particularly attractive in this context.
Protocol analysis at the terminal equipment is of secondary importance. If it is ensured that the transport stream is correctly multiplexed when it is output to the transmission link, reception problems at the terminal equipment can be caused only by errors in transmission or by a defect of the receiver itself Protocol analysis can in such cases provide information on the source of error that prevents reception, it can not however replace measurements on the transmission channel.
Tests for the MPEG2 Transport Stream
The complex structure of the MPEG2 transport stream in conjunction with the data rate of approximately 38Mbit/s makes continuous protocol analysis a highly demanding task. The tests to be performed should be selected so as to enable straightforward analysis and clearcut representation of results. They are in the following derived from demultiplexing (Figure 2). The elements of the data stream of interest are those that have to be accessed by the demultiplexer in order to route the required elementary stream data to the decoder.
First, the demultiplexer must be synchronised, which is done by means of the first byte of each transport stream packet. It is checked to see if the sync byte has the prescribed value of 47hex and if it occurs at the correct interval of 188 bytes in the data stream.
Next, the contents of the transport stream are read out of the Program Association Table and the Program Map Tables. The DVB Measurement Group has specified repetition rates that are to be checked. Moreover, a check word for a cyclic redundancy check is contained at the end of each table, allowing correct reception of a table to be verified.
From the tables, the Pips (Packet Identifications) needed for extracting the packets ofthe required elementary streams from the transport stream can be determined. For smooth demultiplexing it must be checked to see if the Pips stated in the tables are consistent with the Pips actually calTied in the transmitted packets. Errors may be caused in particular in transmultiplexing, where the programs for the transport stream are reconfigured and incorrect updating of the Program Specific Information causes the demultiplexer to search for Pips that may no longer exist.
Program scrambling is a central element in DVB systems. Before the elementary streams are decoded, it must be determined if the data have to be descrambled. Scrambling of an elementary stream is signalled by the field transport_scrambling_control in the header of the TS packet of the transport stream. The Conditional Access Table (CAT) contains information on the type of scrambling employed. If scrambling is indicated by transport_scrambling_control, it can be checked to see if a CAT exists. Moreover, the repetition rate of the CAT can be checked and the CRC evaluated.
The system clock of the demultiplexer corresponds to the associated clock of the multiplexer. The TS contains time references as program clock references (PCRs) for synchronising the two system clocks. The interval between the PCRs as well as the accuracy of their coding are defined by the MPEG2 standard and can be verified. For transmultiplexing the PCRs have to be recalculated, so errors can easily be produced here too.
After completion of the above checks, decoding can be started. The video and audio data to be decoded are in the form of relatively large packets of several times the size of a TS packet before they are multiplexed to form the transport stream packets. This means that only a unit made up of many TS packets can be decoded. If a TS packet is lost or corrupted in transmission, this can be detected by means of a continuity counter which is used for consecutive numbering of the TS packets of an elementary stream.
The data stream contains time stamps for the synchronisation of the audio and the video data. It can be checked if the maximum permissible intervals are complied with.
Decoding of the Service Information (additional data accompanying the program) is mentioned last in this webpage as it is not necessarily required for decoding of the program. In a domestic receiver, however, decoding of the Service Information would come right at the beginning since the viewer first wants to be informed of the programs offered. Program providers too have a strong interest in presenting their programs. Transmultiplexing can lead to problems and inconsistencies if updates are not made carefully. As in the case of PSI, the repetition rate is to be checked and the CRC performed for the Service Information too.
Protocol Analysis According to DVB Guidelines
Within the framework of the Digital Video Broadcasting Project (DVB), the DVB Measurement Group is concerned with the associated measurement technology. The result of the work performed so far are the Measurement Guidelines for DVB Systems that are presently undergoing standardisation and have the status of a proposed European Technical Report (prETR). They include measurements for the transmission via satellite and via cable. Measurements for terrestrial transmission will be included into the document in due course.
Protocol analysis of the transport stream takes up a large part of the measurement guidelines. The tests proposed there are based on similar considerations as those described in Tests for the MPEG transport stream above. Depending on the importance of a test and its complexity, a test is suitable for periodic or for continuous monitoring. In the tests, DVB-specific elements are taken into account. Despite this, the tests are consistent with Part 4 of the MPEG2 standard, which deals with conformance testing. The tests proposed by the Measurement Group can practically completely be performed on a scrambled transport stream. In most cases, the header information of the transport stream packets or the tables of the PSVSI are to be checked. These are scrambled only in exceptional cases. Only the tests relating to the payload of video, audio or additional data streams cannot be performed on scrambled data streams.
The tests are divided in three groups according to their importance:
· The first group includes tests relating to synchronisation and to access to the pro gram data.
· The tests of the second group are used for checking the time references. Moreover, transmission errors can be detected by means of a special bit in the header of the TS packet. Conformance of the data to scrambling is also checked.
· In the third group, the Service Information and the buffer fill state are checked. If transmultiplexing has taken place, the storage capacity of the decoder memory may easily be exceeded since the data of an elementary stream in the new TS are also provided with a new time reference. Subsequent check can be made if any overflow of the buffer has occurred.
The tests laid down in the DVB guidelines can thus be used to check essential elements of the transport stream for compliance with standards. As for multiplexing, it can be checked if boundary conditions relating to PSI/SI and buffer control were taken into account.
The Measurement Group proposed no special tests for video and audio elementary streams for three reasons:
1. No new elements were introduced for these data streams within the framework of the DVB project.
2. The video and audio streams remain largely unchanged during transmission. For transmultiplexing, the data only have to be copied taking into account the buffer fill state.
3. The DVB project defines three interfaces for the transport stream. No separate interface is defined for the video and audio streams.
Return to the top of the page.
Please me and tell me if you liked my webpage on digital video broadcasting and digital video distribution systems, or even if you have any contributing sites on similar info that I can include here as additional links.
Click here to go back to my Technical Page
This page has been accessed
Last revised: Wednesday, 07 May 1997