SMPTE ST 2022-6-2012 Transport of High Bit Rate Media Signals over IP Networks (HBRMT).pdf

《SMPTE ST 2022-6-2012 Transport of High Bit Rate Media Signals over IP Networks (HBRMT).pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 2022-6-2012 Transport of High Bit Rate Media Signals over IP Networks (HBRMT).pdf（16页珍藏版）》请在麦多课文档分享上搜索。

1、 SMPTE ST 2022-6:2012 Table of Contents Page Foreword . 2 Intellectual Property 2 Introduction 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 3 4 Acronyms . 4 5 Definitions 5 6 User Performance Requirements 6 6.1 Basic Network Requirements . 6 6.2 Media Datagram Description . 6 6.

2、3 RTP/UDP/IP Header 6 6.4 High Bit Rate Media Payload Header 8 6.5 High Bit Rate Media Payload . 12 7 FEC Interoperability and Usage . 14 7.1 FEC Interoperability . 14 7.2 Network Consideration (Informative) 14 Annex A Bibliography (Informative) . 16 Page 1 of 16 pages SMPTE STANDARD Transport of Hi

3、gh Bit Rate Media Signals over IP Networks (HBRMT) Copyright 2012 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved October 9, 2012 SMPTE ST 2022-6:2012 Page 2 of 16 pages Foreword SMPTE (the Society of Motion Picture and Televi

4、sion Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices, and Engineering Guid

5、elines, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance wi

6、th the rules given in Part XIII of its Operations Manual. SMPTE ST 2022-6 was prepared by Technology Committee 32NF. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Standard. However, attention is dr

7、awn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. Introduction This section is entirely informative and does not form an integral part of this Engineering Document.

8、 IP-based networks have become increasingly important for delivery of media content such as SMPTE ST 259, SMPTE ST 292-1 and SMPTE ST 424 streams. However, existing transport protocols do not fully meet the user requirements. This standard describes a transport protocol which can be used for the rea

9、l time transport of video/audio over IP networks. In this standard, it is specified that the entire payload of the serial digital interface signal including all VANC and HANC is encapsulated as one stream. The payload packing into RTP datagrams is designed to allow implementers to conveniently emplo

10、y error concealment in the case where no FEC is utilized, or in the case that errors extend beyond what the FEC is capable of correcting. The acronym HBRMT (High Bit Rate Media Transport) has developed a modicum of support in the industry in reference to the technique standardized in this document.

11、This standard is intended for real-time audio/video applications such as contribution, primary distribution, and digital cinema. This standard is designed to be applied to television transport for broadcast production and is not intended for emission purposes. Typically a connection will be set up a

12、nd torn down as a managed configuration of transmitting and receiving equipment. A connection may be unicast or multicast. Support of RFC 4566 Session Description Protocol (SDP) or RFC 3550 Real Time Control Protocol (RTCP) are not required for equipment supporting this standard but could be utilize

13、d at the implementers discretion. The method described herein has been in the process of standardization for several years. The informal name “High Bit-Rate Media Transport” and the acronym “HBRMT” have been associated with the work throughout that time. The mention of HBRMT in the title of this doc

14、ument references that heritage. This standard makes provision for, and specifies relevant parameter limits of an optional FEC mechanism. Details of the FEC implementation are defined in a separate standard document. SMPTE ST 2022-6:2012 Page 3 of 16 pages 1 Scope This standard defines a unidirection

15、al IP-based protocol for the transport of real-time video, audio, and ancillary signals. In particular this standard defines a method for the encapsulation of the payloads of a variety of existing SMPTE serial digital video standards. The term High Bit Rate is used herein to distinguish from other M

16、edia-over-IP applications in which compressed signals are transported. The uncompressed signals in this document are at rates of 270 Mbits/sec and higher. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable or contains the conformance language k

17、eywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords. All text in this document i

18、s, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be followed in order to conform to the document and from which no deviation is p

19、ermitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain po

20、ssibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in the futu

21、re. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one that includes all mandatory provisions (“shall“) and, if implemented, all recommended provisions (“should“)

22、 as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritati

23、ve definition; Tables shall be next; followed by formal languages; then figures; and then any other language forms. 3 Normative References Note: All references in this document to other SMPTE documents use the current numbering style (e.g. SMPTE ST 259:2008) although, during a transitional phase, th

24、e document as published (printed or PDF) may bear an older designation (such as SMPTE 259M-2008). Documents with the same root number (e.g. 259) and publication year (e.g. 2008) are functionally identical. The following standards contain provisions which, through reference in this text, constitute p

25、rovisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. SMPTE

26、 ST 2022-6:2012 Page 4 of 16 pages IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications Recommendation ITU-R BT.656-5, Interface for Digital Video Signals in 525-Line and 625-Line Television Systems Operating at the 4:2:2 Level of Recommendation ITU-R BT.601 SMPTE ST 259:2008, Televis

27、ion SDTV Digital Signal/Data Serial Digital Interface SMPTE ST 292-1:2012, 1.5 Gb/s Signal/Data Serial Interface SMPTE ST 425-1:2011, Source Image Format and Ancillary Data Mapping for the 3 Gb/s Serial Interface SMPTE ST 2022-1:2007, Forward Error Correction for Real-Time Video/Audio Transport Over

28、 IP Networks SMPTE ST 2022-5:2012, Forward Error Correction for High Bit Rate Media Transport Over IP Networks 4 Acronyms D: Number of Rows in an FEC Matrix DiffServ: Differentiated Services (see IETF RFC 2474) FEC: Forward Error Correction HBRMT: High Bit Rate Media Transport IP: Internet Protocol

29、(see IETF STD05) L: (Length) Number of Columns in an FEC Matrix MTU: Maximum Transmission Unit RSVP: Resource Reservation Protocol (see IETF RFC 2205) RTP: Real Time Protocol (see IETF RFC 3550) SDI: Serial Digital Interface SSRC: Synchronization Source List TOS: Type Of Service TS: Timestamp UDP: U

30、ser Datagram Protocol (see IETF STD06) UTC: Coordinated Universal Time XOR: Exclusive OR SMPTE ST 2022-6:2012 Page 5 of 16 pages 5 Definitions Block Aligned FEC Operation: Block Aligned FEC Operation is a correction scheme using a two dimensional matrix where the Media Datagrams are a contiguous gro

31、up of L x D datagrams. The Media Datagrams are protected as follows. Level A protection is achieved by L FEC Datagrams derived from each column for the FEC Matrix. Optional level B protection is achieved by D FEC Datagrams derived from each row for the FEC Matrix. Level A FEC stream shall protect al

32、l media packets exactly once. Optional Level B FEC stream shall protect all media packets exactly once. FEC Datagram: An FEC Datagram is an RTP Datagram consisting of an RTP Header and an FEC Payload. The FEC Payload is composed of an FEC Header and the FEC Payload. The FEC Datagrams are formatted a

33、ccording to the rules specified in SMPTE ST 2022-5. FEC Header: The FEC Header is the header information contained in an FEC Datagram. FEC Matrix: An FEC Matrix is a set of Media Datagrams ordered in a matrix with L columns and D rows. The datagrams are entered into the matrix to fill each row seque

34、ntially with incremented RTP sequence numbers. FEC Payload: The FEC Payload is the payload of an FEC Datagram. High Bit Rate: At the time of development of this Standard, High Bit Rate commonly refers to transmission rates higher than 270 Mb/s (SDI, HD SDI, 3G), although the techniques specified her

35、ein may have continued utility at higher rates (e.g. 40 Gb/s, 100 Gb/s) as technology allows. IP Stream: An individual flow of media and / or FEC datagrams on an IP network which includes all necessary components of the video signal including video, embedded audio, and embedded ancillary data signal

36、s. Media Datagram: A Media Datagram is an RTP Datagram consisting of an RTP header and the media data payload. The media data payload is composed of a Payload Header and a Media Payload. Media Payload: The Media Payload is the raw data (including video, audio, and ancillary data) that are transmitte

37、d from the sender. The Payload Header and the Media Payload are placed inside of a Media Datagram. Non Block-Aligned FEC Operation: A Non Block-Aligned FEC Operation is a correction scheme similar to a Block-Aligned FEC Operation, but performed over non-contiguous Media Datagrams. In a Non Block-ali

38、gned FEC Operation the FEC columns are offset from each other to facilitate Traffic Shaping and/or lower Latency. The FEC rows of a Non Block-Aligned FEC Operation cover contiguous Media Datagrams. Payload Header: The Payload Header is the portion of the payload that precedes the Media Payload. The

39、Payload Header is placed inside of a Media Datagram. The format and contents of the Payload Header is specified in Section 6.4. RTP Datagram: RTP Datagrams are defined in IETF RFC 3550. Video Timestamp: A 32-bit value formed of a sample from a 32-bit Time Clock at the sending device. See Section 6.5

40、 for more information. SMPTE ST 2022-6:2012 Page 6 of 16 pages 6 User Performance Requirements 6.1 Basic Network Requirements In order for a system supporting this standard to function correctly, the bandwidth available in the network shall always meet or exceed that required by the IP Stream genera

41、ted by the system. Note: It is important to ensure that the network path is designed with adequate bandwidth and a low enough error rate such that end equipment can successfully decode the stream. An optional error correction scheme is defined in SMPTE ST 2022-5. 6.2 Media Datagram Description The s

42、ize of output Media Datagrams from a transmitting device shall be less than or equal to 1500 octets so that the Media Datagrams can pass through most networks without fragmentation. The video luminance and color-difference values shall be encapsulated into 1376 octet media payloads. The last datagra

43、m of the video frame, being only partially filled with luminance and color-difference values, shall have additional null octets added to achieve a total length of 1376 octets. This is not considered padding at the RTP layer, therefore the padding bit in the RTP header shall be set to zero. The IP do

44、nt fragment bit shall be set so that IP fragmentation does not occur at the output of the device. As end-point devices will typically be connected to Ethernet style networks, this limits the maximum transmission unit (MTU) to 1500 octets. Note: The MTU on links between intermediate nodes in the netw

45、ork might be lower than 1500 octets, so care should be taken to ensure that IP datagrams are not lost due to the dont fragment requirement. The Media Datagram structure is shown in Figure 1. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header (12 octets) | +-+-+-+-+-+-+-+-

46、+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Header (4, 8, 12 or greater if extended) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Media Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Media Datagram Format 6.3 RTP/UDP/IP H

47、eader The use of IP/UDP/RTP shall be required, as it provides a standard header for the media and FEC datagrams. For interoperability, equipment shall only depend on the main RTP communication between sending and receiving units, and shall not require any additional communication. The UDP port numbe

48、r for the Media Datagrams shall be unique and different from the UDP port numbers of the datagrams used for Row FEC and Column FEC. If FEC is used, the UDP port number for the Column FEC Stream shall be a port number that is two greater than the UDP port number of the media stream. The UDP port numb

49、er for the Row FEC Stream shall be a port number that is four greater than the UDP port number of the media stream. The RFC 3550 RTP header shall be used. SMPTE ST 2022-6:2012 Page 7 of 16 pages Note: The Media Datagram rate for the 3 Gb/s television formats is close to 270,000 datagrams per second; therefore, a 90-kHz clock as utilized for MPEG-2 transport stream (Payload Type 33) will not be useful for receiver datagram management of this payload. A higher rate clock is specified instead, using