draft-ietf-avt-rtp-jpeg2000-beam-05.txt   draft-ietf-avt-rtp-jpeg2000-beam-06.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 5, 2007 Sony Expires: October 19, 2007 Sony
April 03, 2007 April 17, 2007
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-05 draft-ietf-avt-rtp-jpeg2000-beam-06
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 5, 2007. This Internet-Draft will expire on October 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo describes extended uses for payload header in RFC document: This memo describes extended uses for payload header in RFC document:
"RTP Payload Format for JPEG 2000 Video Streams." For better support "RTP Payload Format for JPEG 2000 Video Streams." For better support
of JPEG 2000 features such as scalability and includes a main header of JPEG 2000 features such as scalability and includes a main header
recovery method. recovery method.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Description of the Mechanisms . . . . . . . . . . . . . . 4 1.2. Description of the Mechanisms . . . . . . . . . . . . . . 4
1.2.1. Main Header Compensation . . . . . . . . . . . . . . . 4 1.2.1. Main Header Compensation . . . . . . . . . . . . . . . 4
1.2.2. Priority Table . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Priority Table . . . . . . . . . . . . . . . . . . . . 4
1.3. Motivations for Priority Field coding . . . . . . . . . . 5 1.3. Motivations for Priority Field coding . . . . . . . . . . 5
1.3.1. Scenario: Just enough resolution . . . . . . . . . . . 5 1.3.1. Scenario: Just enough resolution . . . . . . . . . . . 5
1.3.2. Scenario: Multiple clients, single source . . . . . . 5 1.3.2. Scenario: Multiple clients, single source . . . . . . 5
1.4. Conventions Used in This Document . . . . . . . . . . . . 6 1.4. Conventions Used in This Document . . . . . . . . . . . . 6
2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 7 2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 7
2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 7 2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 7
3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 9 3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 9
3.1. Pre-Defined Priority Mapping . . . . . . . . . . . . . . . 9 3.1. Packet Number Based Ordering . . . . . . . . . . . . . . . 9
3.1.1. Packet Number Based Ordering . . . . . . . . . . . . . 9 3.2. Progression Based Ordering . . . . . . . . . . . . . . . . 9
3.1.2. Progression Based Ordering . . . . . . . . . . . . . . 9 3.3. Layer Based Ordering . . . . . . . . . . . . . . . . . . . 10
3.1.3. Layer Based Ordering . . . . . . . . . . . . . . . . . 10 3.4. Resolution Based Ordering . . . . . . . . . . . . . . . . 10
3.1.4. Resolution Based Ordering . . . . . . . . . . . . . . 10 3.5. Component Based Ordering . . . . . . . . . . . . . . . . . 11
3.1.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. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 14
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Media Type Registration . . . . . . . . . . . . . . . . . 16 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 16
7.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 19 7.2. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 19
8. Usage with the SDP Offer/Answer Model . . . . . . . . . . . . 20 8. Usage with the SDP Offer/Answer Model . . . . . . . . . . . . 20
8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 8, line 30 skipping to change at page 8, line 30
codestream in importance. codestream in importance.
The lower the priority value is the higher the importance. A The lower the priority value is the higher the importance. A
priority value of 0 is the highest importance and 255 is the priority value of 0 is the highest importance and 255 is the
lowest importance. We define the priority value 0 as a special lowest importance. We define the priority value 0 as a special
priority value for the headers (the main header or tile-part priority value for the headers (the main header or tile-part
header). If any headers (the main header or tile-part header) are header). If any headers (the main header or tile-part header) are
packed into the RTP payload, the sender MUST set the priority packed into the RTP payload, the sender MUST set the priority
value to 0. value to 0.
Assignment of the values are described in Section 3 with pre- Assignment of the values are described in Section 3
defined table assignments in Section 3.1.
3. Priority Mapping Table 3. Priority Mapping Table
For the progression order, the priority value for each JPEG 2000 For the progression order, the priority value for each JPEG 2000
packet is given by the priority mapping table. packet is given by the priority mapping table.
3.1. Pre-Defined Priority Mapping
This document specify several commonly-used priority mapping tables, This document specify several commonly-used priority mapping tables,
pre-defined priority mapping tables: packet number based (default), pre-defined priority mapping tables: packet number based (default),
progression-based, layer-based, resolution-based, position-based, and progression-based, layer-based, resolution-based, position-based, and
component-based. component-based.
Packet number priority mapping is REQUIRED to be supported by clients Packet number priority mapping is REQUIRED to be supported by clients
implementing this specification. Other priority mapping tables implementing this specification. Other priority mapping tables
(progression, layer, resolution, and component based) are OPTIONAL to (progression, layer, resolution, and component based) are OPTIONAL to
implementations of this specification. implementations of this specification.
skipping to change at page 9, line 34 skipping to change at page 9, line 32
o When there is a header in the packet with a JPEG 2000 packet, the 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. sender MUST set the payload packet priority value to 0.
o When there are multiple JPEG 2000 packets in the same RTP payload o When there are multiple JPEG 2000 packets in the same RTP payload
packet, the sender MUST set the payload packet priority value to packet, the sender MUST set the payload packet priority value to
the lowest JPEG 2000 packet. (i.e. if JPEG 2000 packets with the lowest JPEG 2000 packet. (i.e. if JPEG 2000 packets with
priority: 5,6,7 are packed into a single payload, the priority priority: 5,6,7 are packed into a single payload, the priority
value will be 5.) value will be 5.)
3.1.1. Packet Number Based Ordering 3.1. Packet Number Based Ordering
Packet number based ordering assigns the payload packet priority Packet number based ordering assigns the payload packet priority
value from the "JPEG 2000 packet value". (note: JPEG 2000 codestreams value from the "JPEG 2000 packet value". (note: JPEG 2000 codestreams
are stored in units of packets and each packet has a value .) This are stored in units of packets and each packet has a value .) This
method is the default method for assigning priority value. All method is the default method for assigning priority value. All
implementations of this specification MUST support this method. implementations of this specification MUST support this method.
If the JPEG 2000 codestream packet value is greater than 255, the If the JPEG 2000 codestream packet value is greater than 255, the
sender MUST set the payload priority value to 255. sender MUST set the payload priority value to 255.
3.1.2. Progression Based Ordering 3.2. Progression Based Ordering
The sender will assign the payload packet priority value only based The sender will assign the payload packet priority value only based
on layer, resolution, and component ordering of the codestream. on layer, resolution, and component ordering of the codestream.
This is similar to the packet number based assignment but will not This is similar to the packet number based assignment but will not
take into account the precinct number or position in the JPEG 2000 take into account the precinct number or position in the JPEG 2000
codestream. codestream.
For example: For example:
skipping to change at page 10, line 34 skipping to change at page 10, line 32
then the packet priority value : 2 then the packet priority value : 2
All the packets in: All the packets in:
layer.........0 layer.........0
resolution....0 resolution....0
component.....2 component.....2
then the packet priority value : 3 then the packet priority value : 3
3.1.3. Layer Based Ordering 3.3. Layer Based Ordering
Layer-based priority mapping table simplifies the default mapping to Layer-based priority mapping table simplifies the default mapping to
just matching JPEG 2000 packets together from the same layer. just matching JPEG 2000 packets together from the same layer.
For example: For example:
All the packets in layer 0 : packet priority value : 1 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 1 : packet priority value : 2
All the packets in layer 2 : packet priority value : 3 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 n : packet priority value : n+1
All the packets in layer 255 : packet priority value : 255 All the packets in layer 255 : packet priority value : 255
3.1.4. Resolution Based Ordering 3.4. Resolution Based Ordering
Resolution-based priority mapping table is similar to the layer based Resolution-based priority mapping table is similar to the layer based
order but for JPEG 2000 packets of the same resolution order but for JPEG 2000 packets of the same resolution
For example: For example:
All the packets in resolution 0 : packet priority value : 1 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 1 : packet priority value : 2
All the packets in resolution 2 : packet priority value : 3 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 n : packet priority value : n+1
All the packets in resolution 255 : packet priority value : 255 All the packets in resolution 255 : packet priority value : 255
3.1.5. Component Based Ordering 3.5. Component Based Ordering
Component-based priority mapping table is mapping together JPEG 2000 Component-based priority mapping table is mapping together JPEG 2000
components of the same component components of the same component
For example: For example:
All the packets in component 0 : packet priority value : 1 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 1 : packet priority value : 2
All the packets in component 2 : packet priority value : 3 All the packets in component 2 : packet priority value : 3
... ...
skipping to change at page 19, line 40 skipping to change at page 19, line 40
o The OPTIONAL parameters "mhc" or "pt" MUST be included in the o The OPTIONAL parameters "mhc" or "pt" MUST be included in the
"a=fmtp" line of SDP. "a=fmtp" line of SDP.
These parameters are expressed as a media type string, in the form of These parameters are expressed as a media type string, in the form of
a semicolon separated list of parameter=value pairs. a semicolon separated list of parameter=value pairs.
Therefore, an example of media representation in SDP is as follows: Therefore, an example of media representation in SDP is as follows:
m=video 49170/2 RTP/AVP 98 m=video 49170/2 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000 a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc; pt=default; sampling=YCbCr- a=fmtp:98 mhc=1;pt=default; sampling=YCbCr-4:2:0; width=128;
4:2:0;width=128;height=128 height=128
8. Usage with the SDP Offer/Answer Model 8. 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 [1]:
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
[6], the following rules and limitations apply: [6], 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.
skipping to change at page 20, line 50 skipping to change at page 20, line 50
Offer/Answer example exchanges are provided. Offer/Answer example exchanges are provided.
8.1.1. Example 1 8.1.1. Example 1
Alice offers Main Header Compensation functionality, YCbCr 422 color Alice offers Main Header Compensation functionality, YCbCr 422 color
space, interlace image with 720-pixel width and 480-pixel height and space, interlace image with 720-pixel width and 480-pixel height and
several priority-table options (default, progression, layer, several priority-table options (default, progression, layer,
resolution, component) as below: resolution, component) as below:
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.exampl o=alice 2890844526 2890844526 IN IP4 host.example
s= s=
c=IN IP4 host.exampl c=IN IP4 host.example
t=0 0 t=0 0
m=video 49170 RTP/AVP 98 m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000 a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1;sampling= YCbCr-4:2:2;interlace=1 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2; interlace=1;
a=fmtp:98 pt=default, progression,layer, resolution, component; pt=default,progression,layer,resolution, component;
width=720; height=480 width=720; height=480
Bob accepts Main Header Compensation functionality, YCbCr-4:2:2 color Bob accepts Main Header Compensation functionality, YCbCr-4:2:2 color
space, interlace image, default mapping table and replies: space, interlace image, default mapping table and replies:
v=0 v=0
o=bob 2890844730 2890844731 IN IP4 host.example o=bob 2890844730 2890844731 IN IP4 host.example
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/90000 a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1;sampling= YCbCr-4:2:2;interlace=1 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2;interlace=1;
a=fmtp:98 mhc=1; pt=default; width=720;height=480 pt=default;width=720;height=480
8.1.2. Example 2 8.1.2. Example 2
Alice offers Main Header Compensation, YCbCr 420 color space, Alice offers Main Header Compensation, YCbCr 420 color space,
progressive image with 320-pixel width and 240-pixel height and layer progressive image with 320-pixel width and 240-pixel height and layer
priority-table options as below: priority-table options as below:
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 host.example o=alice 2890844526 2890844526 IN IP4 host.example
s= s=
c=IN IP4 host.example c=IN IP4 host.example
t=0 0 t=0 0
m=video 49170 RTP/AVP 98 m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000 a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1;sampling= YCbCr-4:2:0 a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
a=fmtp:98 pt=layer; width=320; height=240 pt=layer;width=320;height=240
Bob does not accept Main Header Compensation functionality but Bob does not accept Main Header Compensation functionality but
accepts YCbCr-4:2:0 color space,layer based priority mapping and accepts YCbCr-4:2:0 color space,layer based priority mapping and
replies: replies:
v=0 v=0
o=bob 2890844730 2890844731 IN IP4 host.example o=bob 2890844730 2890844731 IN IP4 host.example
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/90000 a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1;sampling= YCbCr-4:2:0 a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
a=fmtp:98 mhc=0; pt=layer;width=320;height=240
a=fmtp:98 pt=layer; width=320; height=240
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Futemma, "RTP Payload Format for JPEG 2000 Video Streams", [1] Futemma, "RTP Payload Format for JPEG 2000 Video Streams",
RFC XXXY, April 2007. RFC XXXY, April 2007.
[2] Bradner, "Key words for use in RFCs to Indicate Requirement [2] Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[3] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, [3] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800,
"Information Technology - JPEG 2000 Image Coding System - Part "Information Technology - JPEG 2000 Image Coding System - Part
1: Core Coding System", December 2000. 1: Core Coding System", December 2000.
[4] Schulzrinne, Casner, Frederick, and Jacobson, "RTP: A Transport [4] Schulzrinne, Casner, Frederick, and Jacobson, "RTP: A Transport
Protocol for Real Time Applications", RFC 3550, STD 64, Protocol for Real Time Applications", RFC 3550, STD 64,
July 2003. July 2003.
[5] Handley and Jacobson, "SDP: Session Description Protocol", [5] Handley and Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998. RFC 4566, July 2006.
[6] Rosenberg and Schulzrinne, "An Offer/Answer Model with Session [6] Rosenberg and Schulzrinne, "An Offer/Answer Model with Session
Description Protocol (SDP)", RFC 3264, June 2002. Description Protocol (SDP)", RFC 3264, June 2002.
[7] Freed and Klensin, "Media Type Specifications and Registration [7] Freed and Klensin, "Media Type Specifications and Registration
Procedures", RFC 4288, December 2005. Procedures", RFC 4288, December 2005.
[8] Casner and Hoschka, "MIME Type Registration of RTP Payload [8] Casner and Hoschka, "MIME Type Registration of RTP Payload
Formats", RFC 3555, July 2003. Formats", RFC 3555, July 2003.
9.2. Informative References 9.2. Informative References
[9] Perkins and Gharai, "RTP Payload Format for Uncompressed Video", [9] Perkins and Gharai, "RTP Payload Format for Uncompressed Video",
RFC 2246, September 2005. RFC 4175, September 2005.
Appendix A. Sample Headers in Detail Appendix A. Sample Headers in Detail
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 End of changes. 22 change blocks. 
35 lines changed or deleted 31 lines changed or added

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