rfc2190.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页


RFC 2190       RTP Payload Format for H.263 Video Streams September 1997


   header is defined in mode C to support fragmentation at MB boundaries
   for frames that are coded with the PB-frames option.

   The mode of each H.263 payload header is indicated by the F and P
   fields in the header. Packets of different modes can be intermixed.
   All client application are required to be able to receive packets in
   any mode, but decoding of mode C packets is optional because the PB-
   frames feature is optional.

   In this section, the H.263 payload format is shown as rows of 32-bit
   words. Each word is transmitted in network byte order. Whenever a
   field represents a numeric value, the most significant bit is at the
   left of the field.

5.1 Mode A

   In this mode, an H.263 bitstream will be packetized on a GOB boundary
   or a picture boundary. Mode A packets always start with the H.263
   picture start code [4] or a GOB, but do not necessarily contain
   complete GOBs. Four bytes are used for the mode A H.263 payload
   header. The H.263 payload header definition for mode A is shown as
   follows with F=0. Mode A packets are allowed to start at a GOB
   boundary even if no GOB header is present in the bitstream for the
   GOB.  However, such use is discouraged due to the dependencies it
   creates across GOB boundaries, as described in Section 3.3.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|P|SBIT |EBIT | SRC |I|U|S|A|R      |DBQ| TRB |    TR         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   F: 1 bit
   The flag bit indicates the mode of the payload header. F=0, mode A;
   F=1, mode B or mode C depending on P bit defined below.

   P: 1 bit
   Optional PB-frames mode as defined by the H.263 [4]. "0" implies
   normal I or P frame, "1" PB-frames. When F=1, P also indicates modes:
   mode B if P=0, mode C if P=1.

   SBIT: 3 bits
   Start bit position specifies number of most significant bits that
   shall be ignored in the first data byte.

   EBIT: 3 bits
   End bit position specifies number of least significant bits that
   shall be ignored in the last data byte.



Zhu                         Standards Track                     [Page 7]

RFC 2190       RTP Payload Format for H.263 Video Streams September 1997


   SRC : 3 bits
   Source format, bit 6,7 and 8 in PTYPE defined by H.263 [4], specifies
   the resolution of the current picture.

   I:  1 bit.
   Picture coding type, bit 9 in PTYPE defined by H.263[4], "0" is
   intra-coded, "1" is inter-coded.

   U: 1 bit
   Set to 1 if the Unrestricted Motion Vector option, bit 10 in PTYPE
   defined by H.263 [4] was set to 1 in the current picture header,
   otherwise 0.

   S: 1 bit
   Set to 1 if the Syntax-based Arithmetic Coding option, bit 11 in
   PTYPE defined by the H.263 [4] was set to 1 for current picture
   header, otherwise 0.

   A: 1 bit
   Set to 1 if the Advanced Prediction option, bit 12 in PTYPE defined
   by H.263 [4] was set to 1 for current picutre header, otherwise 0.

   R: 4 bits
   Reserved, must be set to zero.

   DBQ: 2 bits
   Differential quantization parameter used to calculate quantizer for
   the B frame based on quantizer for the P frame, when PB-frames option
   is used. The value should be the same as DBQUANT defined by H.263
   [4].  Set to zero if PB-frames option is not used.

   TRB: 3 bits
   Temporal Reference for the B frame as defined by H.263 [4]. Set to
   zero if PB-frames option is not used.

   TR: 8 bits
   Temporal Reference for the P frame as defined by H.263 [4]. Set to
   zero if the PB-frames option is not used.

5.2 Mode B

   In this mode, an H.263 bitstream can be fragmented at MB boundaries.
   Whenever a packet starts at a MB boundary, this mode shall be used
   without PB-frames option. Mode B packets are intended for a GOB whose
   size is larger than the maximum packet size allowed in the underlying
   protocol, thus making it impossible to fit one or more complete GOBs
   in a packet. This mode can only be used without the PB-frames option.
   Mode C as defined in the next section can be used to fragment H.263



Zhu                         Standards Track                     [Page 8]

RFC 2190       RTP Payload Format for H.263 Video Streams September 1997


   bitstreams at MB boundaries with the PB-frames option.  The H.263
   payload header definition for mode B is shown as follows with F=1 and
   P=0:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|P|SBIT |EBIT | SRC | QUANT   |  GOBN   |   MBA           |R  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|U|S|A| HMV1        | VMV1        | HMV2        | VMV2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following fields are defined the same as in mode A: F, P, SBIT,
   EBIT, SRC, I, U, S and A. Other fields are defined as follows:

   QUANT: 5 bits
   Quantization value for the first MB coded at the starting of the
   packet.  Set to 0 if the packet begins with a GOB header. This is the
   equivalent of GQUANT defined by the H.263 [4].

   GOBN: 5 bits
   GOB number in effect at the start of the packet. GOB number is
   specified differently for different resolutions. See H.263 [4] for
   details.

   MBA: 9 bits
   The address within the GOB of the first MB in the packet, counting
   from zero in scan order. For example, the third MB in any GOB is
   given MBA = 2.

   HMV1, VMV1: 7 bits each.
   Horizontal and vertical motion vector predictors for the first MB in
   this packet [4]. When four motion vectors are used for current MB
   with advanced prediction option, these would be the motion vector
   predictors for block number 1 in the MB. Each 7 bits field encodes a
   motion vector predictor in half pixel resolution as a 2's complement
   number.

   HMV2, VMV2: 7 bits each.
   Horizontal and vertical motion vector predictors for block number 3
   in the first MB in this packet when four motion vectors are used with
   the advanced prediction option. This is needed because block number 3
   in the MB needs different motion vector predictors from other blocks
   in the MB. These two fields are not used when the MB only has one
   motion vector. See the H.263 [4] for block organization in a
   macroblock.  Each 7 bits field encodes a motion vector predictor in
   half pixel resolution as a 2's complement number.




Zhu                         Standards Track                     [Page 9]

RFC 2190       RTP Payload Format for H.263 Video Streams September 1997


   R : 2 bits
   Reserved, must be set to zero.

5.3 Mode C

   In this mode, an H.263 bitstream is fragmented at MB boundaries of P
   frames with the PB-frames option. It is intended for those GOBs whose
   sizes are larger than the maximum packet size allowed in the
   underlying protocol when PB-frames option is used. The H.263 payload
   header definition for mode C is shown as follows with F=1 and P=1:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|P|SBIT |EBIT | SRC | QUANT   |  GOBN   |   MBA           |R  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|U|S|A| HMV1        | VMV1        | HMV2        | VMV2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RR                                  |DBQ| TRB |    TR         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following fields are defined the same as in mode B: F, P, SBIT,
   EBIT, SRC, QUANT, GOBN, MBA, R, I, U, S, A, HMV1, VMV1, HMV2, VMV2.
   The rest of the fields (TR, DBQ, TRB) are defined the same as in mode
   A, except field RR. The RR field takes 19 bits, and is currently
   reserved.  It must be set to zero.

5.4 Selection of Modes for the H.263 Payload Header

   Packets carrying H.263 video streams with different modes can be
   intermixed. The modes shall be selected carefully based on network
   packet size, H.263 coding options and underlying network protocols.
   More specifically, mode A shall be used for packets starting with a
   GOB or the H.263 picture start code [4], and mode B or C shall be
   used whenever a packet has to start at a MB boundary. Mode B or C are
   necessary for those GOBs with sizes larger than network packet size.

   We strongly recommend use of mode A whenever possible. The major
   advantage of mode A over mode B and C is its simplicity. The H.263
   payload header is smaller than mode B and C. Transmission overhead is
   reduced and the savings may be very significant when working with
   very low data rates or relatively small packet sizes.

   Another advantage of mode A is that it simplifies error recovery in
   the presence of packet loss. The internal state of a decoder can be
   recovered at GOB boundaries instead of having to synchronize with MBs
   as in mode B and C. The GOB headers and the picture start code are
   easy to identify,  and their presence will normally cause a H.263



Zhu                         Standards Track                    [Page 10]

RFC 2190       RTP Payload Format for H.263 Video Streams September 1997


   decoder to re-synchronize its internal states.

   Finally, we would like to stress that recovery from packet loss
   depends on a decoder's ability to use the information provided in the
   H.263 payload header within RTP packets.

6. Limitations

   The packetization method described in this document applies to the
   1996 version of H.263. It may not be applicable to bitstreams with
   features added after that.

Security Considerations

   Security issues are addressed by RTP [1].  This memo does not bring
   up any additional security issues.

7. Acknowledgments

   The author would like to thank the following people for their
   valuable comments: Linda S. Cline, Christian Maciocco, Mojy
   Mirashrafi, Phillip Lantz, Steve Casner, Gary Sullivan, and Sassan
   Pejhan.

8. References

[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
    "RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
    January 1996.

[2] International Telecommunication Union.
    Video Codec for Audiovisual Services at  p x 64 kbits/s,
    ITU-T Recommendation H.261, 1993.

[3] Schulzrinne, H.,
    "RTP Profile for Audio and Video Conference with Minimal
    Control", RFC 1890,
    January 1996.

[4] International Telecommunication Union.
    Video Coding for Low Bitrate Communication, ITU-T Recommendation
    H.263, 1996

[5] Turletti, T., and C. Huitema,
    "RTP Payload Format for H.261 Video Streams", RFC 2032,
    October 1996.





Zhu                         Standards Track                    [Page 11]

RFC 2190       RTP Payload Format for H.263 Video Streams September 1997


[6] International Telecommunication Union.
    Multiplexing Protocol for Low Bitrate Multimedia Communication,
    ITU-T Recommendation H.223, 1995.

7. Author's Address

   C. "Chad"  Zhu
   Mail Stop: JF3-202
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro, OR 97124
   USA

   EMail: [e-mail]
   Phone: [phone]
   Fax: [phone]



































Zhu                         Standards Track                    [Page 12]