draft-ietf-avt-rtp-jpeg2000-beam-10.txt   draft-ietf-avt-rtp-jpeg2000-beam-11.txt 
Audio Video Transport A. Leung Audio Video Transport A. Leung
Internet-Draft S. Futemma Internet-Draft S. Futemma
Intended status: Standards Track E. Itakura Intended status: Standards Track E. Itakura
Expires: October 26, 2008 Sony Expires: January 1, 2009 Sony
Apr 24, 2008 Jun 30, 2008
Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Payload Format for JPEG 2000 Video: Extensions for Scalability and Main
Header Recovery Header Recovery
draft-ietf-avt-rtp-jpeg2000-beam-10 draft-ietf-avt-rtp-jpeg2000-beam-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 26, 2008. This Internet-Draft will expire on January 1, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo describes extended uses for payload header in RFC document: This memo describes extended uses for payload header in "RTP Payload
"RTP Payload Format for JPEG 2000 Video Streams." For better support Format for JPEG 2000 Video Streams" as specified in RFC XXXY. For
of JPEG 2000 features such as scalability and main header recovery. better support of JPEG 2000 features such as scalability and main
header recovery.
This memo must be accompanied with a complete implementation of "RTP This memo must be accompanied with a complete implementation of "RTP
Payload Format for JPEG 2000 Video Streams." That document is a Payload Format for JPEG 2000 Video Streams." That document is a
complete description of the payload header and signaling, this complete description of the payload header and signaling, this
document only describes additional processing for the payload header. document only describes additional processing for the payload header.
There is an additional media type and SDP marker signaling for There is an additional media type and SDP marker signaling for
implementations of this document. implementations of this document.
-- RFC-Editor Note: The authors ask the RFC Editors to replace all
instances of RFC XXXY with the RFC number assigned when
draft-ietf-avt-rtp-jpeg2000-20 [JP2RTP] is published as an RFC. At
that time, please remove the note.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Description of the Mechanisms . . . . . . . . . . . . . . 4 1.1. Description of the Mechanisms . . . . . . . . . . . . . . 4
1.1.1. Main Header Compensation . . . . . . . . . . . . . . . 4 1.1.1. Main Header Compensation . . . . . . . . . . . . . . . 4
1.1.2. Priority Table . . . . . . . . . . . . . . . . . . . . 4 1.1.2. Priority Table . . . . . . . . . . . . . . . . . . . . 4
1.2. Motivations for Priority Field coding . . . . . . . . . . 5 1.2. Motivations for Priority Field coding . . . . . . . . . . 5
1.2.1. Scenario: Just enough resolution . . . . . . . . . . . 5 1.2.1. Scenario: Just enough resolution . . . . . . . . . . . 5
1.2.2. Scenario: Multiple clients, single source . . . . . . 5 1.2.2. Scenario: Multiple clients, single source . . . . . . 5
1.3. Conventions Used in This Document . . . . . . . . . . . . 5 1.3. Conventions Used in This Document . . . . . . . . . . . . 5
2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 6 2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 6
2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 6 2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 6
3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 8 3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 8
3.1. Packet Number Based Ordering . . . . . . . . . . . . . . . 8 3.1. Packet Number Based Ordering . . . . . . . . . . . . . . . 8
3.2. Progression Based Ordering . . . . . . . . . . . . . . . . 8 3.2. Progression Based Ordering . . . . . . . . . . . . . . . . 8
3.3. Layer Based Ordering . . . . . . . . . . . . . . . . . . . 10 3.3. Layer Based Ordering . . . . . . . . . . . . . . . . . . . 10
3.4. Resolution Based Ordering . . . . . . . . . . . . . . . . 10 3.4. Resolution Based Ordering . . . . . . . . . . . . . . . . 11
3.5. Component Based Ordering . . . . . . . . . . . . . . . . . 10 3.5. Component Based Ordering . . . . . . . . . . . . . . . . . 11
4. JPEG 2000 Main Header Compensation Scheme . . . . . . . . . . 12 4. JPEG 2000 Main Header Compensation Scheme . . . . . . . . . . 12
4.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 12 4.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 12
4.2. Receiver Processing . . . . . . . . . . . . . . . . . . . 12 4.2. Receiver Processing . . . . . . . . . . . . . . . . . . . 12
5. Media Type Registration . . . . . . . . . . . . . . . . . . . 14 5. Media Type Registration . . . . . . . . . . . . . . . . . . . 14
6. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 15 6. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Mapping of the optional parameters to SDP . . . . . . . . 15 6.1. Mapping of the optional parameters to SDP . . . . . . . . 15
6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 15 6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 15
6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 20 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 20
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21 9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
10. Normative References . . . . . . . . . . . . . . . . . . . . . 22 10. Normative References . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Sample Headers in Detail . . . . . . . . . . . . . . 23 Appendix A. Sample Headers in Detail . . . . . . . . . . . . . . 23
A.1. Sample 1: Progressive image with single tile, 3500 A.1. Sample 1: Progressive image with single tile, 3500
bytes (i.e. thumbnail) . . . . . . . . . . . . . . . . . . 23 bytes (i.e. thumbnail) . . . . . . . . . . . . . . . . . . 23
A.2. Smaple 2: Image with 4 tiles . . . . . . . . . . . . . . . 25 A.2. Sample 2: Image with 4 tiles . . . . . . . . . . . . . . . 25
A.3. Sample 3: Packing multiple tiles in single payload, A.3. Sample 3: Packing multiple tiles in single payload,
fragmented header. No header compensation, progressive fragmented header. No header compensation, progressive
image . . . . . . . . . . . . . . . . . . . . . . . . . . 26 image . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.4. Sample 4: Interlace image, single tile . . . . . . . . . . 28 A.4. Sample 4: Interlace image, single tile . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 33
1. Introduction 1. Introduction
This document is an extension of: "RTP Payload Format for JPEG 2000 This document is an extension of: "RTP Payload Format for JPEG 2000
Video Streams" [1]. These are additional mechanisms which can be Video Streams" [JP2RTP]. These are additional mechanisms which can
used with certain parts of the header in [1] to support JPEG 2000 be used with certain parts of the header in [JP2RTP] to support JPEG
features such as: scalability and a main header compensation method. 2000 features such as: scalability and a main header compensation
These mechanisms are described in detail in this document. method. These mechanisms are described in detail in this document.
These are optional extensions to RFC XXXY [1].which one may use to These are optional extensions to RFC XXXY [JP2RTP].which one may use
make better use of JPEG 2000 features. These extensions are not to make better use of JPEG 2000 features. These extensions are not
required for any implementations of RFC XXXY[1]. required for any implementations of RFC XXXY[JP2RTP].
1.1. Description of the Mechanisms 1.1. Description of the Mechanisms
1.1.1. Main Header Compensation 1.1.1. Main Header Compensation
JPEG 2000 has a scalable coding scheme which allows for decompressing JPEG 2000 has a scalable coding scheme which allows for decompressing
truncated or partial data streams but only when the main header is truncated or partial data streams but only when the main header is
present. If the header is lost, the data is useless. With JPEG 2000 present. If the header is lost, the data is useless. With JPEG 2000
video coding, coding parameters between frames will rarely change and video coding, coding parameters between frames will rarely change and
previous headers may be used in newly received data which the header previous headers may be used in newly received data which the header
skipping to change at page 5, line 47 skipping to change at page 5, line 47
capability than others (i.e. TV conference vs. Mobile). The capability than others (i.e. TV conference vs. Mobile). The
respective clients can use the priority field to determine which respective clients can use the priority field to determine which
packets are vital for their own visual presentation. The sender will packets are vital for their own visual presentation. The sender will
have to do work on the priority field to optimally serve all the have to do work on the priority field to optimally serve all the
clients while only managing a single visual stream. clients while only managing a single visual stream.
1.3. Conventions Used in This Document 1.3. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119. [2]. document are to be interpreted as described in RFC2119. [RFC2119].
RFC-Editor Note: The RFC Editor is requested to replace all
occurences of RFC XXXY with the RFC number
draft-ietf-avt-rtp-jpeg2000 receives. At that time, please remove
this note.
2. Payload Format Enhanced Processing 2. Payload Format Enhanced Processing
2.1. Enhanced Processing Markers 2.1. Enhanced Processing Markers
This section of the document describes additional usage in the values This section of the document describes additional usage in the values
of mh_id and priority fields and interpretation which differ from RFC of mh_id and priority fields and interpretation which differ from RFC
XXXY [1]. Implementions of this document should follow RFC XXXY [1] XXXY [JP2RTP]. Implementations of this document should follow RFC
first then add additional header processing as described in this XXXY [JP2RTP] first then add additional header processing as
document. Implementations following this document are expected to described in this document. Implementations following this document
interoperate with implementations of [1] and this document as well. are expected to interoperate with implementations of [JP2RTP] and
this document as well.
The RTP payload header format for JPEG 2000 video stream is as The RTP payload header format for JPEG 2000 video stream is as
follows: follows:
0 1 2 3 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 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 | |tp |MHF|mh_id|T| priority | tile number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|reserved | fragment offset | |reserved | fragment offset |
skipping to change at page 9, line 9 skipping to change at page 9, line 9
The ordering can assign the different priority values in the same The ordering can assign the different priority values in the same
layer or the resolution level, which cannot do in the layer based layer or the resolution level, which cannot do in the layer based
ordering or resolution based ordering. ordering or resolution based ordering.
The difference from the packet number based ordering is that it does The difference from the packet number based ordering is that it does
not assign the value in the position level, which saves the priority not assign the value in the position level, which saves the priority
values usage. The position based priority signaling is not so values usage. The position based priority signaling is not so
important because a receiver could recognize the position by checking important because a receiver could recognize the position by checking
the tile number field. Therefore, the ordering would be useful. the tile number field. Therefore, the 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)
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: For example:
If the codestream is ordered in LRCP (Layer, Resolution, Component, If the codestream is ordered in LRCP (Layer, Resolution, Component,
Position) with 1 layer, 2 resolutions, 3 components, and 2 positions, Position) with 1 layer (L=1), 2 resolutions (R=2), 3 components
an example would have packet numbering as so: (C=3), and 2 positions, priority value should be (1 + cval + 3*rval +
6*lval). Then an example would have packet numbering as so:
All the packets in: All the packets in:
layer.........0 layer.........0
resolution....0 resolution....0
component.....0 component.....0
position......0 or 1 position......0 or 1
then the packet priority value : 1 then the packet priority value : 1
skipping to change at page 12, line 33 skipping to change at page 12, line 33
The receiver MAY use the mh_id and MAY retain the header for such The receiver MAY use the mh_id and MAY retain the header for such
compensation. compensation.
4.1. Sender Processing 4.1. Sender Processing
The sender MUST transmit RTP packets with the same mh_id value if the 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 encoder parameters of the current frame are the same as the previous
frame. The encoding parameters are the fixed information marker frame. The encoding parameters are the fixed information marker
segment (SIZ marker) and functional marker segments (COD, COC, RGN, segment (SIZ marker) and functional marker segments (COD, COC, RGN,
QCD, QCC, and POC) specified in JPEG 2000 Part 1 Annex A [3]. QCD, QCC, and POC) specified in JPEG 2000 Part 1 Annex A
[JPEG2000Pt_1].
An initial value of mh_id MUST be selected randomly between 1 and 7
for security reasons.
If the encode parameters changes, the sender transmitting RTP packets If the encode parameters changes, the sender transmitting RTP packets
MUST increment the mh_id value by one, but when mh_id value becomes MUST increment the mh_id value by one, but when mh_id value becomes
greater than 7, a sender MUST set mh_id value back to 1. greater than 7, a sender MUST set mh_id value back to 1.
4.2. Receiver Processing 4.2. Receiver Processing
When the receiver receives the main header completely, the RTP When the receiver receives the main header completely, the RTP
sequence number, the mh_id and main header should be saved. Only the sequence number, the mh_id and main header should be saved. Only the
last main header that was received completely SHOULD be saved. When last main header that was received completely SHOULD be saved. When
skipping to change at page 14, line 5 skipping to change at page 13, line 10
value. If the values match, decoding may be performed by using the value. If the values match, decoding may be performed by using the
previously saved main header. previously saved main header.
If the mh_id field is set to 0, the receiver MUST NOT save the main If the mh_id field is set to 0, the receiver MUST NOT save the main
header and MUST NOT compensate for lost headers. header and MUST NOT compensate for lost headers.
If the mh_id value changes, receivers SHOULD save the current header 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 and save the new mh_id value. The old saved header should be deleted
from storage. 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 5. Media Type Registration
This document extends the associated media type from RFC XXXY[1]. This document extends the associated media type "video/jpeg2000" from
Here are additional optional parameters. RFC XXXY [JP2RTP]. Here are additional optional parameters.
Additional optional parameters: Additional optional parameters:
mhc : Main Header Compensation. this option is used when sender mhc : Main Header Compensation. this option is used when sender
and/or receiver is utilizing the Main Header compensation and/or receiver is utilizing the Main Header compensation
technique as specified in this document. Acceptable values technique as specified in this document. Acceptable values
when using the Main Header compensation technique is "1", when using the Main Header compensation technique is "1",
otherwise, it should be "0". otherwise, it should be "0".
This is a list of options to be included when the sender or This is a list of options to be included when the sender or
skipping to change at page 15, line 16 skipping to change at page 15, line 16
6.1. Mapping of the optional parameters to SDP 6.1. Mapping of the optional parameters to SDP
The new optional parameters mhc and pt, if presented, MUST be The new optional parameters mhc and pt, if presented, MUST be
included in the "a=fmtp" line of SDP. These parameters are expressed 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 as a media type string, in the form of a semicolon separated list of
parameter=value pairs. parameter=value pairs.
6.2. Usage with the SDP Offer/Answer Model 6.2. Usage with the SDP Offer/Answer Model
In addition to SDP Offer/Answer section in RFC XXXY [1]: In addition to SDP Offer/Answer section in RFC XXXY [JP2RTP]:
When offering JPEG 2000 over RTP using SDP in an Offer/Answer model When offering JPEG 2000 over RTP using SDP in an Offer/Answer model
[4], the following rules and limitations apply: [RFC3264], the following rules and limitations apply:
o All parameters MUST have an acceptable value for that parameter. o All parameters MUST have an acceptable value for that parameter.
o All parameters MUST correspond to the parameters of the payload. o All parameters MUST correspond to the parameters of the payload.
o If the optional parameter "mhc" is used, it MUST appear in the 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 offer with value "1", and if accepted, it SHOULD appear in the
answer. answer.
o If the optional parameter "pt" is used, it MUST appear in the o If the optional parameter "pt" is used, it MUST appear in the
offer containing a complete comma-separated list indicating which offer containing a complete comma-separated list indicating which
priority table definitions the sender supprots. If accepted, it priority table definitions the sender supports. If accepted, it
SHOULD appear in the answer containing a single priority table SHOULD appear in the answer containing a single priority table
definition selected from the offer. definition selected from the offer.
o If the optional parameter "mhc" is used, it MUST appear in the 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 offer with value "1", and if accepted, it MUST appear in the
answer. If the optional parameter "pt" is used, it MUST appear in answer. If the optional parameter "pt" is used, it MUST appear in
the offer containing a complete comma-separated list indicating the offer containing a complete comma-separated list indicating
which priority table definitions the sender supports. If which priority table definitions the sender supports. If
accepted, it MUST appear in the answer containing a single accepted, it MUST appear in the answer containing a single
priority table definition selected from the offer. priority table definition selected from the offer.
skipping to change at page 19, line 7 skipping to change at page 19, line 7
s= s=
c=IN IP4 host.example c=IN IP4 host.example
t=0 0 t=0 0
m=video 49920 RTP/AVP 98 m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/27000000 a=rtpmap:98 jpeg2000/27000000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0; a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240 pt=layer;width=320;height=240
7. IANA Consideration 7. IANA Consideration
This document extends the associated media type from XXXY [1]. This document extends the associated media type "video/jpeg2000" from
Additional parameters are specified in Section 5 of this document. XXXY [JP2RTP]. Additional parameters are specified in Section 5 of
this document.
8. Security Consideration 8. Security Consideration
Please refer to section 6 of RFC XXXY [1] for Security Considerations Please refer to section 6 of RFC XXXY [JP2RTP] for Security
regarding this RTP format. The security issues regarding enhanced Considerations regarding this RTP format. The security issues
mechanisms presented in this document are discussed in the section. regarding enhanced mechanisms presented in this document are
discussed in the section.
The mh_id field can identify a maximum of 7 different main headers. The mh_id field can identify a maximum of 7 different main headers.
If severe packet loss (either random or intentionally introduced by If severe packet loss (either random or intentionally introduced by
an attacker) causes 6 successive updates to the main header to be an attacker) causes 6 successive updates to the main header to be
lost, the decoder will attempt decompression using an incorrect main lost, the decoder will attempt decompression using an incorrect main
header. Care should be taken to prevent implementation bugs with header. Even if the incorrect main header is passed, the standard
potential security consequences." 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 detect such an inconsistency.
9. Congestion Control 9. Congestion Control
Please refer to section 7 of RFC XXXY [1] for Congestion Control Please refer to section 7 of RFC XXXY [JP2RTP] for Congestion Control
regarding this RTP format. regarding this RTP format.
10. Normative References 10. Normative References
[1] Futemma, "RTP Payload Format for JPEG 2000 Video Streams", [JP2RTP] Futemma, Leung, and Itakura, "RTP Payload Format for JPEG
RFC XXXY, April 2007. 2000 Video Streams", I-D draft-ietf-avt-rtp-jpeg2000-20,
June 2008.
[2] Bradner, "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, "Key words for use in RFCs to Indicate
Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[3] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, [JPEG2000Pt_1]
"Information Technology - JPEG 2000 Image Coding System - Part ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800,
1: Core Coding System", December 2000. "Information Technology - JPEG 2000 Image Coding System -
Part 1: Core Coding System", December 2000.
[4] Rosenberg and Schulzrinne, "An Offer/Answer Model with Session [RFC3264] Rosenberg and Schulzrinne, "An Offer/Answer Model with
Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
Appendix A. Sample Headers in Detail Appendix A. Sample Headers in Detail
The following figures are sample RTP headers demonstrating values The following figures are sample RTP headers demonstrating values
that should appear in the RTP header. The packet priority is Packet that should appear in the RTP header. The packet priority is Packet
Number Based Priority. Number Based Priority.
For reference, the payload header as follows For reference, the payload header as follows
0 1 2 3 0 1 2 3
skipping to change at page 25, line 5 skipping to change at page 25, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 3 | 0 | | 0 | 0 | 1 |0| 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3210 | | 0 | 3210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A55D 8B73 3B25 25C7 B9EB .... 2FBE B153| |A55D 8B73 3B25 25C7 B9EB .... 2FBE B153|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Header Sample 1-4 (Fourth Packet) Figure 6: Header Sample 1-4 (Fourth Packet)
A.2. Smaple 2: Image with 4 tiles A.2. Sample 2: Image with 4 tiles
First Packet: This packet will have the whole main header. 210 bytes First Packet: This packet will have the whole main header. 210 bytes
0 1 2 3 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 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 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 44 skipping to change at line 1141
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 29 change blocks. 
60 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/