SMPTE RDD 40-2016 Essence-independent IP Live Networked Media Transport.pdf

1、 The attached document is a 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 consistent.

2、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 document, i

3、ncluding 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: Toshiaki Kojima Sony Corporation 4-14-1 Asahi-cho, Atsugi Kanagawa, 243-0014 Japan Email: Toshiak

4、i.K Page 1 of 22 pages SMPTE RDD 40:2016 SMPTE REGISTERED DISCLOSURE DOCUMENT Essence-independent IP Live Networked Media Transport Copyright 2016 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved October 11, 2016 SMPTE RDD 40:2

5、016 Page 2 of 22 pages Table of Contents Page Introduction 3 1 Scope 3 2 Normative Reference 4 3 Overview of the IP Mapping . 5 4 Structure of the IP Mapping 6 4.1 Essence Header . 7 4.2 Common Header 8 4.3 RTP Header 10 5 FEC Creation 11 5.1 XOR Based FEC 11 5.2 RS Based FEC . 12 6 Essence Payload

6、Packing 13 6.1 Video Payload Packing 13 6.1.1 YCBCR 4:2:2 10-bit 13 6.1.2 RGB 4:4:4 10-bit . 13 6.1.3 RGB 4:4:4 12-bit . 14 6.1.4 Compressed Video 14 6.1.5 Supported Video Formats . 15 6.2 Audio Payload Packing 16 6.2.1 Audio Group Information . 16 6.2.2 24-bit Audio Packing . 16 6.2.3 20-bit Audio

7、Packing . 18 6.3 Ancillary Payload Packing 20 7 Essence Synchronization . 22 8 Hitless Failover . 22 SMPTE RDD 40:2016 Page 3 of 22 pages Introduction Although network systems have become common in file-based applications, until recently it has been difficult to apply networking technologies to live

8、 production applications in which there is a strong requirement for real-time processing. However, with the continuing rapid evolution of networking technologies, there is now a trend towards the use of networked systems for live production applications. This RDD describes an IP-based transport mech

9、anism (referred to hereafter as IP mapping) intended mainly for live production applications. 1 Scope This RDD defines the IP mapping which includes the following main characteristics: 1. Essence-independent mapping Each essence (video, audio and ancillary data) can be dealt with independently. 2. P

10、acket protection using FEC and/or hitless failover Appropriate protection can be chosen according to application requirements. 3. Frame-boundary-aware mapping for both essence and FEC Frame accurate processing can be performed in both essence and FEC. 4. Support for up to 4K uncompressed and compres

11、sed video Either uncompressed video or compressed video can be chosen up to 4K video seamlessly according to application requirements. SMPTE RDD 40:2016 Page 4 of 22 pages 2 Normative References IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications IETF RFC 3551, RTP Profile for Audio

12、and Video Conferences with Minimal Control SMPTE RDD 34:2015, LLVC Low Latency Video Codec for Network Transfer SMPTE ST 125:2013, SDTV Component Video Signal Coding 4:4:4 and 4:2:2 for 13.5 MHz and 18 MHz Systems SMPTE ST 272:2004, Television Formatting AES Audio and Auxiliary Data into Digital Vid

13、eo Ancillary Data Space SMPTE ST 274:2008, Television 1920 1080 Image Sample Structure, Digital Representation and Digital Timing Reference Sequences for Multiple Picture Rates SMPTE ST 291-1:2011, Ancillary Data Packet and Space Formatting SMPTE ST 296:2012, 1280 720 Progressive Image 4:2:2 and 4:4

14、4 Sample Structure Analog and Digital Representation and Analog Interface SMPTE ST 299-1:2009, 24-Bit Digital Audio Format for SMPTE 292 Bit-Serial Interface SMPTE ST 424:2012, 3 Gb/s Signal/Data Serial Interface SMPTE ST 425-1:2014, Source Image Format and Ancillary Data Mapping for the 3 Gb/s Ser

15、ial Interface SMPTE ST 425-3:2015, Image Format and Ancillary Data Mapping for the Dual Link 3 Gb/s Serial Interface SMPTE ST 425-5:2015, Image Format and Ancillary Data Mapping for the Quad Link 3 Gb/s Serial Interface SMPTE ST 2022-5:2013, Forward Error Correction for High Bit Rate Media Transport

16、 Over IP Networks (HBRMT) SMPTE ST 2036-1:2014, Ultra High Definition Television Image Parameter Values for Program Production SMPTE ST 2048-1:2011, 2048 1080 and 4096 2160 Digital Cinematography Production Image Formats FS/709 SMPTE ST 2059-1:2015, Generation and Alignment of Interface Signals to t

17、he SMPTE Epoch SMPTE RDD 40:2016 Page 5 of 22 pages 3 Overview of the IP Mapping Figure 1 gives an overview of the IP mapping which consists mainly of the following four processes: 1. De-multiplexing In the case of an SDI input signal it is first de-serialized and de-multiplexed in order to extract

18、each essence (video, audio and ancillary data). This process is out of scope of this document. 2. Essence RTP Packing Each essence is independently mapped as an Essence payload in conjunction with an Essence header, followed by Transport headers added to complete the Essence datagrams. The Transport

19、 headers include Common and RTP (Real Time Protocol, RFC 3550) headers. In order to generate Essence and Common headers, information obtained through the FEC creation process is required (see Section 5). If compressed video is preferred, the input video signal shall be compressed before entering the

20、 Essence Payload Packing module. LLVC described in SMPTE RDD 34 is defined as the primary video codec. 3. FEC RTP Packing FEC shall be used in this mapping. FEC creation is performed based on the data from the Essence payloads. Common and RTP headers are added to complete the FEC RTP datagrams. 4. N

21、etwork Transmission Processing Network (UDP, IP and Ethernet) headers are added to all Essence and FEC RTP datagrams and output as network datagrams. This process is out of scope of this document. Figure 1 Overview of the IP Mapping SMPTE RDD 40:2016 Page 6 of 22 pages 4 Structure of the IP Mapping

22、Figure 2 and Figure 3 show the structure of the Essence Datagram and FEC Datagram respectively. Because all required information for dealing with Essence and FEC datagrams is included in the Essence header and the Common header, all datagrams have the same destination IP address and UDP port number.

23、 In other words, all datagrams are transported as a single stream. The FEC Payload shall be 1,382 bytes as the FEC creation is applied to the Essence Payload which consists of Essence Header (4 bytes) and Essence (1378 bytes). Figure 2 Structure of Essence Datagram Figure 3 Structure of FEC Datagram

24、 SMPTE RDD 40:2016 Page 7 of 22 pages 4.1 Essence Header Figure 4 defines the Essence header. Detailed information on each field is specified in Table 1. Figure 4 Definition of Essence Header Table 1 Essence Header Fields Description Field Name Size (bit) Description PT Payload Type 2 Shall be set a

25、ccording to the essence type of the payload. 0: Video, 1: Audio, 2: Ancillary data, 3: Reserved Payload Length 14 Active essence size of the media payload in octets. S V Start 1 For the first datagram of a video frame (field in the case of interlace) of each essence type: Shall be set to 1. For othe

26、r Essence datagrams: Shall be set to 0. E V End 1 For the last datagram of a video frame (field in the case of interlace) of each essence type: Shall be set to 1. For other Essence datagrams: Shall be set to 0. FC Frame Count 7 All input A/V signals shall be synchronized so that if Frame Count is ad

27、ded to the mapped input A/V signals (Essence datagrams) at a sender, it can be used for synchronizing datagrams at a receiver. The initial value shall be set to the specific value such that Frame Count is 0 at the Epoch defined in SMPTE ST 2059-1. The value shall be incremented by one when a new vid

28、eo frame starts. When a video stream is not present, Frame Count shall be incremented at intervals corresponding to the system frame rate chosen by the user. The same value shall be set for all related Essence datagrams. Range of value is from 0 to 127, and when the value reaches its maximum, the co

29、unt shall rollover and start again at 0. F Field Flag 1 Shall be set as follows: 0: Field 0 1: Field 1 Shall be set to 0 for all datagrams of progressive format. C Compression 1 Shall be set as follows: 0: Uncompressed video 1: Compressed video G Forced End FlaG 1 For the datagrams which contain inv

30、alid Essence data e.g. adding zero padding: Shall be set to 1 For all other datagrams: Shall be 0. RSV Reserved 4 Reserved for future use. Shall be set to 0. This field shall be ignored by receivers. SMPTE RDD 40:2016 Page 8 of 22 pages 4.2 Common Header Figure 5 defines the Common header. Detailed

31、information on each field is specified in Table 2. Figure 5 Definition of the Common Header Table 2 Common Header Fields Description Field Name Size (bit) Description FC Frame Count 7 Shall be set to the same value as that of the corresponding Essence header. Because the Common header is outside of

32、the FEC process, this value can be used before FEC decoding. This enables pre-processes such as clean switching at RTP datagram level. Validity can be checked against the same value from the Essence header with FEC. This value is unique in a single FEC Block. For FEC datagrams, it shall also be set

33、to the same value as that of the corresponding Essence datagrams belonging to the same FEC Block. F Field Flag 1 Shall be set to the same value as that of the corresponding Essence header. Because the Common header is outside of the FEC process, this value can be used before FEC decoding. This enabl

34、es pre-processes such as clean switching at RTP datagram level. Validity can be checked against the same value from the Essence header with FEC. This value is unique in a single Block. FEC datagrams shall also be set to the same value as that of the corresponding Essence datagrams belonging to the s

35、ame FEC Block. FT FEC Type 2 Shall be set to 0. This field indicates the FEC type being used. 0: XOR based 1: Reed-Solomon based 2: Reserved 3: Reserved ST Stream Type 2 Reserved for future use. Shall be set to 0. This field shall be ignored by receivers. DT Datagram Type 2 Type of datagram. 0: Esse

36、nce datagram 1: Row FEC datagram 2: Column FEC datagram 3: Reserved. B FEC Block Last 1 Shall be set to 1 for the last Essence datagram, the last Column FEC datagram and the last Row FEC datagram of every FEC Block transmission. For other datagrams, shall be set to 0. M Transfer Mode 1 Reserved for

37、future use. Shall be set to 0. This field shall be ignored by receivers. SMPTE RDD 40:2016 Page 9 of 22 pages SN Sequence Number 16 Shall be set in each category separately, namely video Essence, audio Essence, ancillary data Essence, Column FEC and Row FEC datagrams. Shall be incremented by one in

38、each transmission of the same category and shall be sequential across FEC Blocks. Initial value should be set randomly. When this value reaches its maximum, the count shall rollover and start again at 0. T FEC Block Top Flag 1 Shall be set to 1 for all Essence and FEC datagram of the first block of

39、a video frame (field in the case of interlace). All other FEC blocks of the video frame (field in the case of interlace) shall be set to 0. RSV Reserved 7 Reserved for future use. Shall be set to 0. This field shall be ignored by receivers. - L Max 4 L value of the LxD Basic FEC Block Size for XOR.

40、It shall never be changed during the RTP session regardless of the actual size. - D Max 4 D value of the LxD Basic FEC Block Size for XOR. It shall never be changed during the RTP session regardless of the actual size. - L Count 4 Row number of the Essence or FEC datagrams (from 0 to L). - D Count 4

41、 Column number of the Essence or FEC datagram (from 0 to D). BLK_ID FEC Block ID 8 Shall be set to a unique number for each FEC Block. Same number shall be set for all Essence and FEC datagrams in the same FEC Block. Shall be incremented by one in each transmission. Initial value should be set arbit

42、rarily. When this value reaches its maximum, the count shall rollover and start again at 0. SMPTE RDD 40:2016 Page 10 of 22 pages 4.3 RTP header The IP Mapping adopts the RTP header specified in RFC 3550. The definition of the RTP header is shown in Figure 6. All fields in the RTP header shall be se

43、t according to RFC 3550. Table 3 clarifies the value of each field. Figure 6 Definition of RTP Header Table 3 RTP Header Fields Description Field Name Size (bit) Description V Version 2 Shall be set to 2 P Padding 1 Shall be set to 0. X Extension 1 Shall be set to 0 CC CSRC Count 4 Shall be set to 0

44、 Note: There are no CSRC lists in Essence and FEC Datagrams. M Marker 1 For the last Essence datagram of video frame (field in the case of interlace): Shall be set to 1. For other Essence and all FEC datagrams: Shall be set to 0. As this field is not used for FEC datagrams, in the case of FEC datag

45、rams transmitters are recommended to set to 0 and receivers shall ignore the field. This field is used to detect the frame (field in the case of interlace) boundary of only Essence datagrams. Frame Count in both Common and Essence headers should be used for all datagrams rather than referring to thi

46、s value. PT Payload Type 7 Shall be set to 110 at the start of transmission. Alternatively, this field may be set by other means in accordance with RFC 3550/3551. This field shall not be changed during the RTP session. SN Sequence Number 16 Shall be increment by one in each transmission. Initial val

47、ue should be set randomly as stated in RFC 3550. When the value reaches its maximum, the count shall rollover and start again at 0. TS Timestamp 32 The value of Timestamp shall be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations

48、 This value is not used in the IP mapping. SSRC Synchronization Source 32 Should be set randomly as stated in RFC 3550. The value shall not be changed during the RTP session. SMPTE RDD 40:2016 Page 11 of 22 pages 5 FEC Creation As described in Section 3, using FEC is mandatory in this mapping. The

49、FEC creation process is described first because information obtained through the FEC creation is required to generate both the Essence header and Common header. One of two FEC mechanisms can be chosen in the IP Mapping, XOR or Reed-Solomon (RS). The RS based FEC shall be used for low bit rate Essence RTP datagrams (less than or equal to 500Mbps) while the XOR based FEC shall be used for high bit rate Essence RTP datagrams (greater than 500Mbps). 5.1 XOR B