INTERNET-DRAFT Ismail Dalgic 3Com Ladan Gharai USC/ISI Allison Mankin USC/ISI David Richardson University of Washington Raymond Yow 3Com March 8, 2000 RTP Payload Format for Uncompressed HDTV Video Streams Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a packetization scheme for encapsulating uncompressed HDTV as defined by SMPTE 274M and SMPTE 296M into a payload format for the Real-Time Transport Protocol (RTP). SMPTE 274M and draft-ietf-gharai-hdtv-video-00.txt [Page 1] INTERNET-DRAFT March 8, 2000 SMPTE 296M define the analog and digital representation of HDTV with image formats of 1920*1080 and 1280*720, respectively. 1. Introduction The analog and digital representation of uncompressed HDTV are specified in SMPTE 274M and SMPTE 296M [1,2]. These standards normatively reference ITU-R BT.709 and follow the parameter values set forth in ITU-R BT.709 for production and international program exchange. SMPTE 274M defines a family of scanning systems with an image format of 1920*1080 with progressive and interlaced scanning, while SMPTE 296M standard defines systems with an image size of 1280*720 and only progressive scanning. Both standards define images with aspect ratios of 16:9, and define the digital representation for RGB and YCbCr components. Both 8-bit and 10-bit quantization is supported. In the case of YCbCr components, Cb and Cr components are subsampled horizontally by a factor of two (4:2:2 color encoding). In this document we specify a packetization scheme for encapsulating the digital representation of uncompressed HDTV as defined by SMPTE 274M and SMPTE 296M into a payload format for RTP. 2. A Note on Compressed HDTV over RTP HDTV is compressed using a subset of MPEG-2 [3] as its compression scheme. This subset is fully described in document A/53 [4] of the Advanced Television Standards Committee. The ATSC has also adopted the MPEG-2 transport system (ISO/IEC 13818-1) [5]. Therefore: 1. The HDTV transport system is a compatible subset of the MPEG-2 transport system. Section 2 of RFC 2250 [7] describes the RTP payload for MPEG-2's transport system, where multiple fixed length (188 bytes) MTS packets are aggregated into a single RTP packet. 2. Compressed HDTV is a subset of MPEG-2 MP@HL with some additional restrictions. Section 3 of RFC 2250 describes a packetization scheme for MPEG-2 elementary streams. The additional restrictions of HDTV do not have any implications for RTP packetization. draft-ietf-gharai-hdtv-video-00.txt [Page 2] INTERNET-DRAFT March 8, 2000 3. Payload Design Each scan line of digital video is packetized into one or more (depending on the current MTU) RTP packets. Only the active samples are included in the RTP payload. From the two timing references, SAV and EAV (start of active video and end of active video) only the field bit, F, is included in the RTP payload header. Scan lines are numbered consecutively. Only active scan lines are included in the RTP payload. Transmissability of the inactive data (including vertical blanking interval) in this payload is for future study. Scan line numbers are included in the RTP payload header. For SMPTE 296M, valid scan line numbers are from 26 through 745, inclusive. For SMPTE 274M, progressive scanning valid scan lines are from scan line 42 through 1121, inclusive. For interlaced scanning, valid scan line numbers for field one (F=0) are from 21 to 560 and valid scan line numbers for the second field (F=1) are from 584 to 1123. Cb and Cr values are subsampled by a factor of two horizontally and are co-sited with even numbered Y samples. Therefore, Cb, Cr and Y samples are arranged in following order: Cb, Y, Cr, Y, Cb, Y, Cr, ... where the first Cb, Y, Cr sequence refers to co-sited luminance and color-difference samples, and the next Y belongs to the next luminance sample. If a scan line must be fragmented, the fragment should always start with a Cb value. In other words, fragmentation MUST only occur at a Cb boundary. 4. RTP Packetization The standard RTP header is followed by a 4 byte payload header, and the payload data. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Data | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-ietf-gharai-hdtv-video-00.txt [Page 3] INTERNET-DRAFT March 8, 2000 4.1. The RTP Header In this specification, the terms "frame" and "image" are used interchangeably, though "image" is the preferred term of the SMPTE specifications. The following fields of the RTP fixed header are used for HDTV encapsulation: Payload Type (PT): A dynamically allocated payload type field which designates the payload as uncompressed HDTV. Timestamp: A 90 kHz timestamp which denotes the display time of the video frame to which the RTP packet belongs. All packets belonging to the same video frame MUST have the same timestamp. Higher-rate timestamps have been considered for related payload types (see the minutes of the AVT Working Group, 46th IETF), but they would be for multiple programs (if considered at all). For uncompressed HDTV, with maximum frame rates of 60 per second (60i), the 90kHz standard RTP timestamp suffices. Marker bit (M): The Marker bit denotes the end of a video frame, and is set to 1 for the last packet of the video frame and is otherwise set to 0 for all other packets. 4.2. Payload Header The payload header is 4 bytes long and is arranged as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|Q| I |S| R | Z | Scan Line (SL) | Scan Offset (SO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field Identification (F): 1 bit Identifies which field the scan line belongs to, for interlaced data. F=0 identifies the the first field and F=1 the second field. For progressive data (SMPTE 296M) F MUST always be set to zero. This bit MUST remain unchanged for all scan lines within the same image. Quantization (Q): 1 bit Designates sample sizes. For 8-bit samples Q is set to 0 and for 10-bit samples Q is set to 1. This bit MUST remain unchanged for all scan lines within the same image. draft-ietf-gharai-hdtv-video-00.txt [Page 4] INTERNET-DRAFT March 8, 2000 Image Size (I): 2 bits Identifies the image size and SMPTE standard which the data conforms to. I=0 designates a 720*1280 image size (SMPTE 296M), and I=1 designates a 1080*1920 image size (SMPTE 274M). This bit MUST remain unchanged for all scan lines within the same image. The remaining values of I are reserved for future use. Scanning (S): 1 bit Designates progressive (S=1) or interlaced (S=0) scanning. For SMPTE 296M data only S=1 is a valid value. This bit MUST remain unchanged for all scan lines within the same image. Frame Rate (R): 3 bits Designates frame rate of transferred data. Frames rates designated by values of consecutive values of R (from 0 to 7) are: 60fps, 59.94fps, 50fps, 30fps, 29.97fps, 25fps, 24fps and 23.98fps. All of the above are valid for SMPTE 274M (I=1), however for SMPTE 296M (or I=0) only R=0 and R=1 are valid. These bits MUST remain unchanged for all scan lines within the same image. Zero (Z): 2 bits For future use. Must be set to zero. Scan Line (SL): 11 bits Scan line number of encapsulated data. Successive RTP packets MAY contains parts of the same scan line (with an incremented sequence number, but the same timestamp). One RTP packet MUST NOT contain the end of one scan line and the start of another. Valid values for SMPTE 296M (I=0) are 26-745. For SMPTE 274M (I=1) with progressive scanning (S=1, F=0) valid scan line numbers are 42-1121, and with interlaced scanning, field one (S=0, F=0) valid values are 21-560; for field two (S=0, F=1), the valid values are 584-1123. Scan Offset (SO): 11 bits Sample number of the co-sited luminance sample where the scan line is fragmented. Valid values for SMPTE 296M (I=0) are 2-1278 and for SMPTE 274M (I=1) 2-1918. 5. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [4], and any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to- draft-ietf-gharai-hdtv-video-00.txt [Page 5] INTERNET-DRAFT March 8, 2000 end, encryption may be performed after compression so there is no conflict between the two operations. This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat. It is perhaps to be noted that the bandwidth of this payload is high enough (1.5 Gbps without the RTP overhead) to cause potential for denial-of-service if transmitted onto most currently available Internet paths. In the absence from the standards track of a suitable congestion control mechanism for flows of this sort, use of the payload should be narrowly limited to suitably connected network endpoints and great care taken with the scope of multicast transmissions. This potential threat is hardly unique to the uncompressed HDTV payload, but the size of this flow is larger than most like it. 6. IANA Considerations [To be done] 7. To Do List For consideration in the next revision of this document: should the vertical blanking interval scan lines be transmissable? How should ancillary data be handled? This follows RFC 2431 in extracting the video data from the whole line, since there is otherwise a lot of extra data, but this decision should be reconsidered in the light of ongoing prototype implementations. Implementation experience will also be used to consider loss recovery in a future revision. 8. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Soci- ety or other Internet organizations, except as needed for the purpose of draft-ietf-gharai-hdtv-video-00.txt [Page 6] INTERNET-DRAFT March 8, 2000 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be fol- lowed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 9. Authors' Addresses Ismail Dalgic Ismail_Dalgic@3com.com Ladan Gharai ladan@isi.edu Allison Mankin mankin@isi.edu David Richardson drr@u.washington.edu Raymond Yow Raymond_Yow@3com.com 10. Bibliography [1] Society of Motion Picture and Television Engineers, 1920*1080 Scanning and Analog and Parallel Digital Interfaces for Multiple Picture Rates, SMPTE 274M, 1998. [2] Society of Motion Picture and Television Engineers, 1280*720 Scanning, Analog and Digital Representation and Analog Interfaces, SMPTE 296M, 1998. [3] ISO/IEC International Standard 13818-2; "Generic coding of moving pictures and associated audio information: Video", 1996. [4] ATSC Digital Television Standard Document A/53, September 1995, http://www.atsc.org draft-ietf-gharai-hdtv-video-00.txt [Page 7] INTERNET-DRAFT March 8, 2000 [5] ISO/IEC International Standard 13818-1; "Generic coding of moving pictures and associated audio information: Systems",1996. [6] Schulzrinne, Casner, Frederick, Jacobson, "RTP: A transport protocol for real time Applications", RFC 1889, IETF, January 1996. [7] Hoffman, Fernando, Goyal, Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, IETF, January 1998. [8] Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, IETF, January 1996. draft-ietf-gharai-hdtv-video-00.txt [Page 8]