idnits 2.17.1 draft-ietf-avt-rtp-jpeg2000-beam-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1122. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1146. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([JP2RTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (Jun 30, 2008) is 5779 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio Video Transport A. Leung 3 Internet-Draft S. Futemma 4 Intended status: Standards Track E. Itakura 5 Expires: January 1, 2009 Sony 6 Jun 30, 2008 8 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main 9 Header Recovery 10 draft-ietf-avt-rtp-jpeg2000-beam-11 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on January 1, 2009. 37 Abstract 39 This memo describes extended uses for payload header in "RTP Payload 40 Format for JPEG 2000 Video Streams" as specified in RFC XXXY. For 41 better support of JPEG 2000 features such as scalability and main 42 header recovery. 44 This memo must be accompanied with a complete implementation of "RTP 45 Payload Format for JPEG 2000 Video Streams." That document is a 46 complete description of the payload header and signaling, this 47 document only describes additional processing for the payload header. 48 There is an additional media type and SDP marker signaling for 49 implementations of this document. 51 -- RFC-Editor Note: The authors ask the RFC Editors to replace all 52 instances of RFC XXXY with the RFC number assigned when 53 draft-ietf-avt-rtp-jpeg2000-20 [JP2RTP] is published as an RFC. At 54 that time, please remove the note. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Description of the Mechanisms . . . . . . . . . . . . . . 4 60 1.1.1. Main Header Compensation . . . . . . . . . . . . . . . 4 61 1.1.2. Priority Table . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Motivations for Priority Field coding . . . . . . . . . . 5 63 1.2.1. Scenario: Just enough resolution . . . . . . . . . . . 5 64 1.2.2. Scenario: Multiple clients, single source . . . . . . 5 65 1.3. Conventions Used in This Document . . . . . . . . . . . . 5 66 2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 6 67 2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 6 68 3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 8 69 3.1. Packet Number Based Ordering . . . . . . . . . . . . . . . 8 70 3.2. Progression Based Ordering . . . . . . . . . . . . . . . . 8 71 3.3. Layer Based Ordering . . . . . . . . . . . . . . . . . . . 10 72 3.4. Resolution Based Ordering . . . . . . . . . . . . . . . . 11 73 3.5. Component Based Ordering . . . . . . . . . . . . . . . . . 11 74 4. JPEG 2000 Main Header Compensation Scheme . . . . . . . . . . 12 75 4.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 12 76 4.2. Receiver Processing . . . . . . . . . . . . . . . . . . . 12 77 5. Media Type Registration . . . . . . . . . . . . . . . . . . . 14 78 6. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 15 79 6.1. Mapping of the optional parameters to SDP . . . . . . . . 15 80 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 15 81 6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 16 82 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 19 83 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 20 84 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21 85 10. Normative References . . . . . . . . . . . . . . . . . . . . . 22 86 Appendix A. Sample Headers in Detail . . . . . . . . . . . . . . 23 87 A.1. Sample 1: Progressive image with single tile, 3500 88 bytes (i.e. thumbnail) . . . . . . . . . . . . . . . . . . 23 89 A.2. Sample 2: Image with 4 tiles . . . . . . . . . . . . . . . 25 90 A.3. Sample 3: Packing multiple tiles in single payload, 91 fragmented header. No header compensation, progressive 92 image . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 A.4. Sample 4: Interlace image, single tile . . . . . . . . . . 28 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 95 Intellectual Property and Copyright Statements . . . . . . . . . . 33 97 1. Introduction 99 This document is an extension of: "RTP Payload Format for JPEG 2000 100 Video Streams" [JP2RTP]. These are additional mechanisms which can 101 be used with certain parts of the header in [JP2RTP] to support JPEG 102 2000 features such as: scalability and a main header compensation 103 method. These mechanisms are described in detail in this document. 105 These are optional extensions to RFC XXXY [JP2RTP].which one may use 106 to make better use of JPEG 2000 features. These extensions are not 107 required for any implementations of RFC XXXY[JP2RTP]. 109 1.1. Description of the Mechanisms 111 1.1.1. Main Header Compensation 113 JPEG 2000 has a scalable coding scheme which allows for decompressing 114 truncated or partial data streams but only when the main header is 115 present. If the header is lost, the data is useless. With JPEG 2000 116 video coding, coding parameters between frames will rarely change and 117 previous headers may be used in newly received data which the header 118 have been lost. 120 Compensation of the main header that has been lost is very simple 121 with this procedure. In the case of JPEG 2000 video, it is very 122 common that encode parameters will not vary greatly between 123 successive frames. Even if the RTP packet including the main header 124 of a frame has been dropped, decoding may be performed by using the 125 main header of a prior frame. 127 1.1.2. Priority Table 129 JPEG 2000 codestream has rich functionality built into it so decoders 130 can easily handle scalable delivery or progressive transmission. 131 Progressive transmission allows images to be reconstructed with 132 increasing pixel accuracy or spatial resolution. This feature allows 133 the reconstruction of images with different resolutions and pixel 134 accuracy, for different target devices. A single image source can 135 provide a codestream that is easily processed for smaller image 136 display devices. 138 JPEG 2000 packets contain all compressed image data from a specific: 139 layer, component, resolution level, and/or precinct. The order in 140 which these JPEG 2000 packets are found in the codestream is called: 141 the progression order. The ordering of the JPEG 2000 packets can 142 progress along four axes: layer, component, resolution and precinct 143 (or position). 145 Providing a priority field to indicate the importance of data 146 contained in a given RTP packet can aid in usage of JPEG 2000 147 progressive and scalable functions. 149 1.2. Motivations for Priority Field coding 151 JPEG 2000 coding scheme allows one to reorder the codestream in many 152 ways. Even when the coding scheme is determined and arranged by the 153 encoder, a decoder can still re-arrange the code stream on the fly to 154 suit decode parameters such as: re-arranging from resolution 155 progressive to quality progressive. 157 Using the priority field coding, the decoder gains insight into the 158 codestream without access to the full codestream and exposes features 159 of JPEG 2000 to a higher level. 161 A few of the scenarios are presented below the authors have thought 162 of to utilize this field. The priority field allows more information 163 about the image to be sent without more signaling between sender and 164 receivers to leverage JPEG 2000 capabilities. 166 1.2.1. Scenario: Just enough resolution 168 The scenario is when rapid scene access is more important than higher 169 quality. By using the priority field, the receiver can decode for 170 its own quality level. If the sender cannot determine the receiver's 171 resolution, the receiver can select which parts of the codestream to 172 decode/load by using the priority field. 174 1.2.2. Scenario: Multiple clients, single source 176 In a multicast environment, there are clients with better visual 177 capability than others (i.e. TV conference vs. Mobile). The 178 respective clients can use the priority field to determine which 179 packets are vital for their own visual presentation. The sender will 180 have to do work on the priority field to optimally serve all the 181 clients while only managing a single visual stream. 183 1.3. Conventions Used in This Document 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC2119. [RFC2119]. 189 2. Payload Format Enhanced Processing 191 2.1. Enhanced Processing Markers 193 This section of the document describes additional usage in the values 194 of mh_id and priority fields and interpretation which differ from RFC 195 XXXY [JP2RTP]. Implementations of this document should follow RFC 196 XXXY [JP2RTP] first then add additional header processing as 197 described in this document. Implementations following this document 198 are expected to interoperate with implementations of [JP2RTP] and 199 this document as well. 201 The RTP payload header format for JPEG 2000 video stream is as 202 follows: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |tp |MHF|mh_id|T| priority | tile number | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |reserved | fragment offset | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: RTP payload header format for JPEG 2000 214 mh_id (Main Header Identification) : 3 bits 216 Main header identification value. This is used for JPEG 2000 main 217 header recovery. 219 The initial value of mh_id MUST be 1 at the beginning of the 220 session. 222 The same mh_id value is used as long as the coding parameters 223 described in the main header remains unchanged between frames. 225 The mh_id value MUST be incremented by 1 every time a new main 226 header is transmitted. Once the mh_id value becomes greater than 227 7, it SHOULD roll over to 1. 229 When mh_id is 0, it has special usage for the receiver. This 230 special usage is described in Section 4.2 of this document. 232 Senders should follow Section 4.1 of this document for proper 233 mh_id assignment and usage. 235 priority : 8 bits 237 The priority field indicates the importance of the JPEG 2000 238 packet included in the payload. Typically, a higher priority is 239 set in the packets containing JPEG 2000 packets containing the 240 lower sub-bands. 242 Special values of priority: 244 0: This is reserved for payload which contain a header (main or 245 tile part header.) This is considered the most important. 247 1 to 255: These values decrease in importance as the values 248 increase. (i.e. 1 is more important than 2, etc.) Applying 249 priority values should correlate directly to JPEG 2000 250 codestream in importance. 252 The lower the priority value is the higher the importance. A 253 priority value of 0 is the highest importance and 255 is the 254 lowest importance. We define the priority value 0 as a special 255 priority value for the headers (the main header or tile-part 256 header). If any headers (the main header or tile-part header) are 257 packed into the RTP payload, the sender MUST set the priority 258 value to 0. 260 Assignment of the values are described in Section 3 262 3. Priority Mapping Table 264 For the progression order, the priority value for each JPEG 2000 265 packet is given by the priority mapping table. 267 This document specify several commonly-used priority mapping tables, 268 pre-defined priority mapping tables: packet number based (default), 269 progression-based, layer-based, resolution-based, position-based, and 270 component-based. 272 Packet number priority mapping is REQUIRED to be supported by clients 273 implementing this specification. Other priority mapping tables 274 (progression, layer, resolution, and component based) are OPTIONAL to 275 implementations of this specification. 277 Rules that all implementations of this specification MUST follow in 278 all priority modes: 280 o When there is a header in the packet with a JPEG 2000 packet, the 281 sender MUST set the payload packet priority value to 0. 283 o When there are multiple JPEG 2000 packets in the same RTP payload 284 packet, the sender MUST set the payload packet priority value to 285 the lowest JPEG 2000 packet. (i.e. if JPEG 2000 packets with 286 priority: 5,6,7 are packed into a single payload, the priority 287 value will be 5.) 289 3.1. Packet Number Based Ordering 291 Packet number based ordering assigns the payload packet priority 292 value from the "JPEG 2000 packet value". (note: JPEG 2000 codestreams 293 are stored in units of packets and each packet has a value .) This 294 method is the default method for assigning priority value. All 295 implementations of this specification MUST support this method. 297 If the JPEG 2000 codestream packet value is greater than 255, the 298 sender MUST set the payload priority value to 255. 300 3.2. Progression Based Ordering 302 The sender will assign the payload packet priority value only based 303 on layer, resolution, and component ordering of the codestream. 305 The ordering can assign the different priority values in the same 306 layer or the resolution level, which cannot do in the layer based 307 ordering or resolution based ordering. 309 The difference from the packet number based ordering is that it does 310 not assign the value in the position level, which saves the priority 311 values usage. The position based priority signaling is not so 312 important because a receiver could recognize the position by checking 313 the tile number field. Therefore, the ordering would be useful. 315 The general algorithm is that the ordering is based on the triple 316 and the minimum priority is 1. So, if 317 the codestream is constructed of L layers (layer value ranges from 0 318 to L-1), R resolutions (resolution value ranges from 0 to R-1), and C 319 components (component value ranges from 0 to C-1), then for a triple 320 , 322 the priority value of the codestream in LRCP order is calculated 323 as: 325 priority = 1 + cval + (C * rval) + (C * R * lval) 327 the priority value of the codestream in RLCP order is calculated 328 as: 330 priority = 1 + cval + (C * lval) + (C * L * rval) 332 the priority value of the codestream in RPCL order is calculated 333 as: 335 priority = 1 + lval + (L * cval) + (L * C * rval) 337 the priority value of which codestream in PCRL order is calculated 338 as: 340 priority = 1 + lval + (L * rval) + (L * R * cval) 342 the priority value of which codestream in CPRL order is calculated 343 as: 345 priority = 1 + lval + (L * rval) + (L * R * cval) 347 For example: 349 If the codestream is ordered in LRCP (Layer, Resolution, Component, 350 Position) with 1 layer (L=1), 2 resolutions (R=2), 3 components 351 (C=3), and 2 positions, priority value should be (1 + cval + 3*rval + 352 6*lval). Then an example would have packet numbering as so: 354 All the packets in: 356 layer.........0 357 resolution....0 358 component.....0 359 position......0 or 1 361 then the packet priority value : 1 363 All the packets in: 365 layer.........0 366 resolution....0 367 component.....1 368 position......0 or 1 370 then the packet priority value : 2 372 All the packets in: 374 layer.........0 375 resolution....0 376 component.....2 377 position......0 or 1 379 then the packet priority value : 3 381 All the packets in: 383 layer.........0 384 resolution....1 385 component.....0 386 position......0 or 1 388 then the packet priority value : 4 390 All the packets in: 392 layer.........0 393 resolution....1 394 component.....1 395 position......0 or 1 397 then the packet priority value : 5 399 3.3. Layer Based Ordering 401 Layer-based priority mapping table simplifies the default mapping to 402 just matching JPEG 2000 packets together from the same layer. 404 For example: 406 All the packets in layer 0 : packet priority value : 1 407 All the packets in layer 1 : packet priority value : 2 408 All the packets in layer 2 : packet priority value : 3 409 ... 410 All the packets in layer n : packet priority value : n+1 411 All the packets in layer 255 : packet priority value : 255 413 3.4. Resolution Based Ordering 415 Resolution-based priority mapping table is similar to the layer based 416 order but for JPEG 2000 packets of the same resolution 418 For example: 420 All the packets in resolution 0 : packet priority value : 1 421 All the packets in resolution 1 : packet priority value : 2 422 All the packets in resolution 2 : packet priority value : 3 423 ... 424 All the packets in resolution n : packet priority value : n+1 425 All the packets in resolution 255 : packet priority value : 255 427 3.5. Component Based Ordering 429 Component-based priority mapping table is mapping together JPEG 2000 430 components of the same component 432 For example: 434 All the packets in component 0 : packet priority value : 1 435 All the packets in component 1 : packet priority value : 2 436 All the packets in component 2 : packet priority value : 3 437 ... 438 All the packets in component n : packet priority value : n+1 439 All the packets in component 255 : packet priority value : 255 441 4. JPEG 2000 Main Header Compensation Scheme 443 The mh_id field of the payload header is used to indicate whether the 444 encoding parameters of the main header are the same as the encoding 445 parameters of the previous frame. The same value is set in mh_id of 446 the RTP packet in the same frame. The mh_id and encode parameters 447 are not associated with each other as 1:1 but they are used to 448 indicate whether the encode parameters of the previous frame are the 449 same or not in the event of a lost header. 451 The mh_id field value SHOULD be saved from previous frames to be used 452 to recover the current frame's main header. If the mh_id of the 453 current frame has the same value as the mh_id value of the previous 454 frame, the previous frame's main header MAY be used to decode the 455 current frame, in case of a lost header in the current frame. 457 The sender MUST increment mh_id when parameters in the header change 458 and send a new main header accordingly. 460 The receiver MAY use the mh_id and MAY retain the header for such 461 compensation. 463 4.1. Sender Processing 465 The sender MUST transmit RTP packets with the same mh_id value if the 466 encoder parameters of the current frame are the same as the previous 467 frame. The encoding parameters are the fixed information marker 468 segment (SIZ marker) and functional marker segments (COD, COC, RGN, 469 QCD, QCC, and POC) specified in JPEG 2000 Part 1 Annex A 470 [JPEG2000Pt_1]. 472 If the encode parameters changes, the sender transmitting RTP packets 473 MUST increment the mh_id value by one, but when mh_id value becomes 474 greater than 7, a sender MUST set mh_id value back to 1. 476 4.2. Receiver Processing 478 When the receiver receives the main header completely, the RTP 479 sequence number, the mh_id and main header should be saved. Only the 480 last main header that was received completely SHOULD be saved. When 481 the mh_id value is 0, the receiver SHOULD NOT save the header. 483 When the main header is not received, the receiver may compare the 484 current payload header's mh_id value with the previous saved mh_id 485 value. If the values match, decoding may be performed by using the 486 previously saved main header. 488 If the mh_id field is set to 0, the receiver MUST NOT save the main 489 header and MUST NOT compensate for lost headers. 491 If the mh_id value changes, receivers SHOULD save the current header 492 and save the new mh_id value. The old saved header should be deleted 493 from storage. 495 Also, if the decoder detects an inconsistency between the header and 496 payload, it is recommended to clear the saved mh_id and the saved 497 main header. Please see Section 8 for more explanation. 499 5. Media Type Registration 501 This document extends the associated media type "video/jpeg2000" from 502 RFC XXXY [JP2RTP]. Here are additional optional parameters. 504 Additional optional parameters: 506 mhc : Main Header Compensation. this option is used when sender 507 and/or receiver is utilizing the Main Header compensation 508 technique as specified in this document. Acceptable values 509 when using the Main Header compensation technique is "1", 510 otherwise, it should be "0". 512 This is a list of options to be included when the sender or 513 receiver is utilizing the Priority Table option as specified in 514 this document. 516 pt : Priority Table. this option is followed by a comma-separated 517 list of predefined priority table definitions to be used by 518 sender or receiver. 520 The option appearing front most in the option line is the most 521 important and next are of decreasing importance. 523 Acceptable values: 525 progression : this table follows the progression ordering 526 of the codestream. 528 layer : this table follows the layer ordering of the 529 codestream. 531 resolution : this table follows the resolution ordering of 532 the codestream. 534 component : this table follows the component ordering of 535 the codestream. 537 default : this table follows the ordering of the 538 codestream. 540 6. SDP Parameters 542 6.1. Mapping of the optional parameters to SDP 544 The new optional parameters mhc and pt, if presented, MUST be 545 included in the "a=fmtp" line of SDP. These parameters are expressed 546 as a media type string, in the form of a semicolon separated list of 547 parameter=value pairs. 549 6.2. Usage with the SDP Offer/Answer Model 551 In addition to SDP Offer/Answer section in RFC XXXY [JP2RTP]: 553 When offering JPEG 2000 over RTP using SDP in an Offer/Answer model 554 [RFC3264], the following rules and limitations apply: 556 o All parameters MUST have an acceptable value for that parameter. 558 o All parameters MUST correspond to the parameters of the payload. 560 o If the optional parameter "mhc" is used, it MUST appear in the 561 offer with value "1", and if accepted, it SHOULD appear in the 562 answer. 564 o If the optional parameter "pt" is used, it MUST appear in the 565 offer containing a complete comma-separated list indicating which 566 priority table definitions the sender supports. If accepted, it 567 SHOULD appear in the answer containing a single priority table 568 definition selected from the offer. 570 o If the optional parameter "mhc" is used, it MUST appear in the 571 offer with value "1", and if accepted, it MUST appear in the 572 answer. If the optional parameter "pt" is used, it MUST appear in 573 the offer containing a complete comma-separated list indicating 574 which priority table definitions the sender supports. If 575 accepted, it MUST appear in the answer containing a single 576 priority table definition selected from the offer. 578 o In a multicast environment: 580 * Senders should send out one option for priority-table- 581 definition for everyone in the group. 583 * Even if a single client in the group does not support the 584 extensions outlined in this document, senders MAY use these 585 mechanisms. A receiver which doesn't support the mechanisms 586 would safely ignore the values.in mh_id and priority field. 588 6.2.1. Examples 590 Offer/Answer example exchanges are provided. 592 6.2.1.1. Example 1 594 Alice offers Main Header Compensation functionality, YCbCr 422 color 595 space, interlace image with 720-pixel width and 480-pixel height and 596 several priority-table options (default, progression, layer, 597 resolution, component) as below: 599 v=0 600 o=alice 2890844526 2890844526 IN IP4 host.example 601 s= 602 c=IN IP4 host.example 603 t=0 0 604 m=video 49170 RTP/AVP 98 605 a=rtpmap:98 jpeg2000/90000 606 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2; interlace=1; 607 pt=default,progression,layer,resolution, component; 608 width=720;height=480 610 Bob accepts Main Header Compensation functionality, YCbCr-4:2:2 color 611 space, interlace image, default mapping table and replies: 613 v=0 614 o=bob 2890844730 2890844731 IN IP4 host.example 615 s= 616 c=IN IP4 host.example 617 t=0 0 618 m=video 49920 RTP/AVP 98 619 a=rtpmap:98 jpeg2000/90000 620 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2;interlace=1; 621 pt=default;width=720;height=480 623 6.2.1.2. Example 2 625 Alice offers Main Header Compensation, YCbCr 420 color space, 626 progressive image with 320-pixel width and 240-pixel height and layer 627 priority-table options as below: 629 v=0 630 o=alice 2890844526 2890844526 IN IP4 host.example 631 s= 632 c=IN IP4 host.example 633 t=0 0 634 m=video 49170 RTP/AVP 98 635 a=rtpmap:98 jpeg2000/90000 636 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0; 637 pt=layer;width=320;height=240 639 Bob does not accept Main Header Compensation functionality but 640 accepts YCbCr-4:2:0 color space,layer based priority mapping and 641 replies: 643 v=0 644 o=bob 2890844730 2890844731 IN IP4 host.example 645 s= 646 c=IN IP4 host.example 647 t=0 0 648 m=video 49920 RTP/AVP 98 649 a=rtpmap:98 jpeg2000/90000 650 a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0; 651 pt=layer;width=320;height=240 653 6.2.1.3. Example 3 655 Alice offers 27 MHz timestamp, Main Header Compensation, YCbCr 420 656 color space, progressive image with 320-pixel width and 240-pixel 657 height and layer priority-table options as below: 659 v=0 660 o=alice 2890844526 2890844526 IN IP4 host.example 661 s= 662 c=IN IP4 host.example 663 t=0 0 664 m=video 49170 RTP/AVP 98 99 665 a=rtpmap:98 jpeg2000/27000000 666 a=rtpmap:99 jpeg2000/90000 667 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0; 668 pt=layer;width=320;height=240 669 a=fmtp:99 mhc=1; sampling=YCbCr-4:2:0; 670 pt=layer;width=320;height=240 672 Bob can accept payload type with 27 MHz timestamp, and does not 673 accept Main Header Compensation functionality but accepts YCbCr-4:2:0 674 color space,layer based priority mapping and replies: 676 v=0 677 o=bob 2890844730 2890844731 IN IP4 host.example 678 s= 679 c=IN IP4 host.example 680 t=0 0 681 m=video 49920 RTP/AVP 98 682 a=rtpmap:98 jpeg2000/27000000 683 a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0; 684 pt=layer;width=320;height=240 686 7. IANA Consideration 688 This document extends the associated media type "video/jpeg2000" from 689 XXXY [JP2RTP]. Additional parameters are specified in Section 5 of 690 this document. 692 8. Security Consideration 694 Please refer to section 6 of RFC XXXY [JP2RTP] for Security 695 Considerations regarding this RTP format. The security issues 696 regarding enhanced mechanisms presented in this document are 697 discussed in the section. 699 The mh_id field can identify a maximum of 7 different main headers. 700 If severe packet loss (either random or intentionally introduced by 701 an attacker) causes 6 successive updates to the main header to be 702 lost, the decoder will attempt decompression using an incorrect main 703 header. Even if the incorrect main header is passed, the standard 704 JPEG 2000 decoder could detect inconsistency of the codestream and 705 process it properly. It is recommended to clear the saved mh_id and 706 the saved main header if the decoder detect such an inconsistency. 708 9. Congestion Control 710 Please refer to section 7 of RFC XXXY [JP2RTP] for Congestion Control 711 regarding this RTP format. 713 10. Normative References 715 [JP2RTP] Futemma, Leung, and Itakura, "RTP Payload Format for JPEG 716 2000 Video Streams", I-D draft-ietf-avt-rtp-jpeg2000-20, 717 June 2008. 719 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 720 Requirement Levels", RFC 2119, March 1997. 722 [JPEG2000Pt_1] 723 ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, 724 "Information Technology - JPEG 2000 Image Coding System - 725 Part 1: Core Coding System", December 2000. 727 [RFC3264] Rosenberg and Schulzrinne, "An Offer/Answer Model with 728 Session Description Protocol (SDP)", RFC 3264, June 2002. 730 Appendix A. Sample Headers in Detail 732 The following figures are sample RTP headers demonstrating values 733 that should appear in the RTP header. The packet priority is Packet 734 Number Based Priority. 736 For reference, the payload header as follows 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 |tp |MHF|mh_id|T| priority | tile number | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 |reserved | fragment offset | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Figure 2: JPEG200 payload header 748 A.1. Sample 1: Progressive image with single tile, 3500 bytes (i.e. 749 thumbnail) 751 First Packet: This packet will have the whole main header. 210 bytes 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | 0 | 3 | 1 |1| 0 | 0 | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | 0 | 0 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |FF4F FF51 002F 0000 .... | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Figure 3: Header Sample 1-1 (First Packet) 765 Second Packet: This packet will have a tile header and the first tile 766 part LLband 1500 bytes 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | 0 | 0 | 1 |0| 1 | 0 | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | 0 | 210 | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 |FF90 000A 0000 0000 2DB3 0001 FF93 .... | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Figure 4: Header Sample 1-2 (Second Packet) 780 Third Packet: This packet will have the next part in the tile, no 781 tile header 1500 bytes 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | 0 | 0 | 1 |0| 2 | 0 | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | 0 | 1710 | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 |E841 4526 4556 9850 C2EA .... | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 Figure 5: Header Sample 1-3 (Third Packet) 795 Fourth Packet: Last packet for the image 290 bytes 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | 0 | 0 | 1 |0| 3 | 0 | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | 0 | 3210 | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 |A55D 8B73 3B25 25C7 B9EB .... 2FBE B153| 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Figure 6: Header Sample 1-4 (Fourth Packet) 809 A.2. Sample 2: Image with 4 tiles 811 First Packet: This packet will have the whole main header. 210 bytes 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | 0 | 3 | 1 |1| 0 | 0 | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | 0 | 0 | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 |FF4F FF51 002F 0000 .... | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Figure 7: Header Sample 2-1 (First Packet) 825 Second Packet: This packet will have a first tile part (tile 0) 1400 826 bytes 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | 0 | 0 | 1 |0| 1 | 0 | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | 0 | 210 | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 |FF90 000A 0000 0000 0578 0001 FF93 .... | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 Figure 8: Header Sample 2-2 (Second Packet) 840 Third Packet: This packet will have a second tile part (tile 1) 1423 841 bytes 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | 0 | 0 | 1 |0| 1 | 1 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | 0 | 1610 | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 |FF90 000A 0001 0000 058F 0001 FF93 .... | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 Figure 9: Header Sample 2-3 (Third Packet) 855 Fourth Packet: This packet will have a third tile part (tile 2) 1355 856 bytes 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | 0 | 0 | 1 |0| 1 | 2 | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | 0 | 3033 | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 |FF90 000A 0002 0000 054B 0001 FF93 .... | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 Figure 10: Header Sample 2-4 (4th Packet) 870 Fifth Packet: This packet will have a fourth tile part (tile 3) 1290 871 bytes 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | 0 | 0 | 1 |0| 1 | 3 | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | 0 | 4388 | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 |FF90 000A 0003 0000 050A 0001 FF93 .... | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Figure 11: Header Sample 2-5 (5th Packet) 885 A.3. Sample 3: Packing multiple tiles in single payload, fragmented 886 header. No header compensation, progressive image 888 First Packet: This packet will have the first part of the main 889 header. 110 bytes 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | 0 | 1 | 0 |1| 0 | 0 | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | 0 | 0 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 |FF4F FF51 002F 0000 .... | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Figure 12: Header Sample 3-1 (First Packet) 902 Second Packet: This packet has the second part of the main header. 903 1400 bytes 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | 0 | 2 | 0 |1| 0 | 0 | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | 0 | 110 | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 |FF64 00FF .... | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Figure 13: Header Sample 3-2 (Second Packet) 917 Third Packet: This packet has two tiles, tile 0 and tile 1 1400 bytes 919 0 1 2 3 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | 0 | 0 | 0 |1| 1 | 0 | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | 0 | 1510 | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 |FF90 000A 0000 0000 02BC 0001 FF93 ... | 927 // . // 928 |FF90 000A 0001 0000 02BC 0001 FF93 ... | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Figure 14: Header Sample 3-3 (Third Packet) 933 Fourth Packet: This packet has one tile, tile 2 1395 bytes 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | 0 | 0 | 0 |0| 1 | 2 | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | 0 | 2910 | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 |FF90 000A 0002 0000 0573 0001 FF93 .... | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 Figure 15: Header Sample 3-4 (4th Packet) 947 A.4. Sample 4: Interlace image, single tile 949 The codestream of each image is ordered in LRCP (Layer, Resolution, 950 Component, Position) with 1 layer, 3 resolutions, 3 components and 1 951 position. 953 First packet: This packet will have the whole main header for the odd 954 field 210 bytes 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | 1 | 3 | 1 |1| 0 | 0 | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | 0 | 0 | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 |FF4F FF51 002F 0000 .... | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 Figure 16: Header Sample 4-1 (First Packet) 968 Second packet: This packet will have the first part of the odd 969 field's tile where three jp2-packets are included. 1400 bytes 971 0 1 2 3 972 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 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | 1 | 0 | 1 |1| 1 | 0 | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | 0 | 210 | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 |FF90 000A 0000 0000 0578 0001 FF93 .... | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 Figure 17: Header Sample 4-2 (Second Packet) 983 Third packet: This packet will have the second part of the odd 984 field's tile 1400 bytes 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | 1 | 0 | 1 |1| 4 | 0 | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | 0 | 1610 | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 |7F04 E708 27D9 D11D 22CB ... | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 Figure 18: Header Sample 4-3 (Third Packet) 998 Fourth packet: This packet will have the third part of the odd 999 field's tile 1300 bytes 1001 0 1 2 3 1002 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 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | 1 | 0 | 1 |1| 7 | 0 | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | 0 | 3010 | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 |98BD EC9B 2826 DC62 D4AB ... | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 Figure 19: Header Sample 4 (4th Packet) 1013 Fifth packet: This packet will have the whole main header for the 1014 even field 1016 0 1 2 3 1017 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 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | 2 | 3 | 1 |1| 0 | 0 | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | 0 | 0 | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 |FF4F FF51 002F 0000 .... | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 Figure 20: Header Sample 4 (5th Packet) 1028 Sixth packet: This packet will have the first part of the odd field's 1029 tile 1400 bytes 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | 2 | 0 | 1 |1| 1 | 0 | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | 0 | 1610 | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 |FF90 000A 0000 0000 0578 0001 FF93 .... | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 Figure 21: Header Sample 4 (6th Packet) 1043 Seventh packet: This packet will have the second part of the odd 1044 field's tile 1400 bytes 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | 2 | 0 | 1 |1| 4 | 0 | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | 0 | 3010 | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 |626C 42F0 166B 6BD0 F8E1 ... | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 Figure 22: Header Sample 4 (7th Packet) 1058 Eighth packet: This packet will have the third part of the odd 1059 field's tile 1300 bytes 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | 2 | 0 | 1 |1| 7 | 0 | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | 0 | 4410 | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 |8114 41D5 18AB 4A1B ... | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 Figure 23: Header Sample 4 (8th Packet) 1073 Authors' Addresses 1075 Andrew Leung 1076 Sony Corporation 1077 1-7-1 Konan 1078 Minato-ku 1079 Tokyo 108-0075 1080 Japan 1082 Phone: +81 3 6748-2111 1083 Email: andrew @ ualberta . net 1084 URI: http://www.sony.net/ 1086 Satoshi Futemma 1087 Sony Corporation 1088 1-7-1 Konan 1089 Minato-ku 1090 Tokyo 108-0075 1091 Japan 1093 Phone: +81 3 6748-2111 1094 Email: satosi-f @ sm . sony . co . jp 1095 URI: http://www.sony.net/ 1097 Eisaburo Itakura 1098 Sony Corporation 1099 1-7-1 Konan 1100 Minato-ku 1101 Tokyo 108-0075 1102 Japan 1104 Phone: +81 3 6748-2111 1105 Email: itakura @ sm . sony . co . jp 1106 URI: http://www.sony.net/ 1108 Full Copyright Statement 1110 Copyright (C) The IETF Trust (2008). 1112 This document is subject to the rights, licenses and restrictions 1113 contained in BCP 78, and except as set forth therein, the authors 1114 retain all their rights. 1116 This document and the information contained herein are provided on an 1117 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1118 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1119 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1120 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1121 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1122 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1124 Intellectual Property 1126 The IETF takes no position regarding the validity or scope of any 1127 Intellectual Property Rights or other rights that might be claimed to 1128 pertain to the implementation or use of the technology described in 1129 this document or the extent to which any license under such rights 1130 might or might not be available; nor does it represent that it has 1131 made any independent effort to identify any such rights. Information 1132 on the procedures with respect to rights in RFC documents can be 1133 found in BCP 78 and BCP 79. 1135 Copies of IPR disclosures made to the IETF Secretariat and any 1136 assurances of licenses to be made available, or the result of an 1137 attempt made to obtain a general license or permission for the use of 1138 such proprietary rights by implementers or users of this 1139 specification can be obtained from the IETF on-line IPR repository at 1140 http://www.ietf.org/ipr. 1142 The IETF invites any interested party to bring to its attention any 1143 copyrights, patents or patent applications, or other proprietary 1144 rights that may cover technology that may be required to implement 1145 this standard. Please address the information to the IETF at 1146 ietf-ipr@ietf.org.