[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-edwards-avt-rtp-jpeg2000) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 RFC 5371

INTERNET-DRAFT                                          Satoshi Futemma
draft-ietf-avt-rtp-jpeg2000-05.txt                     Eisaburo Itakura
                                                           Andrew Leung
                                                       Sony Corporation
                                                          July 16, 2004
                                              Expires: January 16, 2005





              RTP Payload Format for JPEG 2000 Video Streams


Status of this Memo


    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been
    disclosed, or will be disclosed, and any of which I become aware
    will be disclosed, in accordance with RFC 3668.


    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.


    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-Drafts
    as reference material or to cite them other than a "work in
    progress."


    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/1id-abstracts.html


    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html


Abstract


    This document describes an RTP payload format for transporting
    JPEG 2000 video streams, formed as a continuous series of JPEG
    2000 still images. The payload format presented in this document
    has three features: (1) Improvement of robustness to packet loss
    by intelligently fragmenting JPEG 2000 packet units, (2)
    Persistency of main header to minimize loss effect and maximize
    recovery and (3) Priority information field for scalable delivery
    from the same codestream. These will allow for the
    scalability and robustness of JPEG 2000 images to be maximized in
    video streaming applications.










Futemma, et al.                                                [Page 1]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004



Table of Contents


    1.  Introduction ..............................................  3
      1.1   Conventions Used in this Document .....................  6
    2.  JPEG 2000 Video Features ..................................  6
    3.  Payload Design ............................................  6
    4.  Payload Format ............................................  7
      4.1   RTP fixed header usage ................................  7
      4.2   RTP Payload Header Format .............................  7
    5.  RTP Packetization ......................................... 10
      5.1   Non-Intelligent Mode .................................. 10
      5.2   Intelligent mode  ..................................... 11
    6.  Scalable Delivery and Priority field ...................... 12
      6.1   Priority Mapping Table ................................ 12
      6.1.1   Default Priority Mapping ............................ 13
      6.1.2   User-defined Priority Table ......................... 13
      6.2   Sender Action ......................................... 13
      6.3   Receiver Action ....................................... 14
    7.  JPEG 2000 Main Header Compensation Scheme ................. 14
      7.1   Sender Processing ..................................... 14
      7.2   Receiver Processing ................................... 15
    8.  Security Consideration .................................... 15
    9.  IANA Consideration ........................................ 16
      9.1   MIME Registration ..................................... 16
      9.2   SDP Parameters ........................................ 17
    10.  Intellectual Property Right Statement .................... 17
    11.  Informative Appendix  .................................... 17
      11.1   Recommended Practices ................................ 18
      11.2   Sample Headers in Detail ............................. 18
      11.2.1   Sample 1: Image with single tile ................... 19
      11.2.2   Sample 2: Image with 4 tiles ....................... 20
      11.2.3   Sample 3: Packing multiple tiles in single payload . 22
      11.2.4   Sample 4: Non-intelligent packing .................. 24
    13.  References  .............................................. 25
    14.  Authors' Addresses ....................................... 25
    15.  Copyright Statement ...................................... 25



















Futemma, et al.                                                [Page 2]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


1. Introduction


    This document specifies a payload format for JPEG 2000 video
    streams over Real-time Transport Protocol (RTP). JPEG 2000 is an
    ISO/IEC International Standard developed for next-generation
    still image encoding. Its basic encoding technology is described
    in [1].


    Part 3 of the JPEG 2000 standard defines Motion JPEG 2000[6].
    However, Part 3 defines only the file format but not the
    transmission format for streaming on the Internet. It is necessary
    to define an RTP format for JPEG 2000 video streams.


    JPEG 2000 supports many powerful features that are not supported
    in the current JPEG standard[1][7].


        o Higher compression efficiency than JPEG with less visual
          loss especially at extreme compression ratios.


        o A single codestream that offers both lossy and superior
          lossless compression.


        o Robust transmission over noisy environments.


        o Progressive transmission by pixel accuracy (SNR scalability)
          and/or resolution.


        o Random codestream access and processing.


    The JPEG 2000 algorithm is briefly explained below. Fig. 1
    shows a block diagram of JPEG 2000 encoding method.



                                                     +-----+
                                                     | ROI |
                                                     +-----+
                                                        |
                                                        V
                   +----------+   +----------+   +------------+
                   |DC, comp. |   | Wavelet  |   |            |
    raw image  ==> |transform-|==>|transform-|==>|Quantization|==+
                   |  ation   |   |  ation   |   |            |  |
                   +----------+   +----------+   +------------+  |
                                                                 |
                  +-----------+   +----------+   +------------+  |
                  |           |   |          |   |            |  |
     JPEG 2000 <==| Data      |<==|Arithmetic|<==|Coefficient |<=+
     codestream   | Ordering  |   |  coding  |   |bit modeling|
                  +-----------+   +----------+   +------------+


                Fig. 1: A block diagram of the JPEG 2000 encoder



    Each color component or tile is transformed into wavelet


Futemma, et al.                                                [Page 3]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    coefficients. The component or tile is sub-sampled into various
    levels usually vertically and horizontally from high frequencies
    (which contains all the sharp details) to the low frequencies
    (which contains all the flat areas.)  Quantization is performed on
    the coefficients within each sub-band. The wavelet coefficient is
    divided by the quantization step size and the result is truncated.
    After quantization, code blocks are formed from within the
    precincts within the tiles. (Precincts are a finer separation than
    tiles and code blocks are the smallest separation of the image
    data.) Entropy coding is performed within each code block and
    arithmetically encoded by bit plane. After the coefficients of
    all code blocks have been coded into a short bit stream, a header
    is added turning it into a packet, which we call a "jp2-packet" to
    distinguish between it and a network packet in this document. The
    header has all the information needed to decompress the packet
    into code blocks.


    The standard has four ways to transmit and decode a compressed
    image: by resolution, quality, position, or component. Packets
    can be ordered in any way to maximize these features.


    This is only to serve as an introduction to JPEG 2000 and to aid
    in understanding the rest of this document. Further details of
    the encoder can be found in various texts on JPEG 2000 [1].


    To decompress a JPEG 2000 codestream, one would follow the
    reverse order of the encoding order, minus the quantization step.
    JPEG 2000 standard allows one encoded image to be decoded at
    different resolutions, bit-rates, with different regions without
    decoding any more than the minimum necessary amount of data.
    It is outside the scope of this document to describe in detail
    this procedure. Please refer to various JPEG 2000 texts for
    further details [1].


    As shown in Fig. 2, a JPEG 2000 codestream is structured from the
    main header beginning with the SOC marker, one or more tiles, and
    the EOC marker to indicate the end of the codestream. Each tile
    consists of a tile-part header that starts with the SOT marker and
    ends with a SOD marker, and bitstream (a series of jp2-packet).



          +--  +------------+
    Main  |    |    SOC     |  Required as the first marker.
    header|    +------------+
          |    |    main    |  Main header marker segments
          +--  +------------+
          |    |    SOT     |  Required at the beginning of each
    Tile- |    +------------+    tile-part header.
    part  |    |   T0,TP0   |  Tile 0, tile-part 0 header marker
    header|    +------------+    segments
          |    |    SOD     |  Required at the end of each tile-part
          +--  +------------+    header
               | bitstream  |  Tile-part bitstream
          +--  +------------+


Futemma, et al.                                                [Page 4]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


          |    |    SOT     |
    Tile- |    +------------+
    part  |    |   T1,TP0   |
    header|    +------------+
          |    |    SOD     |
          +--  +------------+
               | bit stream |
               +------------+
               |    EOC     |  Required as the last marker in the code
               +------------+  stream


                Fig. 2: A construction of the JPEG 2000 codestream



1.1 Conventions Used in this Document


    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    in this document are to be interpreted as described in RFC2119
    [2].



2. JPEG 2000 Video Features


    JPEG 2000 video streams are formed as a continuous series of JPEG
    2000 still images. The previously described features of JPEG 2000
    can be used effectively in streaming applications. A JPEG 2000
    video stream has the following merits:


    - In JPEG 2000 the SNR quality is improved dramatically over JPEG
      at low bit rates.


    - This is a full intra frame format- each frame is independently
      compressed - and therefore has a low encoding and decoding delay.


    - JPEG 2000 has flexible and accurate rate control. This is
      suitable for traffic control and congestion control during
      network transmission.


    - JPEG 2000 can provide its own codestream error resilience
      markers to aid in codestream recovery outside of other network
      recovery techniques.



3. Payload Design


    To provide a payload format that exploits JPEG 2000 video stream,
    described in the previous section, the following must be taken
    into consideration:


    - Provisions for packet loss


        On the Internet, 5% packet loss is common and this value may
        become 20% or more. To split JPEG 2000 video streams into RTP


Futemma, et al.                                                [Page 5]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


        packets, efficient packetization of the code stream is
        required to minimize problems in decoding due to missing
        code-blocks. If the main header is lost in transmission, the
        image cannot be decoded. A system to compensate for the loss
        of the main header is required.


    - A packetizing scheme that maximizes JPEG 2000 functionality


        A packetizing scheme so that an image can be progressively
        transmitted and reconstructed progressively by the receiver
        using JPEG 2000 functionality would be very powerful. It
        would allow for maximizing performance over various network
        conditions and variations in computing resources of clients.



4. Payload Format


4.1 RTP fixed header usage


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|X|  CC   |M|     PT      |       sequence number         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           timestamp                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           synchronization source (SSRC) identifier            |
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    |            contributing source (CSRC) identifiers             |
    |                             ....                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    For each RTP packet, the RTP fixed header is followed by the JPEG
    2000 payload header, which is followed by JPEG 2000 codestream.
    The RTP header fields that have a meaning specific to a JPEG
    2000 video stream are described as follows:


    Marker bit (M): The marker bit of the RTP fixed header MUST be set
      to 1 on the last RTP packet of a video frame, and otherwise, it
      MUST be 0. When transmission is performed by multiple RTP
      sessions, this bit is 1 in the last packet of the frame in each
      session.


    Payload type (PT): The payload type is dynamically assigned by
      means outside the scope of this document. A payload type in the
      dynamic range shall be chosen by means of an out of band
      signaling protocol (e.g., RTSP, SIP, etc.)


    Timestamp: The RTP timestamp is in units of 90 kHz. The same
      timestamp must appear in each fragment of a given frame. When a
      JPEG 2000 image is interlaced, the odd field and the
      corresponding even field MUST have the same timestamps. The
      initial value of the timestamp is random to make known plaintext


Futemma, et al.                                                [Page 6]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


      attacks on encryption more difficult.


4.2 RTP Payload Header Format


    The RTP payload header format for JPEG 2000 video stream is as
    follows:


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|E|MHF|mh_id|T|     priority  |           tile number         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | reserved  |tp |             fragment offset                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Fig. 3:  RTP payload header format for JPEG 2000



    X : 1 bit


        This bit is reserved for future use. This MUST be set to 0.


    E : 1 bit


        Enable bit flag. If this bit is set to 1, it means
        "intelligent packetization" described in Section 5.2. If E
        bit is 0, it means non-intelligent packetization" and a
        receiver MUST ignore any other payload header information
        other than fragment offset.


    MHF (Main Header Flag) : 2 bits


        MHF indicates whether a header or piece of a header is in the
        RTP packet. If there is no header, MHF has a value of 0.  If
        there is just a part of a fragmented header, MHF has a value
        of 2. If the whole header or last part of a fragmented header
        in the packet, MHF has a value of 3.  MHF with a value 1 is
        reserved for future use.


        +---+-------------------------------------------------------+
        |MHF| Description                                           |
        +---+-------------------------------------------------------+
        | 0 | no main header in the payload.                        |
        | 1 | reserved for future use.                              |
        | 2 | the fragmented main header (not last part) is packed. |
        | 3 | a whole main header or the last part of the           |
        |   | fragmented main header is packed.                     |
        +---+-------------------------------------------------------+
                      Table 1: MHF usage values


    mh_id : 3 bits


        Main header identification value. This is used for JPEG 2000
        main header recovery. The same mh_id value is used as long as


Futemma, et al.                                                [Page 7]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


        the coding parameters described in the main header remain
        unchanged. The initial value of mh_id is random, except for
        0. Mh_id value MUST increase by 1 every time a new main header
        is transmitted. Once the mh_id value is greater than 7, it
        rolls over and start at 1 again. When mh_id is 0, it has
        special usage for the receiver. This special usage is
        described in Section 7 of this document.


    T (Tile field invalidation flag) : 1 bit


        T bit indicates whether the tile number field is invalid or
        not. A sender MUST set T bit to 1 when the tile number field
        is invalid.


        There are two cases where the tile number field is invalid.
        When an RTP packet holds only the main header.  In this case,
        a sender cannot set any number in the tile number field
        because no JPEG 2000 tile-part bitstream is included in the
        RTP packet.


        The other case is that multiple tile-part bitstreams are
        packed together in an RTP packet. In general, it is advisable
        to pack only one tile bitstream in an RTP packet, but if the
        tile-part length is small, it is more efficient to pack
        together multiple tile-parts in one RTP packet. In this case
        it is meaningless to assign a number.


    priority : 8 bits


        The priority field indicates the importance of the JPEG 2000
        packet included in the payload. Typically, a higher priority
        is set in the packets containing JPEG 2000 packets containing
        the lower sub-bands.


        Special values of priority:

        0 :       This is reserved for payload which contain a header
                  (main or tile part header.) This is considered the
                  highest importance


        1 to 255 : These values decrease in importance as the values
                   increase. (i.e. 1 is more important than 2)


    tile number : 16 bits


        This field shows the tile number that a bitstream belongs to
        only when the T bit is 0. A receiver can easily decode an
        arbitrary tile by checking this field. If T bit is set to 1, a
        receiver MUST ignore this field.

    tp (type) : 2 bits


        This field indicates how a JPEG 2000 image is scanned (meaning
        - progressive or interlace).


Futemma, et al.                                                [Page 8]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004



        0: An image is progressively scanned. On a computer monitor,
           it should be displayed as-is at the specified width and
           height in the JPEG 2000 main header.


        1: An image is the odd field of an interlaced video signal.
           The height specified in the JPEG 2000 main header is half
           of the height of the entire displayed image. In a receiver,
           an odd field should be de-interlaced with the even field
           following it so that lines from each image are displayed
           alternately.


        2: An image is the even field of an interlaced video signal.


        3: An image is a single field from an interlaced video signal,
           intended to be displayed full frame as if it were received
           as both the odd & even field of the frame. On a computer
           monitor, each line in the image should be displayed twice,
           doubling the height of the image.

    fragment offset : 24 bits


        This value must be set to the byte offset in the JPEG 2000
        data stream contained in this RTP packet.


        To perform scalable video delivery by using multiple RTP
        sessions, the offset value from the first byte of the same
        frame is set for fragment offset. It is possible, to scalably
        delivery video using multiple RTP sessions, the fragment
        offset may not start from 0 in some RTP sessions even if the
        packet is the first one received.



5. RTP Packetization


    Two packetization modes can be used for a JPEG 2000 RTP packet:
    non-intelligent mode and intelligent mode.


    A sender is allowed to packetize the JPEG 2000 codestream in
    either mode, but MUST not change the mode within the same RTP
    session. A sender may implement only one mode, but a receiver MUST
    interpret both modes.


5.1 Non-Intelligent Mode


    Non-intelligent mode is prepared for a thin sender, which has
    insufficient CPU resources to parse the JPEG 2000 codestream
    syntax and to partition the codestream per jp2-packet.


    In this mode, a sender segments the JPEG 2000 codestream along
    arbitrary lengths into RTP packets, and E bit flag in the payload
    header MUST be set to 0.


    Typically, a sender fragments a JPEG 2000 codestream in a fixed


Futemma, et al.                                                [Page 9]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    length. An example of this packetization is below:


    +------+-------+---------------------------------------+
    |RTP   |payload| JPEG 2000 codestream fragment #1      |
    |header|header |                                       |
    +------+-------+---------------------------------------+
    +------+-------+---------------------------------------+
    |RTP   |payload| JPEG 2000 codestream fragment #2      |
    |header|header |                                       |
    +------+-------+---------------------------------------+
                     ...
    +------+-------+----------------------------------+
    |RTP   |payload| JPEG 2000 codestream fragment #N |
    |header|header |                                  |
    +------+-------+----------------------------------+


        Fig. 4: Example of non-intelligent mode packetization



    A receiver recognizes that the codestream is packetized in
    non-intelligent mode by checking E bit flag, then RTP packets with
    same RTP timestamps are de-packetized to the JPEG 2000 codestream
    using fragment offset in the payload header.
    In this mode, only fragment offset field is interpreted and all
    other fields are ignored.

    If a receiver receives RTP packets each of which has different
    packetization modes, the receiver should ignore both RTP packets.


5.2 Intelligent mode


    In Intelligent mode, the JPEG 2000 codestream is packetized by
    "packetization unit" we introduce newly. A packetization unit is
    defined as either a JPEG 2000 main header, a tile-part header, or
    a jp2-packet.


    First, a sender divides the JPEG 2000 codestream into
    packetization units by parsing the codestream or by getting
    information from the encoder, and packs the packetization units
    into RTP packets. A sender can put an arbitrary number of
    packetization units into an RTP packet, but it MUST preserve the
    codestream order. An example of this kind of RTP packet format is
    below:


    +------+-------+---------------+---------------+
    |RTP   |payload| packetization | packetization |
    |header|header | unit          | unit          |
    +------+-------+---------------+---------------+


        Fig. 5 An Example of RTP packet format with multiple
               packetization units



    If a packetization unit with headers is larger than the MTU size,


Futemma, et al.                                               [Page 10]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    it may be fragmented. To pack a fragmented packetization unit, the
    fragmented unit MUST NOT be packed with the succeeding
    packetization unit within the same RTP packet. An example of this
    kind of RTP packet format is below:


    +------+-------+---------------------------------------+
    |RTP   |payload| packetization unit fragment #1        |
    |header|header |                                       |
    +------+-------+---------------------------------------+
    +------+-------+---------------------------------------+
    |RTP   |payload| packetization unit fragment #2        |
    |header|header |                                       |
    +------+-------+---------------------------------------+
                     ...
    +------+-------+--------------------------------+
    |RTP   |payload| packetization unit fragment #N |
    |header|header |                                |
    +------+-------+--------------------------------+


        Fig. 6 An Example of RTP packet format with a fragmented
               packetization unit



6. Scalable Delivery and Priority field


    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.


    Jp2-packets contain all compressed image data from a specific:
    layer, component, resolution level, and/or precinct. The order in
    which these jp2-packets are found in the codestream is called the
    "progression order". The ordering of the jp2-packets can progress
    along four axes: layer, component, resolution level and precinct.


    The lower the priority value is the higher priority. In other
    words, the priority value 0 is the highest priority and 255 is the
    lowest priority. We define the priority value 0 as a special
    priority value for the headers (the main header or tile-part
    header). When any headers (the main header or tile-part header)
    are packed into the RTP packet, the sender MUST set the priority
    value to 0.


6.1 Priority Mapping Table


    For the progression order, the priority value for each jp2-packet
    is given by the priority mapping table. There are two types of
    priority mapping: default priority mapping and user-defined
    priority mapping. In principle, the priority mapping table is


Futemma, et al.                                               [Page 11]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    negotiated between the sender and the receiver through external
    protocols (such as: RTSP, SIP, etc), which is not within the scope
    of this document. However, in some environments such as a
    multicast video-conference environment, it might be difficult to
    negotiate the priority-mapping table between senders and
    receivers. We define the default priority mapping for such a
    situation. The receiver interprets the priority as a user-defined
    priority value only when the priority-mapping table has been
    negotiated and otherwise the receiver interprets as the default
    priority.


6.1.1 Default Priority Mapping


    The JPEG 2000 codestream is ordered in a progression order and
    in the most cases the fore-most jp2-packets are more important
    than the latter ones.


    With the default priority mapping, the priority value may be
    defined as the jp2-packet sequence number, in which the first
    jp2-packet in a tile MUST be assigned the value 1. For every
    successive packet this number is incremented by one. When the
    maximum value (=255) is reached, the number remains at 255. A
    jp2-packet sequence number is also "hinted" from Nsop of SOP
    marker segment (Annex A.8.1 [1]) in the JPEG 2000 codestream.

6.1.2 User-defined Priority Table


    The user-defined priority table is freely defined by users, but
    priority value 0 MUST be used for packets with headers (the main
    header and tile-part headers).


    For example, in the LRCP order codestream with 3 layers, 3
    resolutions and 3 components, the user-defined priority table
    based on pixel accuracy can be defined as below. 3 level of
    priorities are defined in the below example.


        priority 1: Layer 0
        priority 2: Layer 1
        priority 3: Layer 2


    As another example, the resolution-based priority table can be
    defined as below:


        priority 1: Resolution 0 (1/16 size)
        priority 2: Resolution 1 (a quarter size)
        priority 3: Resolution 2 (full size)


    To change the priority-mapping table, a new priority-mapping table
    must be sent from the sender to the receiver as needed.


6.2 Sender Action


    A priority value is given in accordance with the priority mapping
    table. If multiple jp2-packets are packed into the same RTP


Futemma, et al.                                               [Page 12]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    packet, the lowest priority value is set for the priority field.


    A sender can transmit each priority level packets using separate
    multiple RTP sessions. For example, in layered multicast a sender
    can transmit each priority through each multicast group.


6.3 Receiver Action


    The image architecture provides for the efficient delivery of
    image data in many applications such as client/server
    applications. The receiver should decode packets above a certain
    priority to obtain maximum performance.



7. JPEG 2000 Main Header Compensation Scheme


    The JPEG 2000 main header has various encoding parameters. A
    decoder decodes the JPEG 2000 codestream by using the parameters
    described in the JPEG 2000 main header. If an RTP packet is lost
    with the JPEG 2000 main header, the corresponding JPEG 2000
    codestream cannot be decoded, even if all of the following RTP
    packets are successfully received.


    A recovery of the main header that has been lost is very simple
    with this procedure. In the case of JPEG 2000 video, it is common
    that encode parameters will not vary greatly between each
    successive frame. Even if the RTP packet, including the main
    header, of a frame has been dropped, decoding may be performed by
    using the main header with the same mh_id as the current packet.


    The mh_id field of the payload header is used to recognize whether
    the encoding parameters of the main header are the same as the
    previous frame. The same value is set in mh_id of the RTP packet
    in the same frame. Mh_id and encode parameters are not associated
    with each other as 1:1 but they are used to recognize whether the
    encode parameters of the previous frame are the same or not in the
    event of lost headers.


    The mh_id field value SHOULD be saved from the previous frames to
    be used to recover the current frame's main header, if lost. 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
    SHOULD be used to decode the current frame, in case of a lost
    header.


    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.


7.1 Sender Processing


    The sender must transmit RTP packets with the same mh_id value


Futemma, et al.                                               [Page 13]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    unless the encoder parameters are different from the previous
    frame. The encode 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 [1].
    If the encode parameters changes, the sender transmitting RTP
    packets MUST increment the mh_id value by one.


    If the mh_id field is set to 0, the receiver MUST not save the
    main header and MUST NOT compensate for lost headers using the
    above method.


7.2 Receiver Processing


    When the receiver receives the main header correctly: the RTP
    sequence number and the mh_id and main header should be saved
    except when the mh_id value is 0. Only the last main header that
    was received correctly SHOULD be saved.


    When the main header is not received, the receiver compares the
    current mh_id value (this mh_id can be known by receiving at least
    one RTP packet) with the saved mh_id value. When the values are
    the same, decoding may be performed by using the saved main
    header.



8. Security Consideration


    RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specifications[3]. This implies that confidentiality of the media
    streams is achieved by encryption. Data compression used with this
    payload format is applied end-to-end, encryption may be performed
    on the compressed data so there is no conflict between the two
    operations.


    A potential denial-of-service threat exists for data encodings
    using compression techniques that have non-uniform receiver-end
    computational load.  The attacker can inject pathological
    datagrams into the stream which are complex to decode and cause
    the receiver to be overloaded. The usage of authentication of at
    least the RTP packet is RECOMMENDED, for example with SRTP [8].


    If QoS enhanced service is used, RTP receivers SHOULD monitor
    packet loss to ensure that the service that was requested is
    actually being delivered. If it is not, then they SHOULD assume
    that they are receiving best-effort service and behave accordingly.

    If best-effort service is being used, users of this payload format
    MUST monitor packet loss to ensure that the packet loss rate is
    within acceptable parameters. Packet loss is considered
    acceptable if a TCP flow across the same network path,
    experiencing the same network conditions, would achieve an average
    throughput, measured on a reasonable timescale, that is not less
    than the RTP flow is achieving. This condition can be satisfied


Futemma, et al.                                               [Page 14]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    by implementing congestion control mechanisms to adapt the
    transmission rate (or the number of layers subscribed for a
    layered multicast session), or by arranging for a receiver to
    leave the session if the loss rate is unacceptably high.


    As with any IP-based protocol, in some circumstances a receiver
    may be overloaded simply by receiving too many packets, either
    desired or undesired. Network-layer authentication may be used to
    discard packets from undesired sources, but the processing cost of
    the authentication itself may be too high. In a multicast
    environment, pruning of specific sources may be implemented in
    future versions of IGMP [9] and in multicast routing protocols to
    allow a receiver to select which sources are allowed to reach it.



9. IANA Consideration


9.1 MIME Registration


    This document defines a new RTP payload name and associated MIME
    type, jpeg2000. The MIME registration form for JPEG 2000 video
    stream is enclosed below:


    MIME media type name:      video


    MIME subtype name:         jpeg2000


    Required parameters:     none


    Optional parameters:     none


    Encoding considerations:
        JPEG 2000 video stream may be transmitted with RTP as
    specified in this document.


    Security considerations: see section 9 of RFC XXXY.


    Interoperability considerations:
        JPEG 2000 video stream is a sequence of JPEG 2000 still
        images. An implementation in compliant with [1] can decode and
        attempt to display the encoded JPEG 2000 video stream.


    Published specification: ISO/IEC ITU 15444-1


    Applications which use this media type:
        video streaming and communication


    Additional information: none


    Magic number(s): none


    File extension(s): none


    Macintosh File Type Code(s): none


Futemma, et al.                                               [Page 15]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004



    Person & email address to contact for further information:
        Eisaburo Itakura, Satoshi Futemma
        Email: {itakura|satosi-f}@sm.sony.co.jp


    Intended usage: COMMON

    Author/Change controller:
        Eisaburo Itakura, Satoshi Futemma
        Email: {itakura|satosi-f}@sm.sony.co.jp


9.2 SDP Parameters


    The MIME media type video/jpeg2000 string is mapped to fields in
    the Session Description Protocol (SDP) [4] as follows:


    o The media name in the "m=" line of SDP MUST be video.


    o The encoding name in the "a=rtpmap" line of SDP MUSE be jpeg2000
      (the MIME subtype).


    o The clock rate in the "a=rtpmap" line MUST be 90000.


    Therefore, an example of media representation in SDP is as
    follows:


        m=video 49170/2 RTP/AVP 98
        a=rtpmap:98 jpeg2000/90000



10. Intellectual Property Right Statement


    The IETF takes no position regarding the validity or scope of any
    intellectual property 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; neither does it represent
    that it has made any effort to identify any such rights.
    Information on the IETF's procedures with respect to rights in
    standards-track and standards-related documentation can be found
    in BCP-11. Copies of claims of rights made available for
    publication 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 implementors
    or users of this specification can be obtained from the IETF
    Secretariat.


    The IETF invites any interested party to bring to its attention
    any copyrights, patents or patent applications, or other
    proprietary rights which may cover technology that may be required
    to practice this standard. Please address the information to the
    IETF Executive Director.


    The IETF has been notified of intellectual property rights claimed


Futemma, et al.                                               [Page 16]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    in regard to some or all of the specification contained in this
    document. For more information consult the online list of claimed
    rights.



11. Informative Appendix


11.1 Recommended Practices


    As the JPEG 2000 coding standard is highly flexible, many
    different but compliant data streams can be produced and still be
    labeled as a JPEG 2000 data stream.


    The following is a set of recommendations set forth from our
    experience in developing JPEG 2000 and this payload
    specification. Implementations of this standard must handle all
    possibilities mentioned in this specification. The following is a
    listing of items an implementation could optimize.


    Error Resilience Markers


        The use of error resilience markers in the JPEG 2000 data
        stream is highly recommended in all situations. Error
        recovery with these markers is helpful to the decoder and save
        external resources. Markers such as: RESET, RESTART, and
        ERTERM.


    YPbPr Color space


        The YPbPr color space provides the greatest amount of
        compression in color with respect to the human visual
        system. When used with JPEG 2000, the usage of this color
        space can provide excellent visual results at extreme bit
        rates.


    Progression Ordering


        JPEG 2000 offers many different ways to order the final code
        stream to optimize the transfer with the presentation. The
        most useful ordering in our usage cases have been for layer
        progression and resolution progression ordering.


    Tiling and Packets


        JPEG 2000 packets are formed regardless of the encoding
        method. The encoder has little control over the size of these
        JPEG 2000 packets as they maybe large or small.


        Tiling splits the image up into smaller areas and each are
        encoded separately. With tiles, the JPEG 2000 packet sizes are
        also reduced. When using tiling, almost all JPEG 2000 packet
        sizes are an acceptable size (i.e. smaller than the MTU size
        of most networks.)



Futemma, et al.                                               [Page 17]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


11.2 Sample Headers in Detail


    This section details payload headers for reference.


    For reference, the payload header is:


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|E|MHF|mh_id|T|    priority   |           tile number         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | reserved  |tp |             fragment offset                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    For the first packet with the main header, this is what it will
    look like.


    Assumptions:
      - MTU is 1500bytes (ethernet)


11.2.1 Sample 1: Image with single tile


    Coding parameters:
      single tile
      number of components: 3
      number of decomposition levels: 5  (6 resolutions)
      number of layers: 1
      the number of jp2-packets: 18 (= 3 x (5+1) x 1)


    Packetization parameters:
      intelligent mode
      priority mapping table: default



    First Packet:
        This packet will have the whole main header
        Payload size: 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|1| 3 |  5  |1|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    0                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF4F FF51 002F 000 ....                                        |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |    RTP padding                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Second Packet:
        This packet will have a tile header and the first tile part


Futemma, et al.                                               [Page 18]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


        LLband.
        jp2-packet seq.: 1-10
        Payload size: 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|1| 0 |  5  |0|       1       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    210                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF90 000A 0000 0000 0DB3 0001 FF93 ...                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Third Packet:
        This packet will have the next part in the tile, no tile
        header.
        jp2-packet seq.: 11-15
        Payload size: 1420 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 |  5  |0|       11      |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    1610                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF91 0004 000A E841 4526 4556 9850 C2EA    ....                |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Fourth Packet:
        Last packet for the image.
        jp2-packet seq.: 16-18
        Payload size: 470 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 |  5  |0|       16      |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    2980                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF91 0004 000F A55D 8B73 3B25 25C7 B9EB ....                   |
    |                                                               |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                2FBE B153 FFD9 |    RTP padding                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



11.2.2 Sample 2: Image with 4 tiles


Futemma, et al.                                               [Page 19]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004



    Coding parameters:
      number of tiles: 4
      number of components: 3
      number of decomposition levels: 5
      number of layers: 1


    Packetization parameters:
      intelligent mode


    First Packet:
        This packet will have the whole main header.
        Payload size: 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|1| 3 |  1  |1|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    0                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF4F FF51 002F 000 ....                                        |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |    RTP padding                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Second Packet:
        This packet will have a first tile part (tile number = 0).
        Payload size: 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|1| 0 |  1  |0|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    210                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF90 000A 0000 0000 0578 0001 FF93    ....                     |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Third Packet:
        This packet will have a second tile part (tile number = 1)
        Payload size: 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|1| 0 |  1  |0|       0       |                1              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    1610                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF90 000A 0001 0000 058F 0001 FF93    ....                     |
    |                                                               |
    |                                                 +-+-+-+-+-+-+-+
    |                                                 | RTP padding |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Futemma, et al.                                               [Page 20]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004



    Fourth Packet:
        This packet will have a third tile part (tile number = 2)
        Payload size: 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|1| 0 |  1  |0|       0       |                2              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    3033                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF90 000A 0002 0000 054B 0001 FF93    ....                     |
    |                                                               |
    |                                                 +-+-+-+-+-+-+-+
    |                                                 | RTP padding |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    Fifth Packet:
        This packet will have a fourth tile part (tile number = 3)
        Payload size: 1288 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       |                3              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    4388                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF90 000A 0003 0000 050A 0001 FF93    ....                     |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



11.2.3 Sample 3: Packing multiple tiles in single payload
                 fragmented main header (No header compensation)


    Coding parameters:
      number of tiles: 3


    Packetization parameters:
      fragmented main header
      no header compensation (mh_id = 0)
      packing multiple tiles in single RTP packet (tile #0 and #1)




    First Packet:
        This packet will have the first part of the main header.
        Payload size: 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| 2 |  0  |1|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Futemma, et al.                                               [Page 21]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    |     0     | 0 |                    0                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF4F FF51 002F 0000 ...                                        |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |    RTP padding                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Second Packet:
        This packet has the second and the last part of the main
        header.
        Paylaod size: 100 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| 3 |  0  |1|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    110                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF64 00FF ....                                                 |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Third Packet:
        This packet has two tiles, 0 and 1
        Paylaod size: 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|1| 0 |  0  |1|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    210                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF90 000A 0000 0000 02BD 0001 FF93    ... (Tile #0 bitstream)  |
    |                                                               |
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               | FF90 000A 0001 0000 02B6 0001 FF93 ...        |
    +-+-+-+-+-+-+-+-+ (Tile #1 bitstream)                           |
    |                                                               |
    |                                                 +-+-+-+-+-+-+-+
    |                                                 | RTP padding |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Fourth Packet:
        This packet has one tile, 2
        Paylaod size: 1392 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Futemma, et al.                                               [Page 22]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    |0|1| 0 |  0  |0|       0       |                2              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    1605                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF90 000A 0002 0000 0570 0001 FF93    .... (Tile #2 bitstream) |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



11.2.4 Sample 4: Non-intelligent packing



    First Packet:
        This packet has the first part of the image, as much that will
        fit in the payload
        Paylaod size: 1452 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  |0|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    0                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |FF4F FF51 002F 000 ....                                        |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Second Packet:
        This has the next 1452 bytes of the image.
        Paylaod size: 1452 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  |0|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0     | 0 |                    1452                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A534 7910 7785 1977 FF90 ...                                   |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    Third Packet:
        This has the last part of the image.
        Paylaod size: 1096 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  |0|       0       |                0              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Futemma, et al.                                               [Page 23]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    |     0     | 0 |                    2904                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0482 29FA ....                                                 |
    |                                                               |
    |                                                           FFD9|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



13. References


Normative References


    [1] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 "Information technology -
        JPEG 2000 image coding system - Part 1: Core coding system",
        July 2002.


    [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels", BCP14, RFC2119, March 1997.


    [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,
        "RTP: A Transport Protocol for Real Time Applications", RFC
        3550, July 2003.


    [4] M. Handley and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.


Informative References


    [5] ISO/IEC JTC1/SC29/WG1, "JPEG2000 Part I Final Committee Draft
        Version 1.0", http://www.jpeg.org/public/fcd15444-1.pdf, March
        2000.


    [6] ISO/IEC JTC1/SC29/WG1, "Motion JPEG 2000 Final Committee Draft
        1.0", http://www.jpeg.org/public/fcd15444-3.doc, March, 2001.


    [7] ISO/IEC JTC1/SC29/WG1, "JPEG2000 requirements and profiles
        version 6.3"


    [8] Baugher, McGrew, Carrara, Naslund, and Norrman, "The Secure
        Real-time Transport Protocol," RFC 3711, Internet Engineering
        Task Force, March 2004.


    [9] Deering, S., "Host Extensions for IP Multicasting", STD 5,
        RFC 1112, August 1989.



14. Authors' Addresses


    Satoshi Futemma/Eisaburo Itakura/Andrew Leung
    Sony Corporation
    6-7-35 Kitashinagawa Shinagawa-ku
    Tokyo 141-0001 JAPAN
    Phone: +81 3 5448 2125
    Fax: +81 3 5448 2160


Futemma, et al.                                               [Page 24]

INTERNET-DRAFT    draft-ietf-avt-rtp-jpeg2000-05.txt      July 16, 2004


    Email: {satosi-f|itakura}@sm.sony.co.jp
           andrew.leung@jp.sony.com



15. Copyright Statement


    Copyright (C) The Internet Society (2004).  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 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.





































Futemma, et al.                                               [Page 25]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/