idnits 2.17.1 draft-tynan-rtp-bt656-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 333 has weird spacing: '...cessing to...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1890 (ref. '4') (Obsoleted by RFC 3551) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio-Video Transport WG 3 INTERNET-DRAFT D. Tynan 4 draft-tynan-rtp-bt656-02.txt Claddagh Films 5 March 10th, 1998 6 Expires: 9/14/98 8 RTP Payload Format for BT.656 Video Encoding 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced or obsoleted by other documents at any 19 time. It is not appropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 Abstract 32 This document specifies the RTP payload format for 33 encapsulating ITU Recommendation BT.656-3 video streams in the 34 Real-Time Transport Protocol (RTP). Each RTP packet contains 35 all or a portion of one scan line as defined by ITU 36 Recommendation BT.601-5, and includes fragmentation, decoding 37 and positioning information. 39 1. Introduction 41 This document describes a scheme to packetize uncompressed, studio- 42 quality video streams as defined by BT.656 for transport using RTP 43 [1]. A BT.656 video stream is defined by ITU-R Recommendation 44 BT.656-3 [2], as a means of interconnecting digital television 45 equipment operating on the 525-line or 625-line standards, and 46 complying with the 4:2:2 encoding parameters as defined in ITU-R 47 Recommendation BT.601-5 (formerly CCIR-601) [3], Part A. 49 RTP is defined by the Internet Engineering Task Force (IETF) to 50 provide end-to-end network transport functions suitable for 51 applications transmitting real-time data over multicast or unicast 52 network services. The complete specification of RTP for a particular 53 application requires the RTP protocol document [1], a profile 54 specification document [4], and a payload format specification. This 55 document is intended to serve as the payload format specification for 56 studio-quality video streams. 58 2. Definitions 60 For the purposes of this document, the following definitions apply: 62 Y: An 8-bit or 10-bit coded luminance sample (as per BT.601-5 [3]). 63 Each luminance value has 220 quantization levels with the black level 64 corresponding to level 16 and the peak white level corresponding to 65 235. 67 Cb, Cr: An 8-bit or 10-bit coded color-difference sample (as per 68 BT.601-5). Each color-difference value has 225 quantization levels 69 in the centre part of the quantization scale with a color-difference 70 of zero having an encoded value of 128. 72 True Black: BT.601-5 defines a true black level as the quad-sample 73 sequence 0x80, 0x10, 0x80, 0x10, representing color-difference values 74 of 128 (0x80) and a luminance value of 16 (0x10). 76 SAV, EAV: Video timing reference codes which appear at the start and 77 end of a BT.656 scan line. 79 3. Payload Design 81 ITU Recommendation BT.656-3 defines a schema for the digital 82 interconnection of television video signals in conjunction with 83 BT.601-5 which defines the digital representation of the original 84 analog signal. While BT.601-5 refers to images with or without color 85 subsampling, the interconnection standard (BT.656-3) specifically 86 requires 4:2:2 subsampling. This specification also requires 4:2:2 87 subsampling such that the luminance stream occupies twice the 88 bandwidth of each of the two color-difference streams. For normal 89 4:3 aspect ratio images, this results in 720 luminance samples per 90 scan line, and 360 samples of each of the two chrominance channels. 91 The total number of samples per scan line in this case is 1440. 92 While this payload format specification can accomodate various image 93 sizes and frame rates, only those in accordance with BT.601-5 are 94 currently supported. 96 Due to the lack of any form of video compression within the payload 97 and sampling-rate compliance with BT.601-5, the resultant video 98 stream can be considered ``studio quality''. However, such a stream 99 can require approximately 20 megabytes per second of network 100 bandwidth. In order to maximize packet size within a given MTU, and 101 to optimize scan line decoding, each video scan line is encoded 102 within one or more RTP packets. 104 To allow for scan line synchronization, each packet includes certain 105 flag bits (as defined in BT.656-3) and a unique scan line number. 106 The SAV and EAV timing reference codes are removed. Furthermore, no 107 line blanking samples are included, so no ancillary data can be 108 included in the line blanking period. It is the responsibility of 109 the receiver to generate the timing reference codes, and to insert 110 the correct number of line blanking samples. 112 Similarly, there is no requirement that the frame blanking samples be 113 provided. However, it is possible to include frame blanking samples 114 if such samples contain relevant information, such as a vertical- 115 interlace time code (VITC), or teletext data. In the absence of 116 frame blanking samples, the receiver must generate true black levels 117 as defined above, to complete the correct number of scan lines per 118 field. If frame blanking samples are provided, they must be copied 119 without modification into the resultant BT.656-3 stream. 121 Scan lines must be sent in sequential order. Error concealment for 122 missing scan lines or fragments of scan lines is at the discretion of 123 the receiver. 125 Both 8-bit and 10-bit quantization types as defined by BT.601-5 are 126 supported. 10-bit samples are considered to have two extra bits of 127 fixed-point precision such that a binary value of 10111110.11 128 represents a sample value of 190.75. Using 8-bit quantization, this 129 would give a sample value of 190. An application receiving 8-bit 130 samples for a 10-bit device must consider the sample as reflecting 131 the most-significant 8 bits. The two least-significant bits should 132 be set to zero. Similarly, an application sending 8-bit samples from 133 a 10-bit device should drop the two least-significant bits. For a 134 10-bit quantization payload, each pair of samples must be encoded 135 into a 40-bit word (five octets) prior to transmission, as specified 136 in Section 6. 138 To allow for scan lines with octet lengths larger than the path 139 maximum transmission unit (MTU), a scan offset field is included in 140 the packet header. Applications should attempt path MTU discovery[5] 141 and fragment scan lines into multiple packets no larger than the MTU. 143 Fragmentation must occur on a sample-pair boundary, such that the 144 chrominance and luminance values are not split across packets. For 145 8-bit quantization this gives a four-octet alignment, and a five- 146 octet alignment for 10-bit quantization. As a result, the scan 147 offset refers not to the byte offset within the payload, but the 148 sample-pair offset. 150 4. Usage of RTP 152 Due to the unreliable nature of the RTP protocol, and the lack of an 153 orderly delivery mechanism, each packet contains enough information 154 to form a single scan line without reference to prior scan lines or 155 prior frames. In addition to the RTP header, a fixed length payload 156 header is included in each packet. This header is four octets in 157 length. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | RTP Header | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Payload Header | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Payload Data | 167 | . | 168 | . | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 4.1. RTP Header usage 173 Each RTP packet starts with a fixed RTP header. The following fields 174 of the RTP fixed header are used for BT.656-3 encapsulation: 176 Marker bit (M): The Marker bit of the RTP header is set to 1 when the 177 last packet of a frame (or the last fragment of the last scan line if 178 fragmented), and set to 0 on all other packets. 180 Payload Type (PT): The Payload Type indicates the use of the payload 181 format defined in this document. A profile may assign a payload type 182 value for this format either statically or dynamically as described 183 in [4]. 185 Timestamp: The RTP Timestamp encodes the sampling instant of the 186 video frame currently being rendered. All scan line packets within 187 the same frame will have the same timestamp. The timestamp should 188 refer to the 'Ov' field synchronization point of the first field. 189 For the payload format defined by this document, the RTP timestamp is 190 based on a 90kHz clock. 192 5. Payload Header 194 The payload header is a fixed four-octet header broken down as 195 follows: 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |F|V| Type |P| Z | Scan Line (SL) | Scan Offset (SO) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 F: 1 bit 204 When 0, indicates the first field of a frame (line 4 through 265 205 inclusive for Type=0 or 2, and line 1 through 312 inclusive for 206 Type=1 or 3). Any other scan line is considered a component of the 207 second field, and the F bit will be set to 1. This bit is copied 208 directly from the BT.656-compliant stream by the transmitter, and 209 directly inserted into the stream by the receiver. 211 V: 1 bit 212 When 1, indicates that the scan line is part of the vertical 213 interval. Should always be 0 unless frame blanking data is sent. In 214 which case, the V bit should be set to 1 for scan lines which do not 215 form an integral part of the image. This bit is copied directly from 216 the BT.656-compliant stream by the transmitter, and directly inserted 217 into the stream by the receiver. For receivers which do not receive 218 scan lines during the vertical interval, BT.656 vertical interval 219 data must be generated by repeating the quad-sample sequence 0x80, 220 0x10, 0x80, 0x10, representing a true black level. 222 Type: 4 bits 223 This field indicates the type of frame encoding within the payload. 224 It must remain unchanged for all scan lines within the same frame. 225 Currently only four types of encoding are defined. These are as 226 follows; 228 0 - NTSC (13.5MHz sample rate; 720 samples per line; 60 fields 229 per second; 525 lines per frame) 231 1 - PAL (13.5MHz sample rate; 720 samples per line; 50 fields 232 per second; 625 lines per frame) 234 2 - High Definition NTSC (18MHz sample rate; 1144 samples per 235 line; 60 fields per second; 525 lines per frame) 237 3 - High Definition PAL (18MHz sample rate; 1152 samples per 238 line; 50 fields per second; 625 lines per frame) 240 P: 1 bit 241 Indicates the required sample quantization size. When 0, the payload 242 is comprised of 8-bit samples. Otherwise, it carries 10-bit samples. 243 This bit must remain unchanged for all scan lines within the same 244 frame. 246 Z: 2 bits 247 Reserved for future use. Must be set to zero by the transmitter and 248 ignored by the receiver. 250 Scan Line (SL): 12 bits 251 Indicates the scan line encapsulated in the payload. Valid values 252 range from 1 through 625 inclusive. If no frame blanking data is 253 being transmitted, only scan lines 23 through 310 inclusive, and 254 lines 336 through 623 inclusive should be sent in the case of Type=1 255 or 3. For 525/60 encoding (Type=0 or 2), scan lines 10 through 263 256 inclusive and lines 273 through 525 should be transmitted. 258 If a receiver is generating a BT.656-3 data stream directly from this 259 packet, the F and V bits must be copied from the header rather than 260 being generated implicitly from the scan line number. In the event 261 of a conflict, the F and V bits have precedence. 263 Scan Offset (SO): 11 bits 264 Indicates the offset within the scan line for application-level 265 fragmentation. If the path MTU is less than the required size for 266 one complete scan line, the data must be fragmented such that a given 267 RTP packet does not exceed the allowable MTU. The offset for the 268 first packet of a scan line must be set to zero. The scan offset 269 refers to the sample-pair offset within the scan such that for a scan 270 line width of 720, the maximum scan offset is 359. 272 6. Payload Format 274 In keeping with the 4:2:2 color subsampling of BT.656 and BT.601, 275 each pair of color-difference samples will be intermixed with two 276 luminance samples. As per BT.656, the format for transmission shall 277 be Cb, Y, Cr, Y. The following is a representation of a 720 sample 278 packet with 8-bit quantization: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Cb0 | Y0 | Cr0 | Y1 | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Cb1 | Y2 | Cr1 | Y3 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 . 288 . 289 . 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Cb359 | Y718 | Cr359 | Y719 | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 1144 and 1152 sample packets should increase the packet size 295 accordingly while maintaining the sample order. 297 For 10-bit quantization, each group of four samples must be encoded 298 into a 40-bit word (five octets) prior to transmission. The sample 299 order is identical to that for 8-bit quantization. The following is 300 a representation of a 720 sample packet with 10-bit quantization: 302 0 1 2 3 303 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 304 +---------+---------+---------+---------+ 305 | Cb0 | Y0 | Cr0 | Y1 | 306 +---------+---------+---------+---------+ 307 | Cb1 | Y2 | Cr1 | Y3 | 308 +---------+---------+---------+---------+ 309 . 310 . 311 . 312 +---------+---------+---------+---------+ 313 | Cb359 | Y718 | Cr359 | Y719 | 314 +---------+---------+---------+---------+ 315 (Note that the word width is 40 bits) 316 +-------+-------+-------+-------+-------+ 317 Octets: | 0 | 1 | 2 | 3 | 4 | 318 +-------+-------+-------+-------+-------+ 320 The octets shown in these diagrams are transmitted in network byte 321 order, that is, left-to-right as shown. 323 7. Security Considerations 325 RTP packets using the payload format defined in this specification 326 are subject to the security considerations discussed in the RTP 327 specification [1]. This implies that confidentiality of the media 328 streams is achieved by encryption. Because the payload format is 329 arranged end-to-end, encryption may be performed after encapsulation 330 so there is no conflict between the two operations. 332 This payload type does not exhibit any significant non-uniformity in 333 the receiver side computational complexity for packet processing to 334 cause a potential denial-of-service threat. 336 8. References 338 [1] RTP: A Transport Protocol for Real-Time Applications, H. 339 Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RFC 1889. 340 [2] Interfaces for Digital Component Video Signals in 525-Line and 341 625-Line Television Systems operating at the 4:2:2 Level of 342 Recommendation ITU-R BT.601 (Part A), ITU-R Recommendation 343 BT.656-3, 1995. 344 [3] Studio Encoding Parameters of Digital Television for Standard 4:3 345 and Wide-Screen 16:9 Aspect Ratios, ITU-R Recommendation BT.601-5, 346 1995. 347 [4] RTP Profile for Audio and Video Conference with Minimal Control, 348 H. Schulzrinne, RFC 1890. 349 [5] Path MTU Discovery, J. Mogul, S. Deering, RFC 1191. 351 9. Authors Address 353 Dermot Tynan 354 Claddagh Films Limited 355 3 White Oaks 356 Clybaun Road 357 Galway 358 Ireland 360 Email: dtynan@claddagh.ie 361 Tel: +353 91 529944