SMPTE ST 2022-4-2011 Unidirectional Transport of Non-Piecewise Constant Variable Bit Rate MPEG-2 Streams on IP Networks《IP网络上非分段常数可变位速率MPEG-2传输流的非定向传输》.pdf

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

2、onyms (Informative) 4 5 Definitions (Normative). 5 6 Transmission Protocols (Normative) 5 6.1 TS Packets per Media Datagram. 5 6.2 Signal Time Base Protection and Recovery 6 6.3 FEC Operation . 8 6.4 Media Datagram RTP Numbering 8 6.5 Class of Service . 8 6.6 Session 8 7 Compliance 8 Annex A Non-Pie

3、cewise Constant Data Streams (Informative) 9 Page 1 of 9 pages SMPTE ST 2022-4:2011SMPTE STANDARD Unidirectional Transport of Non-Piecewise Constant Variable Bit Rate MPEG-2 Streams on IP Networks SMPTE ST 2022-4:2011 Page 2 of 9 pages Foreword SMPTE (the Society of Motion Picture and Television Eng

4、ineers) 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 Guidelines,

5、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 with the r

6、ules given in Part XIII of its Administrative Practices. This SMPTE Engineering Document 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,

7、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 IP-based networks have become increasingly important for delivery of compressed conten

8、t contained within MPEG-2 Transport Streams. However, existing transport protocols do not fully meet all user requirements. This standard describes modifications to existing transport protocols which can be used for the unidirectional carriage of non-piecewise constant variable bit rate MPEG-2 Trans

9、port Streams over IP networks. This standard is intended for real-time audio/video transport applications used for contribution and distribution services between professional broadcast equipment over an IP network. The applications addressed by this standard may employ any compression scheme that is

10、 supported by the MPEG-2 Transport Stream. This standard also provides for signal recovery from limited network errors through a forward error correction scheme. SMPTE ST 2022-4:2011 Page 3 of 9 pages 1 Scope This standard defines a transport protocol for the carriage of real-time non-piecewise cons

11、tant variable bit rate (VBR) MPEG-2 Transport Streams over IP networks, either with or without Forward Error Correction for recovery from network transmission errors. A non-piecewise constant VBR transport stream has no predictable time base to reconstruct the signal if the inter-packet timing is al

12、tered in transit through the network. This standard defines two methods to maintain the inter-packet timing through the non-synchronous IP network transport. This standard covers the encapsulation and transmission of MPEG-2 transport streams but does not cover other processes such as MPEG-2 encoding

13、 or multiplexing. The scope of this standard is shown in Figure 1. below. Figure 1 SMPTE ST 2022-4 Scope Boundaries 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“. I

14、nformative 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 is, by default, normative, except: the I

15、ntroduction, 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 permitted. The keywords, “should“ and “s

16、hould 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 possibility or course of action is deprec

17、ated but not prohibited. Multiplexer ASI Transmitter Multiplexer Other 2022-4 sender may be part of a device with associated functions 2022-4 does not apply to the functions of the associated device Sender Receiver Decoder 2022-4 receiver may be part of a device with associated functions ASI Receive

18、r Encoder Other SMPTE ST 2022-4:2011 Page 4 of 9 pages 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 future. The k

19、eyword “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“) as descr

20、ibed. 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 authoritative defini

21、tion; 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 2022-1:2007) although, during a transitional phase, the docu

22、ment as published (printed or PDF) may bear an older designation (such as SMPTE 2022-1-2007). Documents with the same root number (e.g. 2022-1) and publication year (e.g. 2007) are functionally identical. The following standards contain provisions which, through reference in this text, constitute pr

23、ovisions 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 standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated b

24、elow. IETF RFC 3550 RTP: A Transport Protocol for Real Time Applications ISO/IEC 13818-1:2007 Generic coding of moving pictures and associated audio information: Systems SMPTE ST 2022-1:2007, Forward Error Correction for Real-time Video/Audio Transport Over IP Networks SMPTE ST 2022-2:2007, Unidirec

25、tional Transport of Constant Bit Rate MPEG-2 Transport Streams on IP Networks SMPTE ST 2022-3:2010, Unidirectional Transport of Variable Bit Rate MPEG-2 Transport Streams on IP Networks 4 Acronyms (Informative) CBR: Constant Bit Rate FEC: Forward Error Correction IP: Internet Protocol PCR: Program C

26、lock Reference RTP: Real Time Protocol TS: Transport Stream VBR: Variable Bit Rate SMPTE ST 2022-4:2011 Page 5 of 9 pages 5 Definitions (Normative) CBR Transport Stream: An MPEG-2 compliant Transport Stream which is constructed such that the rate of departure of packets from a sender is constant ove

27、r time. Contribution Services: Unidirectional transmission of high quality media content to a media processing facility. These services require high quality transmission such that the signal maintains sufficient quality to support further processing prior to final distribution. Distribution Services

28、: Unidirectional transmission of media content from a media processing facility. These services require robust transmission such that the signal is reliably delivered from one originator to potentially many destinations. Media Datagram: An RTP Datagram consisting of a header and data payload compose

29、d of an integer number of MPEG-2 TS packets Null Packet: An MPEG-2 Transport Stream packet consisting of a PID value of 0x1FFF and an undefined payload. Piecewise Constant: A VBR transport stream that can change rate at packets containing PCRs such that the rate of departure of packets from a sender

30、 is constant between successive PCR packets, according to ISO/IEC 13818-1, Section 2.4.2.2. RTP Datagram: An RTP Packet as defined in RFC 3550. TS Packet: An MPEG-2 Transport Stream packet of 188 or 204 bytes in length as defined in ISO/IEC 13818-1. VBR Transport Stream: An MPEG-2 compliant Transpor

31、t Stream such that the rate of departure of packets from a sender is not constant. 6 Transmission Protocols (Normative) 6.1 TS packets per Media Datagram The number of Transport Stream packets per datagram shall not vary throughout the session. This number of Transport Stream packets per Media datag

32、ram is the Packet_per_Datagram_max. The sender shall always include only the Packet_per_Datagram_max MPEG-2 Transport Stream packets per Media datagram. Senders must support the use of 1, 4 and 7 TS packets as Packet_per_Datagram_max. Senders and receivers may use any number of 1-7 Transport Stream

33、packets as the Packet_per_Datagram_max. Whatever number is chosen must remain constant for the duration of a session as defined in Section 6.7 below. This standard is defined for use with only Mode 1 as defined in SMPTE ST 2022-3. Note: Long-length Media datagrams can cause longer latency in buildin

34、g FEC Matrices. A larger number of short Media datagrams results in more network encapsulation overhead, and a subsequent higher bit rate. Therefore, the value chosen for Packet_per_Datagram_max will be a compromise between these factors. FEC datagrams shall always contain Packet_per_Datagram_max tr

35、ansport packets per RTP datagram for a session. SMPTE ST 2022-4:2011 Page 6 of 9 pages 6.2 Signal Time Base Protection and Recovery Note: An MPEG2 Transport Stream is deemed non piecewise constant when the bit rate varies between PCRs. In such conditions, the time base is dependent on the inter-pack

36、et timing of each TS packet. Since IP networks are non-synchronous the timing relationship between packets will be lost in transit. In this case, the inter-packet timing ought to be signaled to the receiver in the data stream. To provide the inter-packet timing data, the payload of each datagram sha

37、ll contain a number of 32-bit data fields equal to the Packet_per_Datagram_Max defined for a session as shown below in Figure 2. An additional 32-bit data field, called the Payload Extension Field, shall also be provided to define the number of additional inter-packet timing data fields (Packet_per_

38、Datagram_Max) and the type of inter-packet timing data contained in these fields. The inter-packet timing data fields shall be called Packet Timing Fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ | IP h

39、eader | | 20 bytes | +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ | UDP header | | 8 bytes | +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ RTP header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+

40、-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTP payload +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.

41、+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ | MPEG-2 TS packets | | 17 x 188/204bytes | +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ |1 0| TDD |PTD #| Reserved | +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ | Packet Timing Data Field | +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.

42、+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ Repeated over the number of TS packets in the datagram +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ | Packet Timing Data Field | +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+ Figure 2 SMPTE ST 2022-4 Data Mapping Format for the

43、 Packet Timing Field 10: Bit positions zero and one of each Packet Timing Field are set to “1” and “0” respectively. This is used to signal the end of TS packets, and that the remaining payload is packet timing data. TDD: Timing Data Descriptor. This is a 3-bit field used to describe the content of

44、the Packet Timing Data Field. The following Table describes the Timing Data Descriptor values for each Packet Timing Data type. SMPTE ST 2022-4:2011 Page 7 of 9 pages 000 Reserved 001 Running TS Packet Counter 010 27MHz Clock Time Stamp 011 Reserved 100 Reserved 101 Reserved 110 Reserved 111 Reserve

45、d PDT #: Packet Timing Data Field Number. This 3-bit field defines the number of Packet Timing Data Fields sent in the datagram. Packet Timing Data Field: A 32-bit field that is used to carry either a 27-MHz TS time stamp or a running TS packet counter. This standard defines two methods of timing re

46、covery signaling. Both methods shall be supported in both sender and receiver implementations. The sender shall provide a 32-bit TS packet counter to support the running TS packet counter timing method. The sender shall provide a 32-bit 27-MHz clock with accuracy of 10 ppm with a maximum drift rate

47、of 22 ppb/sec to support the time stamp timing method. Note: Of the two timing recovery methods defined in this standard, one method could be optimum for CBR input Transport Streams (that exhibit a significant number of null packets); and the other could be optimum for VBR input Transport Streams (f

48、or which specific inter-packet timing information is unknown). However, this standard does not make that distinction. It is left to the sender to determine which method is selected for a specific input signal. This can be either a manual setting or an input signal detection mechanism. It is outside of the scope of this document to define that process. When a session is started, the method of inter-packet timing recovery shall be defined by the setting of the Timing Data Descriptor field. The receiver shall determine the method of inter-packet timing recovery from th