doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc2190.txt b/doc/rfc/rfc2190.txt
new file mode 100644
index 0000000..41eb909
--- /dev/null
+++ b/doc/rfc/rfc2190.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                             C. Zhu
+Request for Comments: 2190                                   Intel Corp.
+Category: Standards Track                                 September 1997
+
+
+               RTP Payload Format for H.263 Video Streams
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies the payload format for encapsulating an H.263
+   bitstream in the Real-Time Transport Protocol (RTP). Three modes are
+   defined for the H.263 payload header. An RTP packet can use one of
+   the three modes for H.263 video streams depending on the desired
+   network packet size and H.263 encoding options employed. The shortest
+   H.263 payload header (mode A) supports fragmentation at Group of
+   Block (GOB) boundaries. The long H.263 payload headers (mode B and C)
+   support fragmentation at Macroblock (MB) boundaries.
+
+1. Introduction
+
+   This document describes a scheme to packetize an H.263 video stream
+   for transport using RTP [1]. H.263 video stream is defined by ITU-T
+   Recommendation H.263 (referred to as H.263 in this document) [4] for
+   video coding at very low data rates. RTP is defined by the Internet
+   Engineering Task Force (IETF) to provide end-to-end network transport
+   functions suitable for applications transmitting real-time data over
+   multicast or unicast network services.
+
+2. Definitions
+
+   The following definitions apply in this document:
+
+   CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x
+   288 pixels for luminance, and 176 x 144 pixels for chrominance.
+
+   QCIF: Quarter CIF source format with 176 x 144 pixels for luminance
+   and 88 x 72 pixels for chrominance.
+
+   Sub-QCIF:  picture source format with 128 x 96 pixels for luminance
+   and 64 x 48 pixels for chrominance.
+
+
+
+Zhu                         Standards Track                     [Page 1]
+
+RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
+
+
+   4CIF: Picture source format with 704 x 576 pixels for luminance and
+   352 x 288 pixels for chrominance.
+
+   16CIF: Picture source format with 1408 x 1152 pixels for luminance
+   and 704 x 576 pixels for chrominance.
+
+   GOB: For H.263, a Group of Blocks (GOB) consists of  k*16 lines,
+   where k depends on the picture format (k=1 for QCIF, CIF and sub-
+   QCIF; k=2 for 4CIF and k=4 for 16CIF).
+
+   MB: A macroblock (MB) contains four blocks of luminance and the
+   spatially corresponding two blocks of chrominance. Each block
+   consists of 8x8 pixels. For example, there are eleven MBs in a GOB in
+   QCIF format and twenty two MBs in a GOB in CIF format.
+
+3. Design Issues for Packetizing H.263 Bitstreams
+
+   H.263 is based on the ITU-T Recommendation H.261 [2] (referred to as
+   H.261 in this document). Compared to H.261, H.263 employs similar
+   techniques to reduce both temporal and spatial redundancy, but there
+   are several major differences between the two algorithms that affect
+   the design of packetization schemes significantly. This section
+   summarizes those differences.
+
+3.1 Optional Features of H.263
+
+   In addition to the basic source coding algorithms, H.263 supports
+   four negotiable coding options to improve performance: Advanced
+   Prediction, PB-frames, Syntax-based Arithmetic Coding, and
+   Unrestricted Motion Vectors. They can be used in any combination.
+
+   Advanced Prediction(AP): One or four motion vectors can be used for
+   some macroblocks in a frame. This feature makes recovery from packet
+   loss difficult, because more redundant information has to be
+   preserved at the beginning of a packet when fragmenting at a
+   macroblock boundary.
+
+   PB-frames:  Two frames (a P frame and a B frame) are coded into one
+   bitstream with macroblocks from the two frames interleaved. From a
+   packetization point of view, a MB from the P frame and a MB from the
+   B frame must be treated together because each MB for the B frame is
+   coded based on the corresponding MB for the P frame. A means must be
+   provided to ensure proper rendering of two frames in the right order.
+   Also, if part of this combined bitstream is lost, it will affect both
+   frames, and possibly more.
+
+
+
+
+
+
+Zhu                         Standards Track                     [Page 2]
+
+RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
+
+
+   Syntax-based Arithmetic Coding (SAC): When the SAC option is used,
+   the resultant run-value pair after quantization of Discrete Cosine
+   Transform (DCT) coefficients will be coded differently from Huffman
+   codes, but the macroblock hierarchy will be preserved. Since context
+   variables are only synchronized after fixed length codes in the
+   bitstream, any fragmentation starting at variable length codes will
+   result in difficulty in decoding in the presence of packet loss
+   without carrying the values of all the context variables in each
+   H.263 payload header.
+
+   The Unrestricted motion vectors feature allows large range of motion
+   vectors to improve performance of motion compensation for inter-coded
+   pictures. This option also affects packetization because it uses
+   larger range of motion vectors than normal.
+
+   To enable proper decoding of packets received, without dependency on
+   previous packets, the use of these optional features is signaled in
+   the H.263 payload header, as described in Section 5.
+
+3.2 GOB Numbering
+
+   In H.263, each picture is divided into groups of blocks (GOB). GOBs
+   are numbered according to a vertical scan of a picture, starting with
+   the top GOB and ending with the bottom GOB. In contrast, a GOB in
+   H.261 is composed of three rows of 16x16 MB for QCIF, and three
+   half-rows of MBs for CIF. A GOB is divided into macroblocks in H.263
+   and the definition of the macroblocks are the same as in H.261.
+
+   Each GOB in H.263 can have a fixed GOB header, but the use of the
+   header is optional. If the GOB header is present, it may or may not
+   start on a byte boundary. Byte alignment can be achieved by proper
+   bit stuffing by the encoder, but it is not required by the H.263
+   bitstream specification [4].
+
+   In summary, a GOB in H.263 is defined and coded with finer
+   granularity but with the same source format, resulting in more
+   flexibility for packetization than with H.261.
+
+3.3 Motion Vector Encoding
+
+   Differential coding is used to code motion vectors as variable length
+   codes. Unlike in H.261, where each motion vector is predicted from
+   the previous MB in the GOB, H.263 employs a more flexible prediction
+   scheme, where one or three candidate predictors could be used
+   depending on the presence of GOB headers.
+
+
+
+
+
+
+Zhu                         Standards Track                     [Page 3]
+
+RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
+
+
+   If the GOB header is present in a GOB, motion vectors are coded with
+   reference to MBs in the current GOB only. If a GOB header is not
+   present in the current GOB, three motion vectors must be available to
+   decode one macroblock, where two of them might come from the previous
+   GOB. To correctly decode a whole inter-coded GOB, all the motion
+   vectors for MBs in the previous GOB  must be available to compute the
+   predictors or the predictors themselves must be present. The optional
+   use of three motion vector predictors can be a major problem for a
+   packetization scheme like the one defined for H.261 when packetizing
+   at MB boundaries [5].
+
+   Consider the case that a packet starts with a MB but the GOB header
+   is not present. If the previous packet is lost, then all the motion
+   vectors needed to predict the motion vectors for the MBs in the
+   current GOB are not available. In order to decode the received MBs
+   correctly, all the motion vectors for the previous GOB or the motion
+   vector predictors would have to be duplicated at the beginning of the
+   packet. This kind of duplication would be very expensive and
+   unacceptable in terms of bandwidth overhead.
+
+   The encoding strategy of each H.263 CODEC (CODer and DECoder)
+   implementation is beyond the scope of this document, even though it
+   has significant effect on visual quality in the presence of packet
+   loss. However, we strongly recommend use of the GOB header for every
+   GOB at the beginning of a packet to address this problem.
+
+   Similar problems exist because of cross-GOB data dependency related
+   to motion vectors, but they can not be addressed by using the GOB
+   header. For 16CIF and 4CIF pictures, a GOB contains more than one row
+   of MBs. If a GOB can not fit in one RTP packet, and the first packet
+   containing the GOB header is lost, then MBs in the second packet can
+   not compute motion vectors correctly, because they are coded relative
+   to data in the lost packet. Similarly,  when OBMC (Overlapped Block
+   Motion Compensation) [4] in Advanced Prediction mode is used, motion
+   compensation for some MBs in one GOB could use motion vectors of MBs
+   in previous GOB regardless of the presence of GOB header. When MBs
+   that are used to decode received MBs are lost, those received MBs can
+   not be decoded correctly. Each implementation of the method described
+   in this document should take these limitations into account.
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                         Standards Track                     [Page 4]
+
+RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
+
+
+3.4 Macroblock Address
+
+   As specified by H.261, a macroblock address (MBA) is encoded with a
+   variable length code to indicate the position of a macroblock within
+   a group of MBs in H.261 bitstreams. H.263 does not code the MBA
+   explicitly, but the macroblock address within a GOB is necessary to
+   recover from packet loss when fragmenting at MB boundaries.
+   Therefore, this information must be included in the H.263 payload
+   header for modes (mode B and mode C as described in Section 5) that
+   allow packetization at MB boundaries.
+
+4. Usage of RTP
+
+   When transmitting H.263 video streams over the Internet, the output
+   of the encoder can be packetized directly. For every video frame, the
+   H.263 bitstream itself is carried in the RTP payload without
+   alteration, including the picture start code, the entire picture
+   header, in addition to any fixed length codes and variable length
+   codes.  In addition, the output of the encoder is packetized without
+   adding the framing information specified by H.223 [6]. Therefore
+   multiplexing audio and video signals in the same packet is not
+   accommodated, as UDP and RTP provide a much more efficient way to
+   achieve multiplexing.
+
+   RTP does not guarantee a reliable and orderly data delivery service,
+   so a packet might get lost in the network. To achieve a best-effort
+   recovery from packet loss, the decoder needs assistance to proceed
+   with decoding of other packets that are received. Thus it is
+   desirable to be able to process each packet independent of other
+   packets. Some frame level information is included in each packet,
+   such as source format and flags for optional features to assist the
+   decoder in operating correctly and efficiently in presence of packet
+   loss. The flags for H.263 optional features also provide information
+   about coding options used in H.263 video bitstreams that can be used
+   by session management tools.
+
+   H.263 video bitstreams will be carried as payload data within RTP
+   packets. A new H.263 payload header is defined in section 5 on the
+   H.263 payload header. This section defines the usage of RTP fixed
+   header and H.263 video packet structure.
+
+4.1 RTP Header Usage
+
+   Each RTP packet starts with a fixed RTP header [1]. The following
+   fields of the RTP fixed header are used for H.263 video streams:
+
+
+
+
+
+
+Zhu                         Standards Track                     [Page 5]
+
+RFC 2190       RTP Payload Format for H.263 Video Streams September 1997
+
+
+   Marker bit (M bit): The Marker bit of the RTP fixed header is set to
+   1 when the current packet carries the end of current frame; set to 0
+   otherwise.
+
+   Payload Type (PT): The Payload Type shall specify H.263 video payload
+   format using the value specified by the RTP profile in use, for
+   example RFC 1890 [3].
+
+   Timestamp: The RTP timestamp encodes the sampling instant of the
+   video frame contained in the RTP data packet. The RTP timestamp may
+   be the same  on successive packets if a video frame occupies more
+   than one packet. For H.263 video streams, the RTP timestamp is based
+   on a 90 kHz clock, the same as the RTP timestamp for H.261 video
+   streams [5].
+
+4.2 Video Packet Structure
+
+   For each RTP packet, the RTP fixed header is followed by the H.263
+   payload header, which is followed by the standard H.263 compressed
+   bitstream [4].
+
+   The size of the H.263 payload header is variable depending on modes
+   used as detailed in the next section. The layout of an RTP H.263
+   video packet is shown as:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 RTP header                                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 H.263 payload header                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 H.263 bitstream                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+5. H.263 Payload Header
+
+   For H.263 video streams, each RTP packet carries only one H.263 video
+   packet. The H.263 payload header is always present for each H.263
+   video packet.
+
+   Three formats (mode A, mode B and mode C) are defined for H.263
+   payload header. In mode A, an H.263 payload header of four bytes is
+   present before actual compressed H.263 video bitstream in a packet.
+   It allows fragmentation at GOB boundaries. In mode B, an eight byte
+   H.263 payload header is used and each packet starts at MB boundaries
+   without the PB-frames option. Finally, a twelve byte H.263 payload
+
+
+
+Zhu                         Standards Track                     [Page 6]
+
+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: czhu@ibeam.intel.com
+   Phone: (503) 264-6008
+   Fax: (503) 264-1805
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhu                         Standards Track                    [Page 12]
+