1、 Copyright 2007 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100Approved May 24, 2007 Table of Contents Page Foreword . 2 Introduction . 2 1 Scope 3 2 Conformance Notation 3 3 Normative References 3 4 Acronyms (Informative). 3 5 D
2、efinitions . 4 5.1 Traffic Shaping. 4 5.2 XOR . 4 5.3 Latency. 4 5.4 Delay 4 6 Background (Informative) 4 7 Encapsulation Scheme . 5 7.1 RTP/UDP/IP Layer. 5 8 FEC Scheme. 5 8.1 FEC Packet Arrangement 5 8.2 FEC Buffer Overhead and Latency Implications 7 8.3 FEC Packet RTP Header Format 7 8.4 FEC Head
3、er Format. 8 8.5 FEC Traffic Shaping Issues . 9 8.6 Reorder Tolerance (Informative) 10 9 System Configuration 10 Annex A Bibliography (Informative) 11 Annex B Non-Block Aligned FEC Arrangement (Informative) 12 Annex C Block Aligned FEC Arrangement (Informative) 13 Annex D Delay (Informative). 15 Pag
4、e 1 of 15 pages SMPTE 2022-1-2007SMPTE STANDARD Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks SMPTE 2022-1-2007 Page 2 of 15 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organizatio
5、n. 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 Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Commi
6、ttees 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 with the rules given in Part XIII of its Administrative Practices. SMPTE 2022-1 was
7、prepared by Technology Committee N26 on File Management and Networking Techology. Introduction This section is entirely informative and does not form an integral part of this document. IP-based networks have become increasingly important for delivery of compressed content as MPEG-2 Transport Streams
8、. However, existing transport protocols do not fully meet the user requirements, especially for a standardized forward error correction technique required for interoperability between different manufacturers. This standard defines a forward error correction technique to be used to correct for errors
9、 induced when video/audio payloads are transported over IP networks. 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 determine whether FEC is required over the IP network in use, and whether
10、 the mechanism presented here meets their application requirements. This standard is intended for real-time audio/video applications such as contribution, distribution, and ”e-cinema”. The applications addressed by this standard may employ any transport scheme that is supported by the video/audio tr
11、ansport Standards. 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. SMPTE 2022-1-2007 Page 3 of 15 pages 1 Scope This standard defines a forward error correction technique for the carriage of real-time Video/Audio content over
12、 IP networks. 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 user, but not indispensable, and can be rem
13、oved, 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“ or individual paragraphs that start with
14、“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 is recommended as particularly suitable, wi
15、thout 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“ indicate courses of action permissible with
16、in 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 never be defined in the future. 3 Normativ
17、e References The following standards contain provisions which, through reference in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this recommended
18、 practice are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications IETF RFC 2733, An RTP Payload Format for Generic Forward Error Correction IETF RFC 4340, Datagram Congesti
19、on Control Protocol (DCCP) 4 Acronyms (Informative) ASI: Asynchronous Serial Interface CSRC: Contributing Sources List FEC: Forward Error Correction IANA: Internet Assigned Numbers Authority IP: Internet Protocol RTCP: Real Time Control Protocol SMPTE 2022-1-2007 Page 4 of 15 pages RTP: Real Time Pr
20、otocol SDI: Serial Digital Interface SDTI: Serial Digital Transport Interface SNbase: Base RTP Sequence Number SSRC: Synchronization Source List TS: Timestamp UDP: User Datagram Protocol XOR: Exclusive OR 5 Definitions 5.1 Traffic Shaping The process of reducing peak variations in instantaneous bit
21、rate so as to produce a more constant data flow. 5.2 XOR The term XOR is an acronym for exclusive-OR, a Boolean operation. 5.3 Latency Latency is the time for data to become available for a subsequent process. 5.4 Delay Delay is time consumed by all sources such as processing delay, accumulation and
22、 de-accumulation delay, FEC processing delay, IP transfer delay, IP delay variation buffering and FEC latency delay. 6 Background (Informative) In many applications, errors are generally not acceptable; therefore support for some sort of FEC scheme may be required. The use of FEC as defined in this
23、Standard is recommended, but there are applications where occasional errors are preferable to the overhead of the FEC, so manufacturers may support a non-FEC mode. On IP networks, packet losses typically come from three sources gross reordering, bit-error induced packet drops and burst losses/drops.
24、 For any FEC scheme to operate properly, the error from these sources needs to be low enough so that the FEC scheme can correct these errors to meet the application requirements. Implementers should be aware of limitations of any FEC scheme and take steps to ensure that application of this Standard
25、will meet their objectives, given uncorrected link performance. Because, when using the protocols in this Standard, the entire packet will be discarded if there is even a single bit error, there is no requirement for an error correction scheme that can handle packets containing errors every packet w
26、ill either arrive correctly or not at all. An RTP payload format for Generic Forward Error Correction Packets has been defined in the RFC 2733 to enable error correction of real time media. RFC2733 allows the use of traditional error correcting codes. A major advantage of this scheme is that it can
27、be used with any standardized video/audio transport (ASI, SDI, SMPTE 2022-1-2007 Page 5 of 15 pages SDTI,) as long as it is encapsulated in an RTP packet. However, RFC2733 limits the scope of packets used to generate the Forward Error Correction payload, to 24 consecutive packets. To recover burst l
28、oss, an extension to the existing RFC is proposed. The same traditional error correcting codes are applied to non-consecutive media packets that can be spaced over more than 24 packets. Each FEC packet is associated to packets periodically selected. Therefore, consecutive RTP packets can be recovere
29、d from consecutive FEC packets. 7 Encapsulation Scheme This clause defines the limitations on construction of the media packets which will be protected by the FEC scheme. 7.1 RTP/UDP/IP Layer The use of RTP shall be required, as it provides a standard header for the packets. Equipment shall only use
30、 RTP as specified in RFC 3550 and consequently shall not require the use of any additional communication. The following additional constraints on RFC3550 shall apply: The usage, by senders and receivers, of the following bits shall be defined by the associated video/audio transport standards: The Pa
31、dding (P) bit The Marker (M) bit The Extension (X) bit, with the additional constraint that the extension bit and the length of the extension shall be constant for the duration of the session. The following parameters shall be set by the sender as indicated: The CSRC count (CC) field shall be set to
32、 zero. This means there are no entries in the CSRC (Contributing SouRCes list). The value of the SSRC field shall not be relied upon at the receiver; the transmitter is free to assign this to any value. There is no requirement for the initial sequence number to be randomly assigned, as suggested in
33、RFC3550. 8 FEC Scheme 8.1 FEC Packet Arrangement The FEC scheme constitutes an extended version of RFC2733. Each FEC packet is associated with media packets periodically selected. Therefore, consecutive media packets can be recovered from consecutive FEC packets. The process is detailed in Figure 1.
34、 In this Standard, L shall designate the number of columns of protected packets and D shall designate the number of rows. The main advantage of this scheme over RFC2733 is the burst error correction capacity. The error correcting function chosen is XOR which has the ability to recover any one lost p
35、acket. If a one dimensional scheme based on XOR is used (i.e. applied to D consecutive packets), a burst error of two or more lost packets is not SMPTE 2022-1-2007 Page 6 of 15 pages recoverable. However, if the two dimensional scheme is used, the recoverability is greatly improved, since it can rec
36、over up to L consecutive packets. Figure 1 Encoding scheme In Figure 1, the encoding scheme is schematized for L*D media packets. The period chosen between media packets covered by a given FEC packet is L. Thus the payload of the kthFEC packet is computed based on the D packets numbered nL+k (0 n D
37、- 1). The alignment of the columns is for illustration. Implementations may use this alignment for simplicity, but there are some advantages to be gained by offsetting the columns - see Annex B. This means that receiving devices shall not make any assumptions about the relationship between FEC packe
38、ts beyond those that are explicitly specified. This standard defines two levels of FEC protection Level A and Level B. Level A devices shall support one FEC stream. Level B devices shall support two simultaneous FEC streams. These FEC streams shall be carried on separate UDP ports to allow them to h
39、ave separate sequence number handling, and to maintain backward compatibility with implementations that only support a single FEC stream. For senders emitting one FEC stream, media packets shall be sent to destination port N (where N is an even integer per RFC 3550), and the single stream of FEC pac
40、kets shall be sent to destination port N+2. For senders emitting two FEC streams, the first FEC stream shall be sent to destination port N+2 and the second FEC stream shall be sent to destination port N+4. The FEC function on a sending device shall be capable of being enabled or disabled. Level A re
41、ceivers shall process zero or one FEC streams. Level A receivers shall be able to continue to function nominally in the presence of two FEC streams. Level B receivers shall be able to process zero, one or two FEC streams. SMPTE 2022-1-2007 Page 7 of 15 pages The second FEC stream shall be applied to
42、 a run of consecutive packets the length of the L parameter of the first stream. If the columns are aligned this will produce an FEC structure as shown in Figure 2, where the packets labeled RTP are the media packets, the packets labeled FEC are the first FEC stream packets, and the packets labeled
43、FEC are the second FEC stream packets. Figure 2 Dual FEC mode structure The second FEC stream can cope with any single packet loss, and the first FEC stream can cope with burst losses up to L in length. 8.2 FEC Buffer Overhead and Latency Implications To promote interoperability and simplify impleme
44、ntation, limits shall be specified for values of the L and D parameters. These limits are media type specific and are defined in the appropriate media document. Devices shall support all combinations of values of L and D that comply with all limits. Devices may extend beyond these values if desired.
45、 A device shall only support two FEC streams in the case where 4L . NOTES 1 For MPEG-2 Transport streams these limits are defined in SMPTE 2022-2. 2 Given the FEC header format defined in this document ( 7.4), L and D values are limited to 255. 8.3 FEC Packet RTP Header Format RFC2733 places constra
46、ints on the values of the fields in the RTP header. It specifies that the P, X, M, and CC fields are computed from the media packets, but because of the restrictions in 6.1 the values of these fields are as defined in this Standard. SMPTE 2022-1-2007 Page 8 of 15 pages As there is no simple mechanis
47、m available for resolving a dynamic payload type, and the only RTP traffic being sent and received by units corresponding to this Standard would logically be the FEC data and the media data, the FEC data shall be sent using the first available dynamic payload type number, which is 96 decimal. The fo
48、llowing additional restrictions shall be applied: The sender shall set the SSRC field to zero to be compliant with this document. Other values of SSRC are reserved. The value of the SSRC field shall be used by the receiver. There is no requirement for the initial sequence number to be randomly assig
49、ned, as suggested in RFC3550. The time stamp field on FEC packets shall be ignored by the receiver. 8.4 FEC Header Format The FEC header described in the RFC 2733 is originally 12 bytes. To allow for the extension to the error correction scheme, the FEC header shall be defined as detailed in the text below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SNBase low bits | Length Recovery | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| PT recovery | Mask | +-+-+-
