idnits 2.17.1 draft-ietf-avt-jpeg-new-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. ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 13 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 174 has weird spacing: '.... The first...' == Line 235 has weird spacing: '... header when...' == Line 236 has weird spacing: '...using types 6...' == Line 367 has weird spacing: '...izontal vert...' == Line 368 has weird spacing: '... types compo...' == (2 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 (September 1998) is 9355 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 126 == Missing Reference: '64' is mentioned on line 808, 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' ** Obsolete normative reference: RFC 1889 (ref. '6') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '7') (Obsoleted by RFC 3551) -- Unexpected draft version: The latest known version of draft-ietf-idmr-igmp-v2 is -07, but you're referring to -08. Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 10 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-new-01.txt Digital Equipment Corporation 4 W. Fenner 5 Xerox PARC 6 R. Frederick 7 Xerox PARC 8 S. McCanne 9 Lawrence Berkeley Laboratory 10 P. Stewart 11 Xerox PARC 12 March 6, 1998 13 Expires September 1998 15 RTP Payload Format for JPEG-compressed Video 17 Status of this Memo 19 This document is an Internet Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its Areas, and 21 its Working Groups. Note that other groups may also distribute working 22 documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six months. 25 Internet Drafts may be updated, replaced, or obsoleted by other 26 documents at any time. It is not appropriate to use Internet Drafts as 27 reference material or to cite them other than as a "working draft" or 28 "work in progress." 30 To learn the current status of any Internet-Draft, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 33 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 34 ftp.isi.edu (US West Coast). 36 Distribution of this document is unlimited. 38 Abstract 40 This memo describes the RTP payload format for JPEG video streams. 41 The packet format is optimized for real-time video streams where 42 codec parameters change rarely from frame to frame. 44 This document is a product of the Audio-Video Transport working group 45 within the Internet Engineering Task Force. Comments are solicited and 46 should be addressed to the working group's mailing list at rem- 47 conf@es.net and/or the author(s). 49 Changes from RFC 2035 51 Most of this draft is identical to RFC 2035. The changes made to the 52 protocol are summarized in Appendix D. 54 1. Introduction 56 The Joint Photographic Experts Group (JPEG) standard [1,2,3] defines a 57 family of compression algorithms for continuous-tone, still images. 58 This still image compression standard can be applied to video by 59 compressing each frame of video as an independent still image and 60 transmitting them in series. Video coded in this fashion is often 61 called Motion-JPEG. 63 We first give an overview of JPEG and then describe the specific subset 64 of JPEG that is supported in RTP and the mechanism by which JPEG frames 65 are carried as RTP payloads. 67 The JPEG standard defines four modes of operation: the sequential DCT 68 mode, the progressive DCT mode, the lossless mode, and the hierarchical 69 mode. Depending on the mode, the image is represented in one or more 70 passes. Each pass (called a frame in the JPEG standard) is further 71 broken down into one or more scans. Within each scan, there are one to 72 four components, which represent the three components of a color signal 73 (e.g., "red, green, and blue", or a luminance signal and two chrominance 74 signals). These components can be encoded as separate scans or 75 interleaved into a single scan. 77 Each frame and scan is preceded with a header containing optional 78 definitions for compression parameters like quantization tables and 79 Huffman coding tables. The headers and optional parameters are 80 identified with "markers" and comprise a marker segment; each scan 81 appears as an entropy-coded bit stream within two marker segments. 82 Markers are aligned to byte boundaries and (in general) cannot appear in 83 the entropy-coded segment, allowing scan boundaries to be determined 84 without parsing the bit stream. 86 Compressed data is represented in one of three formats: the interchange 87 format, the abbreviated format, or the table-specification format. The 88 interchange format contains definitions for all the tables used by the 89 entropy-coded segments, while the abbreviated format might omit some 90 assuming they were defined out-of-band or by a "previous" image. 92 The JPEG standard does not define the meaning or format of the 93 components that comprise the image. Attributes like the color space and 94 pixel aspect ratio must be specified out-of-band with respect to the 95 JPEG bit stream. The JPEG File Interchange Format (JFIF) [4] is a de- 96 facto standard that provides this extra information using an application 97 marker segment (APP0). Note that a JFIF file is simply a JPEG 98 interchange format image along with the APP0 segment. In the case of 99 video, additional parameters must be defined out-of-band (e.g., frame 100 rate, interlaced vs. non-interlaced, etc.). 102 While the JPEG standard provides a rich set of algorithms for flexible 103 compression, cost-effective hardware implementations of the full 104 standard have not appeared. Instead, most hardware JPEG video codecs 105 implement only a subset of the sequential DCT mode of operation. 106 Typically, marker segments are interpreted in software (which "re- 107 programs" the hardware) and the hardware is presented with a single, 108 interleaved entropy-coded scan represented in the YUV color space. 110 The scan contains an ordered sequence of Minimum Coded Units, or MCUs, 111 which are the smallest group of image data coded in a JPEG bit stream. 112 Each MCU defines the image data for a small rectangular block of the 113 output image. 115 Restart markers in the JPEG data denote a point where the decoder should 116 reset its state. As defined by JPEG, restart markers are the only type 117 of marker that may appear embedded in the entropy-coded segment, and 118 they may only appear on an MCU boundary. A "restart interval" is 119 defined to be a block of data containing a restart marker followed by 120 some fixed number of MCUs. When these markers are used, each frame is 121 composed of some fixed number of back-to-back restart intervals. 123 2. JPEG Over RTP 125 To maximize interoperability among hardware-based codecs, we assume the 126 sequential DCT operating mode [1,Annex F] and restrict the set of 127 predefined RTP/JPEG "type codes" (defined below) to single-scan, 128 interleaved images. While this is more restrictive than even baseline 129 JPEG, many hardware implementation fall short of the baseline 130 specification (e.g., most hardware cannot decode non-interleaved scans). 132 In practice, most of the table-specification data rarely changes from 133 frame to frame within a single video stream. Therefore RTP/JPEG data is 134 represented in abbreviated format, with all of the tables omitted from 135 the bit stream where possible. Each frame begins immediately with the 136 (single) entropy-coded scan. The information that would otherwise be in 137 both the frame and scan headers is represented entirely within the 138 RTP/JPEG header (defined below) that lies between the RTP header and the 139 JPEG payload. 141 While parameters like Huffman tables and color space are likely to 142 remain fixed for the lifetime of the video stream, other parameters 143 should be allowed to vary, notably the quantization tables and image 144 size (e.g., to implement rate-adaptive transmission or allow a user to 145 adjust the "quality level" or resolution manually). Thus explicit 146 fields in the RTP/JPEG header are allocated to represent this 147 information. Since only a small set of quantization tables are 148 typically used, we encode the entire set of quantization tables in a 149 small integer field. Customized quantization tables are accommodated by 150 using a special range of values in this field, and then placing the 151 table before the beginning of the JPEG payload. The image width and 152 height are encoded explicitly. 154 Because JPEG frames are typically larger than the underlying network's 155 maximum packet size, frames must often be fragmented into several 156 packets. One approach is to allow the network layer below RTP (e.g., 157 IP) to perform the fragmentation. However, this precludes rate- 158 controlling the resulting packet stream or partial delivery in the 159 presence of loss. For example, IP will not deliver a fragmented 160 datagram to the application if one or more fragments is lost, or IP 161 might fragment an 8000 byte frame into a burst of 8 back-to-back 162 packets. Instead, RTP/JPEG defines a simple fragmentation and 163 reassembly scheme at the RTP level. 165 3. RTP/JPEG Packet Format 167 The RTP timestamp is in units of 90000Hz. The same timestamp must 168 appear in each fragment of a given frame. The RTP marker bit is set in 169 the last packet of a frame. 171 3.1. JPEG header 173 Each packet contains a special JPEG header which immediately follows the 174 RTP header. The first 8 bytes of this header, called the "main JPEG 175 header", are as follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type-specific | Fragment Offset | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Type | Q | Width | Height | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 A Restart Marker header and/or Quantization Table header may follow this 186 header, depending on the values of the Type and Q fields. 188 3.1.1. Type-specific: 8 bits 190 Interpretation depends on the value of the type field. If no 191 interpretation is specified, this field must be zeroed on transmission 192 and ignored on reception. 194 3.1.2. Fragment Offset: 24 bits 196 The Fragment Offset is the offset in bytes of the current packet in the 197 JPEG frame data. 199 3.1.3. Type: 8 bits 201 The type field specifies the information that would otherwise be present 202 in a JPEG abbreviated table-specification as well as the additional 203 JFIF-style parameters not defined by JPEG. Types 0-63 are reserved as 204 fixed, well-known mappings to be defined by this document and future 205 revisions of this document. Types 64-127 are the same as types 0-63, 206 except that restart markers are present in the JPEG data and a Restart 207 Marker header appears immediately following the main JPEG header. Types 208 128-255 are free to be dynamically defined by a session setup protocol 209 (which is beyond the scope of this document). 211 3.1.4. Q: 8 bits 213 The Q field defines the quantization tables for this frame. Q values 214 0-127 indicate the quantization tables are computed using an algorithm 215 determined by the Type field (see below). Q values 128-255 indicate 216 that a Quantization Table header appears after the main JPEG header (and 217 the Restart Marker header, if present) in the first packet of the frame 218 (fragment offset 0). This header can be used to explicitly specify the 219 quantization tables in-band. 221 3.1.5. Width: 8 bits 223 This field encodes the width of the image in 8-pixel multiples (e.g., a 224 width of 40 denotes an image 320 pixels wide). The maximum width is 225 2040 pixels. 227 3.1.6. Height: 8 bits 229 This field encodes the height of the image in 8-pixel multiples (e.g., a 230 height of 30 denotes an image 240 pixels tall). The maximum height is 231 2040 pixels. 233 3.1.7. Restart Marker header 235 This header must be present immediately after the main JPEG header when 236 using types 64-127. It provides the additional information required to 237 properly decode a data stream containing restart markers. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Restart Interval |F|L| Restart Count | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 The Restart Interval field specifies the number of MCUs that appear 246 between restart markers. It is identical to the 16 bit value that 247 appears in the DRI marker segment in JFIF headers. This value must not 248 be zero. 250 If the restart intervals in a frame are not guaranteed to be aligned 251 with packet boundaries, the F and L bits must be set to 1 and the 252 Restart Count must be set to 0x3FFF. This indicates that a receiver 253 must reassemble the entire frame before decoding it. 255 To support partial frame decoding, the frame is broken into "chunks" 256 each containing an integral number of restart intervals. The Restart 257 Count field contains the position of the first restart interval in the 258 current "chunk" so that receivers know which part of the frame this data 259 corresponds to. Generally, a Restart Interval value should be chosen to 260 allow a "chunk" to completely fit within a single packet. In this case, 261 both the F and L bits of the packet are set to 1. However, if a chunk 262 needs to be spread across multiple packets, the F bit will be set to 1 263 in the first packet of the chunk (and only that one) and the L bit will 264 be set to 1 in the last packet of the chunk (and only that one). 266 3.1.8. Quantization Table header 268 This header must be present after the main JPEG header (and after the 269 Restart Marker header, if present) when using Q values 128-255. It 270 provides a way to specify the quantization tables associated with this Q 271 value in-band. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | MBZ | Precision | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Quantization Table Data | 279 | ... | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 The Length field is set to the length in bytes of the quantization table 283 data to follow. The length field may be set to zero to indicate that no 284 quantization table data is included in this frame. 286 When table data is included, the number of tables present depends on the 287 JPEG type field. For example, type 0 uses two tables (one for the 288 luminance component and one shared by the chrominance components). Each 289 table is an array of 64 values given in zig-zag order, identical to the 290 format used in a JFIF DQT marker segment. 292 For each quantization table present, a bit in the Precision field 293 specifies the size of the coefficients in that table. If the bit is 294 zero, the coefficients are 8 bits yielding a table length of 64 bytes. 295 If the bit is one, the coefficients are 16 bits for a table length of 296 128 bytes. For 16 bit tables, the coefficients are presented in network 297 byte order. The rightmost bit in the Precision field corresponds to the 298 first table and each additional table uses the next bit to the left. 299 Bits beyond those corresponding to the tables needed by the type in use 300 must be ignored. 302 For Q values from 128 to 254, the Q value to quantization table data 303 mapping must be static, i.e., the receivers are guaranteed that they 304 only need to read the table data once in order to correctly decode 305 frames sent with that Q value. A Q value of 255 denotes that the 306 quantization table mapping is dynamic and can change on every frame. 307 Decoders cannot depend on any previous version of the tables, and need 308 to reload these tables on every frame. It is illegal to set Q = 255 and 309 Length = 0. 311 3.1.9. JPEG Payload 313 The data following the RTP/JPEG headers is an entropy-coded segment 314 consisting of a single scan. The scan header is not present and is 315 inferred from the RTP/JPEG header. The scan is terminated either 316 implicitly (i.e., the point at which the image is fully parsed), or 317 explicitly with an EOI marker. The scan may be padded to arbitrary 318 length with undefined bytes. (Some existing hardware codecs generate 319 extra lines at the bottom of a video frame and removal of these lines 320 would require a Huffman-decoding pass over the data.) 322 The type code determines whether restart markers are present. The 323 restart count in the Restart Marker header determines if the restart 324 intervals will be aligned with RTP packets, allowing for partial 325 decoding of frames. Restart Markers markers appear explicitly on byte 326 aligned boundaries beginning with an 0xFF, between MCUs at the defined 327 restart interval. A "stuffed" 0x00 byte follows any 0xFF byte generated 328 by the entropy coder [1, Sec. B.1.1.5]. 330 4. Discussion 332 4.1. The Type Field 334 The Type field defines the abbreviated table-specification and 335 additional JFIF-style parameters not defined by JPEG, since they are not 336 present in the body of the transmitted JPEG data. 338 Three ranges of the type field are currently defined. Types 0-63 are 339 reserved as fixed, well-known mappings to be defined by this document 340 and future revisions of this document. Types 64-127 are the same as 341 types 0-63, except that restart markers are present in the JPEG data and 342 a Restart Marker header appears immediately following the main JPEG 343 header. Types 128-255 are free to be dynamically defined by a session 344 setup protocol (which is beyond the scope of this document). 346 Of the first group of fixed mappings, types 0 and 1 are currently 347 defined, along with the corresponding types 64 and 65 that indicate the 348 presence of restart markers. They correspond to an abbreviated table- 349 specification indicating the "Baseline DCT sequential" mode, 8-bit 350 samples, square pixels, three components in the YUV color space, 351 standard Huffman tables as defined in [1, Annex K.3], and a single 352 interleaved scan with a scan component selector indicating components 1, 353 2, and 3 in that order. The Y, U, and V color planes correspond to 354 component numbers 1, 2, and 3, respectively. Component 1 (i.e., the 355 luminance plane) uses Huffman table number 0 and quantization table 356 number 0 (defined below) and components 2 and 3 (i.e., the chrominance 357 planes) use Huffman table number 1 and quantization table number 1 358 (defined below). 360 Type numbers 2-5 are reserved and should not be used. Applications 361 based on previous versions of this document (RFC 2035) should be updated 362 to indicate the presence of restart markers with type 64 or 65 and the 363 Restart Marker header. 365 The two RTP/JPEG types currently defined are described below: 367 horizontal vertical Quantization 368 types component samp. fact. samp. fact. table number 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 1 (Y) | 2 | 1 | 0 | 371 | 0, 64 | 2 (U) | 1 | 1 | 1 | 372 | | 3 (V) | 1 | 1 | 1 | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | | 1 (Y) | 2 | 2 | 0 | 375 | 1, 65 | 2 (U) | 1 | 1 | 1 | 376 | | 3 (V) | 1 | 1 | 1 | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 These sampling factors indicate that the chrominance components of type 380 0 video is downsampled horizontally by 2 (often called 4:2:2) while the 381 chrominance components of type 1 video are downsampled both horizontally 382 and vertically by 2 (often called 4:2:0). 384 Types 0 and 1 can be used to carry both progressively scanned and 385 interlaced image data. This is encoded using the Type-specific field in 386 the main JPEG header. The following values are defined: 388 0 : Image is progressively scanned. On a computer monitor, it can 389 be displayed as-is at the specified width and height. 391 1 : Image is an odd field of an interlaced video signal. The 392 height specified in the main JPEG header is half of the height 393 of the entire displayed image. This field should be de- 394 interlaced with the even field following it such that lines 395 from each of the images alternate. Corresponding lines from 396 the even field should appear just above those same lines from 397 the odd field. 399 2 : Image is an even field of an interlaced video signal. 401 3 : Image is a single field from an interlaced video signal, but it 402 should be displayed full frame as if it were received as both 403 the odd & even fields of the frame. On a computer monitor, 404 each line in the image should be displayed twice, doubling the 405 height of the image. 407 Appendix B contains C source code for transforming the RTP/JPEG header 408 parameters into the JPEG frame and scan headers that are absent from the 409 data payload. 411 4.2. The Q Field 413 For JPEG types 0 and 1 (and their corresponding types 64 and 65), Q 414 values between 1 and 99 inclusive are defined as follows. Other values 415 less than 128 are reserved. Additional types are encouraged to use this 416 definition if applicable. 418 Both type 0 and type 1 JPEG require two quantization tables. These 419 tables are calculated as follows. For 1 <= Q <= 99, the Independent 420 JPEG Group's formula [5] is used to produce a scale factor S as: 422 S = 5000 / Q for 1 <= Q <= 50 423 = 200 - 2 * Q for 51 <= Q <= 99 425 This value is then used to scale Tables K.1 and K.2 from [1] (saturating 426 each value to 8 bits) to give quantization table numbers 0 and 1, 427 respectively. C source code is provided in Appendix A to compute these 428 tables. 430 For Q values 128-255, dynamically defined quantization tables are used. 431 These tables may be specified either in-band or out of band by something 432 like a session setup protocol, but the Quantization Table header must 433 always be present in the first packet of every frame. When the tables 434 are specified out of band, they may be omitted from the packet by 435 setting the Length field in this header to 0. 437 When the quantization tables are sent in-band, they need not be sent 438 with every frame. Like the out of band case, frames which do not 439 contain tables will have a Quantization Table header with a Length field 440 of 0. While this does decrease the overhead of including the tables, 441 new receivers will be unable to properly decode frames from the time 442 they start up until they receive the tables. 444 4.3. Fragmentation and Reassembly 446 Since JPEG frames can be large, they must often be fragmented. Frames 447 should be fragmented into packets in a manner avoiding fragmentation at 448 a lower level. If support for partial frame decoding is desired, frames 449 should be fragmented such that each packet contains an integral number 450 of restart intervals (see below). 452 Each packet that makes up a single frame has the same timestamp. The 453 fragment offset field is set to the byte offset of this packet within 454 the original frame. The RTP marker bit is set on the last packet in a 455 frame. 457 An entire frame can be identified as a sequence of packets beginning 458 with a packet having a zero fragment offset and ending with a packet 459 having the RTP marker bit set. Missing packets can be detected either 460 with RTP sequence numbers or with the fragment offset and lengths of 461 each packet. Reassembly could be carried out without the offset field 462 (i.e., using only the RTP marker bit and sequence numbers), but an 463 efficient single-copy implementation would not otherwise be possible in 464 the presence of misordered packets. Moreover, if the last packet of the 465 previous frame (containing the marker bit) were dropped, then a receiver 466 could not always detect that the current frame is entirely intact. 468 4.4. Restart Markers 470 Restart markers indicate a point in the JPEG stream at which the Huffman 471 decoder and DC predictors are reset, allowing partial decoding starting 472 at that point. To fully take advantage of this, however, a decoder must 473 know which MCUs of a frame a particular restart interval encodes. While 474 the original JPEG specification does provide a small sequence number 475 field in the restart markers for this purpose, it is not large enough to 476 properly cope with the loss of an entire packet's worth of data at a 477 typical network MTU size. The RTP/JPEG Restart Marker header contains 478 the additional information needed to accomplish this. 480 Ideally, the size of restart intervals should be chosen to always allow 481 an integral number of restart intervals to fit within a single packet. 482 This will guarantee that packets can be decoded independently from one 483 another. If a restart interval ends up being larger than a packet, the 484 F and L bits in the Restart Marker header can be used to fragment it, 485 but the resulting set of packets must all be received by a decoder for 486 that restart interval to be decoded properly. 488 Once a decoder has received either a single packet with both the F and L 489 bits set on or a contiguous sequence of packets (based on the RTP 490 sequence number) which begin with an F bit and end with an L bit, it can 491 begin decoding. The position of the MCU at the beginning of the data 492 can be determined by multiplying the Restart Count value by the Restart 493 Interval value. A packet (or group of packets as identified by the F 494 and L bits) may contain any number of consecutive restart intervals. 496 To accommodate encoders which generate frames with restart markers in 497 them but cannot fragment the data in this manner, the Restart Count 498 field may be set to 0x3FFF with the F and L bits both set to 1. This 499 indicates to decoders that the entire frame must be reassembled before 500 decoding it. 502 5. Security Considerations 504 RTP packets using the payload format defined in this specification are 505 subject to the security considerations discussed in the RTP 506 specification [6], and any appropriate RTP profile (for example [7]). 507 This implies that confidentiality of the media streams is achieved by 508 encryption. Because the data compression used with this payload format 509 is applied end-to-end, encryption may be performed after compression so 510 there is no conflict between the two operations. 512 A potential denial-of-service threat exists for data encodings using 513 compression techniques that have non-uniform receiver-end computational 514 load. The attacker can inject pathological datagrams into the stream 515 which are complex to decode and cause the receiver to be overloaded. 516 However, this encoding does not exhibit any significant non-uniformity. 518 As with any IP-based protocol, in some circumstances a receiver may be 519 overloaded simply by the receipt of too many packets, either desired or 520 undesired. Network-layer authentication may be used to discard packets 521 from undesired sources, but the processing cost of the authentication 522 itself may be too high. In a multicast environment, pruning of specific 523 sources may be implemented in future versions of IGMP [8] and in 524 multicast routing protocols to allow a receiver to select which sources 525 are allowed to reach it. 527 A security review of this payload format found no additional 528 considerations beyond those in the RTP specification. 530 6. Authors' Addresses 532 Lance M. Berc 533 Systems Research Center 534 Digital Equipment Corporation 535 130 Lytton Ave 536 Palo Alto CA 94301 538 Phone: +1 650 853 2100 539 EMail: berc@pa.dec.com 541 William C. Fenner 542 Xerox PARC 543 3333 Coyote Hill Road 544 Palo Alto, CA 94304 546 Phone: +1 650 812 4816 547 EMail: fenner@parc.xerox.com 548 Ron Frederick 549 Xerox PARC 550 3333 Coyote Hill Road 551 Palo Alto, CA 94304 553 Phone: +1 650 812 4459 554 EMail: frederick@parc.xerox.com 556 Steven McCanne 557 Lawrence Berkeley Laboratory 558 M/S 46A-1123 559 One Cyclotron Road 560 Berkeley, CA 94720 562 Phone: +1 510 486 7520 563 EMail: mccanne@ee.lbl.gov 565 Paul Stewart 566 Xerox PARC 567 3333 Coyote Hill Road 568 Palo Alto, CA 94304 570 Phone: +1 650 812 4821 571 EMail: stewart@parc.xerox.com 573 7. References 575 [1] ISO DIS 10918-1. Digital Compression and Coding of Continuous-tone 576 Still Images (JPEG), CCITT Recommendation T.81. 578 [2] William B. Pennebaker, Joan L. Mitchell, JPEG: Still Image Data 579 Compression Standard, Van Nostrand Reinhold, 1993. 581 [3] Gregory K. Wallace, The JPEG Sill Picture Compression Standard, 582 Communications of the ACM, April 1991, Vol 34, No. 1, pp. 31-44. 584 [4] The JPEG File Interchange Format. Maintained by C-Cube 585 Microsystems, Inc., and available in 586 ftp://ftp.uu.net/graphics/jpeg/jfif.ps.gz. 588 [5] Tom Lane et. al., The Independent JPEG Group software JPEG codec. 589 Source code available in 590 ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6a.tar.gz. 592 [6] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A 593 Transport Protocol for Real-Time Applications, RFC1889, Audio-Video 594 Transport Working Group 596 [7] H. Schulzrinne, RTP Profile for Audio and Video Conferences with 597 Minimal Control, RFC1890, GMD Fokus 599 [8] W. Fenner, Internet Group Management Protocol Version 2, RFCxxxx 600 (currently draft-ietf-idmr-igmp-v2-08.txt, in rfc-editor queue), 601 Xerox PARC 603 Appendix A 605 The following code can be used to create a quantization table from a Q 606 factor: 608 /* 609 * Table K.1 from JPEG spec. 610 */ 611 static const int jpeg_luma_quantizer[64] = { 612 16, 11, 10, 16, 24, 40, 51, 61, 613 12, 12, 14, 19, 26, 58, 60, 55, 614 14, 13, 16, 24, 40, 57, 69, 56, 615 14, 17, 22, 29, 51, 87, 80, 62, 616 18, 22, 37, 56, 68, 109, 103, 77, 617 24, 35, 55, 64, 81, 104, 113, 92, 618 49, 64, 78, 87, 103, 121, 120, 101, 619 72, 92, 95, 98, 112, 100, 103, 99 620 }; 622 /* 623 * Table K.2 from JPEG spec. 624 */ 625 static const int jpeg_chroma_quantizer[64] = { 626 17, 18, 24, 47, 99, 99, 99, 99, 627 18, 21, 26, 66, 99, 99, 99, 99, 628 24, 26, 56, 99, 99, 99, 99, 99, 629 47, 66, 99, 99, 99, 99, 99, 99, 630 99, 99, 99, 99, 99, 99, 99, 99, 631 99, 99, 99, 99, 99, 99, 99, 99, 632 99, 99, 99, 99, 99, 99, 99, 99, 633 99, 99, 99, 99, 99, 99, 99, 99 634 }; 636 /* 637 * Call MakeTables with the Q factor and two int[64] return arrays 638 */ 639 void 640 MakeTables(int q, u_char *lum_q, u_char *chr_q) 641 { 642 int i; 643 int factor = q; 645 if (q < 1) factor = 1; 646 if (q > 99) factor = 99; 647 if (q < 50) 648 q = 5000 / factor; 649 else 650 q = 200 - factor*2; 652 for (i=0; i < 64; i++) { 653 int lq = ( jpeg_luma_quantizer[i] * q + 50) / 100; 654 int cq = ( jpeg_chroma_quantizer[i] * q + 50) / 100; 656 /* Limit the quantizers to 1 <= q <= 255 */ 657 if ( lq < 1) lq = 1; 658 else if ( lq > 255) lq = 255; 659 lum_q[i] = lq; 661 if ( cq < 1) cq = 1; 662 else if ( cq > 255) cq = 255; 663 chr_q[i] = cq; 664 } 665 } 667 Appendix B 669 The following routines can be used to create the JPEG marker segments 670 corresponding to the table-specification data that is absent from the 671 RTP/JPEG body. 673 u_char lum_dc_codelens[] = { 674 0, 1, 5, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 675 }; 677 u_char lum_dc_symbols[] = { 678 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 679 }; 681 u_char lum_ac_codelens[] = { 682 0, 2, 1, 3, 3, 2, 4, 3, 5, 5, 4, 4, 0, 0, 1, 0x7d, 683 }; 685 u_char lum_ac_symbols[] = { 686 0x01, 0x02, 0x03, 0x00, 0x04, 0x11, 0x05, 0x12, 687 0x21, 0x31, 0x41, 0x06, 0x13, 0x51, 0x61, 0x07, 688 0x22, 0x71, 0x14, 0x32, 0x81, 0x91, 0xa1, 0x08, 689 0x23, 0x42, 0xb1, 0xc1, 0x15, 0x52, 0xd1, 0xf0, 690 0x24, 0x33, 0x62, 0x72, 0x82, 0x09, 0x0a, 0x16, 691 0x17, 0x18, 0x19, 0x1a, 0x25, 0x26, 0x27, 0x28, 692 0x29, 0x2a, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 693 0x3a, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 694 0x4a, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 695 0x5a, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 696 0x6a, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 697 0x7a, 0x83, 0x84, 0x85, 0x86, 0x87, 0x88, 0x89, 698 0x8a, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97, 0x98, 699 0x99, 0x9a, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7, 700 0xa8, 0xa9, 0xaa, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 701 0xb7, 0xb8, 0xb9, 0xba, 0xc2, 0xc3, 0xc4, 0xc5, 702 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xd2, 0xd3, 0xd4, 703 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 0xe1, 0xe2, 704 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 0xea, 705 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 706 0xf9, 0xfa, 707 }; 709 u_char chm_dc_codelens[] = { 710 0, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 711 }; 713 u_char chm_dc_symbols[] = { 714 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 715 }; 717 u_char chm_ac_codelens[] = { 718 0, 2, 1, 2, 4, 4, 3, 4, 7, 5, 4, 4, 0, 1, 2, 0x77, 719 }; 721 u_char chm_ac_symbols[] = { 722 0x00, 0x01, 0x02, 0x03, 0x11, 0x04, 0x05, 0x21, 723 0x31, 0x06, 0x12, 0x41, 0x51, 0x07, 0x61, 0x71, 724 0x13, 0x22, 0x32, 0x81, 0x08, 0x14, 0x42, 0x91, 725 0xa1, 0xb1, 0xc1, 0x09, 0x23, 0x33, 0x52, 0xf0, 726 0x15, 0x62, 0x72, 0xd1, 0x0a, 0x16, 0x24, 0x34, 727 0xe1, 0x25, 0xf1, 0x17, 0x18, 0x19, 0x1a, 0x26, 728 0x27, 0x28, 0x29, 0x2a, 0x35, 0x36, 0x37, 0x38, 729 0x39, 0x3a, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 730 0x49, 0x4a, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 731 0x59, 0x5a, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 732 0x69, 0x6a, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 733 0x79, 0x7a, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87, 734 0x88, 0x89, 0x8a, 0x92, 0x93, 0x94, 0x95, 0x96, 735 0x97, 0x98, 0x99, 0x9a, 0xa2, 0xa3, 0xa4, 0xa5, 736 0xa6, 0xa7, 0xa8, 0xa9, 0xaa, 0xb2, 0xb3, 0xb4, 737 0xb5, 0xb6, 0xb7, 0xb8, 0xb9, 0xba, 0xc2, 0xc3, 738 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca, 0xd2, 739 0xd3, 0xd4, 0xd5, 0xd6, 0xd7, 0xd8, 0xd9, 0xda, 740 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe9, 741 0xea, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7, 0xf8, 742 0xf9, 0xfa, 743 }; 745 u_char * 746 MakeQuantHeader(u_char *p, u_char *qt, int tableNo) 747 { 748 *p++ = 0xff; 749 *p++ = 0xdb; /* DQT */ 750 *p++ = 0; /* length msb */ 751 *p++ = 67; /* length lsb */ 752 *p++ = tableNo; 753 memcpy(p, qt, 64); 754 return (p + 64); 755 } 757 u_char * 758 MakeHuffmanHeader(u_char *p, u_char *codelens, int ncodes, u_char *symbols, 759 int nsymbols, int tableNo, int tableClass) 760 { 761 *p++ = 0xff; 762 *p++ = 0xc4; /* DHT */ 763 *p++ = 0; /* length msb */ 764 *p++ = 3 + ncodes + nsymbols; /* length lsb */ 765 *p++ = tableClass << 4 | tableNo; 766 memcpy(p, codelens, ncodes); 767 p += ncodes; 768 memcpy(p, symbols, nsymbols); 769 p += nsymbols; 770 return (p); 771 } 773 u_char * 774 MakeDRIHeader(u_char *p, u_short dri) { 775 *p++ = 0xff; 776 *p++ = 0xdd; /* DRI */ 777 *p++ = 0x0; /* length msb */ 778 *p++ = 4; /* length lsb */ 779 *p++ = dri >> 8; /* dri msb */ 780 *p++ = dri & 0xff; /* dri lsb */ 781 return (p); 782 } 784 /* 785 * Arguments: 786 * type, width, height: as supplied in RTP/JPEG header 787 * lqt, cqt: quantization tables as either derived from 788 * the Q field using MakeTables() or as specified 789 * in section 4.2. 790 * dri: restart interval in MCUs, or 0 if no restarts. 791 * 792 * p: pointer to return area 793 * 794 * Return value: 796 * The length of the generated headers. 797 * 798 * Generate a frame and scan headers that can be prepended to the 799 * RTP/JPEG data payload to produce a JPEG compressed image in 800 * interchange format (except for possible trailing garbage and 801 * absence of an EOI marker to terminate the scan). 802 */ 803 int MakeHeaders(u_char *p, int type, int w, int h, u_char *lqt, u_char *cqt, 804 u_short dri) 805 { 806 u_char *start = p; 807 u_char lqt[64]; 808 u_char cqt[64]; 810 /* convert from blocks to pixels */ 811 w <<= 3; 812 h <<= 3; 814 *p++ = 0xff; 815 *p++ = 0xd8; /* SOI */ 817 p = MakeQuantHeader(p, lqt, 0); 818 p = MakeQuantHeader(p, cqt, 1); 820 if (dri != 0) 821 p = MakeDRIHeader(p, dri); 823 *p++ = 0xff; 824 *p++ = 0xc0; /* SOF */ 825 *p++ = 0; /* length msb */ 826 *p++ = 17; /* length lsb */ 827 *p++ = 8; /* 8-bit precision */ 828 *p++ = h >> 8; /* height msb */ 829 *p++ = h; /* height lsb */ 830 *p++ = w >> 8; /* width msb */ 831 *p++ = w; /* wudth lsb */ 832 *p++ = 3; /* number of components */ 833 *p++ = 0; /* comp 0 */ 834 if (type == 0) 835 *p++ = 0x21; /* hsamp = 2, vsamp = 1 */ 836 else 837 *p++ = 0x22; /* hsamp = 2, vsamp = 2 */ 838 *p++ = 0; /* quant table 0 */ 839 *p++ = 1; /* comp 1 */ 840 *p++ = 0x11; /* hsamp = 1, vsamp = 1 */ 841 *p++ = 1; /* quant table 1 */ 842 *p++ = 2; /* comp 2 */ 843 *p++ = 0x11; /* hsamp = 1, vsamp = 1 */ 844 *p++ = 1; /* quant table 1 */ 846 p = MakeHuffmanHeader(p, lum_dc_codelens, 847 sizeof(lum_dc_codelens), 848 lum_dc_symbols, 849 sizeof(lum_dc_symbols), 0, 0); 850 p = MakeHuffmanHeader(p, lum_ac_codelens, 851 sizeof(lum_ac_codelens), 852 lum_ac_symbols, 853 sizeof(lum_ac_symbols), 0, 1); 854 p = MakeHuffmanHeader(p, chm_dc_codelens, 855 sizeof(chm_dc_codelens), 856 chm_dc_symbols, 857 sizeof(chm_dc_symbols), 1, 0); 858 p = MakeHuffmanHeader(p, chm_ac_codelens, 859 sizeof(chm_ac_codelens), 860 chm_ac_symbols, 861 sizeof(chm_ac_symbols), 1, 1); 863 *p++ = 0xff; 864 *p++ = 0xda; /* SOS */ 865 *p++ = 0; /* length msb */ 866 *p++ = 12; /* length lsb */ 867 *p++ = 3; /* 3 components */ 868 *p++ = 0; /* comp 0 */ 869 *p++ = 0; /* huffman table 0 */ 870 *p++ = 1; /* comp 1 */ 871 *p++ = 0x11; /* huffman table 1 */ 872 *p++ = 2; /* comp 2 */ 873 *p++ = 0x11; /* huffman table 1 */ 874 *p++ = 0; /* first DCT coeff */ 875 *p++ = 63; /* last DCT coeff */ 876 *p++ = 0; /* sucessive approx. */ 878 return (p - start); 879 }; 881 Appendix C 883 The following routine is used to illustrate the RTP/JPEG packet 884 fragmentation and header creation. 886 For clarity and brevity, the structure definitions are only valid for 887 32-bit big- endian (most significant octet first) architectures. Bit 888 fields are assumed to be packed tightly in big-endian bit order, with no 889 additional padding. Modifications would be required to construct a 890 portable implementation. 892 /* 893 * RTP data header from RFC1889 894 */ 895 typedef struct { 896 unsigned int version:2; /* protocol version */ 897 unsigned int p:1; /* padding flag */ 898 unsigned int x:1; /* header extension flag */ 899 unsigned int cc:4; /* CSRC count */ 900 unsigned int m:1; /* marker bit */ 901 unsigned int pt:7; /* payload type */ 902 u_int16 seq; /* sequence number */ 903 u_int32 ts; /* timestamp */ 904 u_int32 ssrc; /* synchronization source */ 905 u_int32 csrc[1]; /* optional CSRC list */ 906 } rtp_hdr_t; 908 #define RTP_HDR_SZ 12 910 /* The following definition is from RFC1890 */ 911 #define RTP_PT_JPEG 26 913 struct jpeghdr { 914 unsigned int tspec:8; /* type-specific field */ 915 unsigned int off:24; /* fragment byte offset */ 916 u_int8 type; /* id of jpeg decoder params */ 917 u_int8 q; /* quantization factor (or table id) */ 918 u_int8 width; /* frame width in 8 pixel blocks */ 919 u_int8 height; /* frame height in 8 pixel blocks */ 920 }; 922 struct jpeghdr_rst { 923 u_int16 dri; 924 unsigned int f:1; 925 unsigned int l:1; 926 unsigned int count:14; 927 }; 929 struct jpeghdr_qtable { 930 u_int8 mbz; 931 u_int8 precision; 932 u_int16 length; 933 }; 935 #define RTP_JPEG_RESTART 0x40 937 /* Procedure SendFrame: 938 * 939 * Arguments: 941 * start_seq: The sequence number for the first packet of the current frame. 942 * ts: RTP timestamp for the current frame 943 * ssrc: RTP SSRC value 944 * jpeg_data: Huffman encoded JPEG scan data 945 * len: Length of the JPEG scan data 946 * type: The value the RTP/JPEG type field should be set to 947 * typespec: The value the RTP/JPEG type-specific field should be set to 948 * width: The width in pixels of the JPEG image 949 * height: The height in pixels of the JPEG image 950 * dri: The number of MCUs between restart markers (or 0 if ther are no 951 * restart markers in the data 952 * q: The Q factor of the data, to be specified using the Independent 953 * JPEG group's algorithm if 1 <= q <= 99, specified explicitly with 954 * lqt and cqt if q >= 128, or undefined otherwise. 955 * lqt: The quantization table for the luminance channel if q >= 128 956 * cqt: The quantization table for the chrominance channels if q >= 128 957 * 958 * Return value: 959 * the sequence number to be sent for the first packet of the next frame. 960 * 961 * The following are assumed to be defined: 962 * 963 * PACKET_SIZE - The size of the outgoing packet 964 * send_packet(u_int8 *data, int len) - Sends the packet to the network 965 */ 967 u_int16 SendFrame(u_int16 start_seq, u_int32 ts, u_int32 ssrc, 968 u_int8 *jpeg_data, int len, u_int8 type, u_int8 typespec, 969 int width, int height, int dri, 970 u_int8 q, u_int8 *lqt, u_int8 *cqt) { 971 rtp_hdr_t rtphdr; 972 struct jpeghdr jpghdr; 973 struct jpeghdr_rst rsthdr; 974 struct jpeghdr_qtable qtblhdr; 975 u_int8 packet_buf[PACKET_SIZE]; 976 u_int8 *ptr; 977 int bytes_left = len; 978 int seq = start_seq; 979 int pkt_len, data_len; 981 /* Initialize RTP header 982 */ 983 rtphdr.version = 2; 984 rtphdr.p = 0; 985 rtphdr.x = 0; 986 rtphdr.cc = 0; 987 rtphdr.m = 0; 988 rtphdr.pt = RTP_PT_JPEG; 989 rtphdr.seq = start_seq; 990 rtphdr.ts = ts; 991 rtphdr.ssrc = ssrc; 993 /* Initialize JPEG header 994 */ 995 jpghdr.tspec = typespec; 996 jpghdr.off = 0; 997 jpghdr.type = type | ((dri != 0) ? RTP_JPEG_RESTART : 0); 998 jpghdr.q = q; 999 jpghdr.width = width / 8; 1000 jpghdr.height = height / 8; 1002 /* Initialize DRI header 1003 */ 1004 if (dri != 0) { 1005 rsthdr.dri = dri; 1006 rsthdr.f = 1; /* This code does not align RIs */ 1007 rsthdr.l = 1; 1008 rsthdr.count = 0x3fff; 1009 } 1011 /* Initialize quantization table header 1012 */ 1013 if (q >= 128) { 1014 qtblhdr.mbz = 0; 1015 qtblhdr.precision = 0; /* This code uses 8 bit tables only */ 1016 qtblhdr.length = 128; /* 2 64-byte tables */ 1017 } 1019 while (bytes_left > 0) { 1020 ptr = packet_buf + RTP_HDR_SZ; 1021 memcpy(ptr, &jpghdr, sizeof(jpghdr)); 1022 ptr += sizeof(jpghdr); 1024 if (dri != 0) { 1025 memcpy(ptr, &rsthdr, sizeof(rsthdr)); 1026 ptr += sizeof(rsthdr); 1027 } 1029 if (q >= 128 && jpghdr.off == 0) { 1030 memcpy(ptr, &qtblhdr, sizeof(qtblhdr)); 1031 ptr += sizeof(qtblhdr); 1032 memcpy(ptr, lqt, 64); 1033 ptr += 64; 1034 memcpy(ptr, cqt, 64); 1035 ptr += 64; 1036 } 1037 data_len = PACKET_SIZE - (ptr - packet_buf); 1038 if (data_len >= bytes_left) { 1039 data_len = bytes_left; 1040 rtphdr.m = 1; 1041 } 1043 memcpy(packet_buf, &rtphdr, RTP_HDR_SZ); 1044 memcpy(ptr, jpeg_data + jpghdr.off, data_len); 1046 send_packet(packet_buf, (ptr - packet_buf) + data_len); 1048 jpghdr.off += data_len; 1049 bytes_left -= data_len; 1050 rtphdr.seq++; 1051 } 1052 return rtphdr.seq; 1053 } 1055 Appendix D 1057 This section outlines the changes between this document and its 1058 precdecessor, RFC 2035. The changes to the protocol were made with an 1059 eye towards causing as few interoperability problems between 1060 implementations based on the older text and newer implementations, and 1061 indeed, many of the obsolete conventions can still be unambiguously 1062 decoded by a newer implementation. However, use of the older 1063 conventions in newer implementations is strongly discouraged. 1065 o Types 0 and 1 have been augmented to allow for the encoding of 1066 interlaced video images, using 2 bits of the type-specific field. 1067 See section 4.1 for details. 1069 o There has been discussion in the working group arguing for more 1070 flexibility in specifying the JPEG quantization tables. This draft 1071 allows table coefficients to be specified explicitly through the 1072 use of an optional Quantization Table header, discussed in sections 1073 3.1.8 and 4.2. 1075 o In RFC 2035, the encoding of restart marker information in the Type 1076 field made it difficult to add new types. Additionally, the type- 1077 specific field was used for the restart count, making it 1078 unavailable for other type-specific purposes. This draft moves the 1079 restart marker indication to a particular bit in the Type field, 1080 and adds an optional header to hold the additional information 1081 required, leaving the type-specific field free for its intended 1082 purpose. The handling of partial frame decoding was also made more 1083 robust against packet loss. See sections 3.1.7 and 4.4 for 1084 details.