idnits 2.17.1 draft-tynan-rtp-bt656-00.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. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Audio-Video Transport WG 3 INTERNET-DRAFT D. Tynan 4 draft-tynan-rtp-bt656-00.txt Claddagh Films 5 July 28th, 1997 6 Expires: 2/2/98 8 RTP Payload Format for BT.656-3 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 one scan line as defined by ITU Recommendation BT.601-5, and 36 includes decoding and positioning information. 38 1. Introduction 40 This document describes a scheme to packetize a BT.656-3 video stream 41 for transport using RTP [1]. A BT.656-3 video stream is defined by 42 ITU-R Recommendation BT.656-3 [2], as a means of interconnecting 43 digital television equipment operating on the 525-line or 625-line 44 standards, and complying with the 4:2:2 encoding parameters as 45 defined in ITU-R Recommendation BT.601-5 (formerly CCIR-601) [3], 46 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 will require a profile specification document [4], a 53 payload format specification, and an RTP protocol document [1]. This 54 document is intended to serve as the payload format specification for 55 BT.656-3 video streams. 57 2. Definitions 59 For the purposes of this document, the following definitions apply: 61 Cb, Cr: An 8-bit coded color-difference sample (as per BT.601-5 [3]). 62 Each color-difference value has 225 quantization levels in the centre 63 part of the quantization scale with zero corresponding to 128. 65 Y: An 8-bit coded luminance sample (as per BT.601-5 [3]). Each 66 luminance value has 220 quantization levels with the black level 67 corresponding to level 16 and the peak white level corresponding to 68 235. 70 SAV, EAV: Video timing reference codes which appear at the start and 71 end of a BT.656 scan line. 73 3. Payload Design 75 ITU Recommendation BT.656-3 defines a schema for the digital 76 interconnection of television video signals in conjunction with 77 BT.601-5 which defines the digital representation of the original 78 analog signal. While BT.601-5 refers to images with or without color 79 subsampling, the interconnection standard (BT.656-3) specifically 80 requires 4:2:2 subsampling. This specification also requires 4:2:2 81 subsampling such that the luminance stream occupies twice the 82 bandwidth of each of the two color-difference streams. For normal 83 4:3 aspect ratio images, this results in 720 luminance samples per 84 scan line, and 360 samples of each of the two chrominance channels. 85 The total number of 8-bit samples per scan line then, is 1440. 87 Due to the lack of any form of video compression within BT.656-3, the 88 resultant video stream can be considered ``broadcast quality''. 89 However, such a stream requires approximately 20 megabytes per second 90 of network bandwidth. In order to minimize packet size and to 91 optimize the packetization of the stream, each video scan line is 92 encoded within an RTP packet. 94 To allow for scan line synchronization, each packet includes certain 95 flag bits (as defined in BT.656-3) and a unique scan line number. 96 The SAV and EAV timing reference codes are removed. Furthermore, no 97 line blanking samples are included, so no ancillary data can be 98 included in the line blanking period. It is the responsibility of 99 the receiver to generate the timing reference codes, and to insert 100 the correct number of line blanking samples. 102 Similarly, to save on bandwidth, there is no requirement that the 103 frame blanking samples be provided. However, it is possible to 104 include frame blanking samples if such samples contain relevant 105 information, such as a vertical-interlace time code, or teletext 106 data. In the absence of frame blanking samples, the receiver must 107 generate black levels as described below, to complete the correct 108 number of scan lines per field. If frame blanking samples are 109 provided, they must be copied without modification into the resultant 110 BT.656-3 stream. 112 Scan lines must be sent in sequential order. Missing scan lines can 113 be replaced by the same scan line of the previous frame, the last 114 scan line received, or true black at the discretion of the receiver. 116 4. Usage of RTP 118 Due to the unreliable nature of the RTP protocol, and the lack of an 119 orderly delivery mechanism, each packet contains enough information 120 to form a single scan line without reference to prior scan lines or 121 prior frames. In addition to the RTP header, a fixed length payload 122 header is included in each packet. This header is four octets in 123 length. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | RTP Header | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Payload Header | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Payload Data | 133 | . | 134 | . | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 4.1. RTP Header usage 139 Each RTP packet starts with a fixed RTP header. The following fields 140 of the RTP fixed header are used for BT.656-3 encapsulation: 142 Marker bit (M): The Marker bit of the RTP header is set to 1 when the 143 current packet carries the final scan line of the current frame. 0 144 otherwise. 146 Payload Type (PT): The Payload Type shall specify a BT.656-3 video 147 payload format. 149 Timestamp: The RTP Timestamp encodes the sampling instance of the 150 video frame currently being rendered. All scan line packets within 151 the same frame will have the same timestamp. The timestamp should 152 refer to the 'Ov' field synchronization point of the first (even) 153 field. For BT.656-3 payloads, the RTP timestamp is based on a 90kHz 154 clock. 156 5. Payload Header 158 The payload header is a fixed four-octet header broken down as 159 follows: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | N |S|F|V| Reserved (Must Be 0) | Scan Line (SL) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 N: 2 bits 168 This field indicates the type of frame encoding within the payload. 169 Currently only two types of encoding are defined. If this field is 170 01, then an NTSC frame encoding (525 line/60 fields per second) is 171 specified. If the field is 00, then a PAL frame (625 line/50 fields 172 per second) is specified. 174 S: 1 bit 175 Sample rate. When 1, the sample rate is 18MHz. Otherwise, the 176 normal sample rate of 13.5MHz is used. In the high sample rate case 177 (S=1), the scan line width is 1144 for NTSC frames (N=1) or 1152 178 samples for PAL frames (N=0). With the normal sample rate (S=0), the 179 scan line width is always 720 samples regardless of encoding. High 180 sample rates are used only for 16:9 systems. 182 F: 1 bit 183 When 0, indicates the first field of a frame (line 1 through 312 184 inclusive for N=0, and line 4 through 265 inclusive for N=1). Any 185 other scan line is considered a component of the second field, and 186 the F bit will be set to 1. 188 V: 1 bit 189 When 1, indicates that the scan line is part of the vertical 190 interval. Should always be 0 unless frame blanking data is sent. In 191 which case, the V bit should be set to 1 for scan lines which do not 192 form an integral part of the image. For receivers which do not 193 receive scan lines during the vertical interval, BT.656 vertical 194 interval data should be generated by repeating the 4-byte sequence 195 0x80, 0x10, 0x80, 0x10, representing a true black level. 197 Reserved: 15 bits 198 Reserved for future use, must be set to zero. 200 Scan Line (SL): 12 bits 201 Indicates the scan line encapsulated in the payload. Valid values 202 range from 1 through 625 inclusive. If no frame blanking data is 203 being transmitted, only scan lines 23 through 310 inclusive, and 204 lines 336 through 623 inclusive should be sent in the case of N=0. 205 For 525/60 encoding (N=1), scan lines 10 through 263 inclusive and 206 lines 273 through 525 should be transmitted. 208 If a receiver is generating a BT.656-3 data stream directly from this 209 stream, the F and V bits must be copied from the header rather than 210 being generated implicitly from the scan line number. In the event 211 of a conflict, the F and V bits have precedence. 213 6. Payload Format 215 In keeping with the 4:2:2 color subsampling of BT.656 and BT.601, for 216 each pair of color-difference samples, two luminance samples will be 217 transmitted. As per BT.656, the format for transmission shall be Cb, 218 Y, Cr, Y. The following is a representation of a 720 sample packet: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Cb0 | Y0 | Cr0 | Y1 | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Cb1 | Y2 | Cr1 | Y3 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 . 228 . 229 . 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Cb359 | Y718 | Cr359 | Y719 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 1144 and 1152 sample packets should increase the packet size 235 accordingly while maintaining the sample order. 237 7. References 238 [1] RTP: A Transport Protocol for Real-Time Applications, H. 239 Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RFC 1889. 240 [2] Interfaces for Digital Component Video Signals in 525-Line and 241 625-Line Television Systems operating at the 4:2:2 Level of 242 Recommendation ITU-R BT.601 (Part A), ITU-R Recommendation 243 BT.656-3, 1995. 244 [3] Studio Encoding Parameters of Digital Television for Standard 4:3 245 and Wide-Screen 16:9 Aspect Ratios, ITU-R Recommendation BT.601-5, 246 1995. 247 [4] RTP Profile for Audio and Video Conference with Minimal Control, 248 H. Schulzrinne, RFC 1890. 250 8. Authors Address 252 Dermot Tynan 253 Claddagh Films Limited 254 3 White Oaks 255 Clybaun Road 256 Galway 257 Ireland 259 Email: dtynan@claddagh.ie 260 Tel: +353 91 529944