idnits 2.17.1 draft-ietf-avt-rtp-jpeg2000-beam-00.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 986. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 915. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the mh_id field is set to 0, the receiver MUST not save the main header and MUST NOT compensate for lost headers. -- 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 (February 14, 2005) is 6983 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. '2' ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Andrew Leung 2 draft-ietf-avt-rtp-jpeg2000-beam-00.txt Satoshi Futemma 3 Eisaburo Itakura 4 Sony Corporation 5 February 14, 2005 6 Expires: August 25, 2005 8 Enhanced Processing For Priority and Header in: 9 RTP Payload Format for JPEG 2000 Video Streams 11 Status of this Memo 13 By submitting this Internet-Draft, we certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which we become aware will be disclosed, in accordance 16 with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference materials or to cite them other than as "work in 27 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-Drafts Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This memo describes extended uses for payload header in RFCXXXY, An 38 RTP Payload Format for JPEG 2000 Video, for better support of JPEG 39 2000 features such as scalability and includes a main header 40 recovery method. 42 This memo MUST be accompanied with an implementation of RFCXXXY for 43 a complete implementation. RFCXXXY itself is a complete description 44 of the payload header and signaling, this document only describes 45 additional processing of values for the payload header. There is 46 also another MIME and SDP marker signaling for implementations of 47 this document. 49 1. Introduction 51 This document is an extension of RFCXXXY, An RTP Payload Format for 52 JPEG 2000 Video. There are additional mechanisms to be used with 53 certain parts of the header in RFCXXXY to support JPEG 2000 54 features such as scalability and a main header recovery method. 55 These mechanisms are described in detail in this document. 57 History 59 In the development of RFCXXXY, Sony Corporation filed a patent 60 application on certain mechanisms with the main header recovery, 61 priority table usage, etc. As these are not "essential" to the core 62 RTP format and only describes a mechanism, it was decided that 63 splitting these mechanisms from the core RTP format (essentially 64 IPR free) into another document (IPR). This is the document 65 describing the mechanisms. 67 Description of the mechanisms 69 o Main Header Compensation 71 JPEG 2000's scalable coding scheme allows for decompressing 72 truncated or partial data streams but only when the main header 73 is present. If the header is lost, the data is useless. Also, 74 with JPEG 2000 video coding, coding parameters between frames 75 will rarely change and previous headers may be used in newly 76 received data without headers. 78 A recovery of the main header that has been lost is very simple 79 with this procedure. In the case of JPEG 2000 video, it is common 80 that encode parameters will not vary greatly between each 81 successive frame. Even if the RTP packet including the main header 82 of a frame has been dropped, decoding may be performed by using the 83 main header of a previous frame. 85 o Priority Table 87 JPEG 2000 codestream has rich functionality built into it so 88 decoders can easily handle scalable delivery or progressive 89 transmission. Progressive transmission allows images to be 90 reconstructed with increasing pixel accuracy or spatial resolution. 91 This feature allows the reconstruction of images with different 92 resolutions and pixel accuracy, for different target devices. A 93 single image source can provide a codestream that is easily 94 processed for smaller image display devices. 96 JPEG 2000 packets contain all compressed image data from a 97 specific: layer, component, resolution level, and/or precinct. The 98 order in which these JPEG 2000 packets are found in the codestream 99 is called: progression order. The ordering of the JPEG 2000 packets 100 can progress along four axes: layer, component, resolution and 101 precinct. 103 Providing a priority field to indicate the importance of data 104 contained in a given RTP packet can aid in usage of JPEG 2000 105 progressive and scalable functions. 107 1.1 Conventions Used in this Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 110 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 111 in this document are to be interpreted as described in RFC2119 112 [1]. 114 2. Payload Format Enhanced Processing 116 2.1 Enhanced Processing Markers 118 This section of the document describes changes in the mh_id and 119 priority value which differ from RFCXXXY. Implementions of this 120 document should follow protocol in RFCXXXY first then add in 121 additional header processing for this document. Implementations 122 following this document are expected to seamlessly work with 123 implementations of just RFCXXXY. 125 The RTP payload header format for JPEG 2000 video stream is as 126 follows: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |tp |MHF|mh_id|T| priority | tile number | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |reserved | fragment offset | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Fig. 3: RTP payload header format for JPEG 2000 138 mh_id (Main Header Identification) : 3 bits 140 Main header identification value. This is used for JPEG 141 2000 main header recovery. 143 The same mh_id value is used as long as the coding parameters 144 described in the main header remains unchanged. 146 The initial value of mh_id is random, and may take any value 147 between 1-7, but MUST NOT be 0. 149 When mh_id is 0, it has special usage for 150 the receiver. This special usage is described in Section xxx of 151 this document. 153 The mh_id value MUST increment by 1 every time a new main 154 header is transmitted. Once the mh_id value is greater than 7, 155 it rolls over to 1. 157 priority : 8 bits 159 The priority field indicates the importance of the JPEG 2000 160 packet included in the payload. Typically, a higher priority 161 is set in the packets containing JPEG 2000 packets containing 162 the lower sub-bands. 164 This header is described in detail in documentXXX. Systems not 165 using the method described in documentXXX at the sender this 166 value SHOULD be set to 0 and receivers SHOULD ignore this 167 value. 169 Special values of priority: 171 0 : This is reserved for payload which contain a 172 header (main or tile part header.) This is 173 considered the highest importance. 175 1 to 255 : These values decrease in importance as the 176 values increase. (i.e. 1 is more important than 177 2, etc.) Hence applying priority values should 178 correlate directly to JPEG 2000 codestream in 179 importance in basic usage. 181 The lower the priority value is the higher the priority. 182 Simply, the priority value 0 is the highest priority and 255 is 183 the lowest priority. We define the priority value 0 as a 184 special priority value for the headers (the main header or 185 tile-part header). When any headers (the main header or 186 tile-part header) are packed into the RTP packet, the sender 187 MUST set the priority value to 0. 189 3. Priority Mapping Table 191 For the progression order, the priority value for each JPEG 2000 192 packet is given by the priority mapping table. 194 3.1 Pre-Defined Priority Mapping 196 This document specify several commonly-used several priority 197 mapping table, pre-defined priority mapping tables: packet number 198 based (default), progression-based, layer-based, resolution-based, 199 component-based. 201 Packet number priority mapping is REQUIRED to be supported by 202 clients implementing this specification. Other priority mapping 203 tables (progression, layer, resolution, and component based) are 204 OPTIONAL to implementations of this specification. 206 Rules that all implementations of this specification MUST follow 207 in all priority modes: 209 When there is a header in the packet with a JPEG 2000 packet, 210 the sender MUST set the payload packet priority value to 0. 212 When there are multiple JPEG 2000 packets in the same RTP payload 213 packet, the sender MUST set the payload packet priority value to 214 the lowest priority value of the lowest JPEG 2000 packet. 215 (i.e. if JPEG 2000 packets with priority: 5,6,7 are packed into a 216 single payload, the priority value MUST be 5.) 218 3.1.1 Packet number based Ordering 220 This is the default mode for payload packet priority value and 221 all implementation of this specification MUST support. 223 The sender will have a one-to-one association between payload 224 packet priority value and the payload packet value (i.e. the 225 JPEG 2000 codestream.) The RTP packet value is equal to the 226 JPEG 2000 packet value. 228 If the packet value of JPEG 2000 codestream is greater than 255, 229 the sender MUST set the payload priority value to 255. 231 3.1.2 Progression-based Ordering 233 The sender will assign the payload packet priority value only 234 based on layer, resolution, and component ordering of the 235 codestream. 237 This is similar to the JPEG 2000 packet number based format but 238 will not take into account the precinct number or position in the 239 JPEG 2000 codestream. 241 For example: 242 If the codestream is ordered in LRCP (Layer, Resolution, 243 Component, Position) 245 All the packets in layer 0 246 resolution 0 247 component 0 : packet priority value : 1 249 All the packets in layer 0 250 resolution 0 251 component 1 : packet priority value : 2 253 All the packets in layer 0 254 resolution 0 255 component 2 : packet priority value : 3 257 3.1.3 Layer-based Ordering 259 Layer-based priority mapping table simplifies the default mapping 260 to just matching JPEG 2000 packets together from the same layer. 262 For example: 263 All the packets in layer 0 : packet priority value : 1 264 All the packets in layer 1 : packet priority value : 2 265 All the packets in layer 2 : packet priority value : 3 266 All the packets in layer 3 : packet priority value : 4 268 3.1.4 Resolution-based Ordering 270 Resolution-based priority mapping table is similar to the layer 271 based order but for JPEG 2000 packets of the same resolution 273 For example: 274 All the packets in resolution 0 : packet priority value : 1 275 All the packets in resolution 1 : packet priority value : 2 276 All the packets in resolution 2 : packet priority value : 3 277 All the packets in resolution 3 : packet priority value : 4 279 3.1.5 Component-based Ordering 281 Component-based priority mapping table is mapping together 282 JPEG 2000 components of the same component 284 For example: 285 All the packets in component 0 : packet priority value : 1 286 All the packets in component 1 : packet priority value : 2 287 All the packets in component 2 : packet priority value : 3 288 All the packets in component 3 : packet priority value : 4 290 3.2 Application Specific Priority Table 292 The application specific priority table specification is intended 293 for experimental use as new applications and new priority mapping 294 tables are developed. 296 A case sensitive 8 character ASCII code describing the application 297 specific priority mapping name. The description of these 298 application specific priority tables are outside the scope of this 299 document. 301 This extension may be used when codestream is divided into many 302 layers and many resolutions. 304 4. JPEG 2000 Main Header Compensation Scheme 306 The mh_id field of the payload header is used to recognize whether 307 the encoding parameters of the main header are the same as the 308 encoding parameters of the previous frame. The same value is set 309 in mh_id of the RTP packet in the same frame. The mh_id and encode 310 parameters are not associated with each other as 1:1 but they are 311 used to recognize whether the encode parameters of the previous 312 frame are the same or not in the event of lost headers. 314 The mh_id field value SHOULD be saved from previous frames to be 315 used to recover the current frame's main header. If the mh_id of 316 the current frame has the same value as the mh_id value of the 317 previous frame, the previous frame's main header SHOULD be used to 318 decode the current frame, in case of a lost header. 320 The sender MUST increment mh_id when parameters in the header 321 change and send a new main header accordingly. 323 The receiver MAY use the mh_id and MAY retain the header for such 324 compensation. 326 4.1 Sender Processing 328 The sender MUST transmit RTP packets with the same mh_id value 329 unless the encoder parameters are different from the previous 330 frame. The encoding parameters are the fixed information marker 331 segment (SIZ marker) and functional marker segments (COD, COC, RGN, 332 QCD, QCC, and POC) specified in JPEG 2000 Part 1 Annex A [2]. 333 An initial value of mh_id MUST be selected randomly between 1 and 334 7. 335 If the encode parameters changes, the sender transmitting RTP 336 packets MUST increment the mh_id value by one, but when mh_id value 337 becomes greater than 7, a sender MUST set mh_id value to 1. 339 4.2 Receiver Processing 341 When the receiver receives the main header completely, the RTP 342 sequence number, the mh_id and main header should be saved. Only 343 the last main header that was received completely SHOULD be saved. 344 When the mh_id value is 0, the receiver SHOULD NOT save the header. 346 When the main header is not received, the receiver may compare the 347 current payload header's mh_id value with the saved mh_id value. 348 When the values are the same, decoding may be performed by using 349 the saved main header. 351 If the mh_id field is set to 0, the receiver MUST not save the 352 main header and MUST NOT compensate for lost headers. 354 5. Security Consideration 356 RTP packets using the payload format defined in this specification 357 are subject to the security considerations discussed in the RTP 358 specifications[3] and any applicable profile. This implies that 359 confidentiality of the media streams is achieved by encryption. 360 Data compression used with this payload format is applied 361 end-to-end, encryption may be performed on the compressed data so 362 there is no conflict between the two operations. 364 A potential denial-of-service threat exists for data encodings 365 using compression techniques that have non-uniform receiver-end 366 computational load. The attacker can inject pathological 367 datagrams into the stream which are complex to decode and cause 368 the receiver to be overloaded. The usage of authentication of at 369 least the RTP packet is RECOMMENDED, for example with SRTP [4]. 371 If QoS enhanced service is used, RTP receivers SHOULD monitor 372 packet loss to ensure that the service that was requested is 373 actually being delivered. If it is not, then they SHOULD assume 374 that they are receiving best-effort service and behave accordingly. 376 If best-effort service is being used, users of this payload format 377 MUST monitor packet loss to ensure that the packet loss rate is 378 within acceptable parameters. Packet loss is considered acceptable 379 if a TCP flow across the same network path, experiencing the same 380 network conditions, would achieve an average throughput, measured 381 on a reasonable timescale, that is not less than the RTP flow is 382 achieving. This condition can be satisfied by implementing 383 congestion control mechanisms to adapt the transmission rate (or 384 the number of layers subscribed for a layered multicast session), 385 or by arranging for a receiver to leave the session if the loss 386 rate is unacceptably high. 388 As with any IP-based protocol, in some circumstances a receiver 389 may be overloaded simply by receiving too many packets, either 390 desired or undesired. Network-layer authentication may be used to 391 discard packets from undesired sources, but the processing cost of 392 the authentication itself may be too high. In a multicast 393 environment, pruning of specific sources may be implemented in 394 future versions of IGMP [7] and in multicast routing protocols to 395 allow a receiver to select which sources are allowed to reach it. 397 6. IANA Consideration 399 6.1 MIME Registration 401 This document defines a new RTP payload name and associated MIME 402 type, jpeg2000. 404 The receiver MUST ignore any unspecified parameter. 406 The MIME registration form for JPEG 2000 video stream is enclosed 407 below: 409 MIME media type name: video 411 MIME subtype name: jpeg2000 413 REQUIRED parameters: BEAM 415 BEAM: Implmentations of this standard must include this option in 416 the parameter list when establishing a session. If this option is 417 supported, by the receiver/sender, both should reply with this 418 option in the mime parameter list. If the answer omits this in 419 the mime parameter list, the answerer does not support this 420 option 422 Encoding considerations: 423 JPEG 2000 video stream may be transmitted with RTP as specified 424 in this document. 426 Security considerations: see section 9 of RFC XXXX. 428 Interoperability considerations: 429 JPEG 2000 video stream is a sequence of JPEG 2000 still 430 images. An implementation in compliant with [1] can decode and 431 attempt to display the encoded JPEG 2000 video stream. 433 Published specification: ISO/IEC 15444-1 | ITU-T Rec. T.800 435 Applications which use this media type: 436 video streaming and communication 438 Additional information: none 440 Magic number(s): none 442 File extension(s): none 444 Macintosh File Type Code(s): none 445 Person & email address to contact for further information: 446 Eisaburo Itakura, Satoshi Futemma 447 Email: {itakura|satosi-f}@sm.sony.co.jp 449 Intended usage: COMMON 451 Author/Change controller: 452 Eisaburo Itakura, Satoshi Futemma 453 Email: {itakura|satosi-f}@sm.sony.co.jp 455 6.2 SDP Parameters 456 In addition to section 7.2 in RFCXXXY: 458 The MIME media type video/jpeg2000 string is mapped to fields in 459 the Session Description Protocol (SDP) [5] as follows: 461 o The media name in the "m=" line of SDP MUST be video. 463 o The encoding name in the "a=rtpmap" line of SDP MUST be jpeg2000 464 (the MIME subtype). 466 o The clock rate in the "a=rtpmap" line MUST be 90000. 468 o The REQUIRED parameters "BEAM" MUST be included in the "a=fmtp" 469 line of SDP. 471 o The OPTIONAL parameters "priority-table-default", 472 "priority-table-definition", "priority-table-protocol", MUST be 473 included in the "a=fmtp" line of SDP. 475 These parameters are expressed as a MIME media type string, in the 476 form of a semicolon separated list of parameter=value pairs. 478 Therefore, an example of media representation in SDP is as 479 follows: 481 m=video 49170/2 RTP/AVP 98 482 a=rtpmap:98 jpeg2000/90000 483 a=fmtp:98 BEAM;sampling=YCbCr-4:2:0;width=128;height=128 485 7. Usage with the SDP Offer/Answer Model 487 In addition to section 8 in RFCXXXY: 489 When offering JPEG 2000 over RTP using SDP in an Offer/Answer model 490 [6], the following rules and limitations apply: 492 o All parameters MUST have an acceptable value for that parameter. 494 o All parameters MUST correspond to the parameters of the payload. 496 o The parameters "BEAM" MUST appear in the offer 497 If the parameter "BEAM" is not in the answer, receivers should 498 not process the header according to this document. Senders SHOULD 499 continue to send data with payload headers according to 500 mechanisms outlined in this document. This is highly recommended 501 for multicast streams where not all receivers are of the same 502 type. 504 7.1 Examples 506 An example offer/answer exchanges are provided. 508 7.1.2 Example 1 510 Alice offers BEAM functionality, YCbCr 422 color space, interlace 511 image with 720-pixel width and 480-pixel height and several 512 priority-table options (jp2-packet, progression, layer, 513 resolution, component) as below: 515 v=0 516 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com 517 s= 518 c=IN IP4 host.anywhere.com 519 t=0 0 520 m=video 49170 RTP/AVP 98 521 a=rtpmap:98 jpeg2000/90000 522 a=fmtp:98 BEAM;sampling=YCbCr-4:2:2;interlace 523 a=fmtp:98 priority-table-definition=jp2-packet,progression,layer, 524 resolution,component; width=720; height=480 526 Bob accepts BEAM functionality, YCbCr-4:2:2 color space,interlace 527 image and jp2-packet based priority mapping (default mapping 528 table) and replies: 530 v=0 531 o=bob 2890844730 2890844731 IN IP4 host.example.com 532 s= 533 c=IN IP4 host.example.com 534 t=0 0 535 m=video 49920 RTP/AVP 98 536 a=rtpmap:98 jpeg2000/90000 537 a=fmtp:98 BEAM;sampling=YCbCr-4:2:2;interlace 539 Note that "priority-table-definition" parameter in Bob's answer is 540 omitted, so default priority mapping table (jp2-packet number based 541 priority mapping) is used. 543 7.1.2 Example 2 545 Alice offers YCbCr 420 color space, progressive image with 546 320-pixel width and 240-pixel height and layer priority-table 547 options as below: 549 v=0 550 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com 551 s= 552 c=IN IP4 host.anywhere.com 553 t=0 0 554 m=video 49170 RTP/AVP 98 555 a=rtpmap:98 jpeg2000/90000 556 a=fmtp:98 BEAM;sampling=YCbCr-4:2:0 557 a=fmtp:98 priority-table-definition=layer; width=320; height=240 559 Bob does not accept BEAM functionality but accepts YCbCr-4:2:0 560 color space,interlace image and layer based priority mapping and 561 replies: 563 v=0 564 o=bob 2890844730 2890844731 IN IP4 host.example.com 565 s= 566 c=IN IP4 host.example.com 567 t=0 0 568 m=video 49920 RTP/AVP 98 569 a=rtpmap:98 jpeg2000/90000 570 a=fmtp:98 sampling=YCbCr-4:2:2 572 Note that "BEAM" parameter was not in Bob's answer so Alice must 573 not use settings described in this document for sending or 574 receiving. 576 7.2 Sample Headers in Detail 578 This section has various sample headers in various configurations for 579 reference. 581 For reference, the payload header. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |tp |MHF|mh_id|T| priority | tile number | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 |reserved | fragment offset | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 For the first packet with the main header, this is what it will 592 look like. 594 Note, for this example MTU will be taken as: 1500bytes (Ethernet) 596 Sample 1: Progressive image with single tile, 3500bytes 597 (i.e. thumbnail) 599 First Packet: 600 This packet will have the whole main header. 601 210bytes 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 |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| 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 |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| 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 |FF4FFF51002F000 .... | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Second Packet: 614 This packet will have a tile header and the first tile part LLband 615 1500bytes 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 |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| 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |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| 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |FF90 000A 0000 0000 2DB3 0001 FF93 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Third Packet: 628 This packet will have the next part in the tile, no tile header 629 1500bytes 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 |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| 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 |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| 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 |E841 4526 4556 9850 C2EA .... | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Fourth Packet: 641 Last packet for the image 642 290bytes 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 |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| 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 |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| 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 |A55D 8B73 3B25 25C7 B9EB .... 2FBEB153| 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Smaple 2: Image with 4 tiles 656 First Packet: 657 This packet will have the whole main header. 658 210bytes 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |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| 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |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| 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 |FF4FFF51002F000 .... | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Second Packet: 671 This packet will have a first tile part (tile 0) 672 1400bytes 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 |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| 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 |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| 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 |FF90 000A 0000 0000 0578 0001 FF93 .... | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Third Packet: 684 This packet will have a second tile part (tile 1) 685 1423bytes 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 |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| 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 |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| 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 |FF90 000A 0001 0000 058F 0001 FF93 .... | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Fourth Packet: 697 This packet will have a third tile part (tile 2) 698 1355bytes 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 |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| 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 |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| 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |FF90 000A 0002 0000 054B 0001 FF93 .... | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Fifth Packet: 711 This packet will have a fourth tile part (tile 3) 712 1290bytes 714 0 1 2 3 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 |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| 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 |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| 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |FF90 000A 0003 0000 050A 0001 FF93 .... | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Sample 3: Packing multiple tiles in single payload, fragmented header 725 No header compensation, progressive image 727 First Packet: 728 This packet will have the first part of the main header. 729 110bytes 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 |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| 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 |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| 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 |FF4FFF51002F000 .... | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Second Packet: 741 This packet has the second part of the header. 742 1400bytes 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 |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| 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |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| 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 |FF6400FF .... | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Third Packet: 755 This packet has two tiles, tile 0 and tile 1 756 1400bytes 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 |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| 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |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| 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 |FF90 000A 0000 0000 02BC 0001 FF93 ... | 766 |FF90 000A 0001 0000 02BC 0001 FF93 ... | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Fourth Packet: 769 This packet has one tile, tile 2 770 1395bytes 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 |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| 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 |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| 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 |FF90 000A 0002 0000 0573 0001 FF93 .... | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Sample 4: Interlace image, single tile 784 First packet: 785 This packet will have the whole main header for the odd field 786 210bytes 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 |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| 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 |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| 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 |FF4FFF51002F000 .... | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Second packet: 799 This packet will have the first part of the odd field's tile 800 1400bytes 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 |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| 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 |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| 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 |FF90 000A 0000 0000 0578 0001 FF93 .... | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 Third packet: 812 This packet will have the second part of the odd field's tile 813 1400bytes 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 |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| 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 |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| 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 |7F04 E708 27D9 D11D 22CB ... | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 Fourth packet: 826 This packet will have the third part of the odd field's tile 827 1300bytes 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 |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| 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 |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| 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 |98BD EC9B 2826 DC62 D4AB ... | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Fifth packet: 840 This packet will have the whole main header for the even field 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 |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| 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 |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| 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 |FF4FFF51002F000 .... | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Sixth packet: 852 This packet will have the first part of the odd field's tile 853 1400bytes 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 |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| 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 |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| 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 |FF90 000A 0000 0000 0578 0001 FF93 .... | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Seventh packet: 866 This packet will have the second part of the odd field's tile 867 1400bytes 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 |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| 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 |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| 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 |626C 42F0 166B 6BD0 F8E1 ... | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 Eighth packet: 880 This packet will have the third part of the odd field's tile 881 1300bytes 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 |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| 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 0 0 0 1 0| 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 |8114 41D5 18AB 4A1B ... | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 11. Intellectual Property Right Statement 895 The IETF takes no position regarding the validity or scope of any 896 Intellectual Property Rights or other rights that might be claimed 897 to pertain to the implementation or use of the technology described 898 in this document or the extent to which any license under such 899 rights might or might not be available; nor does it represent that 900 it has made any independent effort to identify any such rights. 901 Information on the procedures with respect to rights in RFC 902 documents can be found in BCP 78 and BCP 79. 904 Copies of IPR disclosures made to the IETF Secretariat and any 905 assurances of licenses to be made available, or the result of an 906 attempt made to obtain a general license or permission for the use 907 of such proprietary rights by implementers or users of this 908 specification can be obtained from the IETF on-line IPR repository 909 at http://www.ietf.org/ipr. 911 The IETF invites any interested party to bring to its attention any 912 copyrights, patents or patent applications, or other proprietary 913 rights that may cover technology that may be required to implement 914 this standard. Please address the information to the IETF at 915 ietf-ipr@ietf.org. 917 12. Informative Appendix 919 12.1 Recommended Practices 921 Receiver Processing 923 In general, the receiver should scan for headers in packets 924 that have an MHF value > 0 to aid in main header recovery. 926 Receivers should be aware of both BEAM capable and incapbale 927 senders. If the sender is incapable of BEAM functionality, 928 receivers should not interpret headers as described in this 929 document. 931 13. References 933 Normative References 935 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 936 Levels", BCP14, RFC2119, March 1997. 938 [2] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800 939 "Information technology - JPEG 2000 image coding system - 940 Part 1: Core coding system", December 2000. 942 [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 943 "RTP: A Transport Protocol for Real Time 944 Applications", STD 64, RFC 945 3550, July 2003. 947 [4] M. Baugher, D. McGrew, M. Naslund, E. Carrara and K. Norrman, 948 "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, 949 March 2004. 951 [5] M. Handley and V. Jacobson, "SDP: Session Description 952 Protocol", RFC 2327, April 1998. 954 [6] J. Rosenberg and H. Schulzrinne, "An Offer/Answer Model with 955 Session Description Protocol (SDP)", RFC 3264, June 2002. 957 Informative References 959 [7] Deering, S., "Host Extensions for IP Multicasting", STD 5, 960 RFC 1112, August 1989. 962 14. Authors' Addresses 964 Andrew Leung/Satoshi Futemma/Eisaburo Itakura 965 Sony Corporation 966 6-7-35 Kitashinagawa Shinagawa-ku 967 Tokyo 141-0001 JAPAN 968 Phone: +81 3 5448 2125 969 Fax: +81 3 5448 4560 970 Email: andrew.leung@jp.sony.com, {satosi-f|itakura}@sm.sony.co.jp 972 15. Full Copyright Statement 974 Copyright (C) The Internet Society (2004). This document is 975 subject to the rights, licenses and restrictions contained in BCP 976 78, and except as set forth therein, the authors retain all their 977 rights. 979 This document and the information contained herein are provided on 980 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 981 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 982 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 983 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 984 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 985 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 986 PARTICULAR PURPOSE.