From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5371.txt | 1739 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1739 insertions(+) create mode 100644 doc/rfc/rfc5371.txt (limited to 'doc/rfc/rfc5371.txt') diff --git a/doc/rfc/rfc5371.txt b/doc/rfc/rfc5371.txt new file mode 100644 index 0000000..ba191b2 --- /dev/null +++ b/doc/rfc/rfc5371.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group S. Futemma +Request for Comments: 5371 E. Itakura +Category: Standards Track A. Leung + Sony + October 2008 + + + RTP Payload Format for JPEG 2000 Video Streams + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo describes an RTP payload format for the ISO/IEC + International Standard 15444-1 | ITU-T Rec. T.800, better known as + JPEG 2000. JPEG 2000 features are considered in the design of this + payload format. JPEG 2000 is a truly scalable compression technology + allowing applications to encode once and decode many different ways. + The JPEG 2000 video stream is formed by extending from a single image + to a series of JPEG 2000 images. + + + + + + + + + + + + + + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 1] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Conventions Used in This Document . . . . . . . . . . . . 6 + 2. JPEG 2000 Video Features . . . . . . . . . . . . . . . . . . . 6 + 3. Payload Design . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. RTP Fixed Header Usage . . . . . . . . . . . . . . . . . . 7 + 4.2. RTP Payload Header Format . . . . . . . . . . . . . . . . 8 + 5. RTP Packetization . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Media Type Registration . . . . . . . . . . . . . . . . . . . 11 + 7. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.1. SDP Mapping . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 15 + 7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 16 + 7.2.2. Examples: Non-90kHz Timestamp . . . . . . . . . . . . 16 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 10. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 18 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 + Appendix A. Informative Appendix . . . . . . . . . . . . . . . . 21 + A.1. Recommended Practices . . . . . . . . . . . . . . . . . . 21 + A.2. Sample Headers in Detail . . . . . . . . . . . . . . . . . 22 + A.2.1. Sample 1: Progressive Image with Single Tile, 3500 + Bytes (i.e., thumbnail) . . . . . . . . . . . . . . . 22 + A.2.2. Sample 2: Image with 4 Tiles . . . . . . . . . . . . . 24 + A.2.3. Sample 3: Packing Multiple Tiles in Single + Payload, Fragmented Header . . . . . . . . . . . . . . 25 + A.2.4. Sample 4: Interlace Image, Single Tile . . . . . . . . 27 + + + + + + + + + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 2] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +1. Introduction + + This document specifies a payload format for JPEG 2000 video streams + over the Real-time Transport Protocol (RTP). JPEG 2000 is an ISO/IEC + International Standard and ITU-T Recommendation (ISO/IEC + International Standard 15444-1 | ITU-T Rec. T.800) developed for + next-generation, still-image compression. JPEG stands for the Joint + Photographers Experts Group, an international group made of academia + and industry to develop image compression standards. JPEG 2000 basic + compression technology is defined in detail in ISO JPEG 2000 Part 1: + Core Coding System [JPEG2000Pt_1], with motion defined in ISO JPEG + 2000 Part 3: Motion JPEG 2000 [JPEG2000Pt_3]. + + Part 3 of the JPEG 2000 standard defines Motion JPEG 2000 + [JPEG2000Pt_3]. However, Motion JPEG 2000 defines a file format, not + a transmission format for the network. This document specifies a + transmission format for the network for a series of JPEG 2000 images. + + JPEG 2000 supports many powerful features [JPEG2000Pt_1] + [JPEG2000Pt_3] that are not supported in the current JPEG standard, + such as: + + o Higher compression efficiency than JPEG with less visual + distortion especially at extreme compression ratios. + + o A single codestream that offers both lossy and lossless + compression. + + o Better error resiliency than JPEG. + + o Progressive transmission by pixel accuracy (Signal-to-Noise Ratio + (SNR) scalability) and resolution (resolution scalability). + + o Random codestream access and processing. + + + + + + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 3] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + The JPEG 2000 algorithm is briefly explained. Figure 1 shows a block + diagram of the JPEG 2000 encoding method. + + +-----+ + | ROI | + +-----+ + | + V + +----------+ +----------+ +------------+ + |DC, comp. | | Wavelet | | | + Raw Image ==> |transform-|==>|transform-|==>|Quantization|==+ + | ation | | ation | | | | + +----------+ +----------+ +------------+ | + | + +-----------+ +----------+ +------------+ | + | | | | | | | + JPEG 2000 <==| Data |<==| Rate |<==| EBCOT |<=+ + codestream | Ordering | | Control | | | + +-----------+ +----------+ +------------+ + + Figure 1: Block diagram of the JPEG 2000 encoder + + The image is first transformed into wavelet coefficients. The image + is sampled into various levels, vertically and horizontally, from + high frequencies (which contain sharp details) to low frequencies + (which contain smooth areas). Quantization is performed on the + coefficients within each sub-band. + + After quantization, code blocks are formed from within the precincts + within the tiles. (Precincts are a finer separation than tiles, and + code blocks are the smallest separation of the image data.) EBCOT + coding (Embedded Block Coding Optimized for Truncation) is performed + within each code block and arithmetically encoded by bit plane. Rate + control is performed to achieve the highest quality image for a + specified rate. + + As a result, for a given tile, data units called JPEG 2000 packets + are generated, which contain data from a specific layer, specific + component, specific resolution, or specific precinct, depending on + the data ordering. + + Finally, the JPEG 2000 packets are interleaved according to the + progression along four axes: layer, resolution, component, and + precinct. A JPEG 2000 header is added to become a fully compliant + JPEG 2000 codestream. + + + + + + +Futemma, et al. Standards Track [Page 4] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + To decompress a JPEG 2000 codestream, one would follow the reverse + order of the encoding order, without the rate control. + + It is outside the scope of this document to further describe in + detail this procedure. Please refer to various JPEG 2000 related + texts for further details [JPEG2000Pt_1]. + + Figure 2 shows a JPEG 2000 codestream in detail. A JPEG 2000 + codestream is structured from the main header, beginning with the SOC + (Start Of Codestream) marker, one or more tiles, and the EOC (End Of + Codestream) marker to indicate the end of the codestream. Each tile + consists of a tile-part header that starts with the SOT (Start of + Tile) marker and ends with a SOD (Start of Data) marker, and + bitstream (a series of JPEG 2000 packets). + + +-- +------------+ + Main | | SOC | Required as the first marker + header| +------------+ + | | main | Main header marker segments + +-- +------------+ + | | SOT | Required at the beginning of each + Tile- | +------------+ tile-part header + part | | T0,TP0 | Tile 0, tile-part 0 header marker + header| +------------+ segments + | | SOD | Required at the end of each tile-part + +-- +------------+ header + | bitstream | Tile-part bitstream + +-- +------------+ + | | SOT | + Tile- | +------------+ + part | | T1,TP0 | + header| +------------+ + | | SOD | + +-- +------------+ + | bit stream | + +------------+ + . + . + . + +------------+ + | EOC | Required as the last marker in the + +------------+ codestream + + Figure 2: Basic construction of the JPEG 2000 codestream + + + + + + + +Futemma, et al. Standards Track [Page 5] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. JPEG 2000 Video Features + + JPEG 2000 video streams are formed as a continuous series of JPEG + 2000 still images. Previously described features of JPEG 2000 may be + used effectively in streaming applications for a JPEG 2000 video. A + JPEG 2000 video stream has the following qualities: + + o At low bit rates, the SNR is improved dramatically over JPEG and + Motion JPEG. + + o This is a full intra-frame format -- each frame is independently + compressed -- and therefore has a low encoding and decoding delay. + + o JPEG 2000 has flexible and accurate rate control. + + o This is suitable for traffic control and congestion control during + network transmission. + + o JPEG 2000 can provide its own codestream error resilience markers + to aid in codestream recovery outside of this specification. + +3. Payload Design + + To design a payload format that maximizes JPEG 2000 features, the + following are taken into consideration: + + o Provisions for packet loss: + + On the Internet, 5% packet loss is common and this percentage may + vary up to 20% or more. To split JPEG 2000 video streams into RTP + packets, efficient packetization of the codestream is required to + minimize problems in decoding due to missing packets. If the main + header is lost, the image cannot be decoded. + + o JPEG 2000 Scalability + + JPEG 2000 has powerful scalability features and markers in the + payload header to indicate the specific meaning of the payload, + such as: + + * Special markers for the headers, fragments of headers, etc. + + + + +Futemma, et al. Standards Track [Page 6] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + * Tile numbering for association of packets. + + * Since this is primarily for video applications, special markers + are used to indicate format (i.e., interlace odd/even fields). + + * Priority importance of the packet using methods described in + RFC 5372 [RFC5372]. + + * Main header recovery using methods described in RFC 5372 + [RFC5372]. + + Additional usage of the payload header is described in RFC 5372 + [RFC5372]. + +4. Payload Format + +4.1. RTP Fixed Header Usage + + For each RTP packet, the RTP fixed header is followed by the JPEG + 2000 RTP payload header, which is followed by the payload, a piece of + a JPEG 2000 codestream, which is usually a JPEG 2000 packet. + + The RTP header fields that have a meaning specific to a JPEG 2000 + video stream are described as follows: + + Marker bit (M): The marker bit of the RTP fixed header MUST be set + to 1 for the last RTP packet of a video frame; otherwise, it MUST + be 0. When transmission is performed by multiple RTP sessions, + this bit is 1 in the last packet of the frame in each session. + + Payload type (PT): The payload type is dynamically assigned by means + outside the scope of this document. A payload type in the dynamic + range shall be chosen by means of an out-of-band signaling + protocol (i.e., Real Time Streaming Protocol (RTSP), SIP, etc.). + + Timestamp: Timestamp indicates the presentation time of the frame + contained in the RTP packet. The same timestamp value MUST appear + in each RTP packet carrying a fragment of a given frame. When a + JPEG 2000 image is in interlace format, the odd field and the + corresponding even field MUST have the same timestamp value. + Following the RTP specification [RFC3550], the initial value of + the timestamp should be randomly chosen. + + As for the clock rate, senders and receivers MUST support the + 90kHz RTP timestamp rate, and MAY support other rates. RTP + timestamp rates below 1000 Hz SHOULD NOT be used because they will + result in insufficient resolution for RTP Control Protocol (RTCP) + measurements based on the RTP timestamp, such as the interarrival + + + +Futemma, et al. Standards Track [Page 7] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + jitter. The clock rate MUST be negotiated at the start of the + session. When using the Session Description Protocol (SDP), it + MUST be expressed using the "rtpmap" attributes. If a non-90kHz + clock rate is to be used, it is RECOMMENDED to present not only a + preferable clock rate but also 90kHz clock rate with a different + RTP payload type. + +4.2. RTP Payload Header Format + + The RTP payload header format for JPEG 2000 video stream is as + follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |tp |MHF|mh_id|T| priority | tile number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |reserved | fragment offset | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: RTP payload header format for JPEG 2000 + + tp (type): 2 bits + + This field indicates how a JPEG 2000 image is scanned (progressive + or interlace). + + 0: The payload is progressively scanned. + + 1: The payload is part of an odd field of an interlaced video + frame. The height specified in the JPEG 2000 main header is + half of the height of the entire displayed image. In a + receiver, an odd field should be de-interlaced with the even + field following it so that lines from each image are displayed + alternately. + + 2: The payload is part of an even field of an interlaced video + signal. + + MHF (Main Header Flag): 2 bits + + MHF indicates whether a main header or packet of a main header is + in the RTP packet. + + + + + + + + +Futemma, et al. Standards Track [Page 8] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + If there is no header, MHF has a value of 0. If there is just a + part of a fragmented header, MHF has a value of 1. If there is + the last part of a fragmented header, MHF has value of 2. If the + whole header is in the packet, MHF has a value of 3. + + +-----------+----------------------------------+ + | MHF Value | Description | + +-----------+----------------------------------+ + | 0 | no main header in the payload | + | 1 | piece of fragmented header | + | 2 | last part of a fragmented header | + | 3 | a whole main header | + +-----------+----------------------------------+ + + Table 1: MHF Usage Values + + mh_id (Main Header Identification): 3 bits + + Main header identification value. This is used for JPEG 2000 main + header recovery. + + For implementations following only this specification, the sender + SHOULD set this value to 0 and the receiver SHOULD ignore this + field on processing. + + T (Tile field invalidation flag): 1 bit + + The T bit indicates whether the tile number field is valid or + invalid. A sender MUST set the T bit to 1 when invalid and 0 when + valid. + + There are two cases where the tile number field is invalid: + + * When an RTP packet holds only the main header. A sender cannot + set any number in the tile number field, as no JPEG 2000 tile- + part bitstream is included in the RTP packet. + + * Multiple tile-parts are packed together in a single payload. + If there are multiple tiles packed into a single payload, there + is no meaning to assign a number to the tile number field. + + priority: 8 bits + + The priority field indicates the importance of the JPEG 2000 + packet included in the payload. Typically, a higher priority + value is set in the packets containing JPEG 2000 packets that + contain the lower sub-bands. + + + + +Futemma, et al. Standards Track [Page 9] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + For implementations following only this specification, the sender + SHOULD set this value to 255 and the receiver SHOULD ignore this + field on processing. + + tile number: 16 bits + + This field shows the tile number of the payload. This field is + only valid when the T bit is 0. If the T bit is set to 1, the + receiver MUST ignore this field. + + R (Reserved): 8 bits + + This bit is reserved for future use. Senders MUST set this to 0. + Receivers MUST ignore this field. + + fragment offset: 24 bits + + This value MUST be set to the byte offset of the current payload + in relation to the very beginning of each JPEG 2000 codestream + (JPEG 2000 frame). + + Byte offsets are calculated from the start of each JPEG 2000 + codestream up to the current position where the current payload + would fit into the complete JPEG 2000 codestream. + + To perform scalable video delivery by using multiple RTP sessions, + the offset value from the first byte of the same frame is set for + fragment offset. It is then possible to deliver layered video + using multiple RTP sessions; the fragment offset might not start + from 0 in some RTP sessions even if the packet is the first one + received in the RTP session. + +5. RTP Packetization + + The sender must packetize the JPEG 2000 appropriately according to + initial media type parameters and/or details from SDP offer/answer + parameters. + + A "packetization unit" is defined as either a JPEG 2000 main header, + a tile-part header, or a JPEG 2000 packet. + + + + + + + + + + + +Futemma, et al. Standards Track [Page 10] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + First, a sender divides the JPEG 2000 codestream into packetization + units by parsing the codestream or by getting information from the + encoder, and packs the packetization units into RTP packets. A + sender can put an arbitrary number of packetization units into an RTP + packet, but it MUST preserve the codestream order. An example of + this kind of RTP packet format is shown in Figure 4: + + +------+-------+---------------+---------------+ + |RTP |payload| packetization | packetization | + |header|header | unit | unit | + +------+-------+---------------+---------------+ + + Figure 4: An example with multiple packetization units + + If a packetization unit with headers (IP header, RTP header, and + payload header) is larger than the MTU size, it MAY be fragmented. + To pack a fragmented packetization unit, the fragmented unit MUST NOT + be packed with the succeeding packetization unit within the same RTP + packet. An example of this kind of RTP packet format is shown in + Figure 5: + + +------+-------+-------------------------------------------------+ + |RTP |payload| packetization unit fragment | + |header|header | | + +------+-------+-------------------------------------------------+ + +------+-------+-------------------------------------------------+ + |RTP |payload| packetization unit fragment | + |header|header | | + +------+-------+-------------------------------------------------+ + . + . + . + +------+-------+------------------------------------+ + |RTP |payload| end of packetization unit fragment | + |header|header | | + +------+-------+------------------------------------+ + + Figure 5: An example with a fragmented packetization unit + +6. Media Type Registration + + This registration uses the template defined in [RFC4288] and follows + [RFC4855]. + + Type name: video + + + + + + +Futemma, et al. Standards Track [Page 11] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + Subtype name: jpeg2000 + + Required parameters: + + rate: The RTP timestamp clock rate. The default rate is 90000, + but other rates MAY be specified. Rates below 1000 Hz SHOULD + NOT be used. + + sampling: A list of values specifying the color space of the + payload data. + + Acceptable values: + + RGB: standard Red, Green, Blue color space. + + BGR: standard Blue, Green, Red color space. + + RGBA: standard Red, Green, Blue, Alpha color space. + + BGRA: standard Blue, Green, Red, Alpha color space. + + YCbCr-4:4:4: standard YCbCr color space; no subsampling. + + YCbCr-4:2:2: standard YCbCr color space; Cb and Cr are + subsampled horizontally by 1/2. + + YCbCr-4:2:0: standard YCbCr color space; Cb and Cr are + subsampled horizontally and vertically by 1/2. + + YCbCr-4:1:1: standard YCbCr color space; Cb and Cr are + subsampled vertically by 1/4. + + GRAYSCALE: basically, a single component image of just + multilevels of grey. + + EXTENSION VALUE: Additional color samplings can be + registered with the current listing of registered color + samplings at: Color Sampling Registration Authority. + Please refer to RTP Format for Uncompressed Video + [RFC4175]. + + Optional parameters: + + interlace: Interlace scanning. If the payload is in interlace + format, the acceptable value is "1"; otherwise, the value + should be "0". Each complete image forms, vertically, half the + display. The tp value MUST properly specify the field the + image represents: odd(tp=1) or even(tp=2). If this option is + + + +Futemma, et al. Standards Track [Page 12] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + not present, the payload MUST be in progressive format and the + tp MUST be set to 0. + + width: A parameter describing the maximum width of the video + stream. This parameter MUST appear when height is present. + Acceptable values: -- an integer value between 0 -- + 4,294,967,295. + + height: A parameter describing the maximum height of the video + stream. This parameter MUST appear when width is present. + Acceptable values: -- an integer value between 0 -- + 4,294,967,295. + + The receiver MUST ignore any unspecified parameters. + + Encoding considerations: + + This media type is framed and binary, see Section 4.8 of + [RFC4288]. + + Security considerations: See Section 9 of this document. + + Interoperability considerations: + + The JPEG 2000 video stream is a sequence of JPEG 2000 still + images. An implementation compliant with [JPEG2000Pt_1] can + decode and attempt to display the encoded JPEG 2000 video stream. + + Published specification: ISO/IEC 15444-1 | ITU-T Rec. T.800 + + Applications that use this media type: + + video streaming and communication + + Person and email address to contact for further information: + + Eisaburo Itakura, Satoshi Futemma, Andrew Leung + Email: itakura@sm.sony.co.jp, satosi-f@sm.sony.co.jp, + andrew@ualberta.net + + Intended usage: COMMON + + Restrictions on Usage: + + This media type depends on RTP framing, and hence is only defined + for the transfer via RTP [RFC3550]. Transport within other + framing protocols is not defined at the time. + + + + +Futemma, et al. Standards Track [Page 13] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + Author/Change Controller: + + Author: + + Eisaburo Itakura, Satoshi Futemma, Andrew Leung + Email: itakura@sm.sony.co.jp, satosi-f@sm.sony.co.jp, + andrew@ualberta.net + + Change controller: + + IETF Audio/Video Transport Working Group delegated from the + IESG. + +7. SDP Parameters + +7.1. SDP Mapping + + The media type video/jpeg2000 string is mapped to fields in the + Session Description Protocol (SDP) [RFC4566] as follows: + + o The media name in the "m=" line of SDP MUST be video. + + o The encoding name in the "a=rtpmap" line of SDP MUST be jpeg2000 + (the subtype). + + o The clock rate in the "a=rtpmap" line is set according to the + "rate" parameter. Senders that wish to use a non-90kHz rate + SHOULD also offer the same stream using a 90kHz timestamp rate + with a different RTP payload type, allowing graceful fallback to + 90kHz for compatibility. + + o The REQUIRED parameter, "sampling", MUST be included in the + "a=fmtp" line of SDP. + + o The OPTIONAL parameters, if presented, MUST be included in the + "a=fmtp" line of SDP. + + These parameters are expressed as a media type string, in the form of + a semicolon separated list of parameter=value pairs. + + Therefore, an example of media representation in SDP using typical + parameters is as follows: + + m=video 49170/2 RTP/AVP 98 + a=rtpmap:98 jpeg2000/90000 + a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128 + + + + + +Futemma, et al. Standards Track [Page 14] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + An example for using non-90kHz timestamp is as follows: + + m=video 49170/2 RTP/AVP 98 99 + a=rtpmap:98 jpeg2000/27000000 + a=rtpmap:99 jpeg2000/90000 + a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128 + a=fmtp:99 sampling=YCbCr-4:2:0;width=128;height=128 + +7.2. Usage with the SDP Offer/Answer Model + + When offering JPEG 2000 over RTP using SDP in an Offer/Answer model + [RFC3264], the following rules and limitations apply: + + o All parameters MUST have an acceptable value for the parameter. + + o All parameters MUST correspond to the parameters of the payload. + + o The parameter "sampling" with an acceptable answer MUST appear in + the offer and in the answer if accepted by the receiver. The + receiver SHOULD do its best to handle the received codestream in + the color space offered. If the receiver cannot handle the + offered color space for whatever reason, it should reply with its + preferred color space in the answer and gracefully end the + session. Senders do not need to conform to the color space in the + answer, but they should take note that the session ended due to + color sampling issues. + + o For optional parameter "interlace", if this option is used, it + MUST appear in the offer and, if accepted, it SHOULD appear in the + answer. Receivers should do their best to handle interlace or + progressive codestreams but, if for some reason, receivers cannot + accommodate, receivers should reply with preferred settings in the + answer, then gracefully end the session. Senders do not need to + adjust settings upon this answer, but they should take note that + the session ended due to interlace or progressive issues. + + o For optional parameters "width" and "height", the following + applies: + + * if "width" appears in the offer or answer, "height" MUST be + present. + + * if "height" appears in the offer or answer, "width" MUST be + present. + + o Width and height should appear in the offer as the maximum + dimensions the sender can offer. In the answer, it SHOULD + represent the maximum the receiver can accommodate. If there is a + + + +Futemma, et al. Standards Track [Page 15] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + difference between the offer and answer, the sender should re- + offer a new width and height and appropriately scale down the + codestream for the receiver. + + o In a multicast environment, [RFC1112] receivers should do their + best to conform to parameters in the offer from the sender. + Senders should use recommended settings in multicast environments + and take note of answers. For width and height, the sender should + accommodate to the lowest values it receives from all answers. + + o Any unknown options in the offer should be ignored and deleted + from the answer. + +7.2.1. Examples + + Example offer/answer exchanges are provided. + + Alice offers YCbCr 4:2:2 color space, interlace image with 720-pixel + width and 480-pixel height as below: + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.example + s= + c=IN IP4 host.example + t=0 0 + m=video 49170 RTP/AVP 98 + a=rtpmap:98 jpeg2000/90000 + a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 + + Bob accepts YCbCr-4:2:2 color space, interlace image and replies: + + v=0 + o=bob 2890844730 2890844731 IN IP4 host.example + s= + c=IN IP4 host.example + t=0 0 + m=video 49920 RTP/AVP 98 + a=rtpmap:98 jpeg2000/90000 + a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 + +7.2.2. Examples: Non-90kHz Timestamp + + Example offer/answer exchanges, where an offerer wishes to use non- + 90kHz timestamp, are provided. + + Alice offers an RTP payload type with 27MHz clock rate as well as + with 90kHz clock rate, and each payload type includes: YCbCr 4:2:2 + color space, interlace image, 720-pixel width and 480-pixel height. + + + +Futemma, et al. Standards Track [Page 16] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + She puts 27MHz clock rate attributes prior to 90kHz because she wants + to use 27 MHz rather than 90kHz. + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.example + s= + c=IN IP4 host.example + t=0 0 + m=video 49170 RTP/AVP 98 99 + a=rtpmap:98 jpeg2000/27000000 + a=rtpmap:99 jpeg2000/90000 + a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 + a=fmtp:99 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 + + If Bob can accept 27MHz clock rate, he replies as below: + + v=0 + o=bob 2890844730 2890844731 IN IP4 host.example + s= + c=IN IP4 host.example + t=0 0 + m=video 49920 RTP/AVP 98 + a=rtpmap:98 jpeg2000/27000000 + a=fmtp:98 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 + + If Bob doesn't accept 27MHz clock rate, he replies as below: + + v=0 + o=bob 2890844730 2890844731 IN IP4 host.example + s= + c=IN IP4 host.example + t=0 0 + m=video 49920 RTP/AVP 99 + a=rtpmap:99 jpeg2000/90000 + a=fmtp:99 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480 + +8. IANA Considerations + + A new media subtype (video/jpeg2000) has been registered by IANA. + For details, see Section 6 of this document. + +9. Security Considerations + + RTP packets using the payload format defined in this specification + are subject to the security considerations discussed in the RTP + specification [RFC3550], and in any applicable RTP profile. The main + security considerations for the RTP packet carrying the RTP payload + format defined within this memo are confidentiality, integrity, and + + + +Futemma, et al. Standards Track [Page 17] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + source authenticity. Confidentiality is achieved by encryption of + the RTP payload. Integrity of the RTP packets is through the use of + suitable cryptographic integrity protection mechanism. A + cryptographic system may also allow the authentication of the source + of the payload. A suitable security mechanism for this RTP payload + format should provide confidentiality, integrity protection, and at + least a source authentication method capable of determining whether + or not an RTP packet is from a member of the RTP session. + + Note that the appropriate mechanism to provide security to RTP and + payloads following this memo may vary. It is dependent on the + application, the transport, and the signaling protocol employed. + Therefore, a single mechanism is not sufficient, although if + suitable, the usage of SRTP [RFC3711] is recommended. Other + mechanism that may be used are IPsec [RFC4301] and Transport Layer + Security (TLS) [RFC5246] (RTP over TCP), but other alternatives may + also exist. + +10. Congestion Control + + If Quality of Service (QoS) enhanced service is used, RTP receivers + SHOULD monitor packet loss to ensure that the service that was + requested is actually being delivered. If it is not, then they + SHOULD assume that they are receiving best-effort service and behave + accordingly. + + If best-effort service is being used, users of this payload format + MUST monitor packet loss to ensure that the packet loss rate is + within acceptable parameters. Packet loss is considered acceptable + if a TCP flow across the same network path, experiencing the same + network conditions, would achieve an average throughput, measured on + a reasonable timescale, that is not less than the RTP flow is + achieving. This condition can be satisfied by implementing + congestion control mechanisms to adapt the transmission rate (or the + number of layers subscribed for a layered multicast session), or by + arranging for a receiver to leave the session if the loss rate is + unacceptably high. + + + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 18] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +11. References + +11.1. Normative References + + [JPEG2000Pt_1] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. + T.800, "Information Technology - JPEG 2000 Image + Coding System - Part 1: Core Coding System", + December 2000. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., + and K. Norrman, "The Secure Real-time Transport + Protocol (SRTP)", RFC 3711, March 2004. + + [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications + and Registration Procedures", BCP 13, RFC 4288, + December 2005. + + [RFC4855] Casner, S., "Media Type Registration of RTP Payload + Formats", RFC 4855, February 2007. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, July 2006. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer + Model with Session Description Protocol (SDP)", + RFC 3264, June 2002. + +11.2. Informative References + + [JPEG2000Pt_3] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. + T.800, "Information Technology - JPEG 2000 Image + Coding System - Part 3: Motion JPEG 2000", + July 2002. + + [RFC5372] Leung, A., Futemma, S., and E. Itakura, "Payload + Format for JPEG 2000 Video: Extensions for + Scalability and Main Header Recovery", RFC 5372, + October 2008. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + + +Futemma, et al. Standards Track [Page 19] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for + Uncompressed Video", RFC 4175, September 2005. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", + STD 5, RFC 1112, August 1989. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 20] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +Appendix A. Informative Appendix + +A.1. Recommended Practices + + As the JPEG 2000 coding standard is highly flexible, many different + but compliant data streams may be produced and still be compliant + JPEG 2000 codestreams. + + The following is a set of recommendations set forth from our + experience in developing JPEG 2000 and this payload specification. + Implementations of this standard must handle all possibilities + mentioned in this specification. The following is a listing of items + an implementation may optimize. + + Error Resilience Markers: The use of error resilience markers in the + JPEG 2000 data stream is highly recommended in all situations. + Error recovery with these markers is helpful to the decoder and + saves external resources (e.g., markers such as RESET, RESTART, + and ERTERM). + + YCbCr Color Space: The YCbCr color space provides the greatest + amount of compression in color with respect to the human visual + system. When used with JPEG 2000, this color space can provide + excellent visual results at low bit rates. + + Progression Ordering: JPEG 2000 offers many different ways to order + the final code stream to optimize the transfer with the + presentation. We have found that the most useful codestream + ordering is layer progression and resolution progression ordering. + + Tiling and Packets: JPEG 2000 packets are formed regardless of the + encoding method. The encoder has little control over the size of + these JPEG 2000 packets as they may be large or small. + Tiling splits the image into smaller areas and each is encoded + separately. With tiles, the JPEG 2000 packet sizes are also + reduced. When using tiling, almost all JPEG 2000 packet sizes are + an acceptable size for transmission (i.e., smaller than the MTU + size of most networks). + + Sender Processing: There are no limitations as to how the sender + should pack the payload. In general, the sender should pack + headers separately from the rest of the codestream to make header + recovery simple. Payloads should generally begin with a Start of + Packet (SOP) marker and end with an End of Packet Header (EPH) + marker for easier decoder processing. + + + + + + +Futemma, et al. Standards Track [Page 21] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +A.2. Sample Headers in Detail + + This section has various sample headers in various configurations for + reference. + + For reference, the payload header is as follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |tp |MHF|mh_id|T| priority | tile number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |reserved | fragment offset | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: JPEG 2000 Payload Header + +A.2.1. Sample 1: Progressive Image with Single Tile, 3500 Bytes (i.e., + thumbnail) + + First Packet: This packet will have the whole main header 210 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 3 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF4F FF51 002F 000 .... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Header Sample 1-1 (First Packet) + + + + + + + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 22] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + Second Packet: This packet will have a tile header and the first tile + part LLband 1500 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 3 | 0 |0| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 210 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0000 0000 2DB3 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: Header Sample 1-2 (Second Packet) + + Third Packet: This packet will have the next part in the tile, no + tile header 1500 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | 0 |0| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 1710 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |E841 4526 4556 9850 C2EA ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: Header Sample 1-3 (Third Packet) + + Fourth Packet: Last packet for the image 290 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | 0 |0| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 3210 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A55D 8B73 3B25 25C7 B9EB ... 2FBE B153| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: Header Sample 1-4 (4th Packet) + + + + + + + + +Futemma, et al. Standards Track [Page 23] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +A.2.2. Sample 2: Image with 4 Tiles + + First Packet: This packet will have the whole main header. 210 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 3 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF4F FF51 002F 000 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 11: Header Sample 2-1 (First Packet) + + Second Packet: This packet will have a first tile part (tile 0) 1400 + bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | 0 |0| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 210 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0000 0000 0578 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 12: Header Sample 2-2 (Second Packet) + + Third Packet: This packet will have a second tile part (tile 1) 1423 + bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | 0 |0| 255 | 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 1610 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0001 0000 058F 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 13: Header Sample 2-3 (Third Packet) + + + + + + +Futemma, et al. Standards Track [Page 24] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + Fourth Packet: This packet will have a third tile part (tile 2) 1355 + bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | 0 |0| 255 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 3033 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0002 0000 054B 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 14: Header Sample 2-4 (4th Packet) + + Fifth Packet: This packet will have a fourth tile part (tile 3) 1290 + bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | 0 |0| 255 | 3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 4388 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0003 0000 050A 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 15: Header Sample 2-5 (5th Packet) + +A.2.3. Sample 3: Packing Multiple Tiles in Single Payload, Fragmented + Header + + First Packet: This packet will have the first part of the main header + 110 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 1 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF4F FF51 002F 000 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Futemma, et al. Standards Track [Page 25] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + Figure 16: Header Sample 3-1 (First Packet) + + Second Packet: This packet has the second part of the header 1400 + bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 2 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 110 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF64 00FF ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 17: Header Sample 3-2 (Second Packet) + + Third Packet: This packet has two tiles, tile 0 and tile 1 1400 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 1510 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0000 0000 02BC 0001 FF93 ... | + // // + |FF90 000A 0001 0000 02BC 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 18: Header Sample 3-3 (Third Packet) + + + + + + + + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 26] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + Fourth Packet: This packet has one tile, tile 2 1395 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | 0 |0| 255 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 2910 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0002 0000 0573 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 19: Header Sample 3-4 (4th Packet) + +A.2.4. Sample 4: Interlace Image, Single Tile + + First packet: This packet will have the whole main header for the odd + field 210 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 3 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF4F FF51 002F 000 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 20: Header Sample 4-1 (First Packet) + + Second packet: This packet will have the first part of the odd + field's tile 1400 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 0 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 210 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0000 0000 0578 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 21: Header Sample 4-2 (Second Packet) + + + + + + +Futemma, et al. Standards Track [Page 27] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + Third packet: This packet will have the second part of the odd + field's tile 1400 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 0 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 1610 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |7F04 E708 27D9 D11D 22CB ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 22: Header Sample 4-3 (Third Packet) + + Fourth packet: This packet will have the third part of the odd + field's tile 1300 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 0 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 3010 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |98BD EC9B 2826 DC62 D4AB ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 23: Header Sample 4-4 (4th Packet) + + Fifth packet: This packet will have the whole main header for the + even field 210 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 3 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF4F FF51 002F 000 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 24: Header Sample 4-5 (5th Packet) + + + + + + + +Futemma, et al. Standards Track [Page 28] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + + Sixth packet: This packet will have the first part of the even + field's tile 1400 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 210 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |FF90 000A 0000 0000 0578 0001 FF93 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 25: Header Sample 4-6 (6th Packet) + + Seventh packet: This packet will have the second part of the even + field's tile 1400 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 1610 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |626C 42F0 166B 6BD0 F8E1 ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 26: Header Sample 4-7 (7th Packet) + + Eighth packet: This packet will have the third part of the even + field's tile 1300 bytes + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 0 |1| 255 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 3010 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |8114 41D5 18AB 4A1B ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 27: Header Sample 4-8 (8th Packet) + + + + + + + +Futemma, et al. Standards Track [Page 29] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +Authors' Addresses + + Satoshi Futemma + Sony Corporation + 1-7-1 Konan + Minato-ku + Tokyo 108-0075 + Japan + + Phone: +81 3 6748-2111 + EMail: satosi-f@sm.sony.co.jp + URI: http://www.sony.net/ + + + Eisaburo Itakura + Sony Corporation + 1-7-1 Konan + Minato-ku + Tokyo 108-0075 + Japan + + Phone: +81 3 6748-2111 + EMail: itakura@sm.sony.co.jp + URI: http://www.sony.net/ + + + Andrew Leung + Sony Corporation + + EMail: andrew@ualberta.net + + + + + + + + + + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 30] + +RFC 5371 JPEG 2000 RTP Payload Format October 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Futemma, et al. Standards Track [Page 31] + -- cgit v1.2.3