idnits 2.17.00 (12 Aug 2021) /tmp/idnits30117/draft-kobayashi-dv-audio12-00.txt: ** The Abstract section seems to be numbered 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. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 87: '... bit MUST be encodes first. The samp...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 1999) is 8186 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 274 looks like a reference -- Missing reference section? '2' on line 270 looks like a reference -- Missing reference section? '3' on line 237 looks like a reference -- Missing reference section? '4' on line 240 looks like a reference -- Missing reference section? '5' on line 242 looks like a reference -- Missing reference section? '0' on line 274 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Katsushi Kobayashi 2 draft-kobayashi-dv-audio12-00.txt Communication Research Laboratory 3 Akimichi Ogawa 4 Keio University 5 Stephen Casner 6 Cisco Systems 7 Carsten Bormann 8 Universitaet Bremen TZI 9 June 25, 1999 10 Expires December 1999 12 RTP Payload Format for nonlinear 12 bits Audio on DV 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 1. Abstract 37 This document specifies the packetization scheme for encapsulating 38 the 12 bits nonlinear audio data streams used in "DV" video into a 39 payload of the Real-Time Transport Protocol (RTP). 41 2. Introduction 43 This document provides the information of 12 bits nonlinear audio 44 used in the DV format and specifies the encapsulation into the Real- 45 time Transport Protocol (RTP), version 2 [1,2]. Also, this document 46 just specifies the differenticated part of 16 bit linear audio as L16 47 [3,4]. Reader is recommended to consult the L16 document with this 48 one. 50 3. The need for the RTP encapsulation for 12 bits nonlinear DV audio. 52 The HD Digital VCR Conference has published a digital video 53 specification set entitled "Specification of Consumer-Use Digital 54 VCRs using 6.3mm magnetic tape" [1]. The digital video format 55 defined by that specification is commonly known as "DV" format. The 56 original DV format treats whole of the data including audio and video 57 as single bundled stream data. On the other hand, RTP recommends 58 that different media data will transport different RTP streams, even 59 if the both streams made by the same source. Therefore, RTP 60 encapsulation format of DV stream also recommends audio and video 61 streams transport different RTP streams with its corresponding RTP 62 format. In the DV standard, audio data encodes PCM and three types 63 of encoding format are defined, i.e. 16 bits linear 20 bits linear 64 and 12 bits nonlinear.(20 bits linear has not been used yet.) The 65 RTP encapsulation format for audio previously published supports 16 66 bits linear audio only [3,4]. 68 The format of 12 bits nonlinear DV audio is congruent with 16 bits 69 linear audio except the format of single sampled data element. An 70 element of 12 bits nonlinear audio data can be obtained from the 71 single sampled element of 16 bits linear one. It is not difficult to 72 convert 12 bits nonlinear into 16 bits linear on the sender side and 73 send it as L16 audio previously defined. However, the amount of the 74 data size of 16 bits increases 33% compared with the 12 bits and it 75 waste network bandwidth with meaningless data. 77 4. 12 bits nonlinear audio format in DV (DV12) 79 The data of 12 bits nonlinear DV audio is derived from the single 80 sampled data of the 16 bit linear audio format. The conversion detail 81 between 16 and 12 bits is shown in the Table. Three levels of 82 sampling frequency are defined in the DV specification, i.e. 32kHz, 83 44.1kHz and 48kHz. All the values are included by the samplig rates 84 listed in L16 documents. And other parameters, encapsulation format 85 and also MIME description are discussed in L16 document. When 12 86 bits size sampled data is packed into payload, the most significant 87 bit MUST be encodes first. The sample code for packing 12 bits DV 88 audio into RTP payload is shown in Appendix. 12 bits length of a 89 sampled data does not accord to the 8 bits byte boundary of RTP 90 payload. When odd number of samples in the payload, four LSBs data 91 of the last byte is unused. 93 16 bits linear (X) 12 bits nonlinear (Y) 94 ------------------------------------------------------------ 95 32,767 (7FFFh) Y = INT(X/64) + (600h) 2,047 (7FFh) 96 16,384 (4000h) 1,792 (700h) 98 ------------------------------------------------------------ 99 16,383 (3FFFh) Y = INT(X/32) + (500h) 1,791 (6FFh) 100 8,192 (2000h) 1,536 (600h) 101 ------------------------------------------------------------ 102 8,191 (1FFFh) Y = INT(X/16) + (400h) 1,535 (5FFh) 103 4,096 (1000h) 1,280 (500h) 104 ------------------------------------------------------------ 105 4,095 (0FFFh) Y = INT(X/8) + (300h) 1,279 (4FFh) 106 2,048 (0800h) 1,024 (400h) 107 ------------------------------------------------------------ 108 2,047 (07FFh) Y = INT(X/4) + (200h) 1,023 (3FFh) 109 1,024 (0400h) 768 (300h) 110 ------------------------------------------------------------ 111 1,023 (03FFh) Y = INT(X/2) + (100h) 767 (2FFh) 112 512 (0200h) 512 (200h) 113 ------------------------------------------------------------ 114 511 (01FFh) Y = X 511 (1FFh) 115 0 (0000h) 0 (000h) 116 ------------------------------------------------------------ 117 -1 (FFFFh) Y = X -1 (FFFh) 118 -512 (FE00h) -512 (E00h) 119 ------------------------------------------------------------ 120 -513 (FFFFh) Y = INT((X + 1)/2) - (101h) -513 (DFFh) 121 -1,024 (FE00h) -768 (D00h) 122 ------------------------------------------------------------ 123 -1,025 (FBFFh) Y = INT((X + 1)/4) - (201h) -769 (CFFh) 124 -2,048 (F800h) -1,024 (C00h) 125 ------------------------------------------------------------ 126 -2,049 (F7FFh) Y = INT((X + 1)/8) - (301h) -1,025 (BFFh) 127 -4,096 (F000h) -1,280 (B00h) 128 ------------------------------------------------------------ 129 -4,097 (EFFFh) Y = INT((X + 1)/16) - (401h) -1,281 (AFFh) 130 -8,192 (E000h) -1,536 (A00h) 131 ------------------------------------------------------------ 132 -8,193 (DFFFh) Y = INT((X + 1)/32) - (501h) -1,537 (9FFh) 133 -16,384 (C000h) -1,792 (900h) 134 ------------------------------------------------------------ 135 -16,385 (BFFFh) Y = INT((X + 1)/64) - (601h) -1,793 (8FFh) 136 -32,768 (8000h) -2,048 (800h) 137 ------------------------------------------------------------ 138 Table. Conversion between 16 bits to 12 bits [1] 140 6. Security Considerations 142 RTP packets using the payload format defined in this specification 143 are subject to the security considerations discussed in the RTP 144 specification [2], and any appropriate RTP profile. This implies 145 that confidentiality of the media streams is achieved by encryption. 147 Because the data compression used with this payload format is applied 148 end-to-end, encryption may be performed after compression so there is 149 no conflict between the two operations. 151 A potential denial-of-service threat exists for data encodings using 152 compression techniques that have non-uniform receiver-end 153 computational load. The attacker can inject pathological datagrams 154 into the stream which are complex to decode and cause the receiver to 155 be overloaded. However, this encoding does not exhibit any 156 significant non-uniformity. 158 As with any IP-based protocol, in some circumstances a receiver may 159 be overloaded simply by the receipt of too many packets, either 160 desired or undesired. Network-layer authentication may be used to 161 discard packets from undesired sources, but the processing cost of 162 the authentication itself may be too high. In a multicast 163 environment, pruning of specific sources may be implemented in future 164 versions of IGMP [5] and in multicast routing protocols to allow a 165 receiver to select which sources are allowed to reach it. 167 7. Full Copyright Statement 169 Copyright (C) The Internet Society (1999). All Rights Reserved. 171 This document and translations of it may be copied and furnished to 172 others, and derivative works that comment on or otherwise explain it 173 or assist in its implementation may be prepared, copied, published 174 and distributed, in whole or in part, without restriction of any 175 kind, provided that the above copyright notice and this paragraph are 176 included on all such copies and derivative works. 178 However, this document itself may not be modified in any way, such as 179 by removing the copyright notice or references to the Internet Soci- 180 ety or other Internet organizations, except as needed for the purpose 181 of developing Internet standards in which case the procedures for 182 copyrights defined in the Internet Standards process must be fol- 183 lowed, or as required to translate it into languages other than 184 English. 186 The limited permissions granted above are perpetual and will not be 187 revoked by the Internet Society or its successors or assigns. 189 This document and the information contained herein is provided on an 190 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 191 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 192 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 193 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 194 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 196 8. Authors' Addresses 198 Katsushi Kobayashi 199 Communication Research Laboratory 200 4-2-1 Nukii-kita machi, Koganei 201 Tokyo 184-8795 202 JAPAN 203 EMail: ikob@koganei.wide.ad.jp 205 Akimichi Ogawa 206 Keio University 207 5322 Endo, Fujisawa 208 Kanagawa 252 209 JAPAN 210 EMail: akimichi@sfc.wide.ad.jp 212 Stephen L. Casner 213 Cisco Systems, Inc. 214 170 West Tasman Drive 215 San Jose, CA 95134-1706 216 United States 217 EMail: casner@cisco.com 219 Carsten Bormann 220 Universitaet Bremen FB3 TZI 221 Postfach 330440 222 D-28334 Bremen, GERMANY 223 Phone: +49.421.218-7024 224 Fax: +49.421.218-7000 225 EMail: cabo@tzi.org 227 10. Bibliography 229 [1] IEC 61834, Helical-scan digital video cassette recording system 230 using 6,35 mm magnetic tape for consumer use (525-60, 625-50, 231 1125-60 and 1250-50 systems) 233 [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A 234 transport protocol for real-time applications. IETF Audio/Video 235 Transport Working Group, January 1996. RFC1889. 237 [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 238 with Minimal Control", RFC 1890, January 1996. 240 [4] Salsman, J., "The Audio/L16 MIME content type", RFC 2586, May 1999 242 [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, 243 RFC 1112, August 1989. 245 Appendix A. Sample code for packing and unpacking 247 int pack12(short[] s, unsigned char[] b1, int n) { 248 unsigned char *b = b1; 249 while (n >= 2) { 250 n -= 2; 251 int s1 = *s++; 252 int s2 = *s++; 253 *b++ = s1 >> 4; 254 *b++ = s1 << 4 + ((s2 >> 4) & 0xF); 255 *b++ = s2; 256 } 257 if (n == 1) { 258 int s1 = *s++; 259 *b++ = s1 >> 4; 260 *b++ = s1 << 4; 261 } 262 return b - b1; 263 } 265 int unpack12(unsigned char[] b, short[] s1, int n) { 266 short *s = s1; 267 while (n >= 3) { 268 n -= 3; 269 *s++ = b[0] << 4 + b[1] >> 4; 270 *s++ = b[1] << 8 + b[2]; 271 b += 3; 272 } 273 if (n == 2) { 274 *s++ = b[0] << 4 + b[1] >> 4; 275 } else if (n == 1) { 276 error("alignment error"); 277 } 278 return s - s1; 279 }