idnits 2.17.1 draft-ietf-avt-smpte292-video-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 89 has weird spacing: '...me will start...' == Line 93 has weird spacing: '... 6 hour perio...' == Line 130 has weird spacing: '...located paylo...' == Line 152 has weird spacing: '...herwise set t...' == Line 177 has weird spacing: '...where the fir...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2001) is 8446 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 357 looks like a reference -- Missing reference section? '2-5' on line 51 looks like a reference -- Missing reference section? '6' on line 376 looks like a reference -- Missing reference section? '7' on line 379 looks like a reference -- Missing reference section? '8' on line 382 looks like a reference -- Missing reference section? '9' on line 385 looks like a reference -- Missing reference section? '10' on line 388 looks like a reference -- Missing reference section? '11' on line 391 looks like a reference -- Missing reference section? '12' on line 394 looks like a reference -- Missing reference section? '2' on line 361 looks like a reference -- Missing reference section? '3' on line 365 looks like a reference -- Missing reference section? '4' on line 368 looks like a reference -- Missing reference section? '5' on line 372 looks like a reference -- Missing reference section? '13' on line 397 looks like a reference -- Missing reference section? '14' on line 401 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Ladan Gharai 3 USC/ISI 4 Gary Goncher 5 Tektronix 6 Colin Perkins 7 USC/ISI 8 David Richardson 9 University of Washington 10 Allison Mankin 11 USC/ISI 12 March 2, 2001 14 RTP Payload Format for SMPTE 292M 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document specifies a packetization scheme for encapsulating 41 uncompressed HDTV as defined by SMPTE 292M into a payload format for 42 the Real-Time Transport Protocol (RTP). The RTP packet counter is 43 extended to 32 bits to accommodate SMPTE 292M's 1.485Gb/s data rate. 45 1. Introduction 47 The serial digital interface, SMPTE 292M[1], defines a universal medium 48 of interchange for uncompressed HDTV between various types of video 49 equipment (camera's, encoders, VTRs, ...) at data rates of 1.485Gb/s 50 (and 1.485/1.001 Gb/s). Source formats transfered by SMPTE 292M are 51 SMPTE 260M, 295M, 274M and 296M[2-5]. Source data for these formats are 52 10-bit words, sampled at 4:2:2. In this memo we specify how to 53 transfer SMPTE 292M over RTP. 55 This memo only addresses the transfer of uncompressed HDTV. Compressed 56 HDTV is a subset of MPEG-2 [6], which is fully described in document 57 A/53 [7] of the Advanced Television Standards Committee. The ATSC has 58 also adopted the MPEG-2 transport system (ISO/IEC 13818-1) [8]. 59 Therefore: 61 1. The HDTV transport system is a compatible subset of the MPEG-2 62 transport system. Section 2 of RFC 2250 [9] describes the RTP payload 63 for MPEG-2's transport system, where multiple fixed length (188 bytes) 64 MTS packets are aggregated into a single RTP packet. 66 2. Compressed HDTV is a subset of MPEG-2 MP@HL with some additional 67 restrictions. Section 3 of RFC 2250 describes a packetization scheme for 68 MPEG-2 elementary streams. The additional restrictions of HDTV do not 69 have any implications for RTP packetization. 71 2. Conventions Used in this Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119[10]. 77 3. Payload Design 79 Each video frame of SMPTE 292M is packetized into a number of constant 80 size RTP packets. All active, vertical blanking and timing information 81 is packetized. The end of a frame is marked by the M bit in the RTP 82 header. A single packet may contain data for two consecutive scan 83 lines. The SMPTE 292M decoder uses the sync info in the scan lines to 84 detect the start of scan lines. 86 A single packet may also contain information from adjacent scan lines in 87 two consecutive frames, or by agreement between sender and receiver the 88 last packet of a video frame may be padded to the full length of all 89 292M RTP packets, in which case a new frame will start in a new packet. 91 The standard 16 bit RTP sequence counter is extended to 32 bits to 92 accommodate HDTV's high data rates. At 1.485Gb/s, with packet sizes of 93 at least 1kByte, 32bits allows for an approximate 6 hour period before 94 the sequence counter wraps around. 96 A 10Mhz timestamp is used as the RTP header's timestamp. This allows the 97 receiver to reconstruct the timing of the SMPTE 292M stream, without 98 knowledge of the exact type of source format (e.g. SMPTE 274M or SMPTE 99 296M). 101 Given SMPTE 292M's 4:2:2 color subsampling, scan line fragmentation MUST 102 occur on sample-pair boundaries, such that Y and Cb and Cr values are 103 not split across packets. This means the payload section of each packet 104 will be a multiple of 40bits. In addition, to ensure unique timestamps, 105 each packet SHOULD contain more than 8 video samples (20 bytes). 107 4. RTP Packetization 109 The standard RTP header is followed by a 4 byte payload header, and the 110 payload data. 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | V |P|X| CC |M| PT | sequence# (low bits) | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | time stamp | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | ssrc | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | sequence# (high bits) | unused | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 4.1. The RTP Header 126 The following fields of the RTP fixed header are used for SMPTE 292M 127 encapsulation: 129 Payload Type (PT): 7bits 130 A dynamically allocated payload type field which designates the 131 payload as SMPTE 292M. 133 Timestamp: 32 bits 134 The timestamp field shall be defined from a counter at 10 MHz. The 135 timestamp shall be defined as the arrival time of the first 20-bit 136 video sample to be transmitted in the current packet. At an arrival 137 rate of 74.25 MHz for 20-bit SMPTE 292M video samples with 138 24/30/60Hz frame rates, the timestamp will be unique for packets 139 with more than 8 video samples (20 bytes) and therefore, each 140 packet SHOULD contain more than 8 samples. Timestamps shall 141 increase monotonically until they roll over at 32 bits. 143 One possible means of deriving the 10 MHz clocks is from a GPS 144 (Global Positioning System) board. These boards have a disciplined 145 oscillator that is synchronized to GPS time. The disciplined 146 oscillator can be as accurate as 1 in 10-12, but is more typically 147 1 in 10-8. Thus clocks at widely separate locations can be 148 synchronized with an accuracy of 100 ns for video timing recovery. 150 Marker bit (M): 1bit 151 The Marker bit denotes the end of a video frame, and is set to 1 152 for the last packet of the video frame and is otherwise set to 0 153 for all other packets. 155 Sequence Number (low bits): 16 bits 156 The low order bits for RTP sequence counter. The standard 16 bit 157 RTP sequence number is augmented with another 16 bits in the 158 payload header in order to accommodate the 1.485Gb/s data rate of 159 SMPTE 292M. 161 4.2. Payload Header 163 Sequence Number (high bits): 16bits 164 The high order bits for the 32bit RTP sequence counter. 166 Unused: 16bits 167 MUST be set to zero at the sender, and ignored at the receiver. 169 4.3. Payload Format 171 For 4:2:2 color subsampling Cb and Cr values are subsampled by a factor 172 of two horizontally and are co-sited with even numbered Y samples. 173 Therefore, Cb, Cr and Y samples MUST be arranged and transmitted in the 174 following order: 176 Cb, Y, Cr, Y, Cb, Y, Cr, ... 177 where the first Cb, Y, Cr sequence refers to co-sited luminance and 178 color-difference samples, and the next Y belongs to the next luminance 179 sample. 181 Therefore, as set forth in RFC2431 [11], for 10-bit words, each group of 182 four samples must be encoded into a 40-bit word (five octets) prior to 183 transmission. The following is a representation of a 720 sample packet 184 with 10-bit quantization: 186 0 1 2 3 187 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 188 +---------+---------+---------+---------+ 189 | Cb0 | Y0 | Cr0 | Y1 | 190 +---------+---------+---------+---------+ 191 | Cb1 | Y2 | Cr1 | Y3 | 192 +---------+---------+---------+---------+ 193 . 194 . 195 . 196 +---------+---------+---------+---------+ 197 | Cb359 | Y718 | Cr359 | Y719 | 198 +---------+---------+---------+---------+ 199 (Note that the word width is 40 bits) 200 +-------+-------+-------+-------+-------+ 201 Octets: | 0 | 1 | 2 | 3 | 4 | 202 +-------+-------+-------+-------+-------+ 204 The octets shown in these diagrams are transmitted in network bit and 205 byte order, that is, left-to-right as shown. 207 5. RTCP Considerations 209 RFC1889 recommends transmission of RTCP packets every 5 seconds or at a 210 reduced minimum in seconds of 360 divided by the session bandwidth in 211 kilobits/seconds. At 1.485Gb/s the reduced minimum interval computes to 212 0.2ms or 4028 packets per second. 214 It should be noted that the sender's octet count in SR packets wraps 215 around in 23 seconds, and that the cumulative number of packets lost 216 wraps around in 93 seconds. This means these two fields cannot 217 accurately represent octet count and number of packets lost since the 218 beginning of transmission, as defined in RFC1889. Therefore for network 219 monitoring purposes other means of keeping track of these variables 220 should be used. 222 6. MIME Registration 224 This document defines a new RTP payload name and associated MIME type, 225 SMPTE292M. The registration forms for MIME type for SMPTE 292M video is 226 enclosed below: 228 MIME media type name: video 230 MIME subtype name: SMPTE292M 232 Required parameters: None 234 Optional parameters: None 236 Encoding considerations: SMPTE292M video can be transmitted with 237 RTP as specified in "draft-ietf-avt-smpte292-video-02". 239 Security considerations: None 241 Interoperability considerations: NONE 243 Published specification: SMPTE292M 244 draft-ietf-avt-smpte292-video-02 246 Applications which use this media type: 247 Video communication. 249 Additional information: None 251 Magic number(s): None 253 File extension(s): DV 255 Macintosh File Type Code(s): None 257 Person & email address to contact for further information: 258 Ladan Gharai 260 Intended usage: COMMON 262 Author/Change controller: 263 Ladan Gharai 265 7. Mapping to SDP Parameters 267 Parameters are mapped to SDP [12] as follows: 269 m=video 30000 RTP/AVP 111 270 a=rtpmap:111 SMPTE292M/10000000 271 a=fmtp:111 length=560 273 In this example, a dynamic payload type 111 is assumed for SMPTE292M. 274 The length field indicates the number of video samples in each packet, 275 560, which means the payload length is 1400bytes. 277 8. Security Considerations 279 RTP packets using the payload format defined in this specification are 280 subject to the security considerations discussed in the RTP 281 specification, and any appropriate RTP profile. This implies that 282 confidentiality of the media streams is achieved by encryption. 284 This payload type does not exhibit any significant non-uniformity in the 285 receiver side computational complexity for packet processing to cause a 286 potential denial-of-service threat. 288 It is perhaps to be noted that the bandwidth of this payload is high 289 enough (1.5 Gbps without the RTP overhead) to cause potential for 290 denial-of-service if transmitted onto most currently available Internet 291 paths. In the absence from the standards track of a suitable congestion 292 control mechanism for flows of this sort, use of the payload should be 293 narrowly limited to suitably connected network endpoints and great care 294 taken with the scope of multicast transmissions. This potential threat 295 is common to all high bit rate applications. 297 9. IANA Considerations 299 See section 6. 301 10. Full Copyright Statement 303 Copyright (C) The Internet Society (2000). All Rights Reserved. 305 This document and translations of it may be copied and furnished to 306 others, and derivative works that comment on or otherwise explain it or 307 assist in its implementation may be prepared, copied, published and 308 distributed, in whole or in part, without restriction of any kind, 309 provided that the above copyright notice and this paragraph are included 310 on all such copies and derivative works. 312 However, this document itself may not be modified in any way, such as by 313 removing the copyright notice or references to the Internet Soci- ety or 314 other Internet organizations, except as needed for the purpose of 315 developing Internet standards in which case the procedures for 316 copyrights defined in the Internet Standards process must be fol- lowed, 317 or as required to translate it into languages other than English. 319 The limited permissions granted above are perpetual and will not be 320 revoked by the Internet Society or its successors or assigns. 322 This document and the information contained herein is provided on an "AS 323 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 324 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 325 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 326 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR 327 FITNESS FOR A PARTICULAR PURPOSE." 329 11. Authors' Addresses 331 Ladan Gharai 332 ladan@isi.edu 333 USC/ISI 334 4350 Fairfax Dr 335 Arlington, VA 22203-1695 337 Gary Goncher 338 ggoncher@tek.com 340 Colin Perkins 341 csp@isi.edu 342 USC/ISI 343 4350 Fairfax Dr 344 Arlington, VA 22203-1695 346 David Richardson 347 drr@u.washington.edu 349 Allison Mankin 350 mankin@isi.edu 351 USC/ISI 352 4350 Fairfax Dr 353 Arlington, VA 22203-1695 355 12. Bibliography 357 [1] Society of Motion Picture and Television Engineers, 358 Bit-Serial Digital Interface for High-Definition Television 359 Systems, SMPTE 292M, 1998. 361 [2] Society of Motion Picture and Television Engineers, 362 Digital Representation and Bit-Parallel Interface - 1125/60 363 High-Definition Production System, SMPTE 260M, 1992. 365 [3] Society of Motion Picture and Television Engineers, 366 1920x1080 50Hz, Scanning and Interface, SMPTE 295M, 1997. 368 [4] Society of Motion Picture and Television Engineers, 369 1920x1080 Scanning and Analog and Parallel Digital Interfaces 370 for Multiple Picture Rates, SMPTE 272M. 372 [5] Society of Motion Picture and Television Engineers, 373 1280x720 Scanning, Analog and Digital Representation and Analog 374 Interfaces, SMPTE 296M, 1998. 376 [6] ISO/IEC International Standard 13818-2; "Generic coding of 377 moving pictures and associated audio information: Video", 1996. 379 [7] ATSC Digital Television Standard Document A/53, September 1995, 380 http://www.atsc.org 382 [8] ISO/IEC International Standard 13818-1; "Generic coding of 383 moving pictures and associated audio information: Systems",1996. 385 [9] Hoffman, Fernando, Goyal, Civanlar, "RTP Payload Format for 386 MPEG1/MPEG2 Video", RFC 2250, IETF, January 1998. 388 [10] IETF RFC 2119, "Key words for use in RFCs to Indicate 389 Requirement Levels". 391 [11] D. Tynan, "RTP Payload Format for BT.656 Video Encoding", 392 RFC 2431, October 1998. 394 [12] M. Handley and V. Jacobson, "SDP: Session Description Protocol", 395 RFC 2327, April 1998. 397 [13] Schulzrinne, Casner, Frederick, Jacobson, "RTP: A transport 398 protocol for real time Applications", RFC 1889, IETF, 399 January 1996. 401 [14] Schulzrinne, "RTP Profile for Audio and Video Conferences with 402 Minimal Control", RFC 1890, IETF, January 1996.