idnits 2.17.1 draft-ietf-avt-smpte292-video-00.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 6 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 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 119 has weird spacing: '...located paylo...' == Line 140 has weird spacing: '...herwise set t...' == Line 168 has weird spacing: '...where the fir...' -- 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 (July 13, 2000) is 8693 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 268 looks like a reference -- Missing reference section? '3' on line 276 looks like a reference -- Missing reference section? '4' on line 279 looks like a reference -- Missing reference section? '5' on line 282 looks like a reference -- Missing reference section? '7' on line 289 looks like a reference -- Missing reference section? '2' on line 272 looks like a reference -- Missing reference section? '6' on line 285 looks like a reference -- Missing reference section? '8' on line 292 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 10 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 David Richardson 7 University of Washington 8 Allison Mankin 9 USC/ISI 10 July 13, 2000 12 RTP Payload Format for SMPTE 292M 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document specifies a packetization scheme for encapsulating 39 uncompressed HDTV as defined by SMPTE 292M [1] into a payload format for 40 the Real-Time Transport Protocol (RTP). The RTP packet counter is 41 extended to 26 bits to accommodate SMPTE 292M's 1.485Gb/s data rate, and 42 additional positioning information is added to the payload header. 44 1. Introduction 46 The serial digital interface, SMPTE 292M, defines a universal medium of 47 interchange for uncompressed HDTV between various types of video 48 equipment (camera's, encoders, VTRs, ...) at data rates of 1.485Gb/s 49 (and 1.485/1.001 Gb/s). Source data are 10-bit words, sampled at 4:2:2. 50 In this draft we specify how to transfer SMPTE 292M over RTP. 52 2. A Note on Compressed HDTV over RTP 54 HDTV is compressed using a subset of MPEG-2 [3] as its compression 55 scheme. This subset is fully described in document A/53 [4] of the 56 Advanced Television Standards Committee. The ATSC has also adopted the 57 MPEG-2 transport system (ISO/IEC 13818-1) [5]. Therefore: 59 1. The HDTV transport system is a compatible subset of the MPEG-2 60 transport system. Section 2 of RFC 2250 [7] describes the RTP payload 61 for MPEG-2's transport system, where multiple fixed length (188 bytes) 62 MTS packets are aggregated into a single RTP packet. 64 2. Compressed HDTV is a subset of MPEG-2 MP@HL with some additional 65 restrictions. Section 3 of RFC 2250 describes a packetization scheme for 66 MPEG-2 elementary streams. The additional restrictions of HDTV do not 67 have any implications for RTP packetization. 69 3. Payload Design 71 Each video frame of SMPTE292M in packetized into a number of variable 72 size RTP packets. All active, vertical blanking and timing information 73 is packetized. The end of a frame is marked by the M bit in the RTP 74 header. A single packet may contain data for two consecutive scan 75 lines. The SMPTE292M decoder uses the sync info in the scan lines to 76 detect the start of scan lines. 78 A single packet may also contain information from adjacent scan lines in 79 two consecutive frames, or by agreement between sender and receiver the 80 last packet of a video frame may be padded and the the new frame start 81 in a new packet. 83 The standard 16 bit RTP sequence counter is extended to 26 bits to 84 accommodate HDTV's high data rates. At 1.485Gb/s, with packet sizes of 85 at least 1k, 26bits allows for 5minute period before the sequence 86 counter wraps around. 88 The payload header includes the offset of the payload data in the video 89 frame. The offset is for 20-bit video words and accounts for active and 90 inactive samples. 92 Given SMPTE292M's 4:2:2 color subsampling, scan line fragmentation must 93 occur on sample-pair boundaries, such that Y and Cb and Cr values are 94 not split across packets. 96 4. RTP Packetization 98 The standard RTP header is followed by a 4 byte payload header, and the 99 payload data. 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | V |P|X| CC |M| PT | sequence# (low bits) | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | time stamp | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 |squence#(high bits)| offset in frame | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 4.1. The RTP Header 115 The following fields of the RTP fixed header are used for SMPTE 292M 116 encapsulation: 118 Payload Type (PT): 7bits 119 A dynamically allocated payload type field which designates the 120 payload as SMPTE 292M. 122 Timestamp: 32 bits 123 The timestamp field shall be defined from a counter at 10 MHz. The 124 timestamp shall be defined as the arrival time of the first 20-bit 125 video sample to be transmitted in the current packet. At an arrival 126 rate of 74.25 MHz for 20-bit 292M video samples with 24/30/60 Hz 127 frame rates, the timestamp will be unique for packets with more 128 than 8 video samples (20 bytes). Timestamps shall increase 129 monotonically until they roll over at 32 bits. 131 The 10 MHz timestamp clock may be obtained from a GPS (Global 132 Positioning System) board. These boards have a disciplined 133 oscillator that is synchronized to GPS time. The disciplined 134 oscillator can be as accurate as 1 in 10-12, but is more typically 135 1 in 10-8. Thus clocks at widely separate locations can be 136 synchronized with an accuracy of 100 ns for video timing recovery. 138 Marker bit (M): 1bit 139 The Marker bit denotes the end of a video frame, and is set to 1 140 for the last packet of the video frame and is otherwise set to 0 141 for all other packets. 143 Sequence Number (low bits): 16 bits 144 The low order bits for RTP sequence counter. The standard 16 bit 145 RTP sequence number is augmented by 10 bits in the payload header 146 in order to accommodate the 1.485Gb/s data rate of SMPTE292M. 148 4.2. Payload Header 150 Sequence Number (high bits): 10bits 151 The high order bits for the 26bit RTP sequence counter. 153 Offset in Frame: 22bits 154 An offset for the position of 20-bit video words in the video 155 frame. The offset includes all information in the video frame and 156 scan lines. Range of values are: 157 1. 0 to 1125*2750-1 for 1080/24p. 158 2. 0 to 1125*2200-1 for 1080/30i. 159 3. 0 to 750*1650-1 for 720/60p. 161 5. Payload Format 163 For 4:2:2 color subsampling Cb and Cr values are subsampled by a factor 164 of two horizontally and are co-sited with even numbered Y samples. 165 Therefore, Cb, Cr and Y samples must be arranged and transmitted in the 166 following order: 167 Cb, Y, Cr, Y, Cb, Y, Cr, ... 168 where the first Cb, Y, Cr sequence refers to co-sited luminance and 169 color-difference samples, and the next Y belongs to the next luminance 170 sample. 172 Therefore, as set forth in RFC2431, for 10-bit words, each group of four 173 samples must be encoded into a 40-bit word (five octets) prior to 174 transmission. The following is a representation of a 720 sample packet 175 with 10-bit quantization: 177 0 1 2 3 178 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 179 +---------+---------+---------+---------+ 180 | Cb0 | Y0 | Cr0 | Y1 | 181 +---------+---------+---------+---------+ 182 | Cb1 | Y2 | Cr1 | Y3 | 183 +---------+---------+---------+---------+ 184 . 185 . 186 . 187 +---------+---------+---------+---------+ 188 | Cb359 | Y718 | Cr359 | Y719 | 189 +---------+---------+---------+---------+ 190 (Note that the word width is 40 bits) 191 +-------+-------+-------+-------+-------+ 192 Octets: | 0 | 1 | 2 | 3 | 4 | 193 +-------+-------+-------+-------+-------+ 195 The octets shown in these diagrams are transmitted in network bit and 196 byte order, that is, left-to-right as shown. 198 6. Security Considerations 200 RTP packets using the payload format defined in this specification are 201 subject to the security considerations discussed in the RTP 202 specification [4], and any appropriate RTP profile. This implies that 203 confidentiality of the media streams is achieved by encryption. Because 204 the data compression used with this payload format is applied end-to- 205 end, encryption may be performed after compression so there is no 206 conflict between the two operations. 208 This payload type does not exhibit any significant non-uniformity in the 209 receiver side computational complexity for packet processing to cause a 210 potential denial-of-service threat. 212 It is perhaps to be noted that the bandwidth of this payload is high 213 enough (1.5 Gbps without the RTP overhead) to cause potential for 214 denial-of-service if transmitted onto most currently available Internet 215 paths. In the absence from the standards track of a suitable congestion 216 control mechanism for flows of this sort, use of the payload should be 217 narrowly limited to suitably connected network endpoints and great care 218 taken with the scope of multicast transmissions. This potential threat 219 is common to all high bit rate applications. 221 7. IANA Considerations 223 [To be done] 225 8. Full Copyright Statement 227 Copyright (C) The Internet Society (1999). All Rights Reserved. 229 This document and translations of it may be copied and furnished to 230 others, and derivative works that comment on or otherwise explain it or 231 assist in its implementation may be prepared, copied, published and 232 distributed, in whole or in part, without restriction of any kind, 233 provided that the above copyright notice and this paragraph are included 234 on all such copies and derivative works. 236 However, this document itself may not be modified in any way, such as by 237 removing the copyright notice or references to the Internet Soci- ety or 238 other Internet organizations, except as needed for the purpose of 239 developing Internet standards in which case the procedures for 240 copyrights defined in the Internet Standards process must be fol- lowed, 241 or as required to translate it into languages other than English. 243 The limited permissions granted above are perpetual and will not be 244 revoked by the Internet Society or its successors or assigns. 246 This document and the information contained herein is provided on an "AS 247 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 248 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 249 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 250 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR 251 FITNESS FOR A PARTICULAR PURPOSE." 253 9. Authors' Addresses 255 Ladan Gharai 256 ladan@isi.edu 258 Gary Goncher 259 ggoncher@tek.com 260 Allison Mankin 261 mankin@isi.edu 263 David Richardson 264 drr@u.washington.edu 266 10. Bibliography 268 [1] Society of Motion Picture and Television Engineers, 269 Bit-Serial Digital Interface for High-Definition Television 270 Systems, SMPTE292M, 1998. 272 [2] Society of Motion Picture and Television Engineers, 273 1280*720 Scanning, Analog and Digital Representation and Analog 274 Interfaces, SMPTE 296M, 1998. 276 [3] ISO/IEC International Standard 13818-2; "Generic coding of 277 moving pictures and associated audio information: Video", 1996. 279 [4] ATSC Digital Television Standard Document A/53, September 1995, 280 http://www.atsc.org 282 [5] ISO/IEC International Standard 13818-1; "Generic coding of 283 moving pictures and associated audio information: Systems",1996. 285 [6] Schulzrinne, Casner, Frederick, Jacobson, "RTP: A transport 286 protocol for real time Applications", RFC 1889, IETF, 287 January 1996. 289 [7] Hoffman, Fernando, Goyal, Civanlar, "RTP Payload Format for 290 MPEG1/MPEG2 Video", RFC 2250, IETF, January 1998. 292 [8] Schulzrinne, "RTP Profile for Audio and Video Conferences with 293 Minimal Control", RFC 1890, IETF, January 1996.