SMPTE ST 2022-5-2013 Forward Error Correction for Transport of High Bit Rate Media Signals over IP Networks (HBRMT).pdf

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

1、 Copyright 2013 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue., White Plains, NY 10601 (914) 761-1100 Approved February 27, 2013 Table of Contents Page Foreword . 2 Intellectual Property 2 Introduction 2 1 Scope . 4 2 Conformance Notation . 4 3 Normative References . 4 4

2、Acronyms (Informative) . 5 5 Definitions (Normative) 5 6 FEC Datagram Structure 6 6.1 Datagram Structure 6 6.2 RTP Header for FEC Datagrams . 7 7 FEC Scheme 8 7.1 FEC Datagram Arrangement . 8 7.2 FEC Buffer Overhead and Latency Implications 10 7.3 FEC Header Format . 10 7.4 Construction of FEC Datag

3、rams 12 7.5 FEC Traffic Shaping Issues . 14 7.6 Re-Order Tolerance (Informative) . 14 Annex A Bibliography (Informative) . 15 Annex B Non Block-Aligned FEC Arrangement (Informative) . 16 Annex C Block-Aligned FEC Arrangement (Informative) . 17 Annex D Delay (Informative) 18 Annex E Conceptual Diagra

4、m (Informative) 19 Annex F Datagram Recovery (Informative) . 20 Annex G Revision Notes (Informative) 22 Page 1 of 22 pages SMPTE ST 2022-5:2013 Revision of SMPTE ST 2022-5:2012 SMPTE STANDARD Forward Error Correction for Transport of High Bit Rate Media Signals over IP Networks (HBRMT) SMPTE ST 2022

5、-5:2013 Page 2 of 22 pages Foreword SMPTE (the Society of Motion Picture and Television 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 Engi

6、neering Documents, including Standards, Recommended Practices, and Engineering Guidelines, 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, i

7、ncluding ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its Operations Manual. SMPTE ST 2022-5 was prepared by Technology Committee 32NF. Intellectual Property At the time of publication no notice had been received by SMPTE claiming paten

8、t rights essential to the implementation of this Standard. However, attention is drawn 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 en

9、tirely informative and does not form an integral part of this Engineering Document. IP-based networks have become increasingly important for delivery of Standard Definition (SD) and High-Definition (HD) television signals at high bit rates (without compression). However, existing transport protocols

10、 do not fully meet user requirements, especially for a standardized forward error correction (FEC) technique required for interoperability between different manufacturers. This standard defines a FEC technique to be used to correct for errors induced when real time video/audio payloads are transport

11、ed over IP networks. This standard is designed to support FEC for SMPTE ST 2022-6, Transport of High Bit Rate Media Signals over IP (HBRMT). This document defines a structured mechanism for FEC. Nothing in this standard defines when this FEC mechanism should be used. It is up to the implementer to d

12、etermine whether FEC is required, and whether the mechanism presented here meets their application requirements. 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 trans

13、port for broadcast production and is not intended for emission purposes. Typically a connection will be set up and torn down as a managed configuration of transmitting and receiving equipment. A connection may be unicast or multicast mode. The support of Session Description Protocol (SDP) and Real T

14、ime Control Protocol (RTCP) are not required for equipment supporting this standard. This standard defines two levels of FEC Level A and Level B. Level A uses one FEC stream and Level B uses two FEC streams. These levels are different from the Uneven Level Protection levels of RFC 5109. On IP networ

15、ks, datagram losses typically come from three sources gross reordering, bit-error induced datagram drops and burst losses/drops. For any FEC scheme to operate properly, errors from these sources need to be low enough so that the FEC scheme can correct enough of these errors to meet the application r

16、equirements. Implementers should be aware of limitations of any FEC scheme and take steps to ensure that application of this standard will meet their objectives, given uncorrected link performance. SMPTE ST 2022-5:2013 Page 3 of 22 pages Because, when using the IP protocol, the underlying transport

17、technologies such as Ethernet will ensure datagrams received with bit errors will be discarded, there is no requirement for an error correction scheme that can handle datagrams containing errors every datagram will either arrive correctly or not at all. An RTP payload format for Generic Forward Erro

18、r Correction Datagrams has been defined in RFC 2733 which was used in SMPTE ST 2022-1 to enable regeneration of lost IP datagrams with MPEG-2 video/audio Transport Streams. However, in RFC 2733 a few fields (the P, X, and CC fields) in the RTP header are specified in ways that are not consistent wit

19、h the way that they are designed in RFC 3550. This prevents payload-independent validity check of the RTP Datagrams. This has been corrected in RFC 5109. This standard is based on SMPTE ST 2022-1 and includes the corrections contained in RFC 5109. The RFC 5109 FEC Datagram structure consists of a FE

20、C Header followed by one or several sections of FEC Level Header and FEC Level Payload. RFC 5109 provides for protection of up to 16 or 48 Media Datagrams and includes a mechanism for providing uneven correction of essential media content and for exclusion of less important datagrams by use of maski

21、ng. Uneven protection is not included in this standard. To recover from burst loss at high bit rates, the SMPTE ST 2022-1 FEC column size and row size is extended and an RFC 5109 style header is used. The same traditional error correcting codes are applied to non-consecutive Media Datagrams. Each FE

22、C Datagram is Associated with Media Datagrams periodically selected. Therefore, consecutive RTP Datagrams can be recovered from consecutive FEC Datagrams. This standard is intended for constant bit rate (CBR) and anticipates variable bit rate (VBR) applications. CBR applications are assumed to use c

23、onstant datagram size and constant datagram rate as this provides the lowest FEC overheads. VBR applications can use variable datagram rates and/or variable datagram lengths as defined in SMPTE ST 2022-3. The method described herein has been in the process of standardization for several years; the i

24、nformal 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 document references that heritage. SMPTE ST 2022-5:2013 Page 4 of 22 pages 1 Scope This Standard defines a forward error correction

25、technique for the carriage of High Bit Rate real-time media over IP networks. The term High Bit Rate is used herein to distinguish from other Media-over-IP applications in which primarily compressed signals are transported; the FEC system described herein is differentiated by an ability to accommoda

26、te media payloads 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 keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the u

27、ser, 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 is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“

28、 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 permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one i

29、s 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 possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ i

30、ndicate 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 future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will

31、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“) as described. A conformant implementation need not implement optional provisions (“may“) and need

32、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 authoritative definition; Tables shall be next; followed by formal languages; then figures; and then any other

33、 language forms. 3 Normative Reference The following standard contains provisions which, through reference in this text, constitute provisions of this Standard. At the time of publication, the edition indicated was valid. All standards are subject to revision, and parties to agreements based on this

34、 standard are encouraged to investigate the possibility of applying the most recent edition of the standard indicated below. IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications SMPTE ST 2022-5:2013 Page 5 of 22 pages 4 Acronyms (Informative) CBR: Constant Bit Rate CSRC: Contributing

35、Source D: Number of Media Datagrams protected by a row FEC Datagram FEC: Forward Error Correction IANA: Internet Assigned Numbers Authority IP: Internet Protocol (see IETF STD05) L: Number of Media Datagrams protected by a column FEC Datagram RTCP: Real Time Control Protocol (see IETF RFC 3550) RTP:

36、 Real Time Protocol (see IETF RFC 3550) SDI: Serial Digital Interface SDP: Session Description Protocol (see IETF RFC 4566) SDTI: Serial Digital Transport Interface SNbase: Base RTP Sequence Number SSRC: Synchronization Source TS: Timestamp UDP: User Datagram Protocol (see IETF STD06) VBR: Variable

37、Bit Rate XOR: Exclusive OR 5 Definitions (Normative) Associated: A FEC Datagram is said to be “associated“ with one or more Media Datagrams (or vice versa) when those Media Datagrams are used to generate the FEC Datagram (by use of the XOR operation). Block-Aligned FEC Operation: Block-Aligned FEC o

38、peration is a correction scheme using a two dimensional matrix where the Media Datagrams are a contiguous group 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

39、 is achieved by D FEC Datagrams derived from each row for the FEC Matrix. Level A FEC stream shall protect all media packets exactly once. Optional Level B FEC stream shall protect all media packets exactly once. See Figure 3. Delay: Delay is time consumed by all sources such as processing delay, ac

40、cumulation and de-accumulation delay, FEC processing delay, IP transfer delay, IP delay variation buffering and FEC Latency delay. SMPTE ST 2022-5:2013 Page 6 of 22 pages FEC Datagram: An FEC Datagram is an RTP Datagram consisting of an RTP header and FEC data payload. The FEC data payload is compos

41、ed of an FEC Header and the FEC Payload. The FEC Datagrams are formatted according to the rules contained this standard. 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 r

42、ows. The datagrams are entered into the matrix to fill each row sequentially with incremented RTP 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 M

43、b/s (SDI, HD SDI, 3G), although the techniques specified herein may have continued utility at higher rates (e.g. 40 Gb/s, 100 Gb/s) as technology allows. Latency: Latency is the time for data to become available for a subsequent process. Media Datagram: A Media Datagram is an RTP Datagram consisting

44、 of an RTP header and media data payload. The media data payload is composed of a Payload Header and a Media Payload. Media Datagrams are formatted according to another standard (e.g. SMPTE ST 2022-6). Media Header: A Media Header is the RTP header for the datagram containing the Media Payload. Medi

45、a Payload: The Media Payload is the raw data (including video, audio, and ancillary data) that are transmitted 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 si

46、milar to a Block-Aligned FEC Operation, but performed over non-contiguous Media Datagrams. In a Non Block-aligned 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 Dat

47、agrams. See Annex B and in particular Figure B1. RTP Datagram: RTP Datagrams are defined in IETF RFC 3550. Traffic Shaping: Traffic Shaping is the process of reducing peak variations in instantaneous bit rate so as to produce a more constant data flow. Wrapped Media: Media that is in a container suc

48、h as that described in SMPTE ST 377-1:2009. 6 FEC Datagram Structure This section defines the construction of RTP Datagrams carrying FEC information. 6.1 Datagram Structure A FEC Datagram is constructed by placing an FEC Header and FEC processed payload into the RTP payload, as shown in Figure 1. SM

49、PTE ST 2022-5:2013 Page 7 of 22 pages +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header (12 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Header (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 FEC Datagram Header Format 6.2 RTP Header for FEC Datagrams All the fields in the RTP header of FEC Datagrams a