SMPTE RDD 11-2007 SMPTE REGISTERED DISCLOSURE DOCUMENT Bitstream Syntax and Semantics for Carriage of HDSDI Ancillary Data in an MPEG-2 Transport Stream《SMPTE注册信息披露文件 运输MPEG-2传送流中H.pdf

1、 The attached document is a Proposed Registered Disclosure Document prepared by the proponent identified below. It has been examined by the appropriate SMPTE Technology Committee and is believed to contain adequate information to satisfy the objectives defined in the Scope, and to be technically con

2、sistent. This document is NOT a Standard, Recommended Practice or Engineering Guideline, and does NOT imply a finding or representation of the Society. Errors in this document should be reported to the proponent identified below, with a copy to engsmpte.org. All other inquiries in respect of this do

3、cument, including inquiries as to intellectual property requirements that may be attached to use of the disclosed technology, should be addressed to the proponent identified below. Proponent contact information: John Mailhot Harris Broadcast Systems 1160 Route 22 East Bridgewater, NJ, 08807 USA E-ma

4、il: Page 1 of 6 pages RDD 11-2007 Copyright 2007 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved July 10, 2007 SMPTE REGISTERED DISCLOSURE DOCUMENT Bitstream Syntax and Semantics for Carriage of HDSDI Ancillary Data in an MPE

5、G-2 Transport Stream RDD 11-2007 Page 2 of 6 pages 1 Overview This Registered Disclosure Document (RDD) describes a bitstream syntax and semantics used to transmit SMPTE 291 formatted ancillary data (both VANC and HVANC) from the input of an encoder, through an MPEG-2 Transport Stream, and to recons

6、truct the ancillary data accurately at the output of a decoder. This protocol is in current use within several fielded productsi,ii. In addition, this data format has been in use by a major television network for HD contribution and distribution applications since mid 2003. 2 Intellectual Property T

7、he protocol and method described in this document and the related intellectual property are the property of the authors employer, Harris Corporation (Harris), with all rights, title and interest reserved. No license is granted or implied by this Registered Disclosure. Furthermore, Harris does not re

8、present or warrant that the protocol and method described herein are free from infringement of 3rd party intellectual property, and no indemnification regarding any such potential claims is made or implied. While reasonable efforts have been made to ensure that this document describes the protocol d

9、etails accurately, Harris does not warrant the sufficiency or accuracy of this document, and shall not be in any manner liable for direct, indirect, or consequential damages resulting from reliance thereupon. This document is disclosed for information purposes only. 3 Background The HDSDI signal doc

10、umented in SMPTE292M is designed to carry ancillary data in addition to the active video signal. Ancillary data packets and formats are defined in SMPTE 291M. Certain Ancillary signals have specific methods of transport within the MPEG-2 Transport Stream (such as audio, or SMPTE 334M VANC caption da

11、ta). This RDD documents a specific mechanism for transporting arbitrary Ancillary data in an MPEG-2 transport stream, and re-inserting it into the decoded video signal accurately. While this mechanism has been in use in some networks for several years, system designers should be mindful of other mec

12、hanisms which are in use from various standards organizations worldwide. It is anticipated that use of Ancillary data signals will increase over time, especially if adequate transport mechanisms are in place. The below-documented transport mechanism is defined based on the following high-level requi

13、rements: 1) Transparent transmission of an Ancillary data signal complaint to SMPTE 291M. 2) Reinsertion of Ancillary data packets on the same frame, line, and space (HVANC or VANC) that they were extracted from. 3) Ability to limit (or manage) the amount of bandwidth consumed by transport of Ancill

14、ary data. In addition to these requirements on the transport mechanism, we have found it useful to have the following behaviors on the encoding equipment: 1) Do not transport embedded audio using this mechanism, as there are other more commonly-used mechanisms for doing so (including SMPTE 302M). 2)

15、 Do not transport the embedded, audio control packets, as they should be generated by the receiver if/when it re-embeds the audio, based on information which can only be known by the receiver. 3) Ability to limit (or manage) the amount of bandwidth consumed by transport of Ancillary data. iWaveStar,

16、 FlexiCoder, VideoRunner and NetVX systems i. The WaveStar Decoder HD 4:2:2 and NetPlus model 200 and model 300 HD Receivers also support the format documented here. iiWaveStar is a registered trademark of Lucent Technologies, used under license. VideoRunner is a registered trademark of Harris Corpo

17、ration, assigned by Aastra Technologies, Ltd. FlexiCoder and NetVX are trademarks of Harris Corporation. RDD 11-2007 Page 3 of 6 pages In addition to these requirements on the transport mechanism, we have found it useful to have the following behaviors on the encoding equipment: 1) Do not transport

18、embedded audio using this mechanism, as there are other more commonly-used mechanisms for doing so (including SMPTE 302M). 2) Do not transport the embedded audio control packets, as they should be generated by the receiver if/when it re-embeds the audio, based on information which can only be known

19、by the receiver. 3) Keep track of the amount of bandwidth consumed by this transport, and drop whole packets of ancillary data if necessary; never try to send partial packets. 4) Do not bother transporting packets which are marked for deletion. 5) Do not bother transporting start marker packets or e

20、nd marker packets. The decoder should regenerate these space permitting. 4 SI/PSI issues and mapping overview The Ancillary data for a source frame of video are organized into a single PES unit for transport. This PES unit is then packaged into MPEG-2 transport stream packets using the methods descr

21、ibed in ISO/IEC 13818-1. Every Ancillary data PES is marked with a Presentation Timestamp (PTS) which shall (with the exception of 3:2 pulldown processing noted below) correlate with the PTS of a video frame. Each Ancillary data PES packet shall be TS aligned, using the adaptation layer stuffing mec

22、hanism as may be necessary. The Ancillary data service shall be on a separate data PID, indicated in the PMT with stream type 0x06 (user private data). A registration descriptor is carried in the PMT with the format_identifier value “LU-A” which uniquely indicates that the data is of the format desc

23、ribed in this document. In the event that the encoder is using the MPEG-2 repeat-first-field/top-field-first method for inverse telecine processing, ancillary data PES is still sent on an “original frames” basis. Care must be taken to correctly associate the ancillary data with the correct source (o

24、r reconstructed) frame. In this case, for coded pictures indicating top-field-first, the PTS of an ancillary data PES shall match the PTS of the coded picture. There may be ancillary data PES packets for which no corresponding video PTS exists, however these ancillary data PTS values shall match the

25、 values which would have been on the video coded pictures had the sequence been coded at its original frame rate. The Ancillary data PES packets are transmitted in the order in which they are presented. 5 Transmission Timing and Buffer Size PES data shall be transmitted as close to CBR (constant-bit

26、-rate) as reasonably possible. Since the amount of Ancillary data may vary frame-to-frame, the encoder shall be provisioned with a peak bit-rate for transmission, in order to facilitate planning of the other bit-rates in the multiplex. PES data shall be transmitted not exceeding this peak rate. The

27、timing of transmission of the ancillary data from the encoder (relative to the STC) shall be based on the T-STD decoder buffer model, with the assumption that the buffer of the decoder is large enough to hold two full frames of ancillary data, and shall be filled at a rate not to exceed 1.2 times th

28、e nominal peak transmission rate. RDD 11-2007 Page 4 of 6 pages 6 Ancillary data PES packet syntax and semantics In keeping with the provisions of ISO/IEC 13838-1, ancillary data is packaged into MPEG-2 “Packetized Elementary Stream” or PES units, one per original video frame. Each ancillary data PE

29、S packet looks like the following: Field Bits Value Start_Code_Prefix 24 0x000001 Stream_id 8 0xBD (private_stream_1) PES_packet_length 16 Length of the remainder of the packet, in bytes Marker_bits 2 10 PES_scrambling_control 2 00 (not scrambled) PES_priority 1 0 Data_alignment_indicator 1 0 Copyri

30、ght 1 0 or 1 Original_or_copy 1 1 PTS_DTS_flags 2 10 (PTS will be present) ESCR_flag 1 0 ES_rate_flag 1 0 DSM_trick_mode_flag 1 0 Additional_copy_info_flag 1 0 PES_CRC_flag 1 0 PES_extension_flag 1 0 PES_header_data_length 8 0x05 (5 bytes of PTS to follow) Marker_bits 4 0010 PTS3230 3 PTS bits 3230

31、Marker_bit 1 1 PTS2915 15 PTS bits 2915 Marker_bit 1 1 PTS140 15 PTS bits 140 Marker_bit 1 1 Ancillary_Data_Structure() Variable Ancillary data structure The fields listed above have the meanings defined in ISO/IEC 13818-1. Ancillary data information for a video frame is organized into an ancillary_

32、data_structure() unit as defined below. The structure organizes ancillary data by “spaces” where the data was found; for example the HVANC space on line 9, and the VANC space on line 9, are considered two separate spaces. The structure shall list all data in the order in which it must be re-inserted

33、 (monotonically increasing line numbers, etc.) Description Bits Value Ancillary_Data_Structure() Marker_bit 1 1 Final_packet_flag 1 Final_packet_flag Bandwidth_limit_flag 1 Bandwidth_limit_flag Reserved 5 0x00 Number_of_spaces 16 Number of ancillary_space_structure() units which follow in this PES p

34、acket. Ancillary_payload_size 16 Size (in bytes) of the ancillary space structures For (i=0; iNumber_of_spaces; i+) Ancillary_space_structure(); RDD 11-2007 Page 5 of 6 pages Final_packet_flag: a value of “1 indicates this is the final PES packet for this frame. A value of 0 indicates that there may

35、 be additional PES packets for this frame. Multiple packets for the same original frame might be used based on buffer size constraints of the encoder, for example. Bandwidth_limit_flag: a value of 1 indicates that some ancillary data was discarded by the encoder due to transmission bandwidth limitat

36、ions. This flag is only indicated during a “final packet” for a frame as indicated by Final_packet_flag. Number_of_spaces: the number of Ancillary_space_structure() units to be transmitted in this PES packet. If there is no ancillary data for a given frame, then set this to zero and send no structur

37、es. Ancillary_space_structure() Marker_bit 1 1 Reserved 3 0x00 Video_line_number 12 Video_Line_Number Marker_bit 1 1 Ancillary_space_type 3 Ancillary_space_type Reserved 2 0x00 Number_of_anc_packets 10 Number_of_anc_packets For (i=0; iNumber_of_anc_packets; i+) Ancillary_Packet_Struct() Ancillary da

38、ta packet structure Video_line_number: the line number where this ancillary space is located. (line numbers are as defined in SMPTE 274M or SMPTE 296M or equivalent defining standard for the prevailing video format) NOTE THAT THE ANCILLARY DATA MUST BE TRANSMITTED IN THE BITSTREAM IN THE ORDER IN WH

39、ICH IT APPEARS IN THE VIDEO FRAME. Ancillary_space_type: a 3-bit code marking what type of space these packets came from according to the following table: 000 VANC Chroma Vertical Ancillary Space Chroma bus 001 VANC Luma Vertical Ancillary Space Luma bus 010 HANC Chroma Horizontal Ancillary Space Ch

40、roma bus 011 HANC Luma Horizontal Ancillary Space Luma bus 100 111 Reserved Reserved Number_of_anc_packets: the number of ancillary data packets transmitted in this space. Ancillary_Packet_Struct() Marker_bit 1 1 Reserved 6 0x00 Number_of_words 9 Number_of_words For (k=0; kNumber_of_words; k+) Ancil

41、_word 10 10-bit word from the HDSDI Byte_Realignment_bits 0, 2, 4, or 6 0xff. Restore byte alignment of the stream. RDD 11-2007 Page 6 of 6 pages Number_of_words: indicates the number of 10-bit words present in this ancillary data packet. Each packet (as defined in SMPTE 291M) consists of the Ancill

42、ary Data Flag (ADF) sequence 0x000 0x3ff 0x3ff which is not transmitted, followed by DID, DBN/SDID, and DC words (which are transmitted) followed by count DC words of ancillary data. Each SMPTE 291M packet ends with a checksum (CS) word. The checksum (CS) word at the end of the packet is transmitted

43、. Number_of_words in this transmission format is equal to DC+4. Ancil_Word: is the 10-bit value as extracted from the HDSDI signal. Byte_Realignment_bits: a 2, 4, 6, or 0 (zero) bit stuffing item, in order to get the Ancillary_Packet_Struct() to be an exact multiple of eight bits long. 7 Implementat

44、ion Limits The above definition covers both the current implementation in fielded encoders and decoders, and also some cases which are not implemented at the present time but might arise in the future. Each specific implementation has limits on the amount of ancillary data which may be transmitted p

45、er frame, and which ancillary data spaces may be supported (among other limits). Generally, current implementations are limted to 2000 10-bit words per frame, and a maximum PES data rate of 720 kBits/sec. Although the protocol allows for multiple PES packets per frame, in practice all of the data is currently packaged into a single PES packet.