home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-avt-qt-rtp-00.txt < prev    next >
Text File  |  1997-07-23  |  31KB  |  843 lines
  1.  
  2.  
  3. Internet Engineering Task Force                 Audio-Video Transport WG
  4. INTERNET-DRAFT                        A. Jones, A. Periyannan, D. Singer
  5. draft-ietf-avt-qt-rtp-00                            Apple Computer, Inc.
  6.                                                            July 22, 1997
  7.                                                Expires: January 22, 1998
  8.  
  9.              RTP Payload Format for QuickTime Media Streams
  10.  
  11. Status of This Memo
  12.  
  13.    This document is an Internet-Draft.  Internet-Drafts are working
  14.    documents of the Internet Engineering Task Force (IETF), its areas,
  15.    and its working groups.  Note that other groups may also distribute
  16.    working documents as Internet-Drafts.
  17.  
  18.    Internet-Drafts are draft documents valid for a maximum of six months
  19.    and may be updated, replaced, or obsoleted by other documents at any
  20.    time.  It is inappropriate to use Internet- Drafts as reference
  21.    material or to cite them other than as ``work in progress.''
  22.  
  23.    To learn the current status of any Internet-Draft, please check the
  24.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  25.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  26.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  27.    ftp.isi.edu (US West Coast).
  28.  
  29.  
  30. Distribution of this document is unlimited.
  31.  
  32.  
  33. Abstract
  34.  
  35.    This document specifies the payload format for encapsulating
  36.    QuickTime media streams in the Realtime Transport Protocol (RTP).
  37.    This specification is intended for QuickTime media/codec types that
  38.    are not already handled by other RTP payload specifications. Each
  39.    QuickTime media track within a movie is sent over a separate RTP
  40.    session and synchronized using standard RTP techniques.  A static
  41.    QuickTime payload type (if assigned) or a dynamic payload type may be
  42.    used. A QuickTime header within the RTP payload is defined to carry
  43.    the media type and other media specific information. A packetization
  44.    scheme is defined for the media data. This specification is intended
  45.    for streaming stored QuickTime movies as well as live QuickTime
  46.    content.
  47.  
  48. 1 Introduction
  49.  
  50.    This document specifies the payload format for encapsulating
  51.  
  52.  
  53.  
  54. A. Jones, A. Periyannan, D. Singer                              [Page 1]
  55.  
  56. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  57.  
  58.  
  59.    QuickTime media streams in the Realtime Transport Protocol (RTP) [1].
  60.    RTP is a generic protocol designed to carry realtime media data along
  61.    with synchronization information over a datagram protocol (mostly UDP
  62.    over IP). The protocol itself does not address the encapsulation of
  63.    specific media types, but instead leaves it to various profile
  64.    specifications. An accompanying RTP profile document [2] contains
  65.    various payload specifications to carry audio and video over RTP for
  66.    conferencing applications and specifies the static payload types for
  67.    various audio/video compression schemes. Other documents specify the
  68.    encapsulation format used to carry specific compression schemes such
  69.    as JPEG, MPEG and H.261 [3,4,5].
  70.  
  71.    The QuickTime file format and architecture support an extensible set
  72.    of media types and compression schemes. Many of these are not covered
  73.    by the profile specifications available today. Hence, it is desirable
  74.    to have an RTP encapsulation scheme that will handle all QuickTime
  75.    media/codec types that are not covered by specific RTP payload types.
  76.  
  77.    This specification proposes a scheme to carry QuickTime media/codec
  78.    types over RTP. The scheme specified here handles all loss-tolerant
  79.    media and a few loss-intolerant media such as text. Support for other
  80.    loss-intolerant media such as MIDI and 3D will be added in future.
  81.    This specification is intended for streaming stored QuickTime movies
  82.    as well as live QuickTime content.
  83.  
  84. 2 QuickTime Overview
  85.  
  86.    QuickTime consists of a software architecture for multimedia
  87.    authoring/playback and a movie file format to store multimedia
  88.    presentations. These two aspects of QuickTime are independent of each
  89.    other but are often combined when referring to QuickTime. It is
  90.    possible to playback/author movies in other file formats such as AVI,
  91.    AIFF, etc. using QuickTime software. Similarly it is possible to use
  92.    QuickTime files independent of the software, for example, streaming
  93.    movies over the Internet. The QuickTime movie file format is
  94.    specified in [6]. More information on the QuickTime software
  95.    architecture can be obtained from [7,8,9].
  96.  
  97.    For the purpose of this document we will mostly be concerned with
  98.    streaming QuickTime content using RTP. "QuickTime content" refers to
  99.    content as specified in the QuickTime movie file format specification
  100.    [6]. This does not preclude live QuickTime content. We merely use the
  101.    file format specification as way to specify the format of the
  102.    content.
  103.  
  104.    QuickTime movie files contain the media data and synchronization
  105.    information for the movie. A movie consists of multiple tracks, each
  106.    of which contains a specific media type such as video, sound, MIDI,
  107.  
  108.  
  109.  
  110. A. Jones, A. Periyannan, D. Singer                              [Page 2]
  111.  
  112. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  113.  
  114.  
  115.    text, etc. Not all media types are loss-tolerant. Table 2.1 lists the
  116.    common QuickTime media types and whether they are loss-tolerant. The
  117.    loss tolerant media can be carried over RTP/UDP in classic RTP-style.
  118.    This will not however work for loss-intolerant data. RTP over TCP or
  119.    using the Realtime Streaming Protocol (RTSP) [10] are some of the
  120.    options for loss-intolerant media data. Another option is to achieve
  121.    semi-reliability through redundant transmission. This specification
  122.    uses this latter option to handle QuickTime "text" media over RTP.
  123.  
  124.    QuickTime Media TypeLoss Tolerant?
  125.    Sound               Yes
  126.    Video               Yes
  127.    Timecode            No
  128.    Text                No
  129.    Music (MIDI)        No
  130.    MPEG                Yes
  131.    Sprite              No
  132.    Tween               No
  133.    3D                  No
  134.  
  135.                       Table 2.1 QuickTime Media Types
  136.  
  137.    QuickTime Timescales
  138.  
  139.    QuickTime has a concept of timescales. A timescale defines the number
  140.    of units of time that pass in every second of real time. Any time
  141.    value has to be specified with respect to a timescale. A QuickTime
  142.    movie has a timescale associated with it. Each of the tracks (medias)
  143.    have a timescale associated with them. All of these timescales could
  144.    be different. The RTP timestamp will be based on the timescale of the
  145.    track associated with the RTP session. The timescale of a track never
  146.    changes during its lifetime.
  147.  
  148.    QuickTime Sample Descriptions
  149.  
  150.    Every QuickTime media type has a sample description format associated
  151.    with it. The sample description specifies how the sample is
  152.    interpreted. For example, the video media sample description
  153.    specifies the compression scheme, quality, bit depth and other such
  154.    information. The sample description may change during the life of a
  155.    track.
  156.  
  157.    QuickTime Track Parameters
  158.  
  159.    Every QuickTime track has a number of parameters associated with it
  160.    such as height, width, transformation matrix, etc. These are as
  161.    important to the presentation as the sample description.
  162.  
  163.  
  164.  
  165.  
  166. A. Jones, A. Periyannan, D. Singer                              [Page 3]
  167.  
  168. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  169.  
  170.  
  171. 3 RTP Encapsulation Format
  172.  
  173.    The encapsulation scheme described here requires that each QuickTime
  174.    media track within a single movie be sent over a separate RTP session
  175.    and be synchronized using standard RTP techniques.
  176.  
  177.    The QuickTime information is carried as payload data within the RTP
  178.    protocol. There is a variable length QuickTime header immediately
  179.    following the RTP header. The media data is packetized and placed in
  180.    the  RTP packet following the QuickTime header.
  181.  
  182.    The RTP packet is formatted as follows:
  183.  
  184.  
  185.            0                   1                   2                   3
  186.            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
  187.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  188.            .                                                               .
  189.            .                          RTP Header                           .
  190.            .                                                               .
  191.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  192.            .                       QuickTime Header...                     .
  193.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.            .                     QuickTime Media Data...                   .
  195.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  196.  
  197.  
  198. 3.1 RTP Header
  199.  
  200.    The format and general usage of the RTP header fields are described
  201.    in [1].
  202.  
  203.    The following fields of the RTP header will be used as specified
  204.    below:
  205.  
  206.    - The payload type should specify the static QuickTime payload type
  207.    (if assigned) or one of the dynamic payload types. (The need for a
  208.    static payload type for QuickTime is up for discussion at the IETF
  209.    AVT working group.) If a dynamic payload type is used, it should be
  210.    agreed upon through some non-RTP means.
  211.  
  212.    - The RTP timestamp is based on the timescale specified in the
  213.    QuickTime header. The timestamp encodes the sampling instant of the
  214.    first media sample contained in the RTP data packet. Multiple samples
  215.    may be contained in one RTP packet or a single sample may require
  216.    multiple RTP packets. The packetization rules are specified in a
  217.    subsequent section. If a media sample occupies more than one packet,
  218.    the timestamp will be the same on all of those packets. Packets
  219.  
  220.  
  221.  
  222. A. Jones, A. Periyannan, D. Singer                              [Page 4]
  223.  
  224. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  225.  
  226.  
  227.    containing different samples must have different timestamps so that
  228.    samples may be distinguished by the timestamp. The initial value of
  229.    the timestamp is random (unpredictable) to make known-plaintext
  230.    attacks on encryption more difficult, see RTP [1].
  231.  
  232.    - The marker bit (M-bit) of the RTP header is set to one in the last
  233.    packet of a sample and otherwise, must be zero. If one or more
  234.    samples are fully contained within an RTP packet the M-bit must be
  235.    set to one. Thus, it is possible to easily detect that a complete
  236.    sample has been received and can be decoded and presented.
  237.  
  238.  
  239. 3.2 QuickTime Header
  240.  
  241.    The QuickTime Header is defined as follows:
  242.  
  243.  
  244.            0                   1                   2                   3
  245.            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
  246.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  247.            |  VER  |Q|P|S|      RES        |      QuickTime Payload ID     |
  248.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  249.            .                 QuickTime Payload Description ...             .
  250.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  251.  
  252.  
  253.    The fields in the QuickTime Header have the following meanings:
  254.  
  255.    VER: 4 bits
  256.    A version field that must be set to zero by transmitters implementing
  257.    this specification.
  258.  
  259.    Q bit: 1 bit
  260.    The Q-bit is set to one if there is a payload description as part of
  261.    this QuickTime header. Otherwise it is set to zero.
  262.  
  263.    P bit: 1 bit
  264.    The P-bit is set to one if there are multiple samples which are of
  265.    different sizes or durations carried in the payload. Otherwise it is
  266.    set to zero.  When the P-bit is set, two or more samples are placed
  267.    in the QuickTime media data portion of the RTP packet along with
  268.    individual timestamp and length information. The format for this
  269.    packing is explained in a subsequent section. When the P-bit is not
  270.    set, one or more samples or a partial sample is placed directly in
  271.    the QuickTime media data portion of the RTP packet.
  272.  
  273.    S bit: 1 bit
  274.    The S-bit is set to one if this packet contains data from a sync
  275.  
  276.  
  277.  
  278. A. Jones, A. Periyannan, D. Singer                              [Page 5]
  279.  
  280. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  281.  
  282.  
  283.    sample, i.e. key sample. Otherwise it is set to zero. When the packet
  284.    contains more than one sample the S-bit is set to one if the first
  285.    sample is a sync sample.
  286.  
  287.    RES: 8 bits
  288.    Reserved for future use. Transmitter must set these bits to zero.
  289.    Receivers must ignore these bits.
  290.  
  291.    QuickTime Payload ID: 16 bits
  292.    A payload identifier that identifies the format of the QuickTime
  293.    media data carried in this RTP session. The payload ID associates the
  294.    QuickTime payload description (that is transmitted periodically) with
  295.    the QuickTime media data. This identifier is changed every time the
  296.    payload format changes. Payload IDs are explained further in a
  297.    subsequent section.
  298.  
  299.    QuickTime Payload Description: variable length
  300.    This field is present only if the Q-bit is set to one. It contains
  301.    the QuickTime payload format description such as media type,
  302.    timescale, sample size, compression information, etc. The header must
  303.    be padded to a 32-bit boundary.
  304.  
  305.    The QuickTime Payload Description is defined as follows:
  306.  
  307.  
  308.            0                   1                   2                   3
  309.            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
  310.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  311.            |A|C|          RES              | QuickTime Payload Desc Length |
  312.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  313.            |                      QuickTime Media Type                     |
  314.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  315.            |                           Timescale                           |
  316.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  317.            .                         QuickTime TLVs ...                    .
  318.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  319.  
  320.  
  321.  
  322.    The fields in the QuickTime Payload Description have the following
  323.    meanings:
  324.  
  325.    A bit: 1 bit
  326.    The A-bit is set to one if all samples are sync (key) samples for
  327.    this payload description. Otherwise it is set to zero.
  328.  
  329.    RES: 7 bits
  330.    Reserved for future use. Transmitter must set these bits to zero.
  331.  
  332.  
  333.  
  334. A. Jones, A. Periyannan, D. Singer                              [Page 6]
  335.  
  336. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  337.  
  338.  
  339.    Receivers must ignore these bits.
  340.  
  341.    QuickTime Payload Description Length: 16 bits
  342.    Number of bytes in the QuickTime payload description (not including
  343.    padding of 0 to 3 bytes). The QuickTime Media Data starts at the RTP
  344.    data offset plus the QuickTime fixed header of 4 bytes plus the
  345.    payload description length plus padding (of 0 to 3 bytes).
  346.  
  347.    QuickTime Media Type: 32 bits
  348.    A 4 character media type that identifies the QuickTime media [6],
  349.    example: 'vide' for video, 'soun' for sound, etc.
  350.  
  351.    Timescale: 32 bits
  352.    The number of units of time that pass in 1 second of real time for
  353.    this QuickTime payload ID. This is the timescale used by the RTP
  354.    timestamp for this session.
  355.  
  356.    QuickTime TLVs: variable length
  357.    One or more QuickTime parameters that describes this payload. The
  358.    parameters are expressed as a Type-Length-Value triplet. The TLVs are
  359.    not padded and can begin at any byte boundary.
  360.  
  361.    A QuickTime TLV is formatted as follows:
  362.  
  363.  
  364.            0                   1                   2                   3
  365.            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
  366.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  367.            |      QuickTime TLV Length     |      QuickTime TLV Type       |
  368.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  369.            .                     QuickTime TLV Value ...                   .
  370.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  371.  
  372.  
  373.    The fields in a QuickTime TLV have the following meanings:
  374.  
  375.    QuickTime TLV Length: 16 bits
  376.    Number of bytes in the QuickTime TLV. The next QuickTime TLV starts
  377.    at the offset of the current TLV plus the current TLV length.
  378.  
  379.    QuickTime TLV Type: 16 bits
  380.    A 2 character TLV type that identifies the QuickTime parameter.
  381.  
  382.    QuickTime TLV Value: variable length
  383.    The value of the TLV as specified by the type. Values must be sent in
  384.    network byte-order (i.e. big-endian format).
  385.  
  386.    Note: Section 3.3 lists the set of currently defined TLVs. Some TLVs
  387.  
  388.  
  389.  
  390. A. Jones, A. Periyannan, D. Singer                              [Page 7]
  391.  
  392. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  393.  
  394.  
  395.    are mandatory and must be present if the QuickTime Payload
  396.    Description is being sent. Other TLVs will assume their default
  397.    values if they are not sent. Any TLV not recognized by a receiver
  398.    must be ignored and skipped over.
  399.  
  400. 3.3 QuickTime TLVs
  401.  
  402.  
  403.    Sample Description (mandatory)
  404.    Type: 'sd'
  405.    Length: variable length
  406.    Media-specific QuickTime sample description. The format for this TLV
  407.    for each of the currently defined media types can be found in [6]
  408.    (starting pg. 59).
  409.    Default: none
  410.  
  411.    QuickTime Atom
  412.    Type: 'qt'
  413.    Length: variable
  414.    Default: none
  415.    This TLV is used to transparently send a QuickTime Atom as defined in
  416.    [6] (pg. 3). For example, this can be used to send User Data Atoms,
  417.    Track Reference Atoms, Track Input Map Atoms, etc. The QuickTime
  418.    atoms sent depends on the media type associated with the QuickTime
  419.    payload description.
  420.  
  421.    Track ID
  422.    Type: 'ti'
  423.    Length: 8
  424.    Default: 0
  425.    Track ID as defined in [6] (pg. 18).
  426.  
  427.    Layer
  428.    Type: 'ly'
  429.    Length: 6
  430.    Default: 0
  431.    Layer as defined in [6] (pg. 18).
  432.  
  433.    Volume
  434.    Type: 'vo'
  435.    Length: 6
  436.    Default: 255
  437.    Volume as defined in [6] (pg. 18).
  438.  
  439.    Matrix
  440.    Type: 'mx'
  441.    Length: 40
  442.    Default: identity matrix
  443.  
  444.  
  445.  
  446. A. Jones, A. Periyannan, D. Singer                              [Page 8]
  447.  
  448. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  449.  
  450.  
  451.    Matrix as defined in [6] (pg. 18 and 77).
  452.  
  453.    Translation Matrix
  454.    Type: 'tr'
  455.    Length: 8
  456.    Default: identity matrix
  457.    h, v -- two 16-bit signed numbers indicating translation values (in
  458.    pixels).This TLV is sent instead of the Matrix TLV when only
  459.    translation is required.
  460.  
  461.    Track Width
  462.    Type: 'tw'
  463.    Length: 8
  464.    Default: 0
  465.    Track Width as defined in [6] (pg. 19).
  466.  
  467.    Track Height
  468.    Type: 'th'
  469.    Length: 8
  470.    Default: 0
  471.    Track Height as defined in [6] (pg. 19)
  472.  
  473.    Language
  474.    Type: 'la'
  475.    Length: 6
  476.    Default: 0
  477.    Language as defined in [6] (pg. 32 and 75).
  478.  
  479. 3.4 Media Data Packetization
  480.  
  481.    The RTP packetization for QuickTime is designed to take into account
  482.    the needs of a varied set of media types and compression schemes.
  483.    Hence, 3 different packetization schemes are defined.
  484.  
  485.    The following pieces of information are required at the transmission
  486.    end to make packetization decisions:
  487.  
  488.    -  Maximum QuickTime Media Data size (MQD) that can be accommodated
  489.    in a single RTP packet.
  490.    - Whether all samples for this media type are of constant size? (CQS)
  491.    - Whether all samples for this media type are of constant duration?
  492.    (CQD)
  493.    - Sample size of all samples (when they are constant) (CSS).
  494.    - Sample size of a specific sample (SS).
  495.  
  496.    Based on the above pieces of information, one of the following
  497.    packetization schemes is adopted:
  498.  
  499.  
  500.  
  501.  
  502. A. Jones, A. Periyannan, D. Singer                              [Page 9]
  503.  
  504. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  505.  
  506.  
  507.    Scheme I : (CQS=true) AND (CQD=true) AND (CSS <= 0.5*MQD)
  508.  
  509.    Multiple samples are packed into one RTP packet. The RTP header M-bit
  510.    is set to one on all packets. The QuickTime header P-bit is set to
  511.    zero on all packets.
  512.  
  513.    Scheme II: ( (CQS=false) OR (CQD=false) ) AND (SS <= 0.5*MQD)
  514.  
  515.    Multiple samples are packed into the QuickTime Media Data portion of
  516.    an RTP packet. The RTP header M-bit is set to one in this packet. The
  517.    QuickTime header P-bit is set to one.
  518.  
  519.    The samples are packed using the format illustrated below:
  520.  
  521.  
  522.  
  523.            0                   1                   2                   3
  524.            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
  525.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  526.            |                         Sample Length                         |
  527.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  528.            |                       Sample Timestamp                        |
  529.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  530.            .                          Sample Data ...                      .
  531.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  532.            |                         Sample Length                         |
  533.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.            |                       Sample Timestamp                        |
  535.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  536.            .                          Sample Data ...                      .
  537.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  538.            .                           ......                              .
  539.            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  540.  
  541.  
  542.    The fields in the QuickTime Media Data have the following meanings:
  543.  
  544.    Sample Length: 32 bits
  545.    Number of bytes in the sample data (not including the length field,
  546.    timestamp field and padding).
  547.  
  548.    Sample Timestamp: 32 bits
  549.    This field contains the timestamp for this sample in the timescale
  550.    associated with this QuickTime payload ID. The first timestamp must
  551.    be the same as the timestamp in the RTP header.
  552.  
  553.    Sample Data: variable length
  554.    This field contains the sample data. The data must be padded to a
  555.  
  556.  
  557.  
  558. A. Jones, A. Periyannan, D. Singer                             [Page 10]
  559.  
  560. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  561.  
  562.  
  563.    32-bit boundary.
  564.  
  565.    All receivers are required to handle this scheme. A transmitter may
  566.    choose to not implement this scheme in which case it will default to
  567.    scheme III.
  568.  
  569.    Note: This scheme leads to more efficient packing than scheme III for
  570.    certain media/codec types. However, there is a trade-off between
  571.    efficiency and losing multiple samples when a packet is lost.
  572.  
  573.    Scheme III: Cases not covered by schemes I and II
  574.  
  575.    A single sample is placed in one or more RTP packets. The RTP header
  576.    M-bit is set to one in the last packet and is otherwise set to zero.
  577.    The QuickTime header P-bit is set to zero in every packet.
  578.  
  579.    The packetization boundaries may be chosen intelligently to respect
  580.    the compression/decompression algorithm requirements. However, this
  581.    is not a requirement. When intelligent boundaries are not chosen, a
  582.    single packet loss will lead to the entire sample being lost in the
  583.    case of multi-packet samples.
  584.  
  585. 3.5 Payload Information
  586.  
  587.    Payload ID
  588.  
  589.    The QuickTime payload ID identifies the format of the QuickTime media
  590.    data carried in an RTP session. It associates the QuickTime payload
  591.    description (that is transmitted periodically) with the QuickTime
  592.    media data. This identifier is an arbitrary 16-bit number that is
  593.    changed every time the payload format changes. When streaming
  594.    QuickTime movie tracks, the payload format changes usually when the
  595.    sample description changes during the life of the track.
  596.  
  597.    The following restrictions apply when picking payload IDs,
  598.  
  599.    - The payload ID must be unique among all QuickTime RTP sessions
  600.    originating from a given source canonical name. This is to ensure
  601.    efficient mapping of payload IDs to payload descriptions using a
  602.    single receiver-side table per canonical name.
  603.  
  604.    - A payload ID must not be reused for a different payload description
  605.    during the lifetime of the session. This allows receivers to cache
  606.    the payload descriptions for the duration of the session.
  607.  
  608.    Payload Description
  609.  
  610.    The QuickTime payload descriptions are transmitted as part of the
  611.  
  612.  
  613.  
  614. A. Jones, A. Periyannan, D. Singer                             [Page 11]
  615.  
  616. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  617.  
  618.  
  619.    QuickTime header. The payload descriptions specify the format of the
  620.    QuickTime media data. The information for the specific fields in a
  621.    payload description can be found in [6]. These fields do not include
  622.    all of the information associated with a QuickTime track. For
  623.    example, information on transformation matrices, layers, etc. is not
  624.    included. This information needs to be communicated through non-RTP
  625.    means.
  626.  
  627.    Payload Description Transmission
  628.  
  629.    The payload description must be transmitted in the first RTP packet
  630.    which contains media samples that require the payload description.
  631.    After the first packet, the payload description must be retransmitted
  632.    at a periodic interval until the format of the media samples changes.
  633.    The maximum retransmission interval should be 1 second, unless
  634.    packets are being transmitted at less than 1 packet/second in which
  635.    case the payload description must be transmitted with each packet.
  636.  
  637.    The retransmission interval may be negotiated to an arbitrary value
  638.    through non-RTP means. Note: This includes the case in which the
  639.    payload descriptions are never sent over RTP, i.e. a retransmission
  640.    interval of infinity. In this case the payload descriptions are
  641.    communicated through some non-RTP means.
  642.  
  643.    A transmitter may send an RTP packet that contains only a payload
  644.    description and no QuickTime media data. This payload description
  645.    must be cached by the receiver and used to interpret data that may
  646.    arrive in the future.
  647.  
  648. 3.6 Loss-intolerant Media Types
  649.  
  650.    Loss-intolerant media types can not be easily handled within the
  651.    standard RTP framework. Hence, we may need to use some non-RTP
  652.    techniques to transmit these media types. However, some of the media
  653.    types, notably Text and Tween media can be sent over RTP by the use
  654.    of redundant transmissions. (Tween media is used to alter the
  655.    characteristics of other media streams. For example, Tween samples
  656.    may contain a series of values that change the volume of an audio
  657.    stream.) The use of this technique is experimental.
  658.  
  659.    Redundant Transmissions
  660.  
  661.    The redundant transmission technique is one in which the RTP packet
  662.    is retransmitted multiple times within the duration of the sample.
  663.    The RTP packet is resent as a whole with the same RTP sequence
  664.    number, timestamp and other information, i.e. it is an identical
  665.    packet when seen on the wire. This technique is not bandwidth
  666.    friendly when used with high bandwidth media types. Hence it will be
  667.  
  668.  
  669.  
  670. A. Jones, A. Periyannan, D. Singer                             [Page 12]
  671.  
  672. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  673.  
  674.  
  675.    used only with the low bandwidth media types such as "text" and
  676.    "tween" media.
  677.  
  678.    The rationale for using the same RTP sequence numbers in the
  679.    retransmitted packets is as follows: If the sequence numbers were
  680.    incremented for each of the retransmitted packets we would require an
  681.    additional field to identify the duplicate samples. In the proposed
  682.    scheme, the receiver can discard duplicates by simply keeping track
  683.    of the sequence numbers of the packets received.
  684.  
  685.    The interval between retransmissions depends on the media type and
  686.    the current congestion situation in the network. This interval can be
  687.    a simple fixed interval, say 4 retransmissions equally spaced within
  688.    the duration of the sample, or it could be more complex, say
  689.    exponentially increasing intervals within the duration of the sample.
  690.    This specification does not currently recommend a preferred scheme to
  691.    use for determining the retransmission interval.
  692.  
  693. 4 Open Issues
  694.  
  695.    The following open issues need to be resolved:
  696.  
  697.    -      How to handle loss-intolerant media with "key" and "update"
  698.    samples?
  699.    Loss-intolerant media samples can be retransmitted multiple times
  700.    with fixed or variable intervals between transmission. The samples
  701.    can be classified as key samples and update samples and handled
  702.    appropriately. Update samples need not be periodically retransmitted.
  703.    For example, in sprite media, key samples will contain the sprite
  704.    image and update samples will contain the motion vectors. Whereas, in
  705.    text media, all samples will be key samples.
  706.  
  707.    -      What is the appropriate interval between redundant
  708.    transmissions for "text" and "tween" media samples?
  709.  
  710.    -      Should there be sample size TLV (that specifies bits per
  711.    sample)?
  712.  
  713. Acknowledgments
  714.  
  715.    The authors would like to thank Joe Pallas (of Apple ATG) and all the
  716.    members of the QuickTime Streaming team, Jay Geagan, Andy Grignon,
  717.    Sylvain Rouze and Kevin Gong for their valuable input in writing this
  718.    proposal.
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726. A. Jones, A. Periyannan, D. Singer                             [Page 13]
  727.  
  728. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  729.  
  730.  
  731. References
  732.  
  733.    [1] H. Schulzrinne, et. al., "RTP : A Transport Protocol for Real-
  734.    Time Applications", IETF RFC 1889, January 1996.
  735.  
  736.    [2] H. Schulzrinne, et. al., "RTP Profile for Audio and Video
  737.    Conference with Minimal Control", IETF RFC 1890, January 1996.
  738.  
  739.    [3] L. Berc, et. al., "RTP Payload Format for JPEG-compressed Video",
  740.    IETF RFC 2035, October 1996.
  741.  
  742.    [4] D. Hoffman, et. al., "RTP Payload Format for MPEG1/MPEG2 Video",
  743.    IETF RFC 2038, October 1996.
  744.  
  745.    [5] T. Turletti, C. Huitema, "RTP Payload Format for H.261 Video
  746.    Streams", IETF RFC 2032, October 1996.
  747.  
  748.    [6] Apple Computer, Inc., "QuickTime File Format Specification", May
  749.    1996.
  750.  
  751.    [7] Apple Computer, Inc., "Inside Macintosh: QuickTime", Addison
  752.    Wesley Press.
  753.  
  754.    [8] Apple Computer, Inc., "Inside Macintosh: QuickTime Components",
  755.    Addison Wesley Press.
  756.  
  757.    [9] Apple Computer, Inc., "QuickTime 2.5 Developer Guide", Developer
  758.    Press.
  759.  
  760.    [10] H. Schulzrinne, et. al., "Real Time Streaming Protocol", IETF
  761.    Draft ietf-mmusic-rtsp-02.txt, March 24 1994, Expires: August 20
  762.    1997.
  763.  
  764.  
  765. Authors' Contact Information
  766.    Alagu Periyannan
  767.    Email: alagu@apple.com
  768.    Tel: (408) 862 5387
  769.    Fax: (408) 974 0234
  770.  
  771.    Anne Jones
  772.    Email: astoria@apple.com
  773.    Tel: (408) 862 1170
  774.  
  775.    David Singer
  776.    Email: singer@apple.com
  777.    Tel: (408) 974 3162
  778.  
  779.  
  780.  
  781.  
  782. A. Jones, A. Periyannan, D. Singer                             [Page 14]
  783.  
  784. Internet Draft          draft-ietf-avt-qt-rtp-00            July 22 1997
  785.  
  786.  
  787.    Apple Computer, Inc.
  788.    One Infinite Loop, MS:302-3MT
  789.    Cupertino  CA 95014
  790.    USA
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838. A. Jones, A. Periyannan, D. Singer                             [Page 15]
  839.  
  840.  
  841.  
  842.  
  843.