home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2190 < prev    next >
Text File  |  1997-09-10  |  26KB  |  676 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                             C. Zhu
  8. Request for Comments: 2190                                   Intel Corp.
  9. Category: Standards Track                                 September 1997
  10.  
  11.  
  12.                RTP Payload Format for H.263 Video Streams
  13.  
  14. Status of This Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document specifies the payload format for encapsulating an H.263
  25.    bitstream in the Real-Time Transport Protocol (RTP). Three modes are
  26.    defined for the H.263 payload header. An RTP packet can use one of
  27.    the three modes for H.263 video streams depending on the desired
  28.    network packet size and H.263 encoding options employed. The shortest
  29.    H.263 payload header (mode A) supports fragmentation at Group of
  30.    Block (GOB) boundaries. The long H.263 payload headers (mode B and C)
  31.    support fragmentation at Macroblock (MB) boundaries.
  32.  
  33. 1. Introduction
  34.  
  35.    This document describes a scheme to packetize an H.263 video stream
  36.    for transport using RTP [1]. H.263 video stream is defined by ITU-T
  37.    Recommendation H.263 (referred to as H.263 in this document) [4] for
  38.    video coding at very low data rates. RTP is defined by the Internet
  39.    Engineering Task Force (IETF) to provide end-to-end network transport
  40.    functions suitable for applications transmitting real-time data over
  41.    multicast or unicast network services.
  42.  
  43. 2. Definitions
  44.  
  45.    The following definitions apply in this document:
  46.  
  47.    CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x
  48.    288 pixels for luminance, and 176 x 144 pixels for chrominance.
  49.  
  50.    QCIF: Quarter CIF source format with 176 x 144 pixels for luminance
  51.    and 88 x 72 pixels for chrominance.
  52.  
  53.    Sub-QCIF:  picture source format with 128 x 96 pixels for luminance
  54.    and 64 x 48 pixels for chrominance.
  55.  
  56.  
  57.  
  58. Zhu                         Standards Track                     [Page 1]
  59.  
  60. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  61.  
  62.  
  63.    4CIF: Picture source format with 704 x 576 pixels for luminance and
  64.    352 x 288 pixels for chrominance.
  65.  
  66.    16CIF: Picture source format with 1408 x 1152 pixels for luminance
  67.    and 704 x 576 pixels for chrominance.
  68.  
  69.    GOB: For H.263, a Group of Blocks (GOB) consists of  k*16 lines,
  70.    where k depends on the picture format (k=1 for QCIF, CIF and sub-
  71.    QCIF; k=2 for 4CIF and k=4 for 16CIF).
  72.  
  73.    MB: A macroblock (MB) contains four blocks of luminance and the
  74.    spatially corresponding two blocks of chrominance. Each block
  75.    consists of 8x8 pixels. For example, there are eleven MBs in a GOB in
  76.    QCIF format and twenty two MBs in a GOB in CIF format.
  77.  
  78. 3. Design Issues for Packetizing H.263 Bitstreams
  79.  
  80.    H.263 is based on the ITU-T Recommendation H.261 [2] (referred to as
  81.    H.261 in this document). Compared to H.261, H.263 employs similar
  82.    techniques to reduce both temporal and spatial redundancy, but there
  83.    are several major differences between the two algorithms that affect
  84.    the design of packetization schemes significantly. This section
  85.    summarizes those differences.
  86.  
  87. 3.1 Optional Features of H.263
  88.  
  89.    In addition to the basic source coding algorithms, H.263 supports
  90.    four negotiable coding options to improve performance: Advanced
  91.    Prediction, PB-frames, Syntax-based Arithmetic Coding, and
  92.    Unrestricted Motion Vectors. They can be used in any combination.
  93.  
  94.    Advanced Prediction(AP): One or four motion vectors can be used for
  95.    some macroblocks in a frame. This feature makes recovery from packet
  96.    loss difficult, because more redundant information has to be
  97.    preserved at the beginning of a packet when fragmenting at a
  98.    macroblock boundary.
  99.  
  100.    PB-frames:  Two frames (a P frame and a B frame) are coded into one
  101.    bitstream with macroblocks from the two frames interleaved. From a
  102.    packetization point of view, a MB from the P frame and a MB from the
  103.    B frame must be treated together because each MB for the B frame is
  104.    coded based on the corresponding MB for the P frame. A means must be
  105.    provided to ensure proper rendering of two frames in the right order.
  106.    Also, if part of this combined bitstream is lost, it will affect both
  107.    frames, and possibly more.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Zhu                         Standards Track                     [Page 2]
  115.  
  116. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  117.  
  118.  
  119.    Syntax-based Arithmetic Coding (SAC): When the SAC option is used,
  120.    the resultant run-value pair after quantization of Discrete Cosine
  121.    Transform (DCT) coefficients will be coded differently from Huffman
  122.    codes, but the macroblock hierarchy will be preserved. Since context
  123.    variables are only synchronized after fixed length codes in the
  124.    bitstream, any fragmentation starting at variable length codes will
  125.    result in difficulty in decoding in the presence of packet loss
  126.    without carrying the values of all the context variables in each
  127.    H.263 payload header.
  128.  
  129.    The Unrestricted motion vectors feature allows large range of motion
  130.    vectors to improve performance of motion compensation for inter-coded
  131.    pictures. This option also affects packetization because it uses
  132.    larger range of motion vectors than normal.
  133.  
  134.    To enable proper decoding of packets received, without dependency on
  135.    previous packets, the use of these optional features is signaled in
  136.    the H.263 payload header, as described in Section 5.
  137.  
  138. 3.2 GOB Numbering
  139.  
  140.    In H.263, each picture is divided into groups of blocks (GOB). GOBs
  141.    are numbered according to a vertical scan of a picture, starting with
  142.    the top GOB and ending with the bottom GOB. In contrast, a GOB in
  143.    H.261 is composed of three rows of 16x16 MB for QCIF, and three
  144.    half-rows of MBs for CIF. A GOB is divided into macroblocks in H.263
  145.    and the definition of the macroblocks are the same as in H.261.
  146.  
  147.    Each GOB in H.263 can have a fixed GOB header, but the use of the
  148.    header is optional. If the GOB header is present, it may or may not
  149.    start on a byte boundary. Byte alignment can be achieved by proper
  150.    bit stuffing by the encoder, but it is not required by the H.263
  151.    bitstream specification [4].
  152.  
  153.    In summary, a GOB in H.263 is defined and coded with finer
  154.    granularity but with the same source format, resulting in more
  155.    flexibility for packetization than with H.261.
  156.  
  157. 3.3 Motion Vector Encoding
  158.  
  159.    Differential coding is used to code motion vectors as variable length
  160.    codes. Unlike in H.261, where each motion vector is predicted from
  161.    the previous MB in the GOB, H.263 employs a more flexible prediction
  162.    scheme, where one or three candidate predictors could be used
  163.    depending on the presence of GOB headers.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Zhu                         Standards Track                     [Page 3]
  171.  
  172. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  173.  
  174.  
  175.    If the GOB header is present in a GOB, motion vectors are coded with
  176.    reference to MBs in the current GOB only. If a GOB header is not
  177.    present in the current GOB, three motion vectors must be available to
  178.    decode one macroblock, where two of them might come from the previous
  179.    GOB. To correctly decode a whole inter-coded GOB, all the motion
  180.    vectors for MBs in the previous GOB  must be available to compute the
  181.    predictors or the predictors themselves must be present. The optional
  182.    use of three motion vector predictors can be a major problem for a
  183.    packetization scheme like the one defined for H.261 when packetizing
  184.    at MB boundaries [5].
  185.  
  186.    Consider the case that a packet starts with a MB but the GOB header
  187.    is not present. If the previous packet is lost, then all the motion
  188.    vectors needed to predict the motion vectors for the MBs in the
  189.    current GOB are not available. In order to decode the received MBs
  190.    correctly, all the motion vectors for the previous GOB or the motion
  191.    vector predictors would have to be duplicated at the beginning of the
  192.    packet. This kind of duplication would be very expensive and
  193.    unacceptable in terms of bandwidth overhead.
  194.  
  195.    The encoding strategy of each H.263 CODEC (CODer and DECoder)
  196.    implementation is beyond the scope of this document, even though it
  197.    has significant effect on visual quality in the presence of packet
  198.    loss. However, we strongly recommend use of the GOB header for every
  199.    GOB at the beginning of a packet to address this problem.
  200.  
  201.    Similar problems exist because of cross-GOB data dependency related
  202.    to motion vectors, but they can not be addressed by using the GOB
  203.    header. For 16CIF and 4CIF pictures, a GOB contains more than one row
  204.    of MBs. If a GOB can not fit in one RTP packet, and the first packet
  205.    containing the GOB header is lost, then MBs in the second packet can
  206.    not compute motion vectors correctly, because they are coded relative
  207.    to data in the lost packet. Similarly,  when OBMC (Overlapped Block
  208.    Motion Compensation) [4] in Advanced Prediction mode is used, motion
  209.    compensation for some MBs in one GOB could use motion vectors of MBs
  210.    in previous GOB regardless of the presence of GOB header. When MBs
  211.    that are used to decode received MBs are lost, those received MBs can
  212.    not be decoded correctly. Each implementation of the method described
  213.    in this document should take these limitations into account.
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Zhu                         Standards Track                     [Page 4]
  227.  
  228. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  229.  
  230.  
  231. 3.4 Macroblock Address
  232.  
  233.    As specified by H.261, a macroblock address (MBA) is encoded with a
  234.    variable length code to indicate the position of a macroblock within
  235.    a group of MBs in H.261 bitstreams. H.263 does not code the MBA
  236.    explicitly, but the macroblock address within a GOB is necessary to
  237.    recover from packet loss when fragmenting at MB boundaries.
  238.    Therefore, this information must be included in the H.263 payload
  239.    header for modes (mode B and mode C as described in Section 5) that
  240.    allow packetization at MB boundaries.
  241.  
  242. 4. Usage of RTP
  243.  
  244.    When transmitting H.263 video streams over the Internet, the output
  245.    of the encoder can be packetized directly. For every video frame, the
  246.    H.263 bitstream itself is carried in the RTP payload without
  247.    alteration, including the picture start code, the entire picture
  248.    header, in addition to any fixed length codes and variable length
  249.    codes.  In addition, the output of the encoder is packetized without
  250.    adding the framing information specified by H.223 [6]. Therefore
  251.    multiplexing audio and video signals in the same packet is not
  252.    accommodated, as UDP and RTP provide a much more efficient way to
  253.    achieve multiplexing.
  254.  
  255.    RTP does not guarantee a reliable and orderly data delivery service,
  256.    so a packet might get lost in the network. To achieve a best-effort
  257.    recovery from packet loss, the decoder needs assistance to proceed
  258.    with decoding of other packets that are received. Thus it is
  259.    desirable to be able to process each packet independent of other
  260.    packets. Some frame level information is included in each packet,
  261.    such as source format and flags for optional features to assist the
  262.    decoder in operating correctly and efficiently in presence of packet
  263.    loss. The flags for H.263 optional features also provide information
  264.    about coding options used in H.263 video bitstreams that can be used
  265.    by session management tools.
  266.  
  267.    H.263 video bitstreams will be carried as payload data within RTP
  268.    packets. A new H.263 payload header is defined in section 5 on the
  269.    H.263 payload header. This section defines the usage of RTP fixed
  270.    header and H.263 video packet structure.
  271.  
  272. 4.1 RTP Header Usage
  273.  
  274.    Each RTP packet starts with a fixed RTP header [1]. The following
  275.    fields of the RTP fixed header are used for H.263 video streams:
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Zhu                         Standards Track                     [Page 5]
  283.  
  284. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  285.  
  286.  
  287.    Marker bit (M bit): The Marker bit of the RTP fixed header is set to
  288.    1 when the current packet carries the end of current frame; set to 0
  289.    otherwise.
  290.  
  291.    Payload Type (PT): The Payload Type shall specify H.263 video payload
  292.    format using the value specified by the RTP profile in use, for
  293.    example RFC 1890 [3].
  294.  
  295.    Timestamp: The RTP timestamp encodes the sampling instant of the
  296.    video frame contained in the RTP data packet. The RTP timestamp may
  297.    be the same  on successive packets if a video frame occupies more
  298.    than one packet. For H.263 video streams, the RTP timestamp is based
  299.    on a 90 kHz clock, the same as the RTP timestamp for H.261 video
  300.    streams [5].
  301.  
  302. 4.2 Video Packet Structure
  303.  
  304.    For each RTP packet, the RTP fixed header is followed by the H.263
  305.    payload header, which is followed by the standard H.263 compressed
  306.    bitstream [4].
  307.  
  308.    The size of the H.263 payload header is variable depending on modes
  309.    used as detailed in the next section. The layout of an RTP H.263
  310.    video packet is shown as:
  311.  
  312.     0                   1                   2                   3
  313.     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
  314.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  315.    |                 RTP header                                    |
  316.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  317.    |                 H.263 payload header                          |
  318.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  319.    |                 H.263 bitstream                               |
  320.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  321.  
  322.  
  323. 5. H.263 Payload Header
  324.  
  325.    For H.263 video streams, each RTP packet carries only one H.263 video
  326.    packet. The H.263 payload header is always present for each H.263
  327.    video packet.
  328.  
  329.    Three formats (mode A, mode B and mode C) are defined for H.263
  330.    payload header. In mode A, an H.263 payload header of four bytes is
  331.    present before actual compressed H.263 video bitstream in a packet.
  332.    It allows fragmentation at GOB boundaries. In mode B, an eight byte
  333.    H.263 payload header is used and each packet starts at MB boundaries
  334.    without the PB-frames option. Finally, a twelve byte H.263 payload
  335.  
  336.  
  337.  
  338. Zhu                         Standards Track                     [Page 6]
  339.  
  340. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  341.  
  342.  
  343.    header is defined in mode C to support fragmentation at MB boundaries
  344.    for frames that are coded with the PB-frames option.
  345.  
  346.    The mode of each H.263 payload header is indicated by the F and P
  347.    fields in the header. Packets of different modes can be intermixed.
  348.    All client application are required to be able to receive packets in
  349.    any mode, but decoding of mode C packets is optional because the PB-
  350.    frames feature is optional.
  351.  
  352.    In this section, the H.263 payload format is shown as rows of 32-bit
  353.    words. Each word is transmitted in network byte order. Whenever a
  354.    field represents a numeric value, the most significant bit is at the
  355.    left of the field.
  356.  
  357. 5.1 Mode A
  358.  
  359.    In this mode, an H.263 bitstream will be packetized on a GOB boundary
  360.    or a picture boundary. Mode A packets always start with the H.263
  361.    picture start code [4] or a GOB, but do not necessarily contain
  362.    complete GOBs. Four bytes are used for the mode A H.263 payload
  363.    header. The H.263 payload header definition for mode A is shown as
  364.    follows with F=0. Mode A packets are allowed to start at a GOB
  365.    boundary even if no GOB header is present in the bitstream for the
  366.    GOB.  However, such use is discouraged due to the dependencies it
  367.    creates across GOB boundaries, as described in Section 3.3.
  368.  
  369.     0                   1                   2                   3
  370.     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
  371.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  372.    |F|P|SBIT |EBIT | SRC |I|U|S|A|R      |DBQ| TRB |    TR         |
  373.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  374.  
  375.    F: 1 bit
  376.    The flag bit indicates the mode of the payload header. F=0, mode A;
  377.    F=1, mode B or mode C depending on P bit defined below.
  378.  
  379.    P: 1 bit
  380.    Optional PB-frames mode as defined by the H.263 [4]. "0" implies
  381.    normal I or P frame, "1" PB-frames. When F=1, P also indicates modes:
  382.    mode B if P=0, mode C if P=1.
  383.  
  384.    SBIT: 3 bits
  385.    Start bit position specifies number of most significant bits that
  386.    shall be ignored in the first data byte.
  387.  
  388.    EBIT: 3 bits
  389.    End bit position specifies number of least significant bits that
  390.    shall be ignored in the last data byte.
  391.  
  392.  
  393.  
  394. Zhu                         Standards Track                     [Page 7]
  395.  
  396. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  397.  
  398.  
  399.    SRC : 3 bits
  400.    Source format, bit 6,7 and 8 in PTYPE defined by H.263 [4], specifies
  401.    the resolution of the current picture.
  402.  
  403.    I:  1 bit.
  404.    Picture coding type, bit 9 in PTYPE defined by H.263[4], "0" is
  405.    intra-coded, "1" is inter-coded.
  406.  
  407.    U: 1 bit
  408.    Set to 1 if the Unrestricted Motion Vector option, bit 10 in PTYPE
  409.    defined by H.263 [4] was set to 1 in the current picture header,
  410.    otherwise 0.
  411.  
  412.    S: 1 bit
  413.    Set to 1 if the Syntax-based Arithmetic Coding option, bit 11 in
  414.    PTYPE defined by the H.263 [4] was set to 1 for current picture
  415.    header, otherwise 0.
  416.  
  417.    A: 1 bit
  418.    Set to 1 if the Advanced Prediction option, bit 12 in PTYPE defined
  419.    by H.263 [4] was set to 1 for current picutre header, otherwise 0.
  420.  
  421.    R: 4 bits
  422.    Reserved, must be set to zero.
  423.  
  424.    DBQ: 2 bits
  425.    Differential quantization parameter used to calculate quantizer for
  426.    the B frame based on quantizer for the P frame, when PB-frames option
  427.    is used. The value should be the same as DBQUANT defined by H.263
  428.    [4].  Set to zero if PB-frames option is not used.
  429.  
  430.    TRB: 3 bits
  431.    Temporal Reference for the B frame as defined by H.263 [4]. Set to
  432.    zero if PB-frames option is not used.
  433.  
  434.    TR: 8 bits
  435.    Temporal Reference for the P frame as defined by H.263 [4]. Set to
  436.    zero if the PB-frames option is not used.
  437.  
  438. 5.2 Mode B
  439.  
  440.    In this mode, an H.263 bitstream can be fragmented at MB boundaries.
  441.    Whenever a packet starts at a MB boundary, this mode shall be used
  442.    without PB-frames option. Mode B packets are intended for a GOB whose
  443.    size is larger than the maximum packet size allowed in the underlying
  444.    protocol, thus making it impossible to fit one or more complete GOBs
  445.    in a packet. This mode can only be used without the PB-frames option.
  446.    Mode C as defined in the next section can be used to fragment H.263
  447.  
  448.  
  449.  
  450. Zhu                         Standards Track                     [Page 8]
  451.  
  452. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  453.  
  454.  
  455.    bitstreams at MB boundaries with the PB-frames option.  The H.263
  456.    payload header definition for mode B is shown as follows with F=1 and
  457.    P=0:
  458.  
  459.     0                   1                   2                   3
  460.     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
  461.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  462.    |F|P|SBIT |EBIT | SRC | QUANT   |  GOBN   |   MBA           |R  |
  463.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  464.    |I|U|S|A| HMV1        | VMV1        | HMV2        | VMV2        |
  465.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  466.  
  467.    The following fields are defined the same as in mode A: F, P, SBIT,
  468.    EBIT, SRC, I, U, S and A. Other fields are defined as follows:
  469.  
  470.    QUANT: 5 bits
  471.    Quantization value for the first MB coded at the starting of the
  472.    packet.  Set to 0 if the packet begins with a GOB header. This is the
  473.    equivalent of GQUANT defined by the H.263 [4].
  474.  
  475.    GOBN: 5 bits
  476.    GOB number in effect at the start of the packet. GOB number is
  477.    specified differently for different resolutions. See H.263 [4] for
  478.    details.
  479.  
  480.    MBA: 9 bits
  481.    The address within the GOB of the first MB in the packet, counting
  482.    from zero in scan order. For example, the third MB in any GOB is
  483.    given MBA = 2.
  484.  
  485.    HMV1, VMV1: 7 bits each.
  486.    Horizontal and vertical motion vector predictors for the first MB in
  487.    this packet [4]. When four motion vectors are used for current MB
  488.    with advanced prediction option, these would be the motion vector
  489.    predictors for block number 1 in the MB. Each 7 bits field encodes a
  490.    motion vector predictor in half pixel resolution as a 2's complement
  491.    number.
  492.  
  493.    HMV2, VMV2: 7 bits each.
  494.    Horizontal and vertical motion vector predictors for block number 3
  495.    in the first MB in this packet when four motion vectors are used with
  496.    the advanced prediction option. This is needed because block number 3
  497.    in the MB needs different motion vector predictors from other blocks
  498.    in the MB. These two fields are not used when the MB only has one
  499.    motion vector. See the H.263 [4] for block organization in a
  500.    macroblock.  Each 7 bits field encodes a motion vector predictor in
  501.    half pixel resolution as a 2's complement number.
  502.  
  503.  
  504.  
  505.  
  506. Zhu                         Standards Track                     [Page 9]
  507.  
  508. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  509.  
  510.  
  511.    R : 2 bits
  512.    Reserved, must be set to zero.
  513.  
  514. 5.3 Mode C
  515.  
  516.    In this mode, an H.263 bitstream is fragmented at MB boundaries of P
  517.    frames with the PB-frames option. It is intended for those GOBs whose
  518.    sizes are larger than the maximum packet size allowed in the
  519.    underlying protocol when PB-frames option is used. The H.263 payload
  520.    header definition for mode C is shown as follows with F=1 and P=1:
  521.  
  522.     0                   1                   2                   3
  523.     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
  524.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  525.    |F|P|SBIT |EBIT | SRC | QUANT   |  GOBN   |   MBA           |R  |
  526.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  527.    |I|U|S|A| HMV1        | VMV1        | HMV2        | VMV2        |
  528.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  529.    | RR                                  |DBQ| TRB |    TR         |
  530.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  531.  
  532.    The following fields are defined the same as in mode B: F, P, SBIT,
  533.    EBIT, SRC, QUANT, GOBN, MBA, R, I, U, S, A, HMV1, VMV1, HMV2, VMV2.
  534.    The rest of the fields (TR, DBQ, TRB) are defined the same as in mode
  535.    A, except field RR. The RR field takes 19 bits, and is currently
  536.    reserved.  It must be set to zero.
  537.  
  538. 5.4 Selection of Modes for the H.263 Payload Header
  539.  
  540.    Packets carrying H.263 video streams with different modes can be
  541.    intermixed. The modes shall be selected carefully based on network
  542.    packet size, H.263 coding options and underlying network protocols.
  543.    More specifically, mode A shall be used for packets starting with a
  544.    GOB or the H.263 picture start code [4], and mode B or C shall be
  545.    used whenever a packet has to start at a MB boundary. Mode B or C are
  546.    necessary for those GOBs with sizes larger than network packet size.
  547.  
  548.    We strongly recommend use of mode A whenever possible. The major
  549.    advantage of mode A over mode B and C is its simplicity. The H.263
  550.    payload header is smaller than mode B and C. Transmission overhead is
  551.    reduced and the savings may be very significant when working with
  552.    very low data rates or relatively small packet sizes.
  553.  
  554.    Another advantage of mode A is that it simplifies error recovery in
  555.    the presence of packet loss. The internal state of a decoder can be
  556.    recovered at GOB boundaries instead of having to synchronize with MBs
  557.    as in mode B and C. The GOB headers and the picture start code are
  558.    easy to identify,  and their presence will normally cause a H.263
  559.  
  560.  
  561.  
  562. Zhu                         Standards Track                    [Page 10]
  563.  
  564. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  565.  
  566.  
  567.    decoder to re-synchronize its internal states.
  568.  
  569.    Finally, we would like to stress that recovery from packet loss
  570.    depends on a decoder's ability to use the information provided in the
  571.    H.263 payload header within RTP packets.
  572.  
  573. 6. Limitations
  574.  
  575.    The packetization method described in this document applies to the
  576.    1996 version of H.263. It may not be applicable to bitstreams with
  577.    features added after that.
  578.  
  579. Security Considerations
  580.  
  581.    Security issues are addressed by RTP [1].  This memo does not bring
  582.    up any additional security issues.
  583.  
  584. 7. Acknowledgments
  585.  
  586.    The author would like to thank the following people for their
  587.    valuable comments: Linda S. Cline, Christian Maciocco, Mojy
  588.    Mirashrafi, Phillip Lantz, Steve Casner, Gary Sullivan, and Sassan
  589.    Pejhan.
  590.  
  591. 8. References
  592.  
  593. [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
  594.     "RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
  595.     January 1996.
  596.  
  597. [2] International Telecommunication Union.
  598.     Video Codec for Audiovisual Services at  p x 64 kbits/s,
  599.     ITU-T Recommendation H.261, 1993.
  600.  
  601. [3] Schulzrinne, H.,
  602.     "RTP Profile for Audio and Video Conference with Minimal
  603.     Control", RFC 1890,
  604.     January 1996.
  605.  
  606. [4] International Telecommunication Union.
  607.     Video Coding for Low Bitrate Communication, ITU-T Recommendation
  608.     H.263, 1996
  609.  
  610. [5] Turletti, T., and C. Huitema,
  611.     "RTP Payload Format for H.261 Video Streams", RFC 2032,
  612.     October 1996.
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Zhu                         Standards Track                    [Page 11]
  619.  
  620. RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
  621.  
  622.  
  623. [6] International Telecommunication Union.
  624.     Multiplexing Protocol for Low Bitrate Multimedia Communication,
  625.     ITU-T Recommendation H.223, 1995.
  626.  
  627. 7. Author's Address
  628.  
  629.    C. "Chad"  Zhu
  630.    Mail Stop: JF3-202
  631.    Intel Corporation
  632.    2111 N.E. 25th Avenue
  633.    Hillsboro, OR 97124
  634.    USA
  635.  
  636.    EMail: czhu@ibeam.intel.com
  637.    Phone: (503) 264-6008
  638.    Fax: (503) 264-1805
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Zhu                         Standards Track                    [Page 12]
  675.  
  676.