summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5372.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5372.txt')
-rw-r--r--doc/rfc/rfc5372.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc5372.txt b/doc/rfc/rfc5372.txt
new file mode 100644
index 0000000..5fde157
--- /dev/null
+++ b/doc/rfc/rfc5372.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group A. Leung
+Request for Comments: 5372 S. Futemma
+Category: Standards Track E. Itakura
+ Sony
+ October 2008
+
+
+ Payload Format for JPEG 2000 Video:
+ Extensions for Scalability and Main Header Recovery
+
+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 extended uses for the payload header in "RTP
+ Payload Format for JPEG 2000 Video Streams" as specified in RFC 5371,
+ for better support of JPEG 2000 features such as scalability and main
+ header recovery.
+
+ This memo must be accompanied with a complete implementation of "RTP
+ Payload Format for JPEG 2000 Video Streams". That document is a
+ complete description of the payload header and signaling, this
+ document only describes additional processing for the payload header.
+ There is an additional media type and Session Description Protocol
+ (SDP) marker signaling for implementations of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 1]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Description of the Mechanisms . . . . . . . . . . . . . . 3
+ 1.1.1. Main Header Compensation . . . . . . . . . . . . . . . 3
+ 1.1.2. Priority Table . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Motivations for Priority Field Coding . . . . . . . . . . 4
+ 1.2.1. Scenario: Just Enough Resolution . . . . . . . . . . . 4
+ 1.2.2. Scenario: Multiple Clients, Single Source . . . . . . 4
+ 1.3. Conventions Used in This Document . . . . . . . . . . . . 4
+ 2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 5
+ 2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 5
+ 3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. Packet-Number-Based Ordering . . . . . . . . . . . . . . . 7
+ 3.2. Progression-Based Ordering . . . . . . . . . . . . . . . . 7
+ 3.3. Layer-Based Ordering . . . . . . . . . . . . . . . . . . . 9
+ 3.4. Resolution-Based Ordering . . . . . . . . . . . . . . . . 9
+ 3.5. Component-Based Ordering . . . . . . . . . . . . . . . . . 10
+ 4. JPEG 2000 Main Header Compensation Scheme . . . . . . . . . . 10
+ 4.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 11
+ 4.2. Receiver Processing . . . . . . . . . . . . . . . . . . . 11
+ 5. Media Type Registration . . . . . . . . . . . . . . . . . . . 11
+ 6. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 6.1. Mapping of the Optional Parameters to SDP . . . . . . . . 12
+ 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 13
+ 6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 13
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
+ 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 16
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
+ Appendix A. Sample Headers in Detail . . . . . . . . . . . . . . 17
+ A.1. Sample 1: Progressive Image with Single Tile, 3500
+ Bytes (i.e., thumbnail) . . . . . . . . . . . . . . . . . 17
+ A.2. Sample 2: Image with 4 Tiles . . . . . . . . . . . . . . . 19
+ A.3. Sample 3: Packing Multiple Tiles in Single Payload,
+ Fragmented Header. No Header Compensation,
+ Progressive Image . . . . . . . . . . . . . . . . . . . . 20
+ A.4. Sample 4: Interlace Image, Single Tile . . . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 2]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+1. Introduction
+
+ This document is an extension of "RTP Payload Format for JPEG 2000
+ Video Streams" [RFC5371]. These are additional mechanisms that can
+ be used with certain parts of the header in [RFC5371] to support JPEG
+ 2000 features such as scalability and a main header compensation
+ method. These mechanisms are described in detail in this document.
+
+ These are optional extensions to RFC 5371 [RFC5371], which one may
+ use to make better use of JPEG 2000 features. These extensions are
+ not required for any implementations of RFC 5371 [RFC5371].
+
+1.1. Description of the Mechanisms
+
+1.1.1. Main Header Compensation
+
+ JPEG 2000 image header contains essential decoding information for
+ the decoder. If a JPEG 2000 decoder receives JPEG 2000 image data
+ without a JPEG 2000 image header, it could not decode the JPEG 2000
+ image data properly. Encoders for JPEG 2000 video very rarely change
+ encoding parameters between successive frames. So, the possibility
+ of the decoder successively decoding the new JPEG 2000 image data
+ using a prior JPEG 2000 image header is very high in this situation.
+
+ The main header compensation scheme used in this document exploits
+ the fact that successive JPEG 2000 video images rarely change
+ encoding parameters. It requires receivers to save past JPEG 2000
+ image headers to use in case of missing JPEG 2000 image headers in
+ the future. Signaling of changes to the JPEG 2000 image header is
+ done through the payload header. When the mh_id value of the payload
+ header changes, receivers should save the new JPEG 2000 header to use
+ for main header recovery.
+
+1.1.2. Priority Table
+
+ JPEG 2000 codestream has rich functionality built into it so decoders
+ can easily handle scalable delivery or progressive transmission.
+ Progressive transmission allows images to be reconstructed with
+ increasing pixel accuracy or spatial resolution. This feature allows
+ the reconstruction of images with different resolutions and pixel
+ accuracy, for different target devices. A single image source can
+ provide a codestream that is easily processed for smaller image
+ display devices.
+
+ JPEG 2000 packets contain all compressed image data from a specific
+ layer, component, resolution level, and/or precinct. The order in
+ which these JPEG 2000 packets are found in the codestream is called
+ the progression order. The ordering of the JPEG 2000 packets can
+
+
+
+Leung, et al. Standards Track [Page 3]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ progress along four axes: layer, component, resolution, and precinct
+ (or position).
+
+ Providing a priority field to indicate the importance of data
+ contained in a given RTP packet can aid in usage of JPEG 2000
+ progressive and scalable functions.
+
+1.2. Motivations for Priority Field Coding
+
+ The JPEG 2000 coding scheme allows one to reorder the codestream in
+ many ways. Even when the coding scheme is determined and arranged by
+ the encoder, a decoder can still re-arrange the code stream on the
+ fly to suit decode parameters such as re-arranging from resolution
+ progressive to quality progressive.
+
+ Using the priority field coding, the decoder gains insight into the
+ codestream without access to the full codestream and exposes features
+ of JPEG 2000 to a higher level.
+
+ The authors found the scenarios below to utilize this field. The
+ priority field allows more information about the image to be sent
+ without more signaling between sender and receivers to leverage JPEG
+ 2000 capabilities.
+
+1.2.1. Scenario: Just Enough Resolution
+
+ The scenario is when rapid scene access is more important than higher
+ image quality. By using the priority field, the receiver can decode
+ for its own quality level. If the sender cannot determine the
+ receiver's resolution, the receiver can select which parts of the
+ codestream to be decoded or loaded by using the priority field.
+
+1.2.2. Scenario: Multiple Clients, Single Source
+
+ In a multicast environment, there are clients with better visual
+ capability than others (i.e., TV conference versus Mobile). The
+ respective clients can use the priority field to determine which
+ packets are vital for their own visual presentation. The sender only
+ has to do work on the priority field to optimally serve all the
+ clients while only managing a single visual stream.
+
+1.3. 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].
+
+
+
+
+
+Leung, et al. Standards Track [Page 4]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+2. Payload Format Enhanced Processing
+
+2.1. Enhanced Processing Markers
+
+ This section of the document describes additional usage in the values
+ of mh_id and priority fields and interpretation that differ from RFC
+ 5371 [RFC5371]. Implementations of this document should follow RFC
+ 5371 [RFC5371] first then add additional header processing as
+ described in this document. Implementations following this document
+ are expected to interoperate with implementations of [RFC5371] and
+ this document as well.
+
+ 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 1: RTP Payload Header Format for JPEG 2000
+
+ mh_id (Main Header Identification): 3 bits
+
+ Main header identification value. This is used for JPEG 2000 main
+ header recovery.
+
+ The initial value of mh_id MUST be 1 at the beginning of the
+ session.
+
+ The same mh_id value is used as long as the coding parameters
+ described in the main header remains unchanged between frames.
+
+ The mh_id value MUST be incremented by 1 every time a new main
+ header is transmitted. Once the mh_id value becomes greater than
+ 7, it SHOULD roll over to 1.
+
+ When mh_id is 0, it has special usage for the receiver. This
+ special usage is described in Section 4.2 of this document.
+
+ Senders should follow Section 4.1 of this document for proper
+ mh_id assignment and usage.
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 5]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ 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
+ containing the lower sub-bands.
+
+ Special values of priority:
+
+ 0: This is reserved for payloads that contain a header (main or
+ tile part header). This is considered the most important.
+
+ 1 to 255: These values decrease in importance as the values
+ increase (i.e., 1 is more important than 2, etc.). Applying
+ priority values should correlate directly to the JPEG 2000
+ codestream in importance.
+
+ The lower the priority value, the higher the importance. A
+ priority value of 0 is the highest importance and 255 is the
+ lowest importance. We define the priority value 0 as a special
+ priority value for the headers (the main header or tile-part
+ header). If any headers (the main header or tile-part header) are
+ packed into the RTP payload, the sender MUST set the priority
+ value to 0.
+
+ Assignment of the values is described in Section 3.
+
+3. Priority Mapping Table
+
+ For the progression order, the priority value for each JPEG 2000
+ packet is given by the priority mapping table.
+
+ This document specify several commonly used priority mapping tables,
+ pre-defined priority mapping tables: packet-number-based (default),
+ progression-based, layer-based, resolution-based, and component-
+ based.
+
+ Packet number priority mapping is REQUIRED to be supported by clients
+ implementing this specification. Other priority mapping tables
+ (progression, layer, resolution, and component-based) are OPTIONAL to
+ implementations of this specification.
+
+ Rules that all implementations of this specification MUST follow in
+ all priority modes:
+
+ o When there is a header in the packet with a JPEG 2000 packet, the
+ sender MUST set the payload packet priority value to 0.
+
+
+
+
+Leung, et al. Standards Track [Page 6]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ o When there are multiple JPEG 2000 packets in the same RTP payload
+ packet, the sender MUST set the payload packet priority value to
+ the lowest JPEG 2000 packet (i.e., if JPEG 2000 packets with
+ priority: 5,6,7 are packed into a single payload, the priority
+ value will be 5).
+
+3.1. Packet-Number-Based Ordering
+
+ Packet-number-based ordering assigns the payload packet priority
+ value from the "JPEG 2000 packet value" (note: JPEG 2000 codestreams
+ are stored in units of packets and each packet has a value). This
+ method is the default method for assigning priority value. All
+ implementations of this specification MUST support this method.
+
+ If the JPEG 2000 codestream packet value is greater than 255, the
+ sender MUST set the payload priority value to 255.
+
+3.2. Progression-Based Ordering
+
+ The sender will assign the payload packet priority value only based
+ on layer, resolution, and component ordering of the codestream.
+
+ Progression-based ordering can assign the different priority values
+ in the same layer or the resolution level, which it cannot do in the
+ layer-based ordering or resolution-based ordering.
+
+ Unlike the packet-number-based ordering, the progression-based
+ ordering does not assign a value in the position level, which saves
+ the priority values. The priority value in the position level is not
+ so important because a receiver could recognize the position by
+ checking the tile number field. Therefore, the progression-based
+ ordering would be useful.
+
+ The general algorithm is that the ordering is based on the triple
+ <layer, resolution, component> and the minimum priority is 1. So, if
+ the codestream is constructed of L layers (layer value ranges from 0
+ to L-1), R resolutions (resolution value ranges from 0 to R-1), and C
+ components (component value ranges from 0 to C-1), then for a triple
+ <lval, rval, cval>:
+
+ the priority value of the codestream in LRCP order is calculated
+ as:
+
+ priority = 1 + cval + (C * rval) + (C * R * lval)
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 7]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ the priority value of the codestream in RLCP order is calculated
+ as:
+
+ priority = 1 + cval + (C * lval) + (C * L * rval)
+
+ the priority value of the codestream in RPCL order is calculated
+ as:
+
+ priority = 1 + lval + (L * cval) + (L * C * rval)
+
+ the priority value of which codestream in PCRL order is calculated
+ as:
+
+ priority = 1 + lval + (L * rval) + (L * R * cval)
+
+ the priority value of which codestream in CPRL order is calculated
+ as:
+
+ priority = 1 + lval + (L * rval) + (L * R * cval)
+
+ For example:
+
+ If the codestream is ordered in LRCP (Layer, Resolution, Component,
+ Position) with 1 layer (L=1), 2 resolutions (R=2), 3 components
+ (C=3), and 2 positions, the priority value should be (1 + cval +
+ 3*rval + 6*lval). Then an example would have packet numbering as so:
+
+ All the packets in:
+
+ layer.........0
+ resolution....0
+ component.....0
+ position......0 or 1
+
+ then the packet priority value : 1
+
+ All the packets in:
+
+ layer.........0
+ resolution....0
+ component.....1
+ position......0 or 1
+
+ then the packet priority value : 2
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 8]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ All the packets in:
+
+ layer.........0
+ resolution....0
+ component.....2
+ position......0 or 1
+
+ then the packet priority value : 3
+
+ All the packets in:
+
+ layer.........0
+ resolution....1
+ component.....0
+ position......0 or 1
+
+ then the packet priority value : 4
+
+ All the packets in:
+
+ layer.........0
+ resolution....1
+ component.....1
+ position......0 or 1
+
+ then the packet priority value : 5
+
+3.3. Layer-Based Ordering
+
+ The layer-based priority mapping table simplifies the default mapping
+ to just matching JPEG 2000 packets together from the same layer.
+
+ For example:
+
+ All the packets in layer 0 : packet priority value : 1
+ All the packets in layer 1 : packet priority value : 2
+ All the packets in layer 2 : packet priority value : 3
+ ...
+ All the packets in layer n : packet priority value : n+1
+ All the packets in layer 255 : packet priority value : 255
+
+3.4. Resolution-Based Ordering
+
+ Resolution-based priority mapping table is similar to the layer-based
+ order but for JPEG 2000 packets of the same resolution.
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 9]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ For example:
+
+ All the packets in resolution 0 : packet priority value : 1
+ All the packets in resolution 1 : packet priority value : 2
+ All the packets in resolution 2 : packet priority value : 3
+ ...
+ All the packets in resolution n : packet priority value : n+1
+ All the packets in resolution 255 : packet priority value : 255
+
+3.5. Component-Based Ordering
+
+ Component-based priority mapping table is mapping together JPEG 2000
+ components of the same component.
+
+ For example:
+
+ All the packets in component 0 : packet priority value : 1
+ All the packets in component 1 : packet priority value : 2
+ All the packets in component 2 : packet priority value : 3
+ ...
+ All the packets in component n : packet priority value : n+1
+ All the packets in component 255 : packet priority value : 255
+
+4. JPEG 2000 Main Header Compensation Scheme
+
+ The mh_id field of the payload header is used to indicate whether the
+ encoding parameters of the main header are the same as the encoding
+ parameters of the previous frame. The same value is set in mh_id of
+ the RTP packet in the same frame. The mh_id and encode parameters
+ are not associated with each other as 1:1, but they are used to
+ indicate whether or not the encode parameters of the previous frame
+ are the same in the event of a lost header.
+
+ The mh_id field value SHOULD be saved from previous frames to be used
+ to recover the current frame's main header. If the mh_id of the
+ current frame has the same value as the mh_id value of the previous
+ frame, the previous frame's main header MAY be used to decode the
+ current frame, in case of a lost header in the current frame.
+
+ The sender MUST increment mh_id when parameters in the header change
+ and send a new main header accordingly.
+
+ The receiver MAY use the mh_id and MAY retain the header for such
+ compensation.
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 10]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+4.1. Sender Processing
+
+ The sender MUST transmit RTP packets with the same mh_id value if the
+ encoder parameters of the current frame are the same as the previous
+ frame. The encoding parameters are the fixed information marker
+ segment (SIZ marker) and functional marker segments (COD, COC, RGN,
+ QCD, QCC, and POC) specified in JPEG 2000 Part 1, Annex A
+ [JPEG2000Pt_1].
+
+ If the encode parameters changes, the sender transmitting RTP packets
+ MUST increment the mh_id value by one, but when the mh_id value
+ becomes greater than 7, a sender MUST set the mh_id value back to 1.
+
+4.2. Receiver Processing
+
+ When the receiver receives the main header completely, the RTP
+ sequence number, the mh_id, and the main header should be saved.
+ Only the last main header that was received completely SHOULD be
+ saved. When the mh_id value is 0, the receiver SHOULD NOT save the
+ header.
+
+ When the main header is not received, the receiver may compare the
+ current payload header's mh_id value with the previous saved mh_id
+ value. If the values match, decoding may be performed by using the
+ previously saved main header.
+
+ If the mh_id field is set to 0, the receiver MUST NOT save the main
+ header and MUST NOT compensate for lost headers.
+
+ If the mh_id value changes, receivers SHOULD save the current header
+ and save the new mh_id value. The old saved header should be deleted
+ from storage.
+
+ Also, if the decoder detects an inconsistency between the header and
+ payload, it is recommended to clear the saved mh_id and the saved
+ main header. Please see Section 8 for more explanation.
+
+5. Media Type Registration
+
+ This document extends the associated media type "video/jpeg2000" from
+ RFC 5371 [RFC5371]. Here are additional optional parameters.
+
+
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 11]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ Additional optional parameters:
+
+ mhc: Main Header Compensation. This option is used when a sender
+ and/or receiver is utilizing the Main Header Compensation
+ technique as specified in this document. Acceptable values
+ when using the Main Header Compensation technique is "1";
+ otherwise, it should be "0".
+
+ This is a list of options to be included when the sender or
+ receiver is utilizing the priority table option as specified in
+ this document.
+
+ pt: Priority Table. This option is followed by a comma-separated
+ list of pre-defined priority table definitions to be used by
+ sender or receiver.
+
+ The option appearing front most in the option line is the most
+ important and the next are of decreasing importance.
+
+ Acceptable values:
+
+ progression: this table follows the progression ordering of
+ the codestream.
+
+ layer: this table follows the layer ordering of the
+ codestream.
+
+ resolution: this table follows the resolution ordering of
+ the codestream.
+
+ component: this table follows the component ordering of the
+ codestream.
+
+ default: this table follows the packet ordering of the
+ codestream.
+
+6. SDP Parameters
+
+6.1. Mapping of the Optional Parameters to SDP
+
+ The new optional parameters mhc and pt, 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.
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 12]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+6.2. Usage with the SDP Offer/Answer Model
+
+ In addition to the SDP Offer/Answer section in RFC 5371 [RFC5371]:
+
+ 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 that parameter.
+
+ o All parameters MUST correspond to the parameters of the payload.
+
+ o If the optional parameter "mhc" is used, it MUST appear in the
+ offer with value "1", and if accepted, it SHOULD appear in the
+ answer.
+
+ o If the optional parameter "pt" is used, it MUST appear in the
+ offer containing a complete comma-separated list indicating which
+ priority table definitions the sender supports. If accepted, it
+ SHOULD appear in the answer containing a single priority table
+ definition selected from the offer.
+
+ o If the optional parameter "mhc" is used, it MUST appear in the
+ offer with value "1", and if accepted, it MUST appear in the
+ answer. If the optional parameter "pt" is used, it MUST appear in
+ the offer containing a complete comma-separated list indicating
+ which priority table definitions the sender supports. If
+ accepted, it MUST appear in the answer containing a single
+ priority table definition selected from the offer.
+
+ o In a multicast environment:
+
+ * Senders should send out one option for a priority table
+ definition for everyone in the group.
+
+ * Even if a single client in the group does not support the
+ extensions outlined in this document, senders MAY use these
+ mechanisms. A receiver that doesn't support the mechanisms
+ would safely ignore the values.in mh_id and priority field.
+
+6.2.1. Examples
+
+ Offer/Answer example exchanges are provided.
+
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 13]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+6.2.1.1. Example 1
+
+ Alice offers Main Header Compensation functionality, YCbCr 422 color
+ space, interlace image with 720-pixel width and 480-pixel height, and
+ several priority table options (default, progression, layer,
+ resolution, component) 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 mhc=1; sampling=YCbCr-4:2:2; interlace=1;
+ pt=default,progression,layer,resolution, component;
+ width=720;height=480
+
+ Bob accepts Main Header Compensation functionality, YCbCr-4:2:2 color
+ space, interlace image, default mapping table 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 mhc=1; sampling=YCbCr-4:2:2;interlace=1;
+ pt=default;width=720;height=480
+
+6.2.1.2. Example 2
+
+ Alice offers Main Header Compensation, YCbCr 420 color space,
+ progressive image with 320-pixel width and 240-pixel height, and
+ layer priority table options 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 mhc=1; sampling=YCbCr-4:2:0;
+ pt=layer;width=320;height=240
+
+
+
+
+
+Leung, et al. Standards Track [Page 14]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ Bob does not accept Main Header Compensation functionality but
+ accepts YCbCr-4:2:0 color space, layer-based priority mapping 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 mhc=0; sampling=YCbCr-4:2:0;
+ pt=layer;width=320;height=240
+
+6.2.1.3. Example 3
+
+ Alice offers 27 MHz timestamp, Main Header Compensation, YCbCr 420
+ color space, progressive image with 320-pixel width and 240-pixel
+ height, and layer priority table options 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 99
+ a=rtpmap:98 jpeg2000/27000000
+ a=rtpmap:99 jpeg2000/90000
+ a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
+ pt=layer;width=320;height=240
+ a=fmtp:99 mhc=1; sampling=YCbCr-4:2:0;
+ pt=layer;width=320;height=240
+
+ Bob can accept payload type with 27 MHz timestamp, and does not
+ accept Main Header Compensation functionality but accepts YCbCr-4:2:0
+ color space, layer-based priority mapping 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/27000000
+ a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
+ pt=layer;width=320;height=240
+
+
+
+
+
+Leung, et al. Standards Track [Page 15]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+7. IANA Considerations
+
+ This document extends the associated media type "video/jpeg2000" from
+ 5371 [RFC5371]. Additional parameters are specified in Section 5 of
+ this document.
+
+8. Security Considerations
+
+ Please refer to Section 6 of RFC 5371 [RFC5371] for Security
+ Considerations regarding this RTP format. The security issues
+ regarding enhanced mechanisms presented in this document are
+ discussed in that section.
+
+ The mh_id field can identify a maximum of 7 different main headers.
+ If severe packet loss (either random or intentionally introduced by
+ an attacker) causes 6 successive updates to the main header to be
+ lost, the decoder will attempt decompression using an incorrect main
+ header. Even if the incorrect main header is passed, the standard
+ JPEG 2000 decoder could detect inconsistency of the codestream and
+ process it properly. It is recommended to clear the saved mh_id and
+ the saved main header if the decoder detects such an inconsistency.
+
+9. Congestion Control
+
+ Please refer to Section 7 of RFC 5371 [RFC5371] for Congestion
+ Control regarding this RTP format.
+
+10. Normative References
+
+ [RFC5371] Futemma, S., Leung, A., and E. Itakura, "RTP Payload
+ Format for JPEG 2000 Video Streams", RFC 5371,
+ October 2008.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
+ Model with Session Description Protocol (SDP)",
+ RFC 3264, June 2002.
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 16]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+Appendix A. Sample Headers in Detail
+
+ The following figures are sample RTP headers demonstrating values
+ that should appear in the RTP header. The packet priority is Packet-
+ Number-Based Priority.
+
+ 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 2: JPEG 2000 Payload Header
+
+A.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 | 1 |1| 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF4F FF51 002F 0000 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: Header Sample 1-1 (First Packet)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 17]
+
+RFC 5372 JPEG 2000 RTP Extensions 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 | 0 | 1 |0| 1 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 210 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0000 0000 2DB3 0001 FF93 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: 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 | 1 |0| 2 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 1710 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |E841 4526 4556 9850 C2EA .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 5: 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 | 1 |0| 3 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 3210 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A55D 8B73 3B25 25C7 B9EB .... 2FBE B153|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 6: Header Sample 1-4 (Fourth Packet)
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 18]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+A.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 | 1 |1| 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF4F FF51 002F 0000 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 7: 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 | 1 |0| 1 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 210 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0000 0000 0578 0001 FF93 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 8: 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 | 1 |0| 1 | 1 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 1610 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0001 0000 058F 0001 FF93 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 9: Header Sample 2-3 (Third Packet)
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 19]
+
+RFC 5372 JPEG 2000 RTP Extensions 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 | 1 |0| 1 | 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 3033 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0002 0000 054B 0001 FF93 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 10: 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 | 1 |0| 1 | 3 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 4388 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0003 0000 050A 0001 FF93 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 11: Header Sample 2-5 (5th Packet)
+
+A.3. Sample 3: Packing Multiple Tiles in Single Payload, Fragmented
+ Header. No Header Compensation, Progressive Image
+
+ 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| 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF4F FF51 002F 0000 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 12: Header Sample 3-1 (First Packet)
+
+
+
+
+Leung, et al. Standards Track [Page 20]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+ Second Packet: This packet has the second part of the main 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| 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 110 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF64 00FF .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 13: 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| 1 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 1510 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0000 0000 02BC 0001 FF93 ... |
+ // . //
+ |FF90 000A 0001 0000 02BC 0001 FF93 ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 14: Header Sample 3-3 (Third Packet)
+
+ 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| 1 | 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 2910 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0002 0000 0573 0001 FF93 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 15: Header Sample 3-4 (4th Packet)
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 21]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+A.4. Sample 4: Interlace Image, Single Tile
+
+ The codestream of each image is ordered in LRCP (Layer, Resolution,
+ Component, Position) with 1 layer, 3 resolutions, 3 components and 1
+ position.
+
+ 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 | 1 |1| 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF4F FF51 002F 0000 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 16: Header Sample 4-1 (First Packet)
+
+ Second packet: This packet will have the first part of the odd
+ field's tile where three jp2-packets are included 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 | 1 |1| 1 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 210 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0000 0000 0578 0001 FF93 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 17: Header Sample 4-2 (Second Packet)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 22]
+
+RFC 5372 JPEG 2000 RTP Extensions 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 | 1 |1| 4 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 1610 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |7F04 E708 27D9 D11D 22CB ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 18: 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 | 1 |1| 7 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 3010 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |98BD EC9B 2826 DC62 D4AB ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 19: 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 | 1 |1| 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF4F FF51 002F 0000 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 20: Header Sample 4-5 (5th Packet)
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 23]
+
+RFC 5372 JPEG 2000 RTP Extensions 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 | 1 |1| 1 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 1610 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |FF90 000A 0000 0000 0578 0001 FF93 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 21: 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 | 1 |1| 4 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 3010 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |626C 42F0 166B 6BD0 F8E1 ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 22: 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 | 1 |1| 7 | 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0 | 4410 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |8114 41D5 18AB 4A1B ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 23: Header Sample 4-8 (8th Packet)
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 24]
+
+RFC 5372 JPEG 2000 RTP Extensions October 2008
+
+
+Authors' Addresses
+
+ Andrew Leung
+ Sony Corporation
+
+ EMail: andrew@ualberta.net
+
+
+ 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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 25]
+
+RFC 5372 JPEG 2000 RTP Extensions 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Leung, et al. Standards Track [Page 26]
+