DVB数据广播实施指南技术报告

需积分: 9 182 浏览量更新于2024-07-22 收藏 260KB PDF 举报

"DVB Specification - Implementation guidelines for Data Broadcasting (TR101202V1.1.1, 1999-02)，由EBU（欧洲广播联盟）和ETSI（欧洲电信标准协会）发布，是关于数字视频广播（DVB）数据广播的实施指南。该技术报告主要涵盖了DVB中的数据广播技术，涉及关键词：DVB、数字、视频、数据、广播和电视。" 在数字电视领域，DVB（Digital Video Broadcasting）规范是一个国际标准，旨在定义数字电视信号的传输和接收方式。这份实施指南详细阐述了如何在DVB系统中实现数据广播，这包括但不限于以下几个核心知识点： 1. **数据广播结构**：DVB数据广播允许在电视信号中传输非视频和音频的数据，如电子节目指南（EPG）、互动电视服务、软件更新等。它通常利用MPEG-2 Transport Stream（TS）来承载这些数据。 2. **数据广播服务**：DVB数据服务可以是单向的，如发送信息到所有用户，也可以是双向的，支持交互式应用。例如，通过DVB-H（Handheld）服务，移动设备用户可以接收数据广播内容。 3. **数据传输协议**：DVB规范定义了多种数据传输协议，如DVB-SI（Service Information）用于广播服务信息，如频道列表和节目时间表；MHP（Multimedia Home Platform）或HbbTV（Hybrid Broadcast Broadband TV）提供了互动电视平台。 4. **错误校验与恢复**：在无线或有线传输中，数据可能会受到干扰。DVB规范包含了错误检测和纠正机制，如FEC（Forward Error Correction）编码，确保数据的可靠传输。 5. **解码与接收**：接收端的设备，如数字电视接收机或个人电脑，需要遵循DVB标准来解析和解码数据广播内容。这涉及到TS包的解析、服务选择以及数据的解压缩和呈现。 6. **网络适应性**：DVB系统需要适应不同的传输媒介，如卫星（DVB-S）、地面（DVB-T）、有线（DVB-C）以及移动环境（DVB-H）。每种媒介都有其特定的技术挑战和优化要求。 7. **安全与加密**：为了保护内容提供商的权益，DVB系统支持内容加密，如Conditional Access System（CAS），确保只有付费用户能够访问特定服务。 8. **实施建议**：这份实施指南提供了具体的实施步骤和最佳实践，帮助制造商和运营商构建符合标准的数据广播系统，确保互操作性和兼容性。 9. **标准更新**：虽然这份指南是1999年的版本，但DVB标准一直在发展，以适应技术进步和市场需求，比如高清、超高清（UHD）、互联网电视（IPTV）的融合等。 10. **反馈与修正**：ETSI鼓励读者发现文档错误后提供反馈，这有助于不断改进和更新标准，确保其准确性和实用性。总结来说，DVB规范的实施指南是理解并实施DVB数据广播的关键参考，涵盖了从数据结构、传输协议到接收终端的一系列技术细节，是电视广播行业的重要技术文档。

ETSI

TR 101 202 V1.1.1 (1999-02)11

4.2.1 Fragmentation of Datagrams

Generally data of any kind of protocols are transmitted in packetized form ("datagrams"). These datagrams may have

different length. If the data are not packetized or the packetization method is irrelevant or hidden to the DVB

transmission chain the most appropriate way of transmission is the Data Pipe (see EN 301 192 [1] Clause 3).

On the layer of MPEG2 Transport Stream data are transmitted within packets with a fixed length of 188 bytes (184 bytes

payload), therefore datagrams of higher layers have to be fragmented at the transmission side and be re-assembled at the

reception. For fragmentation of the datagrams there are three possible ways (see also Figure 4.1):

•

private mechanisms based on the Data Pipe;

•

MPEG2 Packetized Elementary Streams (PES);

•

MPEG2 Sections.

MPEG2 PES provides a mechanism to transmit datagrams of variable size with a maximum length of 64 Kbytes.

Additionally it provides the facility to synchronize different data streams accurately (as used in MPEG for

synchronization of Video and Audio), therefore it was chosen by DVB for the transmission of synchronous and

synchronized but also asynchronous data streams (see EN 301 192 [1], Clause 4 and Clause 5).

MPEG2 Sections can be used to transmit datagrams of variable size with a maximum length of 4 Kbytes. The

transmission is asynchronous. MPEG2 Sections are built in a way that MPEG2 demultiplexers available on the market

can filter out single sections in hardware which may reduce the required software processing power of the receiver. This

is the main reason why the MPEG2 Sections have been chosen as the mechanism for the transmission of encapsulated

protocols and Data Carousels.

For data broadcasting services in the DVB framework the data_broadcast_id_descriptor EN 300 468 [6] can be present

in the PMT, i.e. use of this descriptor is optional.

4.3 Data Pipe

The Data Pipe is an asynchronous transportation mechanism for data. The data are inserted directly in the payload of

MPEG2 Transport Packets.

There is no mechanism for fragmentation and reassembly of datagrams defined. This, if required, is part of the

application definition. For instance, the payload_unit_start_indicator could be used to signal the start of a datagram in a

packet while the transport_priority field could signal the end of a datagram.

The continuity_counter shall be used as defined by MPEG (ISO/IEC 13818-1 [3], Subclause 2.4.3).

4.3.1 Usage of the Adaptation Field

The main use of the Adaptation Field is stuffing. However, it is possible to use it for other purposes, for example the

transmission of PCR.

4.4 Asynchronous/Synchronized/Synchronous Data Streaming

4.4.1 Usage of the Adaptation Field

According to ISO/IEC 13818-1 [3], Subclause 2.4.3 a PES packet always has to start at the first payload byte of an

MPEG2 Transport Packet. This means that for PES packets which are not aligned with the MPEG2 Transport Packet

there is stuffing necessary. Since MPEG only allows stuffing bytes at the end of the packet for sections and not for PES

(see ISO/IEC 13818-1 [3], Subclause 2.4.3.3) stuffing can only be achieved by using Adaptation fields. This is no real

constraint for the performance of a decoder since most demultiplexer implementations provide the automatic extraction

of Adaptation Fields and therefore no additional processing power is required.

ETSI

TR 101 202 V1.1.1 (1999-02)12

An Adaptation Field that is only used for stuffing can be created by setting all adaptation field flags

(discontinuity_indicator, random_access_indicator, elementary_stream_priority_indicator, PCR_flag, OPCR_flag,

splicing_point_flag, transport_private_data_flag, adaptation_field_extension_flag) to "0" and inserting the number of

required stuffing bytes.

The elementary_stream_priority_indicator and the adaptation_field_extension_flag shall be set to zero, since the

affiliated features have no meaning for Data Streaming.

4.4.2 Asynchronous Data Streaming

Asynchronous Data Streaming is used in the case that the PES mechanism is of advantage for applications that need the

asynchronous transmission of datagrams.

Since no synchronization is necessary for this kind of transmission the stream_id "private_stream_2" (see ISO/IEC

13818-1 [3]) has been chosen which implicitly excludes the usage of the PES packet header fields. Therefore the

PES_packet_length field is immediately followed by the datagram.

The definition of the datagram format is part of the private implementation ant therefore not subject of the DVB

specification.

4.4.3 Synchronous/Synchronized Data Streaming

In order to meet the requirements of the Synchronous and Synchronized Data Streaming an additional header, specific to

this DVB application profile has been defined (see EN 301 192 [1], Table 5.1).

The field stream_id shall be set to "private_stream_1", allowing for the usage of the PES header fields, especially the

PTS. Usage of the time stamps requires the definition of Access Units. Since this is application dependant it has not

been defined within the DVB data broadcasting specification.

The first byte of this header (which is from MPEG2 PES point of view the first payload byte) contains the

data_identifier. It is defined in accordance with the specifications for embedding of EBU-data (EN 300 472 [7]) and

DVB-subtitling (ETS 300 743 [8]) and indicates the type of Data Streaming (synchronous /synchronized).

A combination of Synchronized and Synchronous Data Streaming in the same PES packet is not allowed. However, both

types of streaming data can be carried as part of a same program in separate PIDs.

The field sub_stream_id may be used for private definition.

The two flags PTS_extension_flag and output_data_rate_flag indicate the existence of an output data rate field and of a

field for PTS extension. The usage of these fields is explained below.

The PES_data_packet_header_length indicates the length of the header and allows the addition of private bytes in the

header.

The DTS field in PES header is of no use while the PTS shall be coded in the same way as defined by MPEG ISO/IEC

13818-1 [3].

4.4.4 Synchronous Data Streaming

Synchronous data streaming may be used if the output data rate at the receiver side needs to be very accurate. The

receiver clock is synchronized by the PCR. The 9-bit PTS_extension is needed to position data access units (a bit, a byte

or few bytes depending on how one defines access units) very accurately over a large range of data rates (kbit/sec to

Mbit/s). The 9 bits extends the accuracy of the PTS clock from 11 microseconds to the same accuracy as a 27 MHz

clock (37 nanoseconds). Precise positioning of the data is required if multiple data decoders receiving the same data

services (and knowing the latency through the process) have to output the data at the same time in an aligned way, or if

it is required to maintain synchronization in the data output stream following a temporary loss of signal.

ETSI

TR 101 202 V1.1.1 (1999-02)13

The field output_data_rate is used in order to specify the output data rate for the synchronous data stream. With the

28-bit accuracy (instead of the 400 bit/s resolution of 22-bit ES_rate in PES header) it is possible to implement PLL

(with clock down conversion) with a ratio of data output rate to 27 MHz (

30 ppm) covering a wide range of data rates.

The output_data_rate field conveys the bit rate of the regenerated signal for a synchronous data stream. The encoding of

the bit rate of the data stream into the output_data_rate field depends on the application. Applications which require bit

rates which are a multiple of 1 bit/s may encode the data streams bit rate into the output_data_rate field directly with the

units of output_data_rate as bits/second. Applications which require a continuous range of bit rates to be regenerated

within the 30 ppm tolerance specified by MPEG for the 27 MHz system_clock_frequency may encode the bit rate of the

data stream into the output_data_rate field as:

output_data_rate = bit rate

M/system_clock_frequency

where M is chosen to be a number sufficiently large to express the range of bit rates required for the application with the

desired bit rate accuracy. The practical range of bit rates for synchronous data streaming with a system_clock_frequency

of 27 MHz is 1 bit/s to 27 Mbit/s.

NOTE: The decoder model described in Clause 10 of EN 301 192 [1] is not necessarily applicable if the output

data rate field is used.

ES_rate in the PES header can be used without the output_data_rate field in the PES data_packet for applications where

the 400 bit/s accuracy of ES_rate is adequate (for example T1 and E1). If both ES_rate and output_data_rate are present

in an encoded stream, the decoder can use either of the rates.

The recommended buffer size for synchronous data streaming is 4 800 byte. This gives sufficient capacity for a typical

maximum multiplexing jitter of 4 ms and a bit rate up to 9 Mbit/s.

4.4.5 Synchronized Data Streaming

Synchronized Data Streaming is used when the data stream shall be synchronized with another MPEG2 PES stream.

4.5 Multiprotocol encapsulation

4.5.1 Overview

The multiprotocol encapsulation provides a mechanism for transporting data network protocols on top of the MPEG2

Transport Streams in DVB networks. It has been optimized for carriage of the Internet Protocol (IP) (RFC 791 [5]), but

can be used for transportation of any other network protocol by using the LLC/SNAP encapsulation. It covers unicast

(datagrams targeted to a single receiver), multicast (datagrams targeted to a group of receivers) and broadcast

(datagrams targeted to all receivers). 48 bit MAC addresses are used for addressing receivers. However, DVB does not

specify how the MAC addresses are allocated to the receivers.

Due to the broadcast nature of DVB networks, security of the data is very important. The encapsulation allows secure

transmission of data by supporting encryption of the packets and dynamically changing MAC addresses.

4.5.2 Data transport

The datagrams are transported in datagram_sections which are compliant to the DSMCC_section format for private

data. The section format provides an efficient format for mapping the datagrams to the MPEG2 Transport Stream

packets and support filtering of datagrams based on the MAC address using existing hardware or software

demultiplexers.

The section format permits fragmenting datagrams into multiple sections. If the length of the datagram is less or equal

than 4 080 bytes (including the possible LLC/SNAP header), the datagram shall be sent in one section. In case of IP and

the LLC/SNAP header being omitted, the MTU shall be set to 4 080 bytes or less, so that the datagrams will never be

fragmented. In case of IP and the LLC/SNAP header being present the MTU shall be set to 4 074 or less.

The MAC address has been divided into 6 bytes that are located in two groups.

The

reason

for

this

is that the bytes 5 and

6 are in place

of the

table_id_extension field of the

DSMCC_section

while

bytes

1,2,3

and 4

are in the payload area of the

DSMCC_section.

剩余60页未读，继续阅读

oceancsw

粉丝: 0
资源: 2

DVB数据广播实施指南技术报告

ATSC Standards

DVB-T implementation guideline

java specification

ansys-guidelines-contact-convergence

iso/tr 4804.iso/tr 4804

guidelines for the use of the c++14 language in critical and safety-related

guidelines for the use of the c++ language in critical systems

Compare adjacency matrix and adjacency list for graph representation. How you choose which presentation to use depending on task and graph?

最新资源