idnits 2.17.1 draft-ietf-avt-rtp-jpeg2000-beam-06.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 1138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1162. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 17, 2007) is 6218 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 4566 (ref. '5') (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4288 (ref. '7') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3555 (ref. '8') (Obsoleted by RFC 4855, RFC 4856) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 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: October 19, 2007 Sony 6 April 17, 2007 8 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main 9 Header Recovery 10 draft-ietf-avt-rtp-jpeg2000-beam-06 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 October 19, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This memo describes extended uses for payload header in RFC document: 44 "RTP Payload Format for JPEG 2000 Video Streams." For better support 45 of JPEG 2000 features such as scalability and includes a main header 46 recovery method. 48 This memo must be accompanied with a complete implementation of "RTP 49 Payload Format for JPEG 2000 Video Streams." That document is a 50 complete description of the payload header and signaling, this 51 document only describes additional processing for the payload header. 52 There is an additional media type and SDP marker signaling for 53 implementations of this document. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Description of the Mechanisms . . . . . . . . . . . . . . 4 60 1.2.1. Main Header Compensation . . . . . . . . . . . . . . . 4 61 1.2.2. Priority Table . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Motivations for Priority Field coding . . . . . . . . . . 5 63 1.3.1. Scenario: Just enough resolution . . . . . . . . . . . 5 64 1.3.2. Scenario: Multiple clients, single source . . . . . . 5 65 1.4. Conventions Used in This Document . . . . . . . . . . . . 6 66 2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 7 67 2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 7 68 3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 9 69 3.1. Packet Number Based Ordering . . . . . . . . . . . . . . . 9 70 3.2. Progression Based Ordering . . . . . . . . . . . . . . . . 9 71 3.3. Layer Based Ordering . . . . . . . . . . . . . . . . . . . 10 72 3.4. Resolution Based Ordering . . . . . . . . . . . . . . . . 10 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. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 78 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15 79 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 80 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 16 81 7.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 19 82 8. Usage with the SDP Offer/Answer Model . . . . . . . . . . . . 20 83 8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 8.1.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20 85 8.1.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 89 Appendix A. Sample Headers in Detail . . . . . . . . . . . . . . 24 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 91 Intellectual Property and Copyright Statements . . . . . . . . . . 33 93 1. Introduction 95 This document is an extension of: "RTP Payload Format for JPEG 2000 96 Video Streams" [1]. These are additional mechanisms that can be used 97 with certain parts of the header in [1] to support JPEG 2000 features 98 such as scalability and a main header compensation method. These 99 mechanisms are described in detail in this document. 101 1.1. History 103 In the development of RFC XXXY [1], there was an issue of IPR claims 104 on certain mechanisms with main header compensation, priority table 105 usage, etc. in RFC XXXY [1]. As these are not "essential" to the 106 core RTP format of RFC XXXY [1] and only describes a mechanism, it 107 was decided that splitting these mechanisms from the core JPEG 2000 108 RTP format in to a separate document. This is the document 109 describing the IPR related mechanisms for main header recover and 110 priority table usage. 112 1.2. Description of the Mechanisms 114 1.2.1. Main Header Compensation 116 JPEG 2000's scalable coding scheme allows for decompressing truncated 117 or partial data streams but only when the main header is present. If 118 the header is lost, the data is useless. With JPEG 2000 video 119 coding, coding parameters between frames will rarely change and 120 previous headers may be used in newly received data which the header 121 have been lost. 123 Compensation of the main header that has been lost is very simple 124 with this procedure. In the case of JPEG 2000 video, it is very 125 common that encode parameters will not vary greatly between 126 successive frames. Even if the RTP packet including the main header 127 of a frame has been dropped, decoding may be performed by using the 128 main header of a prior frame. 130 1.2.2. Priority Table 132 JPEG 2000 codestream has rich functionality built into it so decoders 133 can easily handle scalable delivery or progressive transmission. 134 Progressive transmission allows images to be reconstructed with 135 increasing pixel accuracy or spatial resolution. This feature allows 136 the reconstruction of images with different resolutions and pixel 137 accuracy, for different target devices. A single image source can 138 provide a codestream that is easily processed for smaller image 139 display devices. 141 JPEG 2000 packets contain all compressed image data from a specific: 142 layer, component, resolution level, and/or precinct. The order in 143 which these JPEG 2000 packets are found in the codestream is called: 144 progression order. The ordering of the JPEG 2000 packets can 145 progress along four axes: layer, component, resolution and precinct 146 (or position). 148 Providing a priority field to indicate the importance of data 149 contained in a given RTP packet can aid in usage of JPEG 2000 150 progressive and scalable functions. 152 1.3. Motivations for Priority Field coding 154 JPEG 2000 coding scheme allows one to reorder the codestream in many 155 ways. Even when the coding scheme is determined and arranged by the 156 encoder, a decoder can still re-arrange the code stream on the fly to 157 suit decode parameters such as: re-arranging from resolution 158 progressive to quality progressive. 160 Using the priority field coding, the decoder gains insight into the 161 codestream without access to the full codestream and exposes features 162 of JPEG 2000 to a higher level. 164 A few of the scenarios are presented below the authors have thought 165 of to utilize this field. The priority field allows more information 166 about the image to be sent without more signaling between sender and 167 receivers to leverage JPEG 2000 capabilities. 169 1.3.1. Scenario: Just enough resolution 171 The scenario is when rapid scene access is more important than higher 172 quality. By using the priority field, the receiver can decode for 173 its own quality level. If the sender cannot determine the receiver's 174 resolution, the receiver can select which parts of the codestream to 175 decode/load by using the priority field. 177 1.3.2. Scenario: Multiple clients, single source 179 In a multicast environment, there are clients with better visual 180 capability than others (i.e. TV conference vs. Mobile). The 181 respective clients can use the priority field to determine which 182 packets are vital for their own visual presentation. The sender will 183 have to do work on the priority field to optimally serve all the 184 clients while only managing a single visual stream. 186 1.4. Conventions Used in This Document 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC2119. [2]. 192 RFC-Editor Note: The RFC Editor is requested to replace all 193 occurences of RFC XXXY with the RFC number 194 draft-ietf-avt-rtp-jpeg2000 receives. At that time, please remove 195 this note. 197 2. Payload Format Enhanced Processing 199 2.1. Enhanced Processing Markers 201 This section of the document describes additional usage in the values 202 of mh_id and priority fields and interpretation which differ from RFC 203 XXXY [1]. Implementions of this document should follow RFC XXXY [1] 204 first then add additional header processing as described in this 205 document. Implementations following this document are expected to 206 interoperate with implementations of [1] and this document as well. 208 The RTP payload header format for JPEG 2000 video stream is as 209 follows: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |tp |MHF|mh_id|T| priority | tile number | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 |reserved | fragment offset | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 1: RTP payload header format for JPEG 2000 221 mh_id (Main Header Identification) : 3 bits 223 Main header identification value. This is used for JPEG 2000 main 224 header recovery. 226 The initial value of mh_id is random, and may take any value 227 between 1-7, but MUST NOT be 0. 229 The same mh_id value is used as long as the coding parameters 230 described in the main header remains unchanged between frames. 232 The mh_id value MUST be incremented by 1 every time a new main 233 header is transmitted. Once the mh_id value becomes greater than 234 7, it SHOULD roll over to 1. 236 When mh_id is 0, it has special usage for the receiver. This 237 special usage is described in Section 4.2 of this document. 239 Senders should follow Section 4.1 of this document for proper 240 mh_id assignment and usage. 242 priority : 8 bits 244 The priority field indicates the importance of the JPEG 2000 245 packet included in the payload. Typically, a higher priority is 246 set in the packets containing JPEG 2000 packets containing the 247 lower sub-bands. 249 Special values of priority: 251 0: This is reserved for payload which contain a header (main or 252 tile part header.) This is considered the most important. 254 1 to 255: These values decrease in importance as the values 255 increase. (i.e. 1 is more important than 2, etc.) Applying 256 priority values should correlate directly to JPEG 2000 257 codestream in importance. 259 The lower the priority value is the higher the importance. A 260 priority value of 0 is the highest importance and 255 is the 261 lowest importance. We define the priority value 0 as a special 262 priority value for the headers (the main header or tile-part 263 header). If any headers (the main header or tile-part header) are 264 packed into the RTP payload, the sender MUST set the priority 265 value to 0. 267 Assignment of the values are described in Section 3 269 3. Priority Mapping Table 271 For the progression order, the priority value for each JPEG 2000 272 packet is given by the priority mapping table. 274 This document specify several commonly-used priority mapping tables, 275 pre-defined priority mapping tables: packet number based (default), 276 progression-based, layer-based, resolution-based, position-based, and 277 component-based. 279 Packet number priority mapping is REQUIRED to be supported by clients 280 implementing this specification. Other priority mapping tables 281 (progression, layer, resolution, and component based) are OPTIONAL to 282 implementations of this specification. 284 Rules that all implementations of this specification MUST follow in 285 all priority modes: 287 o When there is a header in the packet with a JPEG 2000 packet, the 288 sender MUST set the payload packet priority value to 0. 290 o When there are multiple JPEG 2000 packets in the same RTP payload 291 packet, the sender MUST set the payload packet priority value to 292 the lowest JPEG 2000 packet. (i.e. if JPEG 2000 packets with 293 priority: 5,6,7 are packed into a single payload, the priority 294 value will be 5.) 296 3.1. Packet Number Based Ordering 298 Packet number based ordering assigns the payload packet priority 299 value from the "JPEG 2000 packet value". (note: JPEG 2000 codestreams 300 are stored in units of packets and each packet has a value .) This 301 method is the default method for assigning priority value. All 302 implementations of this specification MUST support this method. 304 If the JPEG 2000 codestream packet value is greater than 255, the 305 sender MUST set the payload priority value to 255. 307 3.2. Progression Based Ordering 309 The sender will assign the payload packet priority value only based 310 on layer, resolution, and component ordering of the codestream. 312 This is similar to the packet number based assignment but will not 313 take into account the precinct number or position in the JPEG 2000 314 codestream. 316 For example: 318 If the codestream is ordered in LRCP (Layer, Resolution, Component, 319 Position) 321 All the packets in: 323 layer.........0 324 resolution....0 325 component.....0 327 then the packet priority value : 1 329 All the packets in: 331 layer.........0 332 resolution....0 333 component.....1 335 then the packet priority value : 2 337 All the packets in: 339 layer.........0 340 resolution....0 341 component.....2 343 then the packet priority value : 3 345 3.3. Layer Based Ordering 347 Layer-based priority mapping table simplifies the default mapping to 348 just matching JPEG 2000 packets together from the same layer. 350 For example: 352 All the packets in layer 0 : packet priority value : 1 353 All the packets in layer 1 : packet priority value : 2 354 All the packets in layer 2 : packet priority value : 3 355 ... 356 All the packets in layer n : packet priority value : n+1 357 All the packets in layer 255 : packet priority value : 255 359 3.4. Resolution Based Ordering 361 Resolution-based priority mapping table is similar to the layer based 362 order but for JPEG 2000 packets of the same resolution 364 For example: 366 All the packets in resolution 0 : packet priority value : 1 367 All the packets in resolution 1 : packet priority value : 2 368 All the packets in resolution 2 : packet priority value : 3 369 ... 370 All the packets in resolution n : packet priority value : n+1 371 All the packets in resolution 255 : packet priority value : 255 373 3.5. Component Based Ordering 375 Component-based priority mapping table is mapping together JPEG 2000 376 components of the same component 378 For example: 380 All the packets in component 0 : packet priority value : 1 381 All the packets in component 1 : packet priority value : 2 382 All the packets in component 2 : packet priority value : 3 383 ... 384 All the packets in component n : packet priority value : n+1 385 All the packets in component 255 : packet priority value : 255 387 4. JPEG 2000 Main Header Compensation Scheme 389 The mh_id field of the payload header is used to indicate whether the 390 encoding parameters of the main header are the same as the encoding 391 parameters of the previous frame. The same value is set in mh_id of 392 the RTP packet in the same frame. The mh_id and encode parameters 393 are not associated with each other as 1:1 but they are used to 394 indicate whether the encode parameters of the previous frame are the 395 same or not in the event of a lost header. 397 The mh_id field value SHOULD be saved from previous frames to be used 398 to recover the current frame's main header. If the mh_id of the 399 current frame has the same value as the mh_id value of the previous 400 frame, the previous frame's main header MAY be used to decode the 401 current frame, in case of a lost header in the current frame. 403 The sender MUST increment mh_id when parameters in the header change 404 and send a new main header accordingly. 406 The receiver MAY use the mh_id and MAY retain the header for such 407 compensation. 409 4.1. Sender Processing 411 The sender MUST transmit RTP packets with the same mh_id value if the 412 encoder parameters of the current frame are the same as the previous 413 frame. The encoding parameters are the fixed information marker 414 segment (SIZ marker) and functional marker segments (COD, COC, RGN, 415 QCD, QCC, and POC) specified in JPEG 2000 Part 1 Annex A [3]. 417 An initial value of mh_id MUST be selected randomly between 1 and 7 418 for security reasons. 420 If the encode parameters changes, the sender transmitting RTP packets 421 MUST increment the mh_id value by one, but when mh_id value becomes 422 greater than 7, a sender MUST set mh_id value back to 1. 424 4.2. Receiver Processing 426 When the receiver receives the main header completely, the RTP 427 sequence number, the mh_id and main header should be saved. Only the 428 last main header that was received completely SHOULD be saved. When 429 the mh_id value is 0, the receiver SHOULD NOT save the header. 431 When the main header is not received, the receiver may compare the 432 current payload header's mh_id value with the previous saved mh_id 433 value. If the values match, decoding may be performed by using the 434 previously saved main header. 436 If the mh_id field is set to 0, the receiver MUST NOT save the main 437 header and MUST NOT compensate for lost headers. 439 If the mh_id value changes, receivers SHOULD save the current header 440 and save the new mh_id value. The old saved header should be deleted 441 from storage. 443 5. Security Consideration 445 Please refer to section 6 of RFC XXXY [1] for Security Considerations 446 regarding this RTP format. 448 6. Congestion Control 450 Please refer to section 7 of RFC XXXY [1] for Congestion Control 451 regarding this RTP format. 453 7. IANA Consideration 455 7.1. Media Type Registration 457 This document extends the associated media type from RFC XXXY[1]: 458 Here is the complete original for reference. 460 This registration uses the template defined in [7] and follows [8]. 462 Type name: video 464 Subtype name: jpeg2000 466 Required parameters: 468 sampling: A list of values specifying the color space of the 469 payload data. 471 Acceptable values: 473 RGB: standard Red, Green, Blue color space. 475 BGR: standard Blue, Green, Red color space. 477 RGBA: standard Red, Green, Blue, Alpha color space. 479 BGRA: standard Blue, Green, Red, Alpha color space. 481 YCbCr-4:4:4: standard YCbCr color space, no subsampling. 483 YCbCr-4:2:2: standard YCbCr color space, Cb and Cr are 484 subsampled horizontally by 1/2. 486 YCbCr-4:2:0: standard YCbCr color space, Cb and Cr are 487 subsampled horizontally and vertically by 1/2. 489 YCbCr-4:1:1: standard YCbCr color space, Cb and Cr are 490 subsampled vertically by 1/4 492 GRAYSCALE: basically a single component image of just 493 multilevels of grey. 495 EXTENSION VALUE: Additional color samplings can be registered 496 with and current listing of registered color samplings at: 497 Color Sampling Registration Authority. Please refer to RTP 498 Format for Uncompressed Video. [9] 500 Optional parameters: 502 interlace: interlace scanning. If payload is in interlace 503 format, the acceptable value is "1", otherwise, the value 504 should be "0". Each complete image forms vertically half the 505 display. tp value MUST properly specify the field the image 506 represents odd(tp=1), or even(tp=2). If this option is not 507 present, the payload MUST be in progressive format and tp MUST 508 be set to 0. 510 width: A parameter describing the maximum width of the video 511 stream. This parameter MUST appear when height is present. 512 Acceptable values: - an integer value between 0 - 513 4,294,967,295. 515 height: A parameter describing the maximum height of the video 516 stream. This parameter MUST appear when width is present. 517 Acceptable values: - an integer value between 0 - 518 4,294,967,295. 520 The receiver MUST ignore any unspecified parameters outside of this 521 list and in [1] . 523 Additional parameters for this extension: 525 mhc : Main Header Compensation. this option is used when sender 526 and/or receiver is utilizing the Main Header compensation 527 technique as specified in this document. Acceptable values 528 when using the Main Header compensation technique is "1", 529 otherwise, it should be "0". 531 This is a list of options to be included when the sender or 532 receiver is utilizing the Priority Table(s) as specified in 533 this document. 535 pt : Priority Table. this option is followed by a comma-separated 536 list of predefined priority table definitions to be used by 537 sender or receiver. 539 The option appearing front most in the option line is the most 540 important and next ones are of decreasing importance. 542 Acceptable values: 544 progression : this table follows the progression ordering 545 of the codestream. 547 layer : this table follows the layer ordering of the 548 codestream. 550 resolution : this table follows the resolution ordering of 551 the codestream. 553 component : this table follows the component ordering of 554 the codestream. 556 default : this table follows the ordering of the 557 codestream. 559 Encoding considerations: 561 This media type is framed and binary, see Section 4.8 in [7] 563 Security considerations: 565 see security considerations section Section 5 of this document. 567 Interoperability considerations: 569 JPEG 2000 video stream is a sequence of JPEG 2000 still images. 570 An implementation in compliant with [3] can decode and attempt to 571 display the encoded JPEG 2000 video stream. 573 Published specification: ISO/IEC 15444-1 | ITU-T Rec. T.800 575 Applications which use this media type: 577 video streaming and communication 579 Person and email address to contact for further information: 581 Eisaburo Itakura, Satoshi Futemma, Andrew Leung 582 Email: {itakura|satosi-f} @ sm . sony . co . jp, andrew @ ualberta 583 . net 585 Intended usage: Restriction 587 Restrictions on Usage: 589 This media type depends on RTP framing, and hence is only 590 defined for the transfer via RTP [4]. Transport within other 591 framing protocols is not defined at the time. 593 Author/Change Controller: 595 Author: 597 Eisaburo Itakura, Satoshi Futemma, Andrew Leung 598 Email: {itakura|satosi-f} @ sm . sony . co . jp, andrew @ 599 ualberta . net 601 Change controller: 603 IETF Audio/Video Transport Working Group delegated from the 604 IESG 606 7.2. SDP Parameters 608 In addition to SDP Parameters section in [1]: 610 The media type video/jpeg2000 string is mapped to fields in the 611 Session Description Protocol (SDP) [5] as follows: 613 o The media name in the "m=" line of SDP MUST be video. 615 o The encoding name in the "a=rtpmap" line of SDP MUST be jpeg2000 616 (the MIME subtype). 618 o The clock rate in the "a=rtpmap" line MUST be 90000. 620 o The OPTIONAL parameters "mhc" or "pt" MUST be included in the 621 "a=fmtp" line of SDP. 623 These parameters are expressed as a media type string, in the form of 624 a semicolon separated list of parameter=value pairs. 626 Therefore, an example of media representation in SDP is as follows: 628 m=video 49170/2 RTP/AVP 98 629 a=rtpmap:98 jpeg2000/90000 630 a=fmtp:98 mhc=1;pt=default; sampling=YCbCr-4:2:0; width=128; 631 height=128 633 8. Usage with the SDP Offer/Answer Model 635 In addition to SDP Offer/Answer section in RFC XXXY [1]: 637 When offering JPEG 2000 over RTP using SDP in an Offer/Answer model 638 [6], the following rules and limitations apply: 640 o All parameters MUST have an acceptable value for that parameter. 642 o All parameters MUST correspond to the parameters of the payload. 644 o The parameters "mhc" or "pt" MUST appear in the offer and answer. 645 If the parameter "mhc" or "pt" is not in the answer, senders 646 should not process the header according to this document. 648 o For the "pt" option: 650 * Senders should send a complete list indicating which option are 651 available to the receiver. The receiver should answer with 652 their preference from the offer list. 654 o In a multicast environment: 656 * Senders should send out one option for priority-table- 657 definition for everyone in the group. 659 * If a single client in the group do not support the extensions 660 outlined in this document, senders SHOULD NOT use additional 661 techniques outlined in this document. 663 This is highly recommended for multicast streams where not all 664 receivers are of the same type. 666 8.1. Examples 668 Offer/Answer example exchanges are provided. 670 8.1.1. Example 1 672 Alice offers Main Header Compensation functionality, YCbCr 422 color 673 space, interlace image with 720-pixel width and 480-pixel height and 674 several priority-table options (default, progression, layer, 675 resolution, component) as below: 677 v=0 678 o=alice 2890844526 2890844526 IN IP4 host.example 679 s= 680 c=IN IP4 host.example 681 t=0 0 682 m=video 49170 RTP/AVP 98 683 a=rtpmap:98 jpeg2000/90000 684 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2; interlace=1; 685 pt=default,progression,layer,resolution, component; 686 width=720;height=480 688 Bob accepts Main Header Compensation functionality, YCbCr-4:2:2 color 689 space, interlace image, default mapping table and replies: 691 v=0 692 o=bob 2890844730 2890844731 IN IP4 host.example 693 s= 694 c=IN IP4 host.example 695 t=0 0 696 m=video 49920 RTP/AVP 98 697 a=rtpmap:98 jpeg2000/90000 698 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2;interlace=1; 699 pt=default;width=720;height=480 701 8.1.2. Example 2 703 Alice offers Main Header Compensation, YCbCr 420 color space, 704 progressive image with 320-pixel width and 240-pixel height and layer 705 priority-table options as below: 707 v=0 708 o=alice 2890844526 2890844526 IN IP4 host.example 709 s= 710 c=IN IP4 host.example 711 t=0 0 712 m=video 49170 RTP/AVP 98 713 a=rtpmap:98 jpeg2000/90000 714 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0; 715 pt=layer;width=320;height=240 717 Bob does not accept Main Header Compensation functionality but 718 accepts YCbCr-4:2:0 color space,layer based priority mapping and 719 replies: 721 v=0 722 o=bob 2890844730 2890844731 IN IP4 host.example 723 s= 724 c=IN IP4 host.example 725 t=0 0 726 m=video 49920 RTP/AVP 98 727 a=rtpmap:98 jpeg2000/90000 728 a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0; 729 pt=layer;width=320;height=240 731 9. References 733 9.1. Normative References 735 [1] Futemma, "RTP Payload Format for JPEG 2000 Video Streams", 736 RFC XXXY, April 2007. 738 [2] Bradner, "Key words for use in RFCs to Indicate Requirement 739 Levels", RFC 2119, March 1997. 741 [3] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, 742 "Information Technology - JPEG 2000 Image Coding System - Part 743 1: Core Coding System", December 2000. 745 [4] Schulzrinne, Casner, Frederick, and Jacobson, "RTP: A Transport 746 Protocol for Real Time Applications", RFC 3550, STD 64, 747 July 2003. 749 [5] Handley and Jacobson, "SDP: Session Description Protocol", 750 RFC 4566, July 2006. 752 [6] Rosenberg and Schulzrinne, "An Offer/Answer Model with Session 753 Description Protocol (SDP)", RFC 3264, June 2002. 755 [7] Freed and Klensin, "Media Type Specifications and Registration 756 Procedures", RFC 4288, December 2005. 758 [8] Casner and Hoschka, "MIME Type Registration of RTP Payload 759 Formats", RFC 3555, July 2003. 761 9.2. Informative References 763 [9] Perkins and Gharai, "RTP Payload Format for Uncompressed Video", 764 RFC 4175, September 2005. 766 Appendix A. Sample Headers in Detail 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 |tp |MHF|mh_id|T| priority | tile number | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 |reserved | fragment offset | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Figure 2 778 First Packet: This packet will have the whole main header. 210 bytes 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 |0 0|1 1|1 0 1|1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 |FF4FFF51002F000 .... | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 Figure 3 792 Second Packet: This packet will have a tile header and the first tile 793 part LLband 1500 bytes 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 |0 0|1 1|1 0 1|0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 1 0| 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 |FF90 000A 0000 0000 2DB3 0001 FF93 | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Figure 4 807 Third Packet: This packet will have the next part in the tile, no 808 tile header 1500 bytes 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 |0 0|0 0|1 0 1|0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 1 0 1 1 1 0| 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 |E841 4526 4556 9850 C2EA .... | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 Figure 5 822 Fourth Packet: Last packet for the image 290 bytes 824 0 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 |0 0|0 0|1 0 1|0|0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 1 0 1 0| 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 |A55D 8B73 3B25 25C7 B9EB .... 2FBEB153| 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Figure 6 836 First Packet: This packet will have the whole main header. 210 bytes 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 |0 0|1 1|0 0 1|1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 |FF4FFF51002F000 .... | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Figure 7 850 Second Packet: This packet will have a first tile part (tile 0) 1400 851 bytes 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 |0 0|0 0|0 0 1|0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 1 0| 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 |FF90 000A 0000 0000 0578 0001 FF93 .... | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Figure 8 865 Third Packet: This packet will have a second tile part (tile 1) 1423 866 bytes 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 |0 0|0 0|0 0 1|0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 1 0 1 0| 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 |FF90 000A 0001 0000 058F 0001 FF93 .... | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Figure 9 880 Fourth Packet: This packet will have a third tile part (tile 2) 1355 881 bytes 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 |0 0|0 0|0 0 1|0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 1 1 0 0 1| 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 |FF90 000A 0002 0000 054B 0001 FF93 .... | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Figure 10 895 Fifth Packet: This packet will have a fourth tile part (tile 3) 1290 896 bytes 898 0 1 2 3 899 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 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 |0 0|0 0|0 0 1|0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1| 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 1 0 0 1 0 0| 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 |FF90 000A 0003 0000 050A 0001 FF93 .... | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Figure 11 910 First Packet: This packet will have the first part of the main 911 header. 110 bytes 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 |0 0|0 1|0 0 0|1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 |FF4FFF51002F000 .... | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Figure 12 925 Second Packet: This packet has the second part of the header. 1400 926 bytes 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 |0 0|1 0|0 0 0|1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1 0| 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 |FF6400FF .... | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Figure 13 940 Third Packet: This packet has two tiles, tile 0 and tile 1 1400 bytes 942 0 1 2 3 943 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 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 |0 0|0 0|0 0 0|1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 1 1 0| 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 |FF90 000A 0000 0000 02BC 0001 FF93 ... | 950 |FF90 000A 0001 0000 02BC 0001 FF93 ... | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Figure 14 955 Fourth Packet: This packet has one tile, tile 2 1395 bytes 957 0 1 2 3 958 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 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 |0 0|0 0|0 0 0|0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1 0 1 1 1 1 0| 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 |FF90 000A 0002 0000 0573 0001 FF93 .... | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 15 969 First packet: This packet will have the whole main header for the odd 970 field 210 bytes 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 |0 1|1 1|0 1 0|1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 |FF4FFF51002F000 .... | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 Figure 16 984 Second packet: This packet will have the first part of the odd 985 field's tile 1400 bytes 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 |0 1|0 0|0 1 0|1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 1 0| 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 |FF90 000A 0000 0000 0578 0001 FF93 .... | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 Figure 17 999 Third packet: This packet will have the second part of the odd 1000 field's tile 1400 bytes 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 |0 1|0 0|0 1 0|1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 1 0 1 0| 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 |7F04 E708 27D9 D11D 22CB ... | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 Figure 18 1014 Fourth packet: This packet will have the third part of the odd 1015 field's tile 1300 bytes 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 |0 1|0 0|0 1 0|1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 1 0| 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 |98BD EC9B 2826 DC62 D4AB ... | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 Figure 19 1029 Fifth packet: This packet will have the whole main header for the 1030 even field 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 |1 0|1 1|0 1 1|1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 |FF4FFF51002F000 .... | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 Figure 20 1044 Sixth packet: This packet will have the first part of the odd field's 1045 tile 1400 bytes 1047 0 1 2 3 1048 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 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 |1 0|0 0|0 1 0|1|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 1 0| 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 |FF90 000A 0000 0000 0578 0001 FF93 .... | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 Figure 21 1059 Seventh packet: This packet will have the second part of the odd 1060 field's tile 1400 bytes 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 |1 0|0 0|0 1 0|1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 1 0 1 0| 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 |626C 42F0 166B 6BD0 F8E1 ... | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 Figure 22 1074 Eighth packet: This packet will have the third part of the odd 1075 field's tile 1300 bytes 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 |1 0|0 0|0 1 0|1|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 1 0| 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 |8114 41D5 18AB 4A1B ... | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 Figure 23 1089 Authors' Addresses 1091 Andrew Leung 1092 Sony Corporation 1093 1-7-1 Konan 1094 Minato-ku 1095 Tokyo 108-0075 1096 Japan 1098 Phone: +81 3 6748-2111 1099 Email: andrew @ ualberta . net 1100 URI: http://www.sony.net/ 1102 Satoshi Futemma 1103 Sony Corporation 1104 1-7-1 Konan 1105 Minato-ku 1106 Tokyo 108-0075 1107 Japan 1109 Phone: +81 3 6748-2111 1110 Email: satosi-f @ sm . sony . co . jp 1111 URI: http://www.sony.net/ 1113 Eisaburo Itakura 1114 Sony Corporation 1115 1-7-1 Konan 1116 Minato-ku 1117 Tokyo 108-0075 1118 Japan 1120 Phone: +81 3 6748-2111 1121 Email: itakura @ sm . sony . co . jp 1122 URI: http://www.sony.net/ 1124 Full Copyright Statement 1126 Copyright (C) The IETF Trust (2007). 1128 This document is subject to the rights, licenses and restrictions 1129 contained in BCP 78, and except as set forth therein, the authors 1130 retain all their rights. 1132 This document and the information contained herein are provided on an 1133 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1134 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1135 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1136 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1137 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1138 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1140 Intellectual Property 1142 The IETF takes no position regarding the validity or scope of any 1143 Intellectual Property Rights or other rights that might be claimed to 1144 pertain to the implementation or use of the technology described in 1145 this document or the extent to which any license under such rights 1146 might or might not be available; nor does it represent that it has 1147 made any independent effort to identify any such rights. Information 1148 on the procedures with respect to rights in RFC documents can be 1149 found in BCP 78 and BCP 79. 1151 Copies of IPR disclosures made to the IETF Secretariat and any 1152 assurances of licenses to be made available, or the result of an 1153 attempt made to obtain a general license or permission for the use of 1154 such proprietary rights by implementers or users of this 1155 specification can be obtained from the IETF on-line IPR repository at 1156 http://www.ietf.org/ipr. 1158 The IETF invites any interested party to bring to its attention any 1159 copyrights, patents or patent applications, or other proprietary 1160 rights that may cover technology that may be required to implement 1161 this standard. Please address the information to the IETF at 1162 ietf-ipr@ietf.org. 1164 Acknowledgment 1166 Funding for the RFC Editor function is provided by the IETF 1167 Administrative Support Activity (IASA).