idnits 2.17.1 draft-ietf-avt-smpte292-video-06.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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 175 has weird spacing: '... RTP to accom...' == Line 216 has weird spacing: '... Pixels words...' == Line 256 has weird spacing: '...located paylo...' == Line 267 has weird spacing: '...herwise set t...' == Line 307 has weird spacing: '...ulative numbe...' -- 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 (June 30, 2002) is 7970 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 454 looks like a reference -- Missing reference section? '2-5' on line 143 looks like a reference -- Missing reference section? '6' on line 473 looks like a reference -- Missing reference section? '7' on line 476 looks like a reference -- Missing reference section? '8' on line 479 looks like a reference -- Missing reference section? '9' on line 482 looks like a reference -- Missing reference section? '10' on line 485 looks like a reference -- Missing reference section? '11' on line 488 looks like a reference -- Missing reference section? '12' on line 492 looks like a reference -- Missing reference section? '2' on line 458 looks like a reference -- Missing reference section? '3' on line 462 looks like a reference -- Missing reference section? '4' on line 465 looks like a reference -- Missing reference section? '5' on line 469 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ladan Gharai 2 USC/ISI 3 Colin Perkins 4 USC/ISI 5 Gary Goncher 6 Tektronix 7 Allison Mankin 8 USC/ISI 9 June 30, 2002 11 RTP Payload Format for SMPTE 292M Video 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This memo specifies a RTP payload format for encapsulating uncompressed 38 High Definition Television (HDTV) as defined by the Society of Motion 39 Picture and Television Engineers standard, SMPTE 292M. SMPTE is the main 40 standardizing body in the motion imaging industry and the SMPTE 292M 41 standard defines a bit-serial digital interface for local area HDTV 42 transport. 44 1. Introduction 46 [Note to RFC Editor: All "RFC XXXX" in the IANA considerations section 47 should be filled in with the RFC number of this memo, when published.] 49 The serial digital interface, SMPTE 292M[1], defines a universal medium 50 of interchange for uncompressed High Definition Television (HDTV) 51 between various types of video equipment (cameras, encoders, VTRs, 52 etc.). SMPTE 292M stipulates that the source data be in 10 bit words and 53 the total data rate be 1.485 Gbps or 1.485/1.001 Gbps. 55 The use of a dedicated serial interconnect is appropriate in a studio 56 environment, but it is desirable to leverage the widespread availability 57 of high bandwidth IP connectivity to allow efficient wide area delivery 58 of SMPTE 292M format content. Accordingly, this memo defines an RTP 59 payload format for SMPTE 292M format video. 61 It is to be noted that SMPTE 292M streams have a constant high bit rate 62 and are not congestion controlled. Accordingly, use of this payload 63 format should be tightly controlled and limited to private networks or 64 those networks that provide resource reservation and enhanced quality of 65 service. 67 A SMPTE 292M television line comprises two interleaved streams, one 68 containing the luminance (Y) samples, the other chrominance (CrCb) 69 values. Since chrominance is horizontally sub-sampled (4:2:2 coding) the 70 lengths of the two streams match. Each stream is divided into four 71 parts, (figure 1): (1) start of active video timing reference (SAV); (2) 72 digital active line; (3) end of active video timing reference (EAV); and 73 (4) digital line blanking. A SMPTE 292M line may also carry horizontal 74 ancillary data (H-ANC) or vertical ancillary data (V-ANC) instead of the 75 blanking level, and likewise, ancillary data may transported instead of 76 a digital active line. 78 The EAV and SAV are made up of three 10 bit words, with constant values 79 of 0x000 0x000 0x3FF and an additional word (designated as XYZ in figure 80 2), carrying a number of flags. This includes an F flag which designate 81 which field (1 or 2) the line is transporting and also a V flag which 82 indicates field blanking. Table 1, further displays the code values in 83 SAV and EAV. After EAV, are two words LN1 and LN2 (Table 2), which 84 carry the 11 bit line number for the SMPTE 292M line, immediately 85 following. The Cyclic Redundancy Check, CRC, is a two word value, shown 86 as CR0 and CR1 in figure 2. 88 +------------+-----------------------+-----+---------------------+ 89 | | Digital Line Blanking | | Digital Active Line | 90 | EAV+LN+CRC | (Blanking level or | SAV | (Active Picture or | 91 | | Ancillary Data) | | Ancillary Data) | 92 +------------+-----------------------+-----+---------------------+ 94 Figure 1. The SMPTE 292M line format. 96 0 20 40 60 80 0 20 40 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 98 |3FF| 0 | 0 |XYZ|LN1|LN2|CR0|CR1| |3FF| 0 | 0 |XYZ| 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 100 <---- EAV -----> <- LN-> <- CRC-> <----- SAV -----> 102 Figure 2. Timing reference format. 104 The complete SMPTE 292M stream comprises the sample interleaving of 105 luminance and chrominance streams, including SAV, EAV and the other 106 headers (see Figure 3 of SMPTE 292M [1]). Since the two streams are 107 representing the same video line, their line number, field number and 108 blanking fields will match. 110 +---------------------------------------------------------+ 111 | (MSB) (LSB) | 112 | Word 9 8 7 6 5 4 3 2 1 0 | 113 +---------------------------------------------------------+ 114 | 3FF 1 1 1 1 1 1 1 1 1 1 | 115 | 000 0 0 0 0 0 0 0 0 0 0 | 116 | 000 0 0 0 0 0 0 0 0 0 0 | 117 | XYZ 1 F V H P P P P P P | 118 +---------------------------------------------------------+ 119 | NOTES: | 120 | F=0 during field 1; F=1 during field 2. | 121 | V=0 elsewhere; V=1 during field blanking. | 122 | H=0 in SAV; H=1 in EAV. | 123 | MSB=most significant bit; LSB=least significant bit.| 124 | P= protected bits defined in Table 2 of SMPTE 292M | 125 +---------------------------------------------------------+ 126 Table 1: Timing reference codes. 128 +---------------------------------------------------------+ 129 | (MSB) (LSB) | 130 | Word 9 8 7 6 5 4 3 2 1 0 | 131 +---------------------------------------------------------+ 132 | LN0 R L6 L5 L4 L3 L2 L1 L0 R R | 133 | LN1 R R R R L10 L9 L8 L7 R R | 134 +---------------------------------------------------------+ 135 | NOTES: | 136 | LN0 - L10 - line number in binary code. | 137 | R = reserved, set to "0". | 138 +---------------------------------------------------------+ 139 Table 2: Line number data. 141 The number of words and format for active lines and line blanking is 142 defined by source format documents. Currently, source video formats 143 transfered by SMPTE 292M includes SMPTE 260M, 295M, 274M and 296M[2-5]. 144 In this memo we specify how to transfer SMPTE 292M over RTP, 145 irrespective of the source format. 147 This memo only addresses the transfer of uncompressed HDTV. Compressed 148 HDTV is a subset of MPEG-2 [6], which is fully described in document 149 A/53 [7] of the Advanced Television Standards Committee. The ATSC has 150 also adopted the MPEG-2 transport system (ISO/IEC 13818-1)[8]. 151 Therefore RFC 2250 [9] sufficiently describes transport for compressed 152 HDTV over RTP. 154 2. Conventions Used in this Document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119[10]. 160 3. Payload Design 162 Each SMPTE 292M data line is packetized into one or more RTP packets. 163 This includes all timing signals, blanking levels, active lines and/or 164 ancillary data. Start of active video (SAV) and end of active video 165 (EAV+LN+CRC) signals MUST NOT be fragmented across packets, as the SMPTE 166 292M decoder uses them to detect the start of scan lines. 168 The standard RTP header is followed by a 4 octet payload header. All 169 information in the payload header pertains to the first data sample in 170 the packet. The end of a video frame (the packet containing the last 171 sample before the EAV) is marked by the M bit in the RTP header. 173 The payload header contains a 16 bit extension to the standard 16 bit 174 RTP sequence number, thereby extending the sequence number to 32 bits 175 and enabling RTP to accommodate HDTV's high data rates. At 1.485 Gbps, 176 with packet sizes of at least one thousand octets, 32 bits allows for an 177 approximate 6 hour period before the sequence number wraps around. 179 The payload header also carries the 11 bit line number from the SMPTE 180 292M timing signals. This provides more information at the application 181 level and adds a level of resiliency, in case the packet containing the 182 EAV is lost. 184 A 148.5 MHz (or 148.5/1.001 MHz) time-stamp is used as the RTP 185 timestamp. This allows the receiver to reconstruct the timing of the 186 SMPTE 292M stream, without knowledge of the exact type of source format 187 (e.g. SMPTE 274M or SMPTE 296M). 189 The bit length of both timing signals, SAV and EAV+LN+CRC, are multiples 190 of 8 bits, 40 bits and 80 bits, respectively, and therefore are 191 naturally octet aligned. 193 For the video content it is desirable for the video to both octet align 194 when packetized and also adhere to the principles of application level 195 framing, also known as ALF [11]. For YCrCb video, the ALF principle 196 translates into not fragmenting related luminance and chrominance values 197 across packets. For example with the 4:2:0 color subsampling a 4 pixel 198 group is represented by 6 values, Y1 Y2 Y3 Y4 Cr Cb, and video content 199 should be packetized such that these values are not fragmented across 2 200 packets. However, with 10 bit words this is a 60 bit value which is not 201 octet aligned. To be both octet aligned, and adhere to ALF, an ALF unit 202 must represent 2 groups of 4 Pixels, thereby becoming octet aligned on a 203 15 octet boundary. This length is referred to as the pixel group or 204 pgroup, and it is conveyed in the SDP parameters. Table 3 displays the 205 pgroup value for 4:2:2 and 4:4:4 color samplings. Typical source formats 206 use 4:2:2 sampling, and require a pgroup of 5 octets, other values are 207 included for completeness. 209 The contents of the Digital Active Line SHOULD NOT be fragmented within 210 a pgroup. A pgroup of 1 indicates that data may be split at any octet 211 boundary (this is applicable to instances where the source format is not 212 known). The SAV and EAV+LN+CRC fields MUST NOT be fragmented. 214 +-------------------------------------------------------+ 215 | Color 10 bit | 216 |Subsampling Pixels words aligned on octet# pgroup| 217 +-----------+-------+--------+-------------------+------+ 218 | 4:2:0 | 4 | 6*10 | 2*60/8 = 15 | 15 | 219 +-----------+-------+--------+-------------------+------+ 220 | 4:2:2 | 2 | 4*10 | 40/8 = 5 | 5 | 221 +-----------+-------+--------+-------------------+------+ 222 | 4:4:4 | 1 | 3*10 | 4*30/8 = 15 | 15 | 223 +-----------+-------+--------+-------------------+------+ 224 Table 3. Color subsampling and pgroups. 226 4. RTP Packetization 228 The standard RTP header is followed by a 4 octet payload header, and the 229 payload data, as shown in Figure 4. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | V |P|X| CC |M| PT | sequence# (low bits) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | time stamp | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | ssrc | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | sequence# (high bits) |F|V| Z | line no | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 : SMPTE 292M data : 244 : : 245 | | 246 +---------------------------------------------------------------+ 247 Figure 4: RTP Packet showing SMPTE 292M headers and payload 249 4.1. The RTP Header 251 The following fields of the RTP fixed header are used for SMPTE 292M 252 encapsulation (the other fields in the RTP header are used in their 253 usual manner): 255 Payload Type (PT): 7 bits 256 A dynamically allocated payload type field which designates the 257 payload as SMPTE 292M. 259 Timestamp: 32 bits 260 For a SMPTE 292M transport stream at 1.485 Gbps (or 1.485/1.001 261 Gbps), the timestamp field contains a 148.5 MHz (or 148.5/1.001 262 MHz) timestamp, respectively. This allows for a unique timestamp 263 for each 10 bit word. 265 Marker bit (M): 1 bit 266 The Marker bit denotes the end of a video frame, and is set to 1 267 for the last packet of the video frame and is otherwise set to 0 268 for all other packets. 270 Sequence Number (low bits): 16 bits 271 The low order bits for RTP sequence counter. The standard 16 bit 272 RTP sequence number is augmented with another 16 bits in the 273 payload header in order to accommodate the 1.485 Gbps data rate of 274 SMPTE 292M. 276 4.2. Payload Header 278 Sequence Number (high bits): 16 bits 279 The high order bits for the 32 bit RTP sequence counter, in network 280 byte order. 282 F: 1 bit 283 The F bit as defined in the SMPTE 292M timing signals (see 284 Table 1). F=1 identifies field 2 and F=0 identifies field 1. 286 V: 1 bit 287 The V bit as defined in the SMPTE 292M timing signals (see 288 Table 1). V=1 during field blanking, and V=0 else where. 290 Z: 2 bits 291 SHOULD be set to zero by the sender and MUST be ignored by 292 receivers. 294 Line No: 11 bits 295 The line number of the source data format, extracted from the 296 SMPTE 292M stream (see Table 2). The line number MUST correspond 297 to the line number of the first 10 bit word in the packet. 299 5. RTCP Considerations 301 RFC1889 recommends transmission of RTCP packets every 5 seconds or at a 302 reduced minimum in seconds of 360 divided by the session bandwidth in 303 kilo bits/seconds. At 1.485 Gbps the reduced minimum interval computes 304 to 0.2ms or 4028 packets per second. 306 It should be noted that the sender's octet count in SR packets wraps 307 around in 23 seconds, and that the cumulative number of packets lost 308 wraps around in 93 seconds. This means these two fields cannot 309 accurately represent octet count and number of packets lost since the 310 beginning of transmission, as defined in RFC1889. Therefore for network 311 monitoring purposes other means of keeping track of these variables 312 should be used. 314 6. IANA Considerations 316 This document defines a new RTP payload format and associated MIME type, 317 SMPTE292M. The MIME registration form for SMPTE 292M video is enclosed 318 below: 320 MIME media type name: video 322 MIME subtype name: SMPTE292M 324 Required parameters: rate 325 The RTP timestamp clock rate. The clock runs at either 148500000 Hz 326 or 148500000/1.001 Hz. If the latter rate is used a timestamp of 327 148351000 MUST be used, and receivers MUST interpret this as 328 148500000/1.001 Hz. 330 Optional parameters: pgroup 331 The RECOMMENDED grouping for aligning 10 bit words and octets. 332 Defaults to 1 octet, if not present. 334 Encoding considerations: SMPTE292M video can be transmitted with 335 RTP as specified in RFC XXXX. 337 Security considerations: see RFC XXXX section 8. 339 Interoperability considerations: NONE 341 Published specification: SMPTE292M 342 RFC XXXX 344 Applications which use this media type: 345 Video communication. 347 Additional information: None 349 Magic number(s): None 351 File extension(s): None 353 Macintosh File Type Code(s): None 355 Person & email address to contact for further information: 356 Ladan Gharai 357 IETF AVT working group. 359 Intended usage: COMMON 361 Author/Change controller: 362 Ladan Gharai 364 7. Mapping to SDP Parameters 366 Parameters are mapped to SDP [12] as follows: 368 m=video 30000 RTP/AVP 111 369 a=rtpmap:111 SMPTE292M/148500000 370 a=fmtp:111 pgroup=5 372 In this example, a dynamic payload type 111 is used for SMPTE292M. The 373 RTP timestamp is 148500000 Hz and the SDP parameter pgroup, indicates 374 that for video data after the SAV signal, must be packetized in 375 multiples of 5 octets. 377 8. Security Considerations 379 RTP packets using the payload format defined in this specification are 380 subject to the security considerations discussed in the RTP 381 specification, and any appropriate RTP profile. This implies that 382 confidentiality of the media streams is achieved by encryption. 384 This payload type does not exhibit any significant non-uniformity in the 385 receiver side computational complexity for packet processing to cause a 386 potential denial-of-service threat. 388 It is perhaps to be noted that the bandwidth of this payload is high 389 enough (1.485 Gbps without the RTP overhead) to cause potential for 390 denial-of-service if transmitted onto most currently available Internet 391 paths. In the absence from the standards track of a suitable congestion 392 control mechanism for flows of this sort, use of the payload should be 393 narrowly limited to suitably connected network endpoints, or to networks 394 where QoS guarantees are available, and great care taken with the scope 395 of multicast transmissions. This potential threat is common to all high 396 bit rate applications without congestion control. 398 9. Full Copyright Statement 400 Copyright (C) The Internet Society (2002). All Rights Reserved. 402 This document and translations of it may be copied and furnished to 403 others, and derivative works that comment on or otherwise explain it or 404 assist in its implementation may be prepared, copied, published and 405 distributed, in whole or in part, without restriction of any kind, 406 provided that the above copyright notice and this paragraph are included 407 on all such copies and derivative works. 409 However, this document itself may not be modified in any way, such as by 410 removing the copyright notice or references to the Internet Society or 411 other Internet organizations, except as needed for the purpose of 412 developing Internet standards in which case the procedures for 413 copyrights defined in the Internet Standards process must be followed, 414 or as required to translate it into languages other than English. 416 The limited permissions granted above are perpetual and will not be 417 revoked by the Internet Society or its successors or assigns. 419 This document and the information contained herein is provided on an "AS 420 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 421 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 422 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 423 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 424 FITNESS FOR A PARTICULAR PURPOSE." 426 10. Authors' Addresses 428 Ladan Gharai 429 ladan@isi.edu 431 Colin Perkins 432 csp@isi.edu 434 Allison Mankin 435 mankin@isi.edu 436 USC Information Sciences Institute 437 3811 N. Fairfax Drive 438 Arlington, VA 22203-1695 440 Gary Goncher 441 ggoncher@tek.com 442 Tektronix, Inc. 443 P.O. Box 500, M/S 50-480 444 Beaverton, OR 97077 446 11. Acknowledgment 448 We would like to thank David Richardson for his insightful comments and 449 contributions to the draft. We would also like to thank Chuck Harrison 450 for his input and for explaining the intricases of SMPTE 292M. 452 12. Bibliography 454 [1] Society of Motion Picture and Television Engineers, 455 Bit-Serial Digital Interface for High-Definition Television 456 Systems, SMPTE 292M-1998. 458 [2] Society of Motion Picture and Television Engineers, 459 Digital Representation and Bit-Parallel Interface - 1125/60 460 High-Definition Production System, SMPTE 260M-1999. 462 [3] Society of Motion Picture and Television Engineers, 463 1920x1080 50Hz, Scanning and Interface, SMPTE 295M-1997. 465 [4] Society of Motion Picture and Television Engineers, 466 1920x1080 Scanning and Analog and Parallel Digital Interfaces 467 for Multiple Picture Rates, SMPTE 274M-1998. 469 [5] Society of Motion Picture and Television Engineers, 470 1280x720 Scanning, Analog and Digital Representation and Analog 471 Interfaces, SMPTE 296M-1998. 473 [6] ISO/IEC International Standard 13818-2; "Generic coding of 474 moving pictures and associated audio information: Video", 1996. 476 [7] ATSC Digital Television Standard Document A/53, September 1995, 477 http://www.atsc.org 479 [8] ISO/IEC International Standard 13818-1; "Generic coding of 480 moving pictures and associated audio information: Systems",1996. 482 [9] Hoffman, Fernando, Goyal, Civanlar, "RTP Payload Format for 483 MPEG1/MPEG2 Video", RFC 2250, IETF, January 1998. 485 [10] S. Bradner, "Key words for use in RFCs to Indicate 486 Requirement Levels", RFC 2119. 488 [11] Clark, D. D., and Tennenhouse, D. L., "Architectural Considerations 489 for a New Generation of Protocols", In Proceedings of SIGCOMM '90 490 (Philadelphia, PA, Sept. 1990), ACM. 492 [12] M. Handley and V. Jacobson, "SDP: Session Description Protocol", 493 RFC 2327, April 1998.