idnits 2.17.1 draft-ietf-avt-rtp-jpeg2000-20.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1299. 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 (Jun 30, 2008) is 5776 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) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio Video Transport S. Futemma 3 Internet-Draft A. Leung 4 Intended status: Standards Track E. Itakura 5 Expires: January 1, 2009 Sony 6 Jun 30, 2008 8 RTP Payload Format for JPEG 2000 Video Streams 9 draft-ietf-avt-rtp-jpeg2000-20 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 1, 2009. 36 Abstract 38 This memo describes an RTP payload format for the ISO/IEC 39 International Standard 15444-1 | ITU-T Rec. T.800, otherwise better 40 known as: JPEG 2000. JPEG 2000 features are considered in the design 41 of this payload format. JPEG 2000 is a truly scalable compression 42 technology allowing applications to encode once and decode many 43 different ways. JPEG 2000 video stream is formed by extending from a 44 single image to a series of JPEG 2000 images. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Conventions Used in This Document . . . . . . . . . . . . 6 50 2. JPEG 2000 Video Features . . . . . . . . . . . . . . . . . . . 7 51 3. Payload Design . . . . . . . . . . . . . . . . . . . . . . . . 8 52 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 9 53 4.1. RTP Fixed Header Usage . . . . . . . . . . . . . . . . . . 9 54 4.2. RTP Payload Header Format . . . . . . . . . . . . . . . . 10 55 5. RTP Packetization . . . . . . . . . . . . . . . . . . . . . . 13 56 6. Media Type Registration . . . . . . . . . . . . . . . . . . . 15 57 7. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 18 58 7.1. SDP Mapping . . . . . . . . . . . . . . . . . . . . . . . 18 59 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 18 60 7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 20 61 7.2.2. Examples: non-90kHz timestamp . . . . . . . . . . . . 20 62 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 22 63 9. Security Consideration . . . . . . . . . . . . . . . . . . . . 23 64 10. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 24 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 66 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 67 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 68 Appendix A. Informative Appendix . . . . . . . . . . . . . . . . 27 69 A.1. Recommended Practices . . . . . . . . . . . . . . . . . . 27 70 A.2. Sample Headers in Detail . . . . . . . . . . . . . . . . . 28 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 72 Intellectual Property and Copyright Statements . . . . . . . . . . 37 74 1. Introduction 76 This document specifies a payload format for JPEG 2000 video streams 77 over the Real-time Transport Protocol (RTP). JPEG 2000 is an ISO/IEC 78 International Standard and ITU-T Recommendation (ISO/IEC 79 International Standard 15444-1 | ITU-T Rec. T.800) developed for next 80 generation still image compression. JPEG stands for the: Joint 81 Photograhers Experts Group. An international group made of academia 82 and industry to develop image compression standards. JPEG 2000 basic 83 compression technology is described in detail in ISO JPEG 2000 Part 84 1: Core Coding System[JPEG2000Pt_1] with motion covered in ISO JPEG 85 2000 Part 3: Motion JPEG 2000 [JPEG2000Pt_3]. 87 Part 3 of the JPEG 2000 standard defines Motion JPEG 2000 88 [JPEG2000Pt_3]. However, Motion JPEG 2000 focuses on the file format 89 and it does not specify the transmission format for the network. 90 This document specifies a transmission format for the network for a 91 series of JPEG 2000 images. 93 JPEG 2000 supports many powerful features [JPEG2000Pt_1] 94 [JPEG2000Pt_3]that are not supported in the current JPEG standard 95 such as: 97 o Higher compression efficiency than JPEG with less visual 98 distortion especially at extreme compression ratios. 100 o A single codestream that offers both lossy and lossless 101 compression. 103 o Better error resiliency than JPEG. 105 o Progressive transmission by pixel accuracy (SNR scalability) and 106 resolution (resolution scalability.) 108 o Random codestream access and processing. 110 The JPEG 2000 algorithm is briefly explained. Figure 1 shows a block 111 diagram of the JPEG 2000 encoding method. 113 +-----+ 114 | ROI | 115 +-----+ 116 | 117 V 118 +----------+ +----------+ +------------+ 119 |DC, comp. | | Wavelet | | | 120 Raw Image ==> |transform-|==>|transform-|==>|Quantization|==+ 121 | ation | | ation | | | | 122 +----------+ +----------+ +------------+ | 123 | 124 +-----------+ +----------+ +------------+ | 125 | | | | | | | 126 JPEG 2000 <==| Data |<==| Rate |<==| EBCOT |<=+ 127 codestream | Ordering | | Control | | | 128 +-----------+ +----------+ +------------+ 130 Figure 1: Block diagram of the JPEG 2000 encoder 132 The image is first transformed into wavelet coefficients. The image 133 is sampled into various levels vertically and horizontally from high 134 frequencies (which contain sharp details) to low frequencies (which 135 contain smooth areas.) Quantization is performed on the coefficients 136 within each sub-band. 138 After quantization, code blocks are formed from within the precincts 139 within the tiles. (Precincts are a finer separation than tiles and 140 code blocks are the smallest separation of the image data.) EBCOT 141 coding (Embedded Block Coding Optimized for Truncation) is performed 142 within each code block and arithmetically encoded by bit plane. Rate 143 control is performed to achieve the highest quality image for a 144 specified rate. 146 As a result, for a given tile, data units called JPEG 2000 packets 147 are generated, which contain data from a specific layer, a specific 148 component, a specific resolution, or a specific precinct, depending 149 on the data ordering. 151 Finally, the JPEG 2000 packets are interleaved according to the 152 progression along four axes: layer, resolution, component and 153 precinct, and add a JPEG 2000 header to become a fully compliant JPEG 154 2000 codestream. 156 To decompress a JPEG 2000 codestream, one would follow the reverse 157 order of the encoding order, without the quantization, and rate 158 control. 160 It is outside the scope of this document to further describe in 161 detail this procedure. Please refer to various JPEG 2000 texts for 162 further details [JPEG2000Pt_1]. 164 Figure 2 shows a JPEG 2000 codestream in detail. A JPEG 2000 165 codestream is structured from the main header beginning with the SOC 166 (Start Of Codestream) marker, one or more tiles, and the EOC (End Of 167 Codestream) marker to indicate the end of the codestream. Each tile 168 consists of a tile-part header that starts with the SOT (Start of 169 Tile) marker and ends with a SOD (Start of Data) marker, and 170 bitstream (a series of JPEG 2000 packet.) 172 +-- +------------+ 173 Main | | SOC | Required as the first marker. 174 header| +------------+ 175 | | main | Main header marker segments 176 +-- +------------+ 177 | | SOT | Required at the beginning of each 178 Tile- | +------------+ tile-part header. 179 part | | T0,TP0 | Tile 0, tile-part 0 header marker 180 header| +------------+ segments 181 | | SOD | Required at the end of each tile-part 182 +-- +------------+ header 183 | bitstream | Tile-part bitstream 184 +-- +------------+ 185 | | SOT | 186 Tile- | +------------+ 187 part | | T1,TP0 | 188 header| +------------+ 189 | | SOD | 190 +-- +------------+ 191 | bit stream | 192 +------------+ 193 . 194 . 195 . 196 +------------+ 197 | EOC | Required as the last marker in the code 198 +------------+ stream 200 Figure 2: Basic construction of the JPEG 2000 codestream 202 1.1. Conventions Used in This Document 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in RFC2119 [RFC2119]. 208 RFC-Editor Note: The RFC Editor is requested to replace all 209 occurrences of "RFC XXXX" with the RFC number 210 draft-ietf-avt-rtp-jpeg2000-beam receives. At that time please 211 remove this note. 213 2. JPEG 2000 Video Features 215 JPEG 2000 video streams are formed as a continuous series of JPEG 216 2000 still images. Previously described features of JPEG 2000 may be 217 used effectively in streaming applications for JPEG 2000 video. A 218 JPEG 2000 video stream has the following qualities: 220 o At low bit rates, the SNR is improved dramatically over JPEG and 221 Motion JPEG. 223 o This is a full intra frame format - each frame is independently 224 compressed - and therefore has a low encoding and decoding delay. 226 o JPEG 2000 has flexible and accurate rate control. 228 o This is suitable for traffic control and congestion control during 229 network transmission. 231 o JPEG 2000 can provide its own codestream error resilience markers 232 to aid in codestream recovery outside of this specification. 234 3. Payload Design 236 To design a payload format that maximizes JPEG 2000 features, the 237 following are taken into consideration: 239 o Provisions for packet loss: 241 On the Internet, 5% packet loss is common and this percentage may 242 vary, upto 20% or more. To split JPEG 2000 video streams into RTP 243 packets, efficient packetization of the code stream is required to 244 minimize problems in decoding due to missing packets. If the main 245 header is lost, the image cannot be decoded. 247 o JPEG 2000 Scalability 249 JPEG 2000 has powerful scalability features and markers in the 250 payload header indicate specific meaning of the payload. Such as: 252 * Since this is primarily for video applications, special markers 253 are used to indicate format (i.e. interlace odd/even fields). 255 * Special markers for the headers, fragment of headers, etc. 257 * Tile numbering for association of packets 259 * Priority importance of the packet using methods described in 260 RFC XXXX [JP2RTPEX]. 262 * Main header recovery using methods described in RFC XXXX 263 [JP2RTPEX]. 265 Additional usage of the payload header is described in RFC XXXX 266 [JP2RTPEX]. 268 4. Payload Format 270 4.1. RTP Fixed Header Usage 272 For each RTP packet, the RTP fixed header is followed by the JPEG 273 2000 RTP payload header, which is followed by the payload, a piece of 274 a JPEG 2000 codestream, which is usually a JPEG 2000 packet. 276 The RTP header fields that have a meaning specific to a JPEG 2000 277 video stream are described as follows: 279 Marker bit (M): The marker bit of the RTP fixed header MUST be set 280 to 1 for the last RTP packet of a video frame, otherwise, it MUST 281 be 0. When transmission is performed by multiple RTP sessions, 282 this bit is 1 in the last packet of the frame in each session. 284 Payload type (PT): The payload type is dynamically assigned by means 285 outside the scope of this document. A payload type in the dynamic 286 range shall be chosen by means of an out of band signaling 287 protocol (i.e. RTSP, SIP, etc.) 289 Timestamp: Timestamp indicates the presentation time of the frame 290 contained in the RTP packet. The same timestamp value MUST appear 291 in each RTP packet carrying a fragment of a given frame. When a 292 JPEG 2000 image is in interlace format, the odd field and the 293 corresponding even field MUST have the same timestamp value. 294 Following the RTP specification [RFC3550], the initial value of 295 the timestamp should be randomly chosen. 297 As for the clock rate, senders and receivers MUST support the 298 90kHz RTP timestamp rate, and MAY support other rates. RTP 299 timestamp rates below 1000 Hz SHOULD NOT be used because they will 300 result in insufficient resolution for RTCP measurements based on 301 the RTP timestamp, such as the interarrival jitter. The clock 302 rate MUST be negotiated at the start of the session. When using 303 SDP, it MUST be expressed using the "rtpmap" attributes. If non- 304 90kHz clock rate is to be used, it is RECOMMENDED to present not 305 only a preferable clock rate but also 90kHz clock rate with a 306 different RTP payload type. 308 4.2. RTP Payload Header Format 310 The RTP payload header format for JPEG 2000 video stream is as 311 follows: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |tp |MHF|mh_id|T| priority | tile number | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |reserved | fragment offset | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 3: RTP payload header format for JPEG 2000 323 tp (type) : 2 bits 325 This field indicates how a JPEG 2000 image is scanned (progressive 326 or interlace). 328 0: The payload is progressively scanned. 330 1: The payload is part of an odd field of an interlaced video 331 frame. The height specified in the JPEG 2000 main header is 332 half of the height of the entire displayed image. In a 333 receiver, an odd field should be de-interlaced with the even 334 field following it so that lines from each image are displayed 335 alternately. 337 2: The payload is part of an even field of an interlaced video 338 signal. 340 MHF (Main Header Flag) : 2 bits 342 MHF indicates whether a main header or packet of a main header is 343 in the RTP packet. 345 If there is no header, MHF has a value of 0. If there is just a 346 part of a fragmented header, MHF has a value of 1. If there is 347 the last part of a fragmented header, MHF has value of 2. If the 348 whole header in the packet, MHF has a value of 3. 350 +-----------+----------------------------------+ 351 | MHF Value | Description | 352 +-----------+----------------------------------+ 353 | 0 | no main header in the payload | 354 | | | 355 | 1 | piece of fragmented header | 356 | | | 357 | 2 | last part of a fragmented header | 358 | | | 359 | 3 | a whole main header | 360 +-----------+----------------------------------+ 362 Table 1: MHF Usage Values 364 mh_id (Main Header Identification) : 3 bits 366 Main header identification value. This is used for JPEG 2000 main 367 header recovery. 369 For implementations following only this specification, the sender 370 SHOULD set this value to 0 and the receiver SHOULD ignore this 371 field on processing. 373 T (Tile field invalidation flag) : 1 bit 375 The T bit indicates whether the tile number field is valid or 376 invalid. A sender MUST set the T bit to 1 when invalid and 0 when 377 valid. 379 There are two cases where the tile number field is invalid: 381 * When an RTP packet holds only the main header. A sender cannot 382 set any number in the tile number field as no JPEG 2000 tile- 383 part bitstream is included in the RTP packet. 385 * Multiple tile-parts are packed together in a single payload. 386 If there are multiple tiles packed into a single payload, there 387 is no meaning to assign a number to the tile number field. 389 priority : 8 bits 391 The priority field indicates the importance of the JPEG 2000 392 packet included in the payload. Typically, a higher priority is 393 set in the packets containing JPEG 2000 packets containing the 394 lower sub-bands. 396 For implementations following only this specification, the sender 397 SHOULD set this value to 255 and the receiver SHOULD ignore this 398 field on processing. 400 tile number : 16 bits 402 This field shows the tile number of the payload. This field is 403 only valid when the T bit is 0. If T bit is set to 1, the 404 receiver MUST ignore this field. 406 R (Reserved) : 8 bits 408 This bit is reserved for future use. Senders MUST set this to 0. 409 Receivers MUST ignore this field. 411 fragment offset : 24 bits 413 This value MUST be set to the byte offset of the current payload 414 in relation to the very beginning of each JPEG 2000 codestream 415 (JPEG 2000 frame). 417 Byte offsets are calculated from the start of each JPEG 2000 418 codestream up to the current position where the current payload 419 would fit into the complete JPEG 2000 codestream. 421 To perform scalable video delivery by using multiple RTP sessions, 422 the offset value from the first byte of the same frame is set for 423 fragment offset. It is then possible, to deliver layered video 424 using multiple RTP sessions, the fragment offset may not start 425 from 0 in some RTP sessions even if the packet is the first one 426 received. 428 5. RTP Packetization 430 The sender must packetize the JPEG 2000 appropriately according to 431 initial media type parameters and/or details from SDP offer/answer 432 parameters. 434 A "packetization unit" is defined as either a JPEG 2000 main header, 435 a tile-part header, or a JPEG 2000 packet. 437 First, a sender divides the JPEG 2000 codestream into packetization 438 units by parsing the codestream or by getting information from the 439 encoder, and packs the packetization units into RTP packets. A 440 sender can put an arbitrary number of packetization units into an RTP 441 packet, but it MUST preserve the codestream order. An example of 442 this kind of RTP packet format is shown in Figure 4: 444 +------+-------+---------------+---------------+ 445 |RTP |payload| packetization | packetization | 446 |header|header | unit | unit | 447 +------+-------+---------------+---------------+ 449 Figure 4: An example with multiple packetization units 451 If a packetization unit with headers (IP header, RTP header and 452 payload header) is larger than the MTU size, it MAY be fragmented. 453 To pack a fragmented packetization unit, the fragmented unit MUST NOT 454 be packed with the succeeding packetization unit within the same RTP 455 packet. An example of this kind of RTP packet format is shown in 456 Figure 5: 458 +------+-------+-------------------------------------------------+ 459 |RTP |payload| packetization unit fragment | 460 |header|header | | 461 +------+-------+-------------------------------------------------+ 462 +------+-------+-------------------------------------------------+ 463 |RTP |payload| packetization unit fragment | 464 |header|header | | 465 +------+-------+-------------------------------------------------+ 466 . 467 . 468 . 469 +------+-------+------------------------------------+ 470 |RTP |payload| end of packetization unit fragment | 471 |header|header | | 472 +------+-------+------------------------------------+ 473 Figure 5: An example with a fragmented packetization unit 475 6. Media Type Registration 477 This registration uses the template defined in [RFC4288] and follows 478 [RFC4855]. 480 Type name: video 482 Subtype name: jpeg2000 484 Required parameters: 486 rate: The RTP timestamp clock rate. The default rate is 90000, 487 but other rates MAY be specified. Rates below 1000 Hz SHOULD 488 NOT be used. 490 sampling: A list of values specifying the color space of the 491 payload data. 493 Acceptable values: 495 RGB: standard Red, Green, Blue color space. 497 BGR: standard Blue, Green, Red color space. 499 RGBA: standard Red, Green, Blue, Alpha color space. 501 BGRA: standard Blue, Green, Red, Alpha color space. 503 YCbCr-4:4:4: standard YCbCr color space, no subsampling. 505 YCbCr-4:2:2: standard YCbCr color space, Cb and Cr are 506 subsampled horizontally by 1/2. 508 YCbCr-4:2:0: standard YCbCr color space, Cb and Cr are 509 subsampled horizontally and vertically by 1/2. 511 YCbCr-4:1:1: standard YCbCr color space, Cb and Cr are 512 subsampled vertically by 1/4 514 GRAYSCALE: basically a single component image of just 515 multilevels of grey. 517 EXTENSION VALUE: Additional color samplings can be 518 registered with and current listing of registered color 519 samplings at: Color Sampling Registration Authority. 520 Please refer to RTP Format for Uncompressed Video. 521 [RFC4175] 523 Optional parameters: 525 interlace: interlace scanning. If payload is in interlace 526 format, the acceptable value is "1", otherwise, the value 527 should be "0". Each complete image forms vertically half the 528 display. tp value MUST properly specify the field the image 529 represents odd(tp=1), or even(tp=2). If this option is not 530 present, the payload MUST be in progressive format and tp MUST 531 be set to 0. 533 width: A parameter describing the maximum width of the video 534 stream. This parameter MUST appear when height is present. 535 Acceptable values: - an integer value between 0 - 536 4,294,967,295. 538 height: A parameter describing the maximum height of the video 539 stream. This parameter MUST appear when width is present. 540 Acceptable values: - an integer value between 0 - 541 4,294,967,295. 543 The receiver MUST ignore any unspecified parameters. 545 Encoding considerations: 547 This media type is framed and binary, see Section 4.8 in [RFC4288] 549 Security considerations: See Section 9 of this document. 551 Interoperability considerations: 553 JPEG 2000 video stream is a sequence of JPEG 2000 still images. 554 An implementation compliant with [JPEG2000Pt_1] can decode and 555 attempt to display the encoded JPEG 2000 video stream. 557 Published specification: ISO/IEC 15444-1 | ITU-T Rec. T.800 559 Applications which use this media type: 561 video streaming and communication 563 Person and email address to contact for further information: 565 Eisaburo Itakura, Satoshi Futemma, Andrew Leung 566 Email:{itakura|satosi-f}@ sm . sony . co . jp, andrew @ ualberta . 567 net 569 Intended usage: Restriction 570 Restrictions on Usage: 572 This media type depends on RTP framing, and hence is only 573 defined for the transfer via RTP [RFC3550]. Transport within 574 other framing protocols is not defined at the time. 576 Author/Change Controller: 578 Author: 580 Eisaburo Itakura, Satoshi Futemma 581 Email: {itakura|satosi-f} @ sm . sony .co . jp 583 Change controller: 585 IETF Audio/Video Transport Working Group delegated from the 586 IESG 588 7. SDP Parameters 590 7.1. SDP Mapping 592 The media type video/jpeg2000 string is mapped to fields in the 593 Session Description Protocol (SDP) [RFC4566] as follows: 595 o The media name in the "m=" line of SDP MUST be video. 597 o The encoding name in the "a=rtpmap" line of SDP MUST be jpeg2000 598 (the subtype). 600 o The clock rate in the "a=rtpmap" line is set according to the 601 "rate" parameter. Senders that wish to use a non-90kHz rate 602 SHOULD also offer the same stream using a 90kHz timestamp rate 603 with a different RTP payload type allowing graceful fallback to 604 90kHz for compatibility. 606 o The REQUIRED parameter, "sampling", MUST be included in the 607 "a=fmtp" line of SDP. 609 o The OPTIONAL parameters, if presented, MUST be included in the 610 "a=fmtp" line of SDP. 612 These parameters are expressed as a media type string, in the form of 613 a semicolon separated list of parameter=value pairs. 615 Therefore, an example of media representation in SDP using typical 616 parameters is as follows: 618 m=video 49170/2 RTP/AVP 98 619 a=rtpmap:98 jpeg2000/90000 620 a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128 622 An example for using non-90kHz timestamp is as follows: 624 m=video 49170/2 RTP/AVP 98 99 625 a=rtpmap:98 jpeg2000/27000000 626 a=rtpmap:99 jpeg2000/90000 627 a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128 628 a=fmtp:99 sampling=YCbCr-4:2:0;width=128;height=128 630 7.2. Usage with the SDP Offer/Answer Model 632 When offering JPEG 2000 over RTP using SDP in an Offer/Answer model 633 [RFC3264], the following rules and limitations apply: 635 o All parameters MUST have an acceptable value for the parameter. 637 o All parameters MUST correspond to the parameters of the payload. 639 o The parameter "sampling" with an acceptable answer MUST appear in 640 the offer and in the answer if accepted by the receiver. The 641 receiver SHOULD do its best to handle received codestream in the 642 color space offered. If the receiver cannot handle the offered 643 color space for whatever reason, it should reply with its 644 preferred color space in the answer and gracefully end the 645 session. Senders do not need conform to the color space in the 646 answer but should take note that the session ended due to color 647 sampling issues. 649 o For optional parameter: "interlace", if this option is used, it 650 MUST appear in the offer and if accepted it SHOULD appear in the 651 answer. Receivers should do their best to handle interlace or 652 progressive codestreams but if for some reason, receivers cannot 653 accommodate, receivers should reply with preferred settings in the 654 answer then gracefully end the session. Senders do not need to 655 adjust settings upon this answer but should take note that the 656 session ended due to interlace or progressive issues. 658 o For optional parameters "width" and "height" the following 659 applies: 661 * if "width" appears in the offer or answer, "height" MUST be 662 present. 664 * if "height" appears in the offer or answer, "width" MUST be 665 present. 667 o Width and height should appear in the offer as the maximum 668 dimensions the sender can offer. In the answer, it SHOULD 669 represent the maximum the receiver can accommodate. If there is a 670 difference between the offer and answer, the sender should re- 671 offer a new width and height and appropriately scale down the 672 codestream for the receiver. 674 o In a multicast environment, [RFC1112] receivers should do their 675 best to conform to parameters in the offer from the sender. 676 Senders should use recommended settings in multicast environments 677 and take note of answers. For width and height, the sender should 678 accommodate to the lowest values it receives from all answers. 680 o Any unknown options in the Offer should be ignored and deleted 681 from the Answer. 683 7.2.1. Examples 685 An example offer/answer exchanges are provided. 687 Alice offers YCbCr 4:2:2 color space, interlace image with 720-pixel 688 width and 480-pixel height as below: 690 v=0 691 o=alice 2890844526 2890844526 IN IP4 host.example 692 s= 693 c=IN IP4 host.example 694 t=0 0 695 m=video 49170 RTP/AVP 98 696 a=rtpmap:98 jpeg2000/90000 697 a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 699 Bob accepts YCbCr-4:2:2 color space, interlace image and replies: 701 v=0 702 o=bob 2890844730 2890844731 IN IP4 host.example 703 s= 704 c=IN IP4 host.example 705 t=0 0 706 m=video 49920 RTP/AVP 98 707 a=rtpmap:98 jpeg2000/90000 708 a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 710 7.2.2. Examples: non-90kHz timestamp 712 An example offer/answer exchanges, where an offerer wishes to use 713 non-90kHz timestamp, are provided. 715 Alice offers RTP payload type with 27MHz clock rate as well as with 716 90kHz clock rate and each payload type includes: YCbCr 4:2:2 color 717 space, interlace image, 720-pixel width and 480-pixel height. She 718 puts 27MHz clock rate attributes prior to 90kHz because she wants to 719 use 27 MHz rather than 90kHz. 721 v=0 722 o=alice 2890844526 2890844526 IN IP4 host.example 723 s= 724 c=IN IP4 host.example 725 t=0 0 726 m=video 49170 RTP/AVP 98 99 727 a=rtpmap:98 jpeg2000/27000000 728 a=rtpmap:99 jpeg2000/90000 729 a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 730 a=fmtp:99 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 732 If Bob can accept 27MHz clock rate, he replies as below: 734 v=0 735 o=bob 2890844730 2890844731 IN IP4 host.example 736 s= 737 c=IN IP4 host.example 738 t=0 0 739 m=video 49920 RTP/AVP 98 740 a=rtpmap:98 jpeg2000/27000000 741 a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 743 If Bob doesn't accept 27MHz clock rate, he replies as below: 745 v=0 746 o=bob 2890844730 2890844731 IN IP4 host.example 747 s= 748 c=IN IP4 host.example 749 t=0 0 750 m=video 49920 RTP/AVP 99 751 a=rtpmap:99 jpeg2000/90000 752 a=fmtp:99 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 754 8. IANA Consideration 756 It is requested that one new media subtype (video/jpeg2000) is 757 registered by IANA. For details, see of this document. 759 9. Security Consideration 761 RTP packets using the payload format defined in this specification 762 are subject to the security considerations discussed in the RTP 763 specification [RFC3550], and in any applicable RTP profile. The main 764 security considerations for the RTP packet carrying the RTP payload 765 format defined within this memo are confidentiality, integrity and 766 source authenticity. Confidentiality is achieved by encryption of 767 the RTP payload. Integrity of the RTP packets through the use of 768 suitable cryptographic integrity protection mechanism. Cryptographic 769 system may also allow the authentication of the source of the 770 payload. A suitable security mechanism for this RTP payload format 771 should provide confidentiality, integrity protection and at least a 772 source authentication method capable of determining if an RTP packet 773 is from a member of the RTP session or not. 775 Note that the appropriate mechanism to provide security to RTP and 776 payloads following this memo may vary. It is dependent on the 777 application, the transport, and the signalling protocol employed. 778 Therefore a single mechanism is not sufficient, although if suitable 779 the usage of SRTP [RFC3711] is recommended. Other mechanism that may 780 be used are IPsec [RFC4301] and TLS [RFC4346] (RTP over TCP), but 781 also other alternatives may exist. 783 10. Congestion Control 785 If QoS enhanced service is used, RTP receivers SHOULD monitor packet 786 loss to ensure that the service that was requested is actually being 787 delivered. If it is not, then they SHOULD assume that they are 788 receiving best-effort service and behave accordingly. 790 If best-effort service is being used, users of this payload format 791 MUST monitor packet loss to ensure that the packet loss rate is 792 within acceptable parameters. Packet loss is considered acceptable 793 if a TCP flow across the same network path, experiencing the same 794 network conditions, would achieve an average throughput, measured on 795 a reasonable timescale, that is not less than the RTP flow is 796 achieving. This condition can be satisfied by implementing 797 congestion control mechanisms to adapt the transmission rate (or the 798 number of layers subscribed for a layered multicast session), or by 799 arranging for a receiver to leave the session if the loss rate is 800 unacceptably high. 802 11. References 804 11.1. Normative References 806 [JPEG2000Pt_1] 807 ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, 808 "Information Technology - JPEG 2000 Image Coding System - 809 Part 1: Core Coding System", December 2000. 811 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 812 Requirement Levels", RFC 2119, March 1997. 814 [RFC3550] Schulzrinne, Casner, Frederick, and Jacobson, "RTP: A 815 Transport Protocol for Real Time Applications", RFC 3550, 816 STD 64, July 2003. 818 [RFC3711] Baugher, McGrew, Naslund, Carrara, and Norrman, "The 819 Secure Real-time Transport Protocol (SRTP", RFC 3711, 820 March 2004. 822 [RFC4288] Freed and Klensin, "Media Type Specifications and 823 Registration Procedures", RFC 4288, December 2005. 825 [RFC4855] Casner, "Media Type Registration of RTP Payload Formats", 826 RFC 4855, February 2007. 828 [RFC4566] Handley and Jacobson, "SDP: Session Description Protocol", 829 RFC 4566, July 2006. 831 [RFC3264] Rosenberg and Schulzrinne, "An Offer/Answer Model with 832 Session Description Protocol (SDP)", RFC 3264, June 2002. 834 11.2. Informative References 836 [JPEG2000Pt_3] 837 ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, 838 "Information Technology - JPEG 2000 Image Coding System - 839 Part 3: Motion JPEG 2000", July 2002. 841 [JP2RTPEX] 842 Leung, Futemma, and Itakura, "RTP Payload format for JPEG 843 2000: Extensions for Scalability and Main Header 844 Recovery", RFC XXXX, April 2007. 846 [RFC4301] Kent and Seo, "Security Architecture for the Internet 847 Protocol", RFC 4301, December 2005. 849 [RFC4346] Dierks and Rescorla, "The Transport Layer Security (TLS) 850 Protocol Version 1.1", RFC 4346, April 2006. 852 [RFC4175] Perkins and Gharai, "RTP Payload Format for Uncompressed 853 Video", RFC 4175, September 2005. 855 [RFC1112] Deering, "Host Extensions for IP Multicasting", RFC 1112, 856 August 1989. 858 Appendix A. Informative Appendix 860 A.1. Recommended Practices 862 As the JPEG 2000 coding standard is highly flexible, many different 863 but compliant data streams may be produced and be a compliant JPEG 864 2000 codestream. 866 The following is a set of recommendations set forth from our 867 experience in developing JPEG 2000 and this payload specification. 868 Implementations of this standard must handle all possibilities 869 mentioned in this specification. The following is a listing of items 870 an implementation may optimize. 872 Error Resilience Markers: The use of error resilience markers in the 873 JPEG 2000 data stream is highly recommended in all situations. 874 Error recovery with these markers is helpful to the decoder and 875 save external resources. Markers such as: RESET, RESTART, and 876 ERTERM. 878 YCbCr Color space: The YCbCr color space provides the greatest 879 amount of compression in color with respect to the human visual 880 system. When used with JPEG 2000, the usage of this color space 881 can provide excellent visual results at extreme bit rates. 883 Progression Ordering: JPEG 2000 offers many different ways to order 884 the final code stream to optimize the transfer with the 885 presentation. We have found the most useful codestream ordering 886 have been for layer progression and resolution progression 887 ordering. 889 Tiling and Packets: JPEG 2000 packets are formed regardless of the 890 encoding method. The encoder has little control over the size of 891 these JPEG 2000 packets as they maybe large or small. 892 Tiling splits the image up into smaller areas and each are encoded 893 separately. With tiles, the JPEG 2000 packet sizes are also 894 reduced. When using tiling, almost all JPEG 2000 packet sizes are 895 an acceptable size (i.e. smaller than the MTU size of most 896 networks.) 898 Sender Processing: There are no limitations as to how the sender 899 should pack the payload. In general, the sender should pack 900 headers separately from the rest of the codestream to make header 901 recovery simple. Payloads should generally begin with an SOP 902 marker and end with EPH marker for easier decoder processing. 904 A.2. Sample Headers in Detail 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 |tp |MHF|mh_id|T| priority | tile number | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 |reserved | fragment offset | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Figure 6 916 First Packet: This packet will have the whole main header. 210 bytes 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 |0 0|1 1|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 |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| 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 |FF4FFF51002F000 .... | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Figure 7 930 Second Packet: This packet will have a tile header and the first tile 931 part LLband 1500 bytes 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 |0 0|1 1|0 0 0|0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 |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| 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 |FF90 000A 0000 0000 2DB3 0001 FF93 | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 Figure 8 945 Third Packet: This packet will have the next part in the tile, no 946 tile header 1500 bytes 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 |0 0|0 0|0 0 0|0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 |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| 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 |E841 4526 4556 9850 C2EA .... | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 Figure 9 960 Fourth Packet: Last packet for the image 290 bytes 962 0 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 |0 0|0 0|0 0 0|0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 |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| 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 |A55D 8B73 3B25 25C7 B9EB .... 2FBEB153| 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Figure 10 974 First Packet: This packet will have the whole main header. 210 bytes 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 |0 0|1 1|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 |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| 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 |FF4FFF51002F000 .... | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 Figure 11 988 Second Packet: This packet will have a first tile part (tile 0) 1400 989 bytes 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 |0 0|0 0|0 0 0|0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 |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| 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 |FF90 000A 0000 0000 0578 0001 FF93 .... | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 Figure 12 1003 Third Packet: This packet will have a second tile part (tile 1) 1423 1004 bytes 1006 0 1 2 3 1007 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 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 |0 0|0 0|0 0 0|0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 |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| 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 |FF90 000A 0001 0000 058F 0001 FF93 .... | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 Figure 13 1018 Fourth Packet: This packet will have a third tile part (tile 2) 1355 1019 bytes 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 |0 0|0 0|0 0 0|0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 |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| 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 |FF90 000A 0002 0000 054B 0001 FF93 .... | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 Figure 14 1033 Fifth Packet: This packet will have a fourth tile part (tile 3) 1290 1034 bytes 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 |0 0|0 0|0 0 0|0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1| 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 |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| 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 |FF90 000A 0003 0000 050A 0001 FF93 .... | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 Figure 15 1048 First Packet: This packet will have the first part of the main 1049 header. 110 bytes 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 |0 0|0 1|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 |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| 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 |FF4FFF51002F000 .... | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 Figure 16 1063 Second Packet: This packet has the second part of the header. 1400 1064 bytes 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 |0 0|1 0|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 |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| 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 |FF6400FF .... | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Figure 17 1078 Third Packet: This packet has two tiles, tile 0 and tile 1 1400 bytes 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 |0 0|0 0|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 |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| 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 |FF90 000A 0000 0000 02BC 0001 FF93 ... | 1088 |FF90 000A 0001 0000 02BC 0001 FF93 ... | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 Figure 18 1093 Fourth Packet: This packet has one tile, tile 2 1395 bytes 1095 0 1 2 3 1096 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 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 |0 0|0 0|0 0 0|0|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 |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| 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 |FF90 000A 0002 0000 0573 0001 FF93 .... | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 Figure 19 1107 First packet: This packet will have the whole main header for the odd 1108 field 210 bytes 1110 0 1 2 3 1111 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 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 |0 1|1 1|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 |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| 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 |FF4FFF51002F000 .... | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Figure 20 1122 Second packet: This packet will have the first part of the odd 1123 field's tile 1400 bytes 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 |0 1|0 0|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 |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| 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 |FF90 000A 0000 0000 0578 0001 FF93 .... | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 Figure 21 1137 Third packet: This packet will have the second part of the odd 1138 field's tile 1400 bytes 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 |0 1|0 0|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 |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| 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 |7F04 E708 27D9 D11D 22CB ... | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 Figure 22 1152 Fourth packet: This packet will have the third part of the odd 1153 field's tile 1300 bytes 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 |0 1|0 0|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 |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| 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 |98BD EC9B 2826 DC62 D4AB ... | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 Figure 23 1167 Fifth packet: This packet will have the whole main header for the 1168 even field 1170 0 1 2 3 1171 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 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 |1 0|1 1|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 |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| 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 |FF4FFF51002F000 .... | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 Figure 24 1182 Sixth packet: This packet will have the first part of the odd field's 1183 tile 1400 bytes 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 |1 0|0 0|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 |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| 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 |FF90 000A 0000 0000 0578 0001 FF93 .... | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Figure 25 1197 Seventh packet: This packet will have the second part of the odd 1198 field's tile 1400 bytes 1200 0 1 2 3 1201 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 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 |1 0|0 0|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 |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| 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 |626C 42F0 166B 6BD0 F8E1 ... | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 Figure 26 1212 Eighth packet: This packet will have the third part of the odd 1213 field's tile 1300 bytes 1215 0 1 2 3 1216 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 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 |1 0|0 0|0 0 0|1|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 |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| 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 |8114 41D5 18AB 4A1B ... | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Figure 27 1227 Authors' Addresses 1229 Satoshi Futemma 1230 Sony Corporation 1231 1-7-1 Konan 1232 Minato-ku 1233 Tokyo 108-0075 1235 Phone: +81 3 6748-2111 1236 Email: satosi-f @ sm . sony . co . jp 1237 URI: http://www.sony.net/ 1239 Andrew Leung 1240 Sony Corporation 1241 1-7-1 Konan 1242 Minato-ku 1243 Tokyo 108-0075 1244 Japan 1246 Phone: +81 3 6748-2111 1247 Email: andrew @ ualberta . net 1248 URI: http://www.sony.net/ 1250 Eisaburo Itakura 1251 Sony Corporation 1252 1-7-1 Konan 1253 Minato-ku 1254 Tokyo 108-0075 1255 Japan 1257 Phone: +81 3 6748-2111 1258 Email: itakura @ sm . sony . co . jp 1259 URI: http://www.sony.net/ 1261 Full Copyright Statement 1263 Copyright (C) The IETF Trust (2008). 1265 This document is subject to the rights, licenses and restrictions 1266 contained in BCP 78, and except as set forth therein, the authors 1267 retain all their rights. 1269 This document and the information contained herein are provided on an 1270 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1271 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1272 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1273 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1274 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1277 Intellectual Property 1279 The IETF takes no position regarding the validity or scope of any 1280 Intellectual Property Rights or other rights that might be claimed to 1281 pertain to the implementation or use of the technology described in 1282 this document or the extent to which any license under such rights 1283 might or might not be available; nor does it represent that it has 1284 made any independent effort to identify any such rights. Information 1285 on the procedures with respect to rights in RFC documents can be 1286 found in BCP 78 and BCP 79. 1288 Copies of IPR disclosures made to the IETF Secretariat and any 1289 assurances of licenses to be made available, or the result of an 1290 attempt made to obtain a general license or permission for the use of 1291 such proprietary rights by implementers or users of this 1292 specification can be obtained from the IETF on-line IPR repository at 1293 http://www.ietf.org/ipr. 1295 The IETF invites any interested party to bring to its attention any 1296 copyrights, patents or patent applications, or other proprietary 1297 rights that may cover technology that may be required to implement 1298 this standard. Please address the information to the IETF at 1299 ietf-ipr@ietf.org.