idnits 2.17.1 draft-ietf-avt-jpeg-03.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-24) 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. ** 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 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. ** There are 22 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 17 has weird spacing: '...working docu-...' == Line 19 has weird spacing: '...t other group...' == Line 20 has weird spacing: '...cuments as In...' == Line 23 has weird spacing: '... may be updat...' == Line 24 has weird spacing: '...other documen...' == (6 more instances...) -- 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 (July 7, 1996) is 10153 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Annex F' on line 104 == Missing Reference: '64' is mentioned on line 604, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Audio-Video Transport Working Group 2 INTERNET-DRAFT L. Berc 3 draft-ietf-avt-jpeg-03.txt Digital Equipment Corporation 4 W. Fenner 5 Xerox PARC 6 R. Frederick 7 Xerox PARC 8 S. McCanne 9 Lawrence Berkeley Laboratory 10 July 7, 1996 11 Expires: 1/1/97 13 RTP Payload Format for JPEG-compressed Video 15 Status of this Memo 17 This document is an Internet Draft. Internet Drafts are working docu- 18 ments of the Internet Engineering Task Force (IETF), its Areas, and 19 its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts). 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 "working draft" or "work in progress." 28 Please check the I-D abstract listing contained in each Internet 29 Draft directory to learn the current status of this or any other Inter- 30 net Draft. 32 Distribution of this document is unlimited. 34 Abstract 36 This draft describes the RTP payload format for JPEG video streams. 37 The packet format is optimized for real-time video streams where 38 codec parameters change rarely from frame to frame. 40 This document is a product of the Audio-Video Transport working group 41 within the Internet Engineering Task Force. Comments are solicited and 42 should be addressed to the working group's mailing list at rem- 43 conf@es.net and/or the author(s). 45 1. Introduction 47 The Joint Photographic Experts Group (JPEG) standard [1,2,3] defines a 48 family of compression algorithms for continuous-tone, still images. 49 This still image compression standard can be applied to video by 50 compressing each frame of video as an independent still image and 51 transmitting them in series. Video coded in this fashion is often 52 called Motion-JPEG. 54 We first give an overview of JPEG and then describe the specific subset 55 of JPEG that is supported in RTP and the mechanism by which JPEG frames 56 are carried as RTP payloads. 58 The JPEG standard defines four modes of operation: the sequential DCT 59 mode, the progressive DCT mode, the lossless mode, and the hierarchical 60 mode. Depending on the mode, the image is represented in one or more 61 passes. Each pass (called a frame in the JPEG standard) is further bro- 62 ken down into one or more scans. Within each scan, there are one to 63 four components,which represent the three components of a color signal 64 (e.g., ``red, green, and blue'', or a luminance signal and two chroman- 65 ince signals). These components can be encoded as separate scans or 66 interleaved into a single scan. 68 Each frame and scan is preceded with a header containing optional defin- 69 itions for compression parameters like quantization tables and Huffman 70 coding tables. The headers and optional parameters are identified with 71 ``markers'' and comprise a marker segment; each scan appears as an 72 entropy-coded bit stream within two marker segments. Markers are 73 aligned to byte boundaries and (in general) cannot appear in the 74 entropy-coded segment, allowing scan boundaries to be determined without 75 parsing the bit stream. 77 Compressed data is represented in one of three formats: the interchange 78 format, the abbreviated format, or the table-specification format. The 79 interchange format contains definitions for all the table used in the by 80 the entropy-coded segments, while the abbreviated format might omit some 81 assuming they were defined out-of-band or by a ``previous'' image. 83 The JPEG standard does not define the meaning or format of the com- 84 ponents that comprise the image. Attributes like the color space and 85 pixel aspect ratio must be specified out-of-band with respect to the 86 JPEG bit stream. The JPEG File Interchange Format (JFIF) [4] is a 87 defacto standard that provides this extra information using an applica- 88 tion marker segment (APP0). Note that a JFIF file is simply a JPEG 89 interchange format image along with the APP0 segment. In the case of 90 video, additional parameters must be defined out-of-band (e.g., frame 91 rate, interlaced vs. non-interlaced, etc.). 93 While the JPEG standard provides a rich set of algorithms for flexible 94 compression, cost-effective hardware implementations of the full stan- 95 dard have not appeared. Instead, most hardware JPEG video codecs imple- 96 ment only a subset of the sequential DCT mode of operation. Typically, 97 marker segments are interpreted in software (which ``re-programs'' the 98 hardware) and the hardware is presented with a single, interleaved 99 entropy-coded scan represented in the YUV color space. 101 2. JPEG Over RTP 103 To maximize interoperability among hardware-based codecs, we assume the 104 sequential DCT operating mode [1,Annex F] and restrict the set of pre- 105 defined RTP/JPEG ``type codes'' (defined below) to single-scan, inter- 106 leaved images. While this is more restrictive than even baseline JPEG, 107 many hardware implementation fall short of the baseline specification 108 (e.g., most hardware cannot decode non-interleaved scans). 110 In practice, most of the table-specification data rarely changes from 111 frame to frame within a single video stream. Therefore, RTP/JPEG data 112 is represented in abbreviated format, with all of the tables omitted 113 from the bit stream. Each image begins immediately with the (single) 114 entropy-coded scan. The information that would otherwise be in both the 115 frame and scan headers is represented entirely within a 64-bit RTP/JPEG 116 header (defined below) that lies between the RTP header and the JPEG 117 scan and is present in every packet. 119 While parameters like Huffman tables and color space are likely to 120 remain fixed for the lifetime of the video stream, other parameters 121 should be allowed to vary, notably the quantization tables and image 122 size (e.g., to implement rate-adaptive transmission or allow a user to 123 adjust the ``quality level'' or resolution manually). Thus explicit 124 fields in the RTP/JPEG header are allocated to represent this informa- 125 tion. Since only a small set of quantization tables are typically used, 126 we encode the entire set of quantization tables in a small integer 127 field. The image width and height are encoded explicitly. 129 Because JPEG frames are typically larger than the underlying network's 130 maximum packet size, frames must often be fragmented into several pack- 131 ets. One approach is to allow the network layer below RTP (e.g., IP) to 132 perform the fragmentation. However, this precludes rate-controlling the 133 resulting packet stream or partial delivery in the presence of loss. 134 For example, IP will not deliver a fragmented datagram to the applica- 135 tion if one or more fragments is lost, or IP might fragment an 8000 byte 136 frame into a burst of 8 back-to-back packets. Instead, RTP/JPEG defines 137 a simple fragmentation and reassembly scheme at the RTP level. 139 3. RTP/JPEG Packet Format 141 The RTP timestamp is in units of 90000Hz. The same timestamp must 142 appear across all fragments of a single frame. The RTP marker bit is 143 set in the last packet of a frame. 145 3.1. JPEG header 147 A special header is added to each packet that immediately follows the 148 RTP header: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type specific | Fragment Offset | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type | Q | Width | Height | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 3.1.1. Type specific: 8 bits 160 Interpretation depends on the value of the type field. 162 3.1.2. Fragment Offset: 24 bits 164 The Fragment Offset is the data offset in bytes of the current 165 packet in the JPEG scan. 167 3.1.3. Type: 8 bits 169 The type field specifies the information that would otherwise be 170 present in a JPEG abbreviated table-specification as well as the 171 additional JFIF-style parameters not defined by JPEG. Types 0-127 172 are reserved as fixed, well-known mappings to be defined by this 173 document and future revisions of this document. Types 128-255 are 174 free to be dynamically defined by a session setup protocol (which 175 is beyond the scope of this document). 177 3.1.4. Q: 8 bits 179 The Q field defines the quantization tables for this frame using an 180 algorithm that determined by the Type field (see below). 182 3.1.5. Width: 8 bits 184 This field encodes the width of the image in 8-pixel multiples 185 (e.g., a width of 40 denotes an image 320 pixels wide). 187 3.1.6. Height: 8 bits 189 This field encodes the height of the image in 8-pixel multiples 190 (e.g., a height of 30 denotes an image 240 pixels tall). 192 3.1.7. Data 194 The data following the RTP/JPEG header is an entropy-coded segment 195 consisting of a single scan. The scan header is not present and is 196 inferred from the RTP/JPEG header. The scan is terminated either 197 implicitly (i.e., the point at which the image is fully parsed), or 198 explicitly with an EOI marker. The scan may be padded to arbitrary 199 length with undefined bytes. (Existing hardware codecs generate 200 extra lines at the bottom of a video frame and removal of these 201 lines would require a Huffman-decoding pass over the data.) 203 As defined by JPEG, restart markers are the only type of marker 204 that may appear embedded in the entropy-coded segment. The ``type 205 code'' determines whether a restart interval is defined, and there- 206 fore whether restart markers may be present. It also determines if 207 the restart intervals will be aligned with RTP packets, allowing for 208 partial decode of frames, thus increasing resiliance to packet 209 drop. If restart markers are present, the 6-byte DRI segment (define 210 restart interval marker [1, Sec. B.2.4.4] precedes the scan). 212 JPEG markers appear explicitly on byte aligned boundaries beginning 213 with an 0xFF. A ``stuffed'' 0x00 byte follows any 0xFF byte gen- 214 erated by the entropy coder [1, Sec. B.1.1.5]. 216 4. Discussion 218 4.1. The Type Field 220 The Type field defines the abbreviated table-specification and addi- 221 tional JFIF-style parameters not defined by JPEG, since they are not 222 present in the body of the transmitted JPEG data. The Type field must 223 remain constant for the duration of a session. 225 Six type codes are currently defined. They correspond to an abbre- 226 viated table-specification indicating the ``Baseline DCT sequential'' 227 mode, 8-bit samples, square pixels, three components in the YUV color 228 space, standard Huffman tables as defined in [1, Annex K.3], and a 229 single interleaved scan with a scan component selector indicating 230 components 0, 1, and 2 in that order. The Y, U, and V color planes 231 correspond to component numbers 0, 1, and 2, respectively. Component 232 0 (i.e., the luminance plane) uses Huffman table number 0 and quantiz- 233 ation table number 0 (defined below) and components 1 and 2 (i.e., 234 the chrominance planes) use Huffman table number 1 and quantization 235 table number 1 (defined below). 237 Additionally, video is non-interlaced and unscaled (i.e., the aspect 238 ratio is determined by the image width and height). The frame rate is 239 variable and explicit via the RTP timestamp. 241 Six RTP/JPEG types are currently defined that assume all of the above. 242 The odd types have different JPEG sampling factors from the even ones: 244 horizontal vertical 245 types comp samp. fact. samp. fact. 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | 0/2/4 | 0 | 2 | 1 | 248 | 0/2/4 | 1 | 1 | 1 | 249 | 0/2/4 | 2 | 1 | 1 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | 1/3/5 | 0 | 2 | 2 | 252 | 1/3/5 | 1 | 1 | 1 | 253 | 1/3/5 | 2 | 1 | 1 | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 These sampling factors indicate that the chromanince components of type 257 0/2/4 video is downsampled horizontally by 2 (often called 4:2:2) while 258 the chrominance components of type 1/3/5 video are downsampled both 259 horizontally and vertically by 2 (often called 4:2:0). 261 The three pairs of types (0/1), (2/3) and (4/5) differ from each other 262 as follows: 264 0/1 : No restart markers are present in the entropy data. 265 No restriction is placed on the fragmentation of the stream into 266 RTP packets. 267 The type specific field is unused and must be zero. 269 2/3 : Restart markers are present in the entropy data. 270 The entropy data is preceded by a DRI marker segment, defining the 271 restart interval. 272 No restriction is placed on the fragmentation of the stream into 273 RTP packets. 274 The type specific field is unused and must be zero. 276 4/5 : Restart markers are present in the entropy data. 277 The entropy data is preceded by a DRI marker segment, defining the 278 restart interval. 279 Restart intervals are be sent as separate (possibly multiple) RTP 280 packets. 281 The type specific field (TSPEC) is used as follows: 282 A restart interval count (RCOUNT) is defined, which starts at 283 zero, and is incremented for each restart interval in the 284 frame. 286 The first packet of a restart interval gets TSPEC = RCOUNT. 287 Subsequent packets of the restart interval get TSPEC = 254, 288 except the final packet, which gets TSPEC = 255. 290 Additional types in the range 128-255 may be defined by external means, 291 such as a session protocol. 293 Appendix B contains C source code for transforming the RTP/JPEG header 294 parameters into the JPEG frame and scan headers that are absent from the 295 data payload. 297 4.2. The Q Field 299 The quantization tables used in the decoding process are algorithmically 300 derived from the Q field. The algorithm used depends on the type field 301 but only one algorithm is currently defined for the two types. 303 Both type 0 and type 1 JPEG assume two quantizations tables. These 304 tables are chosen as follows. For 1 <= Q <= 99, the Independent JPEG 305 Group's formula [5] is used to produce a scale factor S as: 307 S = 5000 / Q for 1 <= Q <= 50 308 = 200 - 2 * Q for 51 <= Q <= 99 310 This value is then used to scale Tables K.1 and K.2 from [1] (saturating 311 each value to 8-bits) to give quantization table numbers 0 and 1, 312 respectively. C source code is provided in Appendix A to compute these 313 tables. 315 For Q >= 100, a dynamically defined quantization table is used, which 316 might be specified by a session setup protocol. (This session protocol 317 is beyond the scope of this document). It is expected that the standard 318 quantization tables will handle most cases in practice, and dynamic 319 tables will be used rarely. Q = 0 is reserved. 321 4.3. Fragmentation and Reassembly 323 Since JPEG frames are large, they must often be fragmented. Frames 324 should be fragmented into packets in a manner avoiding fragmentation at 325 a lower level. When using restart markers, frames should be fragmented 326 such that each packet starts with a restart interval (see below). 328 Each packet that makes up a single frame has the same timestamp. The 329 fragment offset field is set to the byte offset of this packet within 330 the original frame. The RTP marker bit is set on the last packet in a 331 frame. 333 An entire frame can be identified as a sequence of packets beginning 334 with a packet having a zero fragment offset and ending with a packet 335 having the RTP marker bit set. Missing packets can be detected either 336 with RTP sequence numbers or with the fragment offset and lengths of 337 each packet. Reassembly could be carried out without the offset field 338 (i.e., using only the RTP marker bit and sequence numbers), but an effi- 339 cient single-copy implementation would not otherwise be possible in the 340 presence of misordered packets. Moreover, if the last packet of the 341 previous frame (containing the marker bit) were dropped, then a receiver 342 could not detect that the current frame is entirely intact. 344 4.4. Restart Markers 346 Restart markers indicate a point in the JPEG stream at which the Huffman 347 codec and DC predictors are reset, allowing partial decoding starting 348 at that point. The use of restart markers allows for robustness in the 349 face of packet loss. 351 RTP/JPEG Types 4/5 allow for partial decode of frames, due to the 352 alignment of restart intervals with RTP packets. The decoder knows it 353 has a whole restart interval when it gets sequence of packets with 354 contiguous RTP sequence numbers, starting with TSPEC<254 (RCOUNT) and 355 either ending with TSPEC==255, or TSPEC<255 and next packet's TSPEC<254 356 (or end of frame). 358 It can then decompress the RST interval, and paint it. The X and Y tile 359 offsets of the first MCU in the interval are given by:- 361 tile_offset = RCOUNT * restart_interval * 2 362 x_offset = tile_offset % frame_width_in_tiles 363 y_offset = tile_offset / frame_width_in_tiles 365 The MCUs in a restart interval may span multiple tile rows. 367 Decoders can, however, treat types 4/5 as types 2/3, simply reassembling 368 the entire frame and then decoding. 370 5. Security Considerations 372 Security issues are not discussed in this memo. 374 6. Authors' Addresses 376 Lance M. Berc 377 Systems Research Center 378 Digital Equipment Corporation 379 130 Lytton Ave 380 Palo Alto CA 94301 381 Phone: +1 415 853 2100 382 Email: berc@pa.dec.com 384 William C. Fenner 385 Xerox PARC 386 3333 Coyote Hill Road 387 Palo Alto, CA 94304 388 Phone: +1 415 812 4816 389 Email: fenner@cmf.nrl.navy.mil 391 Ron Frederick 392 Xerox PARC 393 3333 Coyote Hill Road 394 Palo Alto, CA 94304 395 Phone: +1 415 812 4459 396 Email: frederick@parc.xerox.com 398 Steven McCanne 399 Lawrence Berkeley Laboratory 400 M/S 46A-1123 401 One Cyclotron Road 402 Berkeley, CA 94720 403 Phone: +1 510 486 7520 404 Email: mccanne@ee.lbl.gov 406 7. References 408 [1] ISO DIS 10918-1. Digital Compression and Coding of Continuous-tone 409 Still Images (JPEG), CCITT Recommendation T.81. 411 [2] William B. Pennebaker, Joan L. Mitchell, JPEG: Still Image Data 412 Compression Standard, Van Nostrand Reinhold, 1993. 414 [3] Gregory K. Wallace, The JPEG Sill Picture Compression Standard, 415 Communications of the ACM, April 1991, Vol 34, No. 1, pp. 31-44. 417 [4] The JPEG File Interchange Format. Maintained by C-Cube Microsys- 418 tems, Inc., and available in 419 ftp://ftp.uu.net/graphics/jpeg/jfif.ps.gz. 421 [5] Tom Lane et. al., The Independent JPEG Group software JPEG codec. 422 Source code available in 423 ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v5.tar.gz. 425 Appendix A 427 The following code can be used to create a quantization table from a Q 428 factor: 430 /* 431 * Table K.1 from JPEG spec. 432 */ 433 static const int jpeg_luma_quantizer[64] = { 434 16, 11, 10, 16, 24, 40, 51, 61, 435 12, 12, 14, 19, 26, 58, 60, 55, 436 14, 13, 16, 24, 40, 57, 69, 56, 437 14, 17, 22, 29, 51, 87, 80, 62, 438 18, 22, 37, 56, 68, 109, 103, 77, 439 24, 35, 55, 64, 81, 104, 113, 92, 440 49, 64, 78, 87, 103, 121, 120, 101, 441 72, 92, 95, 98, 112, 100, 103, 99 442 }; 444 /* 445 * Table K.2 from JPEG spec. 446 */ 447 static const int jpeg_chroma_quantizer[64] = { 448 17, 18, 24, 47, 99, 99, 99, 99, 449 18, 21, 26, 66, 99, 99, 99, 99, 450 24, 26, 56, 99, 99, 99, 99, 99, 451 47, 66, 99, 99, 99, 99, 99, 99, 452 99, 99, 99, 99, 99, 99, 99, 99, 453 99, 99, 99, 99, 99, 99, 99, 99, 454 99, 99, 99, 99, 99, 99, 99, 99, 455 99, 99, 99, 99, 99, 99, 99, 99 456 }; 458 /* 459 * Call MakeTables with the Q factor and two int[64] return arrays 460 */ 461 void 462 MakeTables(int q, u_char *lum_q, u_char *chr_q) 463 { 464 int i; 465 int factor = q; 467 if (q < 1) factor = 1; 468 if (q > 99) factor = 99; 469 if (q < 50) 470 q = 5000 / factor; 471 else 472 q = 200 - factor*2; 474 for (i=0; i < 64; i++) { 475 int lq = ( jpeg_luma_quantizer[i] * q + 50) / 100; 476 int cq = ( jpeg_chroma_quantizer[i] * q + 50) / 100; 478 /* Limit the quantizers to 1 <= q <= 255 */ 479 if ( lq < 1) lq = 1; 480 else if ( lq > 255) lq = 255; 481 lum_q[i] = lq; 483 if ( cq < 1) cq = 1; 484 else if ( cq > 255) cq = 255; 485 chr_q[i] = cq; 486 } 487 } 489 Appendix B 491 The following routines can be used to create the JPEG marker segments 492 corresponding to the table-specification data that is absent from the 493 RTP/JPEG body. 495 u_char lum_dc_codelens[] = { 496 0, 1, 5, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 497 }; 498 u_char lum_dc_symbols[] = { 499 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 500 }; 502 u_char lum_ac_codelens[] = { 503 0, 2, 1, 3, 3, 2, 4, 3, 5, 5, 4, 4, 0, 0, 1, 0x7d, 504 }; 506 u_char lum_ac_symbols[] = { 507 0x01, 0x02, 0x03, 0x00, 0x04, 0x11, 0x05, 0x12, 508 0x21, 0x31, 0x41, 0x06, 0x13, 0x51, 0x61, 0x07, 509 0x22, 0x71, 0x14, 0x32, 0x81, 0x91, 0xa1, 0x08, 510 0x23, 0x42, 0xb1, 0xc1, 0x15, 0x52, 0xd1, 0xf0, 511 0x24, 0x33, 0x62, 0x72, 0x82, 0x09, 0x0a, 0x16, 512 0x17, 0x18, 0x19, 0x1a, 0x25, 0x26, 0x27, 0x28, 513 0x29, 0x2a, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 514 0x3a, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 515 0x4a, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 516 0x5a, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 517 0x6a, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 518 0x7a, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 519 0x8a, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 520 0x99, 0x9a, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, 521 0xa8, 0xa9, 0xaa, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 522 0xb7, 0xb8, 0xb9, 0xba, 0xc2, 0xc3, 0xc4, 0xc5, 523 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xd2, 0xd3, 0xd4, 524 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 0xe1, 0xe2, 525 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea, 526 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 527 0xf9, 0xfa, 528 }; 530 u_char chm_dc_codelens[] = { 531 0, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 532 }; 534 u_char chm_dc_symbols[] = { 535 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 536 }; 538 u_char chm_ac_codelens[] = { 539 0, 2, 1, 2, 4, 4, 3, 4, 7, 5, 4, 4, 0, 1, 2, 0x77, 540 }; 542 u_char chm_ac_symbols[] = { 543 0x00, 0x01, 0x02, 0x03, 0x11, 0x04, 0x05, 0x21, 544 0x31, 0x06, 0x12, 0x41, 0x51, 0x07, 0x61, 0x71, 545 0x13, 0x22, 0x32, 0x81, 0x08, 0x14, 0x42, 0x91, 546 0xa1, 0xb1, 0xc1, 0x09, 0x23, 0x33, 0x52, 0xf0, 547 0x15, 0x62, 0x72, 0xd1, 0x0a, 0x16, 0x24, 0x34, 548 0xe1, 0x25, 0xf1, 0x17, 0x18, 0x19, 0x1a, 0x26, 549 0x27, 0x28, 0x29, 0x2a, 0x35, 0x36, 0x37, 0x38, 550 0x39, 0x3a, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 551 0x49, 0x4a, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 552 0x59, 0x5a, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 553 0x69, 0x6a, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 554 0x79, 0x7a, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 555 0x88, 0x89, 0x8a, 0x92, 0x93, 0x94, 0x95, 0x96, 556 0x97, 0x98, 0x99, 0x9a, 0xa2, 0xa3, 0xa4, 0xa5, 557 0xa6, 0xa7, 0xa8, 0xa9, 0xaa, 0xb2, 0xb3, 0xb4, 558 0xb5, 0xb6, 0xb7, 0xb8, 0xb9, 0xba, 0xc2, 0xc3, 559 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xd2, 560 0xd3, 0xd4, 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 561 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 562 0xea, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 563 0xf9, 0xfa, 564 }; 566 u_char * 567 MakeQuantHeader(u_char *p, u_char *qt, int tableNo) 568 { 569 *p++ = 0xff; 570 *p++ = 0xdb; /* DQT */ 571 *p++ = 0; /* length msb */ 572 *p++ = 67; /* length lsb */ 573 *p++ = tableNo; 574 memcpy(p, qt, 64); 575 return (p + 64); 576 } 578 u_char * 579 MakeHuffmanHeader(u_char *p, u_char *codelens, int ncodes, u_char *symbols, 580 int nsymbols, int tableNo, int tableClass) 581 { 582 *p++ = 0xff; 583 *p++ = 0xc4; /* DHT */ 584 *p++ = 0; /* length msb */ 585 *p++ = 3 + ncodes + nsymbols; /* length lsb */ 586 *p++ = tableClass << 4 | tableNo; 587 memcpy(p, codelens, ncodes); 588 p += ncodes; 589 memcpy(p, symbols, nsymbols); 590 p += nsymbols; 591 return (p); 592 } 593 /* 594 * Given an RTP/JPEG type code, q factor, width, and height, 595 * generate a frame and scan headers that can be prepended 596 * to the RTP/JPEG data payload to produce a JPEG compressed 597 * image in interchange format (except for possible trailing 598 * garbage and absence of an EOI marker to terminate the scan). 599 */ 600 int MakeHeaders(u_char *p, int type, int q, int w, int h) 601 { 602 u_char *start = p; 603 u_char lqt[64]; 604 u_char cqt[64]; 606 /* convert from blocks to pixels */ 607 w <<= 3; 608 h <<= 3; 610 MakeTables(q, lqt, cqt); 612 *p++ = 0xff; 613 *p++ = 0xd8; /* SOI */ 615 p = MakeQuantHeader(p, lqt, 0); 616 p = MakeQuantHeader(p, cqt, 1); 618 p = MakeHuffmanHeader(p, lum_dc_codelens, sizeof(lum_dc_codelens), 619 lum_dc_symbols, sizeof(lum_dc_symbols), 0, 0); 620 p = MakeHuffmanHeader(p, lum_ac_codelens, sizeof(lum_ac_codelens), 621 lum_ac_symbols, sizeof(lum_ac_symbols), 0, 1); 622 p = MakeHuffmanHeader(p, chm_dc_codelens, sizeof(chm_dc_codelens), 623 chm_dc_symbols, sizeof(chm_dc_symbols), 1, 0); 624 p = MakeHuffmanHeader(p, chm_ac_codelens, sizeof(chm_ac_codelens), 625 chm_ac_symbols, sizeof(chm_ac_symbols), 1, 1); 627 *p++ = 0xff; 628 *p++ = 0xc0; /* SOF */ 629 *p++ = 0; /* length msb */ 630 *p++ = 17; /* length lsb */ 631 *p++ = 8; /* 8-bit precision */ 632 *p++ = h >> 8; /* height msb */ 633 *p++ = h; /* height lsb */ 634 *p++ = w >> 8; /* width msb */ 635 *p++ = w; /* wudth lsb */ 636 *p++ = 3; /* number of components */ 637 *p++ = 0; /* comp 0 */ 638 if (type == 0) 639 *p++ = 0x21; /* hsamp = 2, vsamp = 1 */ 640 else 641 *p++ = 0x22; /* hsamp = 2, vsamp = 2 */ 642 *p++ = 0; /* quant table 0 */ 643 *p++ = 1; /* comp 1 */ 644 *p++ = 0x11; /* hsamp = 1, vsamp = 1 */ 645 *p++ = 1; /* quant table 1 */ 646 *p++ = 2; /* comp 2 */ 647 *p++ = 0x11; /* hsamp = 1, vsamp = 1 */ 648 *p++ = 1; /* quant table 1 */ 650 *p++ = 0xff; 651 *p++ = 0xda; /* SOS */ 652 *p++ = 0; /* length msb */ 653 *p++ = 12; /* length lsb */ 654 *p++ = 3; /* 3 components */ 655 *p++ = 0; /* comp 0 */ 656 *p++ = 0; /* huffman table 0 */ 657 *p++ = 1; /* comp 1 */ 658 *p++ = 0x11; /* huffman table 1 */ 659 *p++ = 2; /* comp 2 */ 660 *p++ = 0x11; /* huffman table 1 */ 661 *p++ = 0; /* first DCT coeff */ 662 *p++ = 63; /* last DCT coeff */ 663 *p++ = 0; /* sucessive approx. */ 665 return (p - start); 666 };