ITU-R BT 1300-3-2005 Service multiplex transport and identification methods for digital terrestrial television broadcasting《数字地面电视广播的业务复用、传送和识别方法》.pdf

《ITU-R BT 1300-3-2005 Service multiplex transport and identification methods for digital terrestrial television broadcasting《数字地面电视广播的业务复用、传送和识别方法》.pdf》由会员分享，可在线阅读，更多相关《ITU-R BT 1300-3-2005 Service multiplex transport and identification methods for digital terrestrial television broadcasting《数字地面电视广播的业务复用、传送和识别方法》.pdf（23页珍藏版）》请在麦多课文档分享上搜索。

1、 Rec. ITU-R BT.1300-3 1 RECOMMENDATION ITU-R BT.1300-3 Service multiplex, transport, and identification methods for digital terrestrial television broadcasting (Question ITU-R 31/6) (1997-2000-2004-2005) Scope This Recommendation defines service transport methods and service multiplex methods for th

2、e terrestrial digital television broadcasting systems. It specifies the utilization of and constraints on the use of ISO/IEC Standard 13818-1 (MPEG-2 Systems). The ITU Radiocommunication Assembly, considering a) that digital terrestrial television broadcasting (DTTB) will be introduced in the VHF/UH

3、F bands by many administrations; b) that the simultaneous transmission of video, sound, data and control signals is required in a DTTB service; c) that practical implementation of digital terrestrial broadcasting systems may require certain constraints and/or extensions to the International Organiza

4、tion for Standardization/International Electrotechnical Commission (ISO/IEC) Standard 13818-1 transport specification; d) that a common Transport Stream (TS) syntax has been established in ISO/IEC Standard 13818-1 (Moving Picture Experts Group (MPEG-2) Systems); e) that a common TS syntax is recomme

5、nded by Recommendations ITU-R BT.1207 and ITU-R BT.1209 based upon ISO/IEC Standard 13818-1; f) that the MPEG-2 defines two methods of transport, the Program Stream and TS methods, and that TS syntax is optimized for use in environments where transmission errors are likely; g) that the exchange of p

6、rogramming from various sources will continue to be necessary, placing special demands on the transport layer, recommends 1 that DTTB systems should comply with ISO/IEC Standard 13818-1 multiplexed streams and TS syntax as given in Recommendations ITU-R BT.1207 and ITU-R BT.1209, using one of the se

7、rvice transport methods described in Annex 1; 2 that digital terrestrial television systems should be designed to comply with the method for harmonization of service multiplex methods summarized in Annex 2. NOTE 1 New DTTB systems or functions may require the addition of new standard methods to the

8、appropriate Annex. 2 Rec. ITU-R BT.1300-3 “Service multiplex and transport” refers to the means of dividing the digital data stream into “packets” of information, the means of uniquely identifying each packet or packet type, and the appropriate methods of multiplexing video data stream packets, audi

9、o data stream packets, and ancillary data stream packets into a single data stream consisting of a sequence of 188-byte TS packets. Annex 1 describes service transport methods and Annex 2 describes service multiplex methods. NOTE ISO/IEC Standard 13818-1 is available at the following address: http:/

10、www.iso.org/itu. Annex 1 Service transport methods 1 Introduction The service transport method shall conform with the MPEG-2 TS syntax described in ISO/IEC Standard 13818-1 (MPEG-2 Systems). Permissible constraints and extensions for existing systems have been standardized and are given in 2 of this

11、 Annex. In developing the transport mechanism, interoperability among digital media, such as terrestrial broadcasting, cable distribution, satellite distribution, recording media, and computer interfaces, is a prime consideration. ITU-R recommends that digital television systems employ the MPEG-2 TS

12、 syntax for the packetization and multiplexing of video, audio, and data signals for digital broadcasting systems. The MPEG-2 TS syntax was developed for applications where channel bandwidth or recording media capacity is limited and the requirement for an efficient transport mechanism is paramount.

13、 It was designed also to facilitate interoperability with the asynchronous transfer mode (ATM) transport mechanism. 2 Service transport method 2.1 System overview The specifications for service multiplex and transport systems characteristics of System A, System B and System C are referenced in Appen

14、dices 1, 2 and 3, respectively. The transport format and protocol for System A, System B and System C are compatible subsets of the MPEG-2 Systems specification defined in ISO/IEC Standard 13818-1. All three systems are based on a fixed-length packet transport stream approach that has been defined a

15、nd optimized for digital television delivery applications. In these system standards certain extensions and constraints with respect to MPEG-2 Systems are specified. The following sections outline these. 2.2 Specification The syntax and semantics of the specification of the System A, System B and Sy

16、stem C standards conform to ISO/IEC Standard 13818-1 subject to the constraints and conditions specified here. The coding constraints that apply to the use of the MPEG-2 Systems specification in System A, System B and System C are as follows. Rec. ITU-R BT.1300-3 3 2.2.1 MPEG-2 Systems standard 2.2.

17、1.1 Video Transport Standard (T-STD) The video T-STD is specified in 2.4.2 of ISO/IEC Standard 13818-1 and follows the constraints for the level encoded in the video elementary stream (ES). 2.2.1.2 Audio T-STD The audio T-STD for System A is specified in 3.6 of Annex A (Appendix 1 to Annex 2 ATSC, 2

18、001). The audio T-STD for System B and System C is specified in 2.4.2 of ISO/IEC Standard 13818-1. The buffer model for ISO/IEC 13818-7 is described in Annex Q of ISO/IEC Standard 13818-1. 2.2.2 Registration descriptor System A uses the registration descriptor described in 2.6.8 of ISO/IEC Standard

19、13818-1 to identify the contents of programs and elementary streams to decoding equipment. In System B and System C, the use of the registration descriptor is in accordance with 2.6.8 of ISO/IEC Standard 13818-1. 2.2.2.1 Program format identifier Programs which conform to the System A specification

20、may be identified by the 32-bit format identifier within a registration descriptor carried in the programme (service) descriptor loop in the section of the Program Map Table (PMT) detailed in 2.4.4.8 of ISO/IEC Standard 13818-1. When used to identify the program as conforming to the System A specifi

21、cation, the format identifier is coded according to 2.6.8 of ISO/IEC Standard 13818-1, and has a value of 0x4741 3934 (“GA94” in ASCII). 2.2.2.2 Audio elementary stream format identifier Audio ESs which conform to the System A specification may be identified by the 32-bit format identifier within a

22、registration descriptor carried in the ES descriptor loop in the section of the Program Map Table (PMT) detailed in 2.4.4.8 of ISO/IEC Standard 13818-1. When present, the format identifier is coded according to 2.6.8 of ISO/IEC Standard 13818-1, and has a value of 0x4143 2D33 (“AC-3” in ASCII). 2.2.

23、3 Program-related constraints No program-related constraints on the Packet IDentifier (PID) allocation, beyond those specified in 2.2.7.1 below, are required in System A, System B or System C. 2.2.4 Constraints on Program Specific Information (PSI) In System A, the program constituents for all progr

24、ams are described in the PSI as specified in ISO/IEC Standard 13818-1 and in the Program and System Information Protocol (PSIP) (Appendix 1 to Annex 2ATSC, 2003). The following constraints apply to the PSI information: TS packets identified by a particular PMT_PID value are constrained to carry only

25、 one program definition, as described by a single TS_program_map_section(). For terrestrial broadcast applications, these TS packets are further constrained to carry no other kind of PSI table. The TS is constructed such that the time interval between the byte containing the last bit of the TS_progr

26、am_map_section() containing television program information and successive occurrences of the same TS_program_map_section() are less than or equal to 400 ms. 4 Rec. ITU-R BT.1300-3 The program numbers are associated with the corresponding PMT_PIDs in the Program Association Table (PAT). The TS is con

27、structed such that the time interval between the byte containing the last bit of the program_association_section() and successive occurrences of the program_association_section() are less than or equal to 100 ms. However, when program_association_section()s, CA_section()s, and TS_program_map_section

28、()s are approaching their maximum allowed sizes, the potential exists to exceed the 80 000 bit/s rate specified in 2.4.2.3 of ISO/IEC Standard 13818-1. In cases where the table section sizes are such that the 100 ms repetition rate of the program_association_section() would cause the 80 000 bit/s ma

29、ximum rate to be exceeded, the time interval between the byte containing the last bit of the program_association_section() may be increased but in no event shall exceed 140 ms, so that under no circumstances the limit of 80 000 bit/s is exceeded. When an ES of stream_type 0x02 (MPEG-2 video) is pres

30、ent in the TS, the data_stream_alignment_descriptor() (described in 2.6.10 of ISO/IEC Standard 13818-1) is included in the descriptor loop immediately following the ES_info_length field in the TS_program_map_section() describing that ES. The descriptor_tag value is set to 0x06, the descriptor_length

31、 value is set to 0x01, and the alignment_type value is set to 0x02 (video access unit). Adaptation headers are not allowed to occur in TS packets identified by PID 0x0000 (the PAT PID) for purposes other than for signalling with the discontinuity_indicator that the version_number ( 2.4.4.5 of ISO/IE

32、C Standard 13818-1) may be discontinuous. Adaptation headers are not allowed to occur in TS packets identified by a program_map_PID value for purposes other than for signalling with the discontinuity_indicator that the version_number ( 2.4.4.9 of ISO/IEC Standard 13818-1) may be discontinuous. In Sy

33、stem B, the program constituents for all programs are described in the PSI as specified in ISO/IEC Standard 13818-1 and in the Service Information (SI) as specified in Appendix 2 to Annex 2 ETSI, 1997a. The following constraints apply to the PSI information: Each section of the PAT and the PMT shoul

34、d be transmitted at least once every 100 ms. The Network Information Table (NIT) is defined in compliance with ISO/IEC Standard 13818-1, and the data format is further defined in Appendix 2 to Annex 2 ETSI, 1997a. The NIT is carried in TS packets with a PID value of 0x0010. Each section of the NIT s

35、hall be transmitted at least once every 10 s. The minimum time interval between the arrival of the last byte of a section to the first byte of the next transmitted section with the same table_id and table_id_extension shall be 25 ms. In System C, the program constituents for all programs are describ

36、ed in the PSI as specified in ISO/IEC Standard 13818-1 and in the SI as specified in Appendix 3 to Annex 2 ARIB, 2004a. The following constraints apply to the PSI information: Each section of the PAT and the PMT is preferably to be transmitted at least once every 100 ms. The Network Information Tabl

37、e (NIT) is defined in compliance with ISO/IEC Standard 13818-1, and the data format is further defined in Appendix 3 to Annex 2 ARIB, 2004a. The NIT is carried in TS packets with a PID value of 0x0010. Each section of the NIT is preferably to be transmitted at least once every 10 s. TS packets of SI

38、 with the same PID, are transmitted within the range of 4 kilobytes 100% (0 to 8 kilobytes) in 32 ms each. Rec. ITU-R BT.1300-3 5 2.2.5 Packetized Elementary Stream (PES) constraints PES syntax and semantics shall be used to encapsulate the audio and video ES information. The PES syntax is used to c

39、onvey the Presentation Time-Stamp (PTS) and Decoding Time-Stamp (DTS) information required for decoding audio and video information with synchronism. This section describes the coding constraints for this system layer. Within the PES packet header, the following restrictions apply: For System A: PES

40、_scrambling_control shall be coded as 00. ESCR_flag shall be coded as 0. ES_rate_flag shall be coded as 0. PES_CRC_flag shall be coded as 0. For System B: The following trick mode fields shall not be transmitted in a broadcast bitstream: trick_mode_control, field_id, intra_slice_refresh, frequency_t

41、runcation, field_rep_cntrl. For System C, specific constraints are not specified but may apply if necessary. Within the PES packet extension in System A, the following restrictions apply: PES_private_data_flag shall be coded as 0. pack_header_field_flag shall be coded as 0. program_packet_sequence_c

42、ounter_flag shall be coded as 0. P-STD_buffer_flag shall be coded as 0. 2.2.5.1 Video PES constraints The following constraints are specified in System A. Each PES packet shall begin with a video access unit, as defined in 2.1.1 of ISO/IEC Standard 13818-1, which is aligned with the PES packet heade

43、r. The first byte of a PES packet payload shall be the first byte of a video access unit. Each PES header shall contain a PTS. Additionally, it shall contain a DTS as appropriate. For terrestrial broadcast, the PES packet shall not contain more than one coded video frame, and shall be void of video

44、picture data only when transmitted in conjunction with the discontinuity_indicator to signal that the continuity_counter may be discontinuous. Within the PES packet header, the following restrictions apply: The PES_packet_length shall be coded as 0x0000. data_alignment_indicator shall be coded as 1.

45、 Video PES constraints of System C are specified in Appendix 3 to Annex 2 ARIB, 2004b. 2.2.5.2 Audio PES constraints The following constraints are specified in System A. The audio decoder may be capable of simultaneously decoding more than one ES containing different program elements, and then combi

46、ning the program elements into a complete program. In this case, the audio decoder may sequentially decode audio frames (or audio blocks) from each ES and do the combining (mixing together) on a frame (or block) basis. In order to have the audio from the two ESs reproduced in exact sample synchronis

47、m, it is necessary for the original audio elementary stream encoders to have encoded the two audio program elements frame synchronously; i.e., if audio program 1 has sample 0 of frame n at time t0, then audio program 2 should also have 6 Rec. ITU-R BT.1300-3 frame n beginning with its sample 0 at th

48、e identical time t0. If the encoding is done frame synchronously, then matching audio frames should have identical values of PTS. If PES packets from two audio services that are to be decoded simultaneously contain identical values of PTS then the corresponding encoded audio frames contained in the

49、PES packets should be presented to the audio decoder for simultaneous synchronous decoding. If the PTS values do not match (indicating that the audio encoding was not frame synchronous) then the audio frames which are closest in time may be presented to the audio decoder for simultaneous decoding. In this case the two services may be reproduced out of sync by as much as 1/2 of a frame time (which is often satisfactory, e.g., a voice-over does not require precise timing). The value of