idnits 2.17.1 draft-tynan-rtp-bt656-01.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-26) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. -- 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: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Audio-Video Transport WG 2 INTERNET-DRAFT D. Tynan 3 draft-tynan-rtp-bt656-01.txt Claddagh Films 4 November 21st, 1997 5 Expires: 5/25/98 7 RTP Payload Format for BT.656 Video Encoding 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced or obsoleted by other documents at any 18 time. It is not appropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 This document specifies the RTP payload format for 32 encapsulating ITU Recommendation BT.656-3 video streams in the 33 Real-Time Transport Protocol (RTP). Each RTP packet contains 34 all or a portion of one scan line as defined by ITU 35 Recommendation BT.601-5, and includes fragmentation, decoding 36 and positioning information. 38 1. Introduction 40 This document describes a scheme to packetize uncompressed, studio- 41 quality video streams as defined by BT.656 for transport using RTP 42 [1]. A BT.656 video stream is defined by ITU-R Recommendation 43 BT.656-3 [2], as a means of interconnecting digital television 44 equipment operating on the 525-line or 625-line standards, and 45 complying with the 4:2:2 encoding parameters as defined in ITU-R 46 Recommendation BT.601-5 (formerly CCIR-601) [3], Part A. 48 RTP is defined by the Internet Engineering Task Force (IETF) to 49 provide end-to-end network transport functions suitable for 50 applications transmitting real-time data over multicast or unicast 51 network services. The complete specification of RTP for a particular 52 application requires the RTP protocol document [1], a profile 53 specification document [4], and a payload format specification. This 54 document is intended to serve as the payload format specification for 55 studio-quality video streams. 57 2. Definitions 59 For the purposes of this document, the following definitions apply: 61 Y: An 8-bit or 10-bit coded luminance sample (as per BT.601-5 [3]). 62 Each luminance value has 220 quantization levels with the black level 63 corresponding to level 16 and the peak white level corresponding to 64 235. 66 Cb, Cr: An 8-bit or 10-bit coded color-difference sample (as per 67 BT.601-5). Each color-difference value has 225 quantization levels 68 in the centre part of the quantization scale with a color-difference 69 of zero having an encoded value of 128. 71 True Black: BT.601-5 defines a true black level as the quad-sample 72 sequence 0x80, 0x10, 0x80, 0x10, representing color-difference values 73 of 128 (0x80) and a luminance value of 16 (0x10). 75 SAV, EAV: Video timing reference codes which appear at the start and 76 end of a BT.656 scan line. 78 3. Payload Design 80 ITU Recommendation BT.656-3 defines a schema for the digital 81 interconnection of television video signals in conjunction with 82 BT.601-5 which defines the digital representation of the original 83 analog signal. While BT.601-5 refers to images with or without color 84 subsampling, the interconnection standard (BT.656-3) specifically 85 requires 4:2:2 subsampling. This specification also requires 4:2:2 86 subsampling such that the luminance stream occupies twice the 87 bandwidth of each of the two color-difference streams. For normal 88 4:3 aspect ratio images, this results in 720 luminance samples per 89 scan line, and 360 samples of each of the two chrominance channels. 90 The total number of samples per scan line in this case is 1440. 91 While this payload format specification can accomodate various image 92 sizes and frame rates, only those in accordance with BT.601-5 are 93 currently supported. 95 Due to the lack of any form of video compression within the payload 96 and sampling-rate compliance with BT.601-5, the resultant video 97 stream can be considered ``studio quality''. However, such a stream 98 can require approximately 20 megabytes per second of network 99 bandwidth. In order to maximize packet size within a given MTU, and 100 to optimize scan line decoding, each video scan line is encoded 101 within one or more RTP packets. 103 To allow for scan line synchronization, each packet includes certain 104 flag bits (as defined in BT.656-3) and a unique scan line number. 105 The SAV and EAV timing reference codes are removed. Furthermore, no 106 line blanking samples are included, so no ancillary data can be 107 included in the line blanking period. It is the responsibility of 108 the receiver to generate the timing reference codes, and to insert 109 the correct number of line blanking samples. 111 Similarly, there is no requirement that the frame blanking samples be 112 provided. However, it is possible to include frame blanking samples 113 if such samples contain relevant information, such as a vertical- 114 interlace time code (VITC), or teletext data. In the absence of 115 frame blanking samples, the receiver must generate true black levels 116 as defined above, to complete the correct number of scan lines per 117 field. If frame blanking samples are provided, they must be copied 118 without modification into the resultant BT.656-3 stream. 120 Scan lines must be sent in sequential order. Error concealment for 121 missing scan lines or fragments of scan lines is at the discretion of 122 the receiver. 124 Both 8-bit and 10-bit quantization types as defined by BT.601-5 are 125 supported. 10-bit samples are considered to have two extra bits of 126 fixed-point precision such that a binary value of 10111110.11 127 represents a sample value of 190.75. Using 8-bit quantization, this 128 would give a sample value of 190. An application receiving 8-bit 129 samples for a 10-bit device must consider the sample as reflecting 130 the most-significant 8 bits. The two least-significant bits should 131 be set to zero. Similarly, an application sending 8-bit samples from 132 a 10-bit device should drop the two least-significant bits. For a 133 10-bit quantization payload, each pair of samples must be encoded 134 into a 40-bit word (five octets) prior to transmission, as specified 135 in Section 6. 137 To allow for scan lines with octet lengths larger than the path 138 maximum transmission unit (MTU), a scan offset field is included in 139 the packet header. Applications should attempt path MTU discovery[5] 140 and fragment scan lines into multiple packets no larger than the MTU. 142 Fragmentation must occur on a sample-pair boundary, such that the 143 chrominance and luminance values are not split across packets. For 144 8-bit quantization this gives a four-octet alignment, and a five- 145 octet alignment for 10-bit quantization. As a result, the scan 146 offset refers not to the byte offset within the payload, but the 147 sample-pair offset. 149 4. Usage of RTP 151 Due to the unreliable nature of the RTP protocol, and the lack of an 152 orderly delivery mechanism, each packet contains enough information 153 to form a single scan line without reference to prior scan lines or 154 prior frames. In addition to the RTP header, a fixed length payload 155 header is included in each packet. This header is four octets in 156 length. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | RTP Header | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Payload Header | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Payload Data | 166 | . | 167 | . | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 4.1. RTP Header usage 172 Each RTP packet starts with a fixed RTP header. The following fields 173 of the RTP fixed header are used for BT.656-3 encapsulation: 175 Marker bit (M): The Marker bit of the RTP header is set to 1 when the 176 last packet of a frame (or the last fragment of the last scan line if 177 fragmented), and set to 0 on all other packets. 179 Payload Type (PT): The Payload Type indicates the use of the payload 180 format defined in this document. A profile may assign a payload type 181 value for this format either statically or dynamically as described 182 in [4]. 184 Timestamp: The RTP Timestamp encodes the sampling instant of the 185 video frame currently being rendered. All scan line packets within 186 the same frame will have the same timestamp. The timestamp should 187 refer to the 'Ov' field synchronization point of the first field. 188 For the payload format defined by this document, the RTP timestamp is 189 based on a 90kHz clock. 191 5. Payload Header 193 The payload header is a fixed four-octet header broken down as 194 follows: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |F|V| Type |P| Z | Scan Line (SL) | Scan Offset (SO) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 F: 1 bit 203 When 0, indicates the first field of a frame (line 4 through 265 204 inclusive for Type=0 or 2, and line 1 through 312 inclusive for 205 Type=1 or 3). Any other scan line is considered a component of the 206 second field, and the F bit will be set to 1. This bit is copied 207 directly from the BT.656-compliant stream by the transmitter, and 208 directly inserted into the stream by the receiver. 210 V: 1 bit 211 When 1, indicates that the scan line is part of the vertical 212 interval. Should always be 0 unless frame blanking data is sent. In 213 which case, the V bit should be set to 1 for scan lines which do not 214 form an integral part of the image. This bit is copied directly from 215 the BT.656-compliant stream by the transmitter, and directly inserted 216 into the stream by the receiver. For receivers which do not receive 217 scan lines during the vertical interval, BT.656 vertical interval 218 data must be generated by repeating the quad-sample sequence 0x80, 219 0x10, 0x80, 0x10, representing a true black level. 221 Type: 4 bits 222 This field indicates the type of frame encoding within the payload. 223 It must remain unchanged for all scan lines within the same frame. 224 Currently only four types of encoding are defined. These are as 225 follows; 227 0 - NTSC (13.5MHz sample rate; 720 samples per line; 60 fields 228 per second; 525 lines per frame) 230 1 - PAL (13.5MHz sample rate; 720 samples per line; 50 fields 231 per second; 625 lines per frame) 233 2 - High Definition NTSC (18MHz sample rate; 1144 samples per 234 line; 60 fields per second; 525 lines per frame) 236 3 - High Definition PAL (18MHz sample rate; 1152 samples per 237 line; 50 fields per second; 625 lines per frame) 239 P: 1 bit 240 Indicates the required sample quantization size. When 0, the payload 241 is comprised of 8-bit samples. Otherwise, it carries 10-bit samples. 242 This bit must remain unchanged for all scan lines within the same 243 frame. 245 Z: 2 bits 246 Reserved for future use. Must be set to zero by the transmitter and 247 ignored by the receiver. 249 Scan Line (SL): 12 bits 250 Indicates the scan line encapsulated in the payload. Valid values 251 range from 1 through 625 inclusive. If no frame blanking data is 252 being transmitted, only scan lines 23 through 310 inclusive, and 253 lines 336 through 623 inclusive should be sent in the case of Type=1 254 or 3. For 525/60 encoding (Type=0 or 2), scan lines 10 through 263 255 inclusive and lines 273 through 525 should be transmitted. 257 If a receiver is generating a BT.656-3 data stream directly from this 258 packet, the F and V bits must be copied from the header rather than 259 being generated implicitly from the scan line number. In the event 260 of a conflict, the F and V bits have precedence. 262 Scan Offset (SO): 11 bits 263 Indicates the offset within the scan line for application-level 264 fragmentation. If the path MTU is less than the required size for 265 one complete scan line, the data must be fragmented such that a given 266 RTP packet does not exceed the allowable MTU. The offset for the 267 first packet of a scan line must be set to zero. The scan offset 268 refers to the sample-pair offset within the scan such that for a scan 269 line width of 720, the maximum scan offset is 359. 271 6. Payload Format 273 In keeping with the 4:2:2 color subsampling of BT.656 and BT.601, 274 each pair of color-difference samples will be intermixed with two 275 luminance samples. As per BT.656, the format for transmission shall 276 be Cb, Y, Cr, Y. The following is a representation of a 720 sample 277 packet with 8-bit quantization: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Cb0 | Y0 | Cr0 | Y1 | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Cb1 | Y2 | Cr1 | Y3 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 . 287 . 288 . 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Cb359 | Y718 | Cr359 | Y719 | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 1144 and 1152 sample packets should increase the packet size 294 accordingly while maintaining the sample order. 296 For 10-bit quantization, each group of four samples must be encoded 297 into a 40-bit word (five octets) prior to transmission. The sample 298 order is identical to that for 8-bit quantization. The following is 299 a representation of a 720 sample packet with 10-bit quantization: 301 0 1 2 3 302 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 303 +---------+---------+---------+---------+ 304 | Cb0 | Y0 | Cr0 | Y1 | 305 +---------+---------+---------+---------+ 306 | Cb1 | Y2 | Cr1 | Y3 | 307 +---------+---------+---------+---------+ 308 . 309 . 310 . 311 +---------+---------+---------+---------+ 312 | Cb359 | Y718 | Cr359 | Y719 | 313 +---------+---------+---------+---------+ 314 (Note that the word width is 40 bits) 315 +-------+-------+-------+-------+-------+ 316 Octets: | 0 | 1 | 2 | 3 | 4 | 317 +-------+-------+-------+-------+-------+ 319 The octets shown in these diagrams are transmitted in network byte 320 order, that is, left-to-right as shown. 322 7. References 324 [1] RTP: A Transport Protocol for Real-Time Applications, H. 325 Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RFC 1889. 326 [2] Interfaces for Digital Component Video Signals in 525-Line and 327 625-Line Television Systems operating at the 4:2:2 Level of 328 Recommendation ITU-R BT.601 (Part A), ITU-R Recommendation 329 BT.656-3, 1995. 330 [3] Studio Encoding Parameters of Digital Television for Standard 4:3 331 and Wide-Screen 16:9 Aspect Ratios, ITU-R Recommendation BT.601-5, 332 1995. 333 [4] RTP Profile for Audio and Video Conference with Minimal Control, 334 H. Schulzrinne, RFC 1890. 335 [5] Path MTU Discovery, J. Mogul, S. Deering, RFC 1191. 337 8. Authors Address 339 Dermot Tynan 340 Claddagh Films Limited 341 3 White Oaks 342 Clybaun Road 343 Galway 344 Ireland 346 Email: dtynan@claddagh.ie 347 Tel: +353 91 529944