doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc2429.txt b/doc/rfc/rfc2429.txt
new file mode 100644
index 0000000..1d85999
--- /dev/null
+++ b/doc/rfc/rfc2429.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group
+Request for Comments: 2429                                    C. Bormann
+Category: Standards Track                                   Univ. Bremen
+                                                                L. Cline
+                                                              G. Deisher
+                                                               T. Gardos
+                                                             C. Maciocco
+                                                               D. Newell
+                                                                   Intel
+                                                                  J. Ott
+                                                            Univ. Bremen
+                                                             G. Sullivan
+                                                              PictureTel
+                                                               S. Wenger
+                                                               TU Berlin
+                                                                  C. Zhu
+                                                                   Intel
+                                                            October 1998
+
+
+               RTP Payload Format for the 1998 Version of
+                    ITU-T Rec. H.263 Video (H.263+)
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1. Introduction
+
+   This document specifies an RTP payload header format applicable to
+   the transmission of video streams generated based on the 1998 version
+   of ITU-T Recommendation H.263 [4].  Because the 1998 version of H.263
+   is a superset of the 1996 syntax, this format can also be used with
+   the 1996 version of H.263 [3], and is recommended for this use by new
+   implementations.  This format does not replace RFC 2190, which
+   continues to be used by existing implementations, and may be required
+   for backward compatibility in new implementations.  Implementations
+   using the new features of the 1998 version of H.263 shall use the
+   format described in this document.
+
+
+
+
+Bormann, et. al.            Standards Track                     [Page 1]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   The 1998 version of ITU-T Recommendation H.263 added numerous coding
+   options to improve codec performance over the 1996 version.  The 1998
+   version is referred to as H.263+ in this document.  Among the new
+   options, the ones with the biggest impact on the RTP payload
+   specification and the error resilience of the video content are the
+   slice structured mode, the independent segment decoding mode, the
+   reference picture selection mode, and the scalability mode.  This
+   section summarizes the impact of these new coding options on
+   packetization.  Refer to [4] for more information on coding options.
+
+   The slice structured mode was added to H.263+ for three purposes: to
+   provide enhanced error resilience capability, to make the bitstream
+   more amenable to use with an underlying packet transport such as RTP,
+   and to minimize video delay.  The slice structured mode supports
+   fragmentation at macroblock boundaries.
+
+   With the independent segment decoding (ISD) option, a video picture
+   frame is broken into segments and encoded in such a way that each
+   segment is independently decodable.  Utilizing ISD in a lossy network
+   environment helps to prevent the propagation of errors from one
+   segment of the picture to others.
+
+   The reference picture selection mode allows the use of an older
+   reference picture rather than the one immediately preceding the
+   current picture.  Usually, the last transmitted frame is implicitly
+   used as the reference picture for inter-frame prediction.  If the
+   reference picture selection mode is used, the data stream carries
+   information on what reference frame should be used, indicated by the
+   temporal reference as an ID for that reference frame.  The reference
+   picture selection mode can be used with or without a back channel,
+   which provides information to the encoder about the internal status
+   of the decoder.  However, no special provision is made herein for
+   carrying back channel information.
+
+   H.263+ also includes bitstream scalability as an optional coding
+   mode.  Three kinds of scalability are defined: temporal, signal-to-
+   noise ratio (SNR), and spatial scalability.  Temporal scalability is
+   achieved via the disposable nature of bi-directionally predicted
+   frames, or B-frames. (A low-delay form of temporal scalability known
+   as P-picture temporal scalability can also be achieved by using the
+   reference picture selection mode described in the previous
+   paragraph.)  SNR scalability permits refinement of encoded video
+   frames, thereby improving the quality (or SNR).  Spatial scalability
+   is similar to SNR scalability except the refinement layer is twice
+   the size of the base layer in the horizontal dimension, vertical
+   dimension, or both.
+
+
+
+
+
+Bormann, et. al.            Standards Track                     [Page 2]
+
+RFC 2429                         H.263+                     October 1998
+
+
+2. Usage of RTP
+
+   When transmitting H.263+ video streams over the Internet, the output
+   of the encoder can be packetized directly.  All the bits resulting
+   from the bitstream including the fixed length codes and variable
+   length codes will be included in the packet, with the only exception
+   being that when the payload of a packet begins with a Picture, GOB,
+   Slice, EOS, or EOSBS start code, the first two (all-zero) bytes of
+   the start code are removed and replaced by setting an indicator bit
+   in the payload header.
+
+   For H.263+ bitstreams coded with temporal, spatial, or SNR
+   scalability, each layer may be transported to a different network
+   address.  More specifically, each layer may use a unique IP address
+   and port number combination.  The temporal relations between layers
+   shall be expressed using the RTP timestamp so that they can be
+   synchronized at the receiving ends in multicast or unicast
+   applications.
+
+   The H.263+ video stream will be carried as payload data within RTP
+   packets.  A new H.263+ payload header is defined in section 4.  This
+   section defines the usage of the RTP fixed header and H.263+ video
+   packet structure.
+
+2.1 RTP Header Usage
+
+   Each RTP packet starts with a fixed RTP header.  The following fields
+   of the RTP fixed header are used for H.263+ video streams:
+
+   Marker bit (M bit): The Marker bit of the RTP header is set to 1 when
+   the current packet carries the end of current frame, and is 0
+   otherwise.
+
+   Payload Type (PT): The Payload Type shall specify the H.263+ video
+   payload format.
+
+   Timestamp: The RTP Timestamp encodes the sampling instance of the
+   first video frame data contained in the RTP data packet.  The RTP
+   timestamp shall be the same on successive packets if a video frame
+   occupies more than one packet.  In a multilayer scenario, all
+   pictures corresponding to the same temporal reference should use the
+   same timestamp.  If temporal scalability is used (if B-frames are
+   present), the timestamp may not be monotonically increasing in the
+   RTP stream.  If B-frames are transmitted on a separate layer and
+   address, they must be synchronized properly with the reference
+   frames.  Refer to the 1998 ITU-T Recommendation H.263 [4] for
+   information on required transmission order to a decoder.  For an
+   H.263+ video stream, the RTP timestamp is based on a 90 kHz clock,
+
+
+
+Bormann, et. al.            Standards Track                     [Page 3]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   the same as that of the RTP payload for H.261 stream [5].  Since both
+   the H.263+ data and the RTP header contain time information, it is
+   required that those timing information run synchronously.  That is,
+   both the RTP timestamp and the temporal reference (TR in the picture
+   header of H.263) should carry the same relative timing information.
+   Any H.263+ picture clock frequency can be expressed as
+   1800000/(cd*cf) source pictures per second, in which cd is an integer
+   from 1 to 127 and cf is either 1000 or 1001.  Using the 90 kHz clock
+   of the RTP timestamp, the time increment between each coded H.263+
+   picture should therefore be a integer multiple of (cd*cf)/20. This
+   will always be an integer for any "reasonable" picture clock
+   frequency (for example, it is 3003 for 29.97 Hz NTSC, 3600 for 25 Hz
+   PAL, 3750 for 24 Hz film, and 1500, 1250 and 1200 for the computer
+   display update rates of 60, 72 and 75 Hz, respectively).  For RTP
+   packetization of hypothetical H.263+ bitstreams using "unreasonable"
+   custom picture clock frequencies, mathematical rounding could become
+   necessary for generating the RTP timestamps.
+
+2.2 Video Packet Structure
+
+   A section of an H.263+ compressed bitstream is carried as a payload
+   within each RTP packet.  For each RTP packet, the RTP header is
+   followed by an H.263+ payload header, which is followed by a number
+   of bytes of a standard H.263+ compressed bitstream.  The size of the
+   H.263+ payload header is variable depending on the payload involved
+   as detailed in the section 4.  The layout of the 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+ Compressed Data Stream                            ...
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Any H.263+ start codes can be byte aligned by an encoder by using the
+   stuffing mechanisms of H.263+.  As specified in H.263+, picture,
+   slice, and EOSBS starts codes shall always be byte aligned, and GOB
+   and EOS start codes may be byte aligned.  For packetization purposes,
+   GOB start codes should be byte aligned; however, since this is not
+   required in H.263+, there may be some cases where GOB start codes are
+   not aligned, such as when transmitting existing content, or when
+   using H.263 encoders that do not support GOB start code alignment.
+   In this case, follow-on packets (see section 5.2) should be used for
+   packetization.
+
+
+
+Bormann, et. al.            Standards Track                     [Page 4]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin
+   with 16 zero-valued bits.  If a start code is byte aligned and it
+   occurs at the beginning of a packet, these two bytes shall be removed
+   from the H.263+ compressed data stream in the packetization process
+   and shall instead be represented by setting a bit (the P bit) in the
+   payload header.
+
+3. Design Considerations
+
+   The goals of this payload format are to specify an efficient way of
+   encapsulating an H.263+ standard compliant bitstream and to enhance
+   the resiliency towards packet losses.  Due to the large number of
+   different possible coding schemes in H.263+, a copy of the picture
+   header with configuration information is inserted into the payload
+   header when appropriate.  The use of that copy of the picture header
+   along with the payload data can allow decoding of a received packet
+   even in such cases in which another packet containing the original
+   picture header becomes lost.
+
+   There are a few assumptions and constraints associated with this
+   H.263+ payload header design.  The purpose of this section is to
+   point out various design issues and also to discuss several coding
+   options provided by H.263+ that may impact the performance of
+   network-based H.263+ video.
+
+   o The optional slice structured mode described in Annex K of H.263+
+     [4] enables more flexibility for packetization.  Similar to a
+     picture segment that begins with a GOB header, the motion vector
+     predictors in a slice are restricted to reside within its
+     boundaries.  However, slices provide much greater freedom in the
+     selection of the size and shape of the area which is represented as
+     a distinct decodable region. In particular, slices can have a size
+     which is dynamically selected to allow the data for each slice to
+     fit into a chosen packet size. Slices can also be chosen to have a
+     rectangular shape which is conducive for minimizing the impact of
+     errors and packet losses on motion compensated prediction.  For
+     these reasons, the use of the slice structured mode is strongly
+     recommended for any applications used in environments where
+     significant packet loss occurs.
+
+   o In non-rectangular slice structured mode, only complete slices
+     should be included in a packet.  In other words, slices should not
+     be fragmented across packet boundaries.  The only reasonable need
+     for a slice to be fragmented across packet boundaries is when the
+     encoder which generated the H.263+ data stream could not be
+     influenced by an awareness of the packetization process (such as
+     when sending H.263+ data through a network other than the one to
+     which the encoder is attached, as in network gateway
+
+
+
+Bormann, et. al.            Standards Track                     [Page 5]
+
+RFC 2429                         H.263+                     October 1998
+
+
+     implementations).  Optimally, each packet will contain only one
+     slice.
+
+   o The independent segment decoding (ISD) described in Annex R of [4]
+     prevents any data dependency across slice or GOB boundaries in the
+     reference picture.  It can be utilized to further improve
+     resiliency in high loss conditions.
+
+   o If ISD is used in conjunction with the slice structure, the
+     rectangular slice submode shall be enabled and the dimensions and
+     quantity of the slices present in a frame shall remain the same
+     between each two intra-coded frames (I-frames), as required in
+     H.263+. The individual ISD segments may also be entirely intra
+     coded from time to time to realize quick error recovery without
+     adding the latency time associated with sending complete INTRA-
+     pictures.
+
+   o When the slice structure is not applied, the insertion of a
+     (preferably byte-aligned) GOB header can be used to provide resync
+     boundaries in the bitstream, as the presence of a GOB header
+     eliminates the dependency of motion vector prediction across GOB
+     boundaries.  These resync boundaries provide natural locations for
+     packet payload boundaries.
+
+   o H.263+ allows picture headers to be sent in an abbreviated form in
+     order to prevent repetition of overhead information that does not
+     change from picture to picture.  For resiliency, sending a complete
+     picture header for every frame is often advisable.  This means that
+     (especially in cases with high packet loss probability in which
+     picture header contents are not expected to be highly predictable),
+     the sender may find it advisable to always set the subfield UFEP in
+     PLUSPTYPE to '001' in the H.263+ video bitstream.  (See [4] for the
+     definition of the UFEP and PLUSPTYPE fields).
+
+   o In a multi-layer scenario, each layer may be transmitted to a
+     different network address.  The configuration of each layer such as
+     the enhancement layer number (ELNUM), reference layer number
+     (RLNUM), and scalability type should be determined at the start of
+     the session and should not change during the course of the session.
+
+   o All start codes can be byte aligned, and picture, slice, and EOSBS
+     start codes are always byte aligned.  The boundaries of these
+     syntactical elements provide ideal locations for placing packet
+     boundaries.
+
+
+
+
+
+
+
+Bormann, et. al.            Standards Track                     [Page 6]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   o We assume that a maximum Picture Header size of 504 bits is
+     sufficient.  The syntax of H.263+ does not explicitly prohibit
+     larger picture header sizes, but the use of such extremely large
+     picture headers is not expected.
+
+4. 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.  The payload header is of variable length.  A 16
+   bit field of the basic payload header may be followed by an 8 bit
+   field for Video Redundancy Coding (VRC) information, and/or by a
+   variable length extra picture header as indicated by PLEN. These
+   optional fields appear in the order given above when present.
+
+   If an extra picture header is included in the payload header, the
+   length of the picture header in number of bytes is specified by PLEN.
+   The minimum length of the payload header is 16 bits, corresponding to
+   PLEN equal to 0 and no VRC information present.
+
+   The remainder of this section defines the various components of the
+   RTP payload header.  Section five defines the various packet types
+   that are used to carry different types of H.263+ coded data, and
+   section six summarizes how to distinguish between the various packet
+   types.
+
+4.1 General H.263+ payload header
+
+   The H.263+ payload header is structured as follows:
+
+      0                   1
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   RR    |P|V|   PLEN    |PEBIT|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   RR: 5 bits
+     Reserved bits.  Shall be zero.
+
+   P: 1 bit
+     Indicates the picture start or a picture segment (GOB/Slice) start
+     or a video sequence end (EOS or EOSBS).  Two bytes of zero bits
+     then have to be prefixed to the payload of such a packet to compose
+     a complete picture/GOB/slice/EOS/EOSBS start code.  This bit allows
+     the omission of the two first bytes of the start codes, thus
+     improving the compression ratio.
+
+
+
+
+
+Bormann, et. al.            Standards Track                     [Page 7]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   V: 1 bit
+     Indicates the presence of an 8 bit field containing information for
+     Video Redundancy Coding (VRC), which follows immediately after the
+     initial 16 bits of the payload header if present.  For syntax and
+     semantics of that 8 bit VRC field see section 4.2.
+
+   PLEN: 6 bits
+     Length in bytes of the extra picture header.  If no extra picture
+     header is attached, PLEN is 0.  If PLEN>0, the extra picture header
+     is attached immediately following the rest of the payload header.
+     Note the length reflects the omission of the first two bytes of the
+     picture start code (PSC).  See section 5.1.
+
+   PEBIT: 3 bits
+     Indicates the number of bits that shall be ignored in the last byte
+     of the picture header.  If PLEN is not zero, the ignored bits shall
+     be the least significant bits of the byte.  If PLEN is zero, then
+     PEBIT shall also be zero.
+
+4.2 Video Redundancy Coding Header Extension
+
+   Video Redundancy Coding (VRC) is an optional mechanism intended to
+   improve error resilience over packet networks.  Implementing VRC in
+   H.263+ will require the Reference Picture Selection option described
+   in Annex N of [4].  By having multiple "threads" of independently
+   inter-frame predicted pictures, damage of individual frame will cause
+   distortions only within its own thread but leave the other threads
+   unaffected.  From time to time, all threads converge to a so-called
+   sync frame (an INTRA picture or a non-INTRA picture which is
+   redundantly represented within multiple threads); from this sync
+   frame, the independent threads are started again.  For more
+   information on codec support for VRC see [7].
+
+   P-picture temporal scalability is another use of the reference
+   picture selection mode and can be considered a special case of VRC in
+   which only one copy of each sync frame may be sent.  It offers a
+   thread-based method of temporal scalability without the increased
+   delay caused by the use of B pictures.  In this use, sync frames sent
+   in the first thread of pictures are also used for the prediction of a
+   second thread of pictures which fall temporally between the sync
+   frames to increase the resulting frame rate.  In this use, the
+   pictures in the second thread can be discarded in order to obtain a
+   reduction of bit rate or decoding complexity without harming the
+   ability to decode later pictures.  A third or more threads can also
+   be added as well, but each thread is predicted only from the sync
+   frames (which are sent at least in thread 0) or from frames within
+   the same thread.
+
+
+
+
+Bormann, et. al.            Standards Track                     [Page 8]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   While a VRC data stream is - like all H.263+ data - totally self-
+   contained, it may be useful for the transport hierarchy
+   implementation to have knowledge about the current damage status of
+   each thread.  On the Internet, this status can easily be determined
+   by observing the marker bit, the sequence number of the RTP header,
+   and the thread-id and a circling "packet per thread" number.  The
+   latter two numbers are coded in the VRC header extension.
+
+   The format of the VRC header extension is as follows:
+
+      0 1 2 3 4 5 6 7
+     +-+-+-+-+-+-+-+-+
+     | TID | Trun  |S|
+     +-+-+-+-+-+-+-+-+
+
+   TID: 3 bits
+     Thread ID.  Up to 7 threads are allowed. Each frame of H.263+ VRC
+     data will use as reference information only sync frames or frames
+     within the same thread.  By convention, thread 0 is expected to be
+     the "canonical" thread, which is the thread from which the sync
+     frame should ideally be used.  In the case of corruption or loss of
+     the thread 0 representation, a representation of the sync frame
+     with a higher thread number can be used by the decoder.  Lower
+     thread numbers are expected to contain equal or better
+     representations of the sync frames than higher thread numbers in
+     the absence of data corruption or loss.  See [7] for a detailed
+     discussion of VRC.
+
+   Trun: 4 bits
+     Monotonically increasing (modulo 16) 4 bit number counting the
+     packet number within each thread.
+
+   S: 1 bit
+     A bit that indicates that the packet content is for a sync frame.
+     An encoder using VRC may send several representations of the same
+     "sync" picture, in order to ensure that regardless of which thread
+     of pictures is corrupted by errors or packet losses, the reception
+     of at least one representation of a particular picture is ensured
+     (within at least one thread).  The sync picture can then be used
+     for the prediction of any thread.  If packet losses have not
+     occurred, then the sync frame contents of thread 0 can be used and
+     those of other threads can be discarded (and similarly for other
+     threads).  Thread 0 is considered the "canonical" thread, the use
+     of which is preferable to all others.  The contents of packets
+     having lower thread numbers shall be considered as having a higher
+     processing and delivery priority than those with higher thread
+     numbers.  Thus packets having lower thread numbers for a given sync
+     frame shall be delivered first to the decoder under loss-free and
+
+
+
+Bormann, et. al.            Standards Track                     [Page 9]
+
+RFC 2429                         H.263+                     October 1998
+
+
+     low-time-jitter conditions, which will result in the discarding of
+     the sync contents of the higher-numbered threads as specified in
+     Annex N of [4].
+
+5. Packetization schemes
+
+5.1 Picture Segment Packets and Sequence Ending Packets (P=1)
+
+   A picture segment packet is defined as a packet that starts at the
+   location of a Picture, GOB, or slice start code in the H.263+ data
+   stream.  This corresponds to the definition of the start of a video
+   picture segment as defined in H.263+.  For such packets, P=1 always.
+
+   An extra picture header can sometimes be attached in the payload
+   header of such packets.  Whenever an extra picture header is attached
+   as signified by PLEN>0, only the last six bits of its picture start
+   code, '100000', are included in the payload header.  A complete
+   H.263+ picture header with byte aligned picture start code can be
+   conveniently assembled on the receiving end by prepending the sixteen
+   leading '0' bits.
+
+   When PLEN>0, the end bit position corresponding to the last byte of
+   the picture header data is indicated by PEBIT.  The actual bitstream
+   data shall begin on an 8-bit byte boundary following the payload
+   header.
+
+   A sequence ending packet is defined as a packet that starts at the
+   location of an EOS or EOSBS code in the H.263+ data stream.  This
+   delineates the end of a sequence of H.263+ video data (more H.263+
+   video data may still follow later, however, as specified in ITU-T
+   Recommendation H.263).  For such packets, P=1 and PLEN=0 always.
+
+   The optional header extension for VRC may or may not be present as
+   indicated by the V bit flag.
+
+5.1.1 Packets that begin with a Picture Start Code
+
+   Any packet that contains the whole or the start of a coded picture
+   shall start at the location of the picture start code (PSC), and
+   should normally be encapsulated with no extra copy of the picture
+   header. In other words, normally PLEN=0 in such a case.   However, if
+   the coded picture contains an incomplete picture header (UFEP =
+   "000"), then a representation of the complete (UFEP = "001") picture
+   header may be attached during packetization in order to provide
+   greater error resilience.  Thus, for packets that start at the
+   location of a picture start code, PLEN shall be zero unless both of
+   the following conditions apply:
+
+
+
+
+Bormann, et. al.            Standards Track                    [Page 10]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   1) The picture header in the H.263+ bitstream payload is incomplete
+      (PLUSPTYPE present and UFEP="000"), and
+
+   2) The additional picture header which is attached is not incomplete
+      (UFEP="001").
+
+   A packet which begins at the location of a Picture, GOB, slice, EOS,
+   or EOSBS start code shall omit the first two (all zero) bytes from
+   the H.263+ bitstream, and signify their presence by setting P=1 in
+   the payload header.
+
+   Here is an example of encapsulating the first packet in a frame
+   (without an attached redundant complete picture header):
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   RR    |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | first two 0 bytes of the PSC                                ...
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.1.2 Packets that begin with GBSC or SSC
+
+   For a packet that begins at the location of a GOB or slice start
+   code, PLEN may be zero or may be nonzero, depending on whether a
+   redundant picture header is attached to the packet.  In environments
+   with very low packet loss rates, or when picture header contents are
+   very seldom likely to change (except as can be detected from the GFID
+   syntax of H.263+), a redundant copy of the picture header is not
+   required. However, in less ideal circumstances a redundant picture
+   header should be attached for enhanced error resilience, and its
+   presence is indicated by PLEN>0.
+
+   Assuming a PLEN of 9 and P=1, below is an example of a packet that
+   begins with a byte aligned GBSC or a SSC:
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   RR    |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header    |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | starting with TR, PTYPE ...                                   |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | ...                                           | bitstream     |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | data starting with GBSC/SSC without its first two 0 bytes   ...
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Bormann, et. al.            Standards Track                    [Page 11]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   Notice that only the last six bits of the picture start code,
+   '100000', are included in the payload header.  A complete H.263+
+   picture header with byte aligned picture start code can be
+   conveniently assembled if needed on the receiving end by prepending
+   the sixteen leading '0' bits.
+
+5.1.3 Packets that Begin with an EOS or EOSBS Code
+
+   For a packet that begins with an EOS or EOSBS code, PLEN shall be
+   zero, and no Picture, GOB, or Slice start codes shall be included
+   within the same packet.  As with other packets beginning with start
+   codes, the two all-zero bytes that begin the EOS or EOSBS code at the
+   beginning of the packet shall be omitted, and their presence shall be
+   indicated by setting the P bit to 1 in the payload header.
+
+   System designers should be aware that some decoders may interpret the
+   loss of a packet containing only EOS or EOSBS information as the loss
+   of essential video data and may thus respond by not displaying some
+   subsequent video information.  Since EOS and EOSBS codes do not
+   actually affect the decoding of video pictures, they are somewhat
+   unnecessary to send at all.  Because of the danger of
+   misinterpretation of the loss of such a packet (which can be detected
+   by the sequence number), encoders are generally to be discouraged
+   from sending EOS and EOSBS.
+
+   Below is an example of a packet containing an EOS code:
+
+      0                   1                   2
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   RR    |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0|
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   5.2 Encapsulating Follow-On Packet (P=0)
+
+   A Follow-on packet contains a number of bytes of coded H.263+ data
+   which does not start at a synchronization point.  That is, a Follow-
+   On packet does not start with a Picture, GOB, Slice, EOS, or EOSBS
+   header, and it may or may not start at a macroblock boundary.  Since
+   Follow-on packets do not start at synchronization points, the data at
+   the beginning of a follow-on packet is not independently decodable.
+   For such packets, P=0 always.  If the preceding packet of a Follow-on
+   packet got lost, the receiver may discard that Follow-on packet as
+   well as all other following Follow-on packets.  Better behavior, of
+   course, would be for the receiver to scan the interior of the packet
+   payload content to determine whether any start codes are found in the
+   interior of the packet which can be used as resync points.  The use
+   of an attached copy of a picture header for a follow-on packet is
+
+
+
+Bormann, et. al.            Standards Track                    [Page 12]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   useful only if the interior of the packet or some subsequent follow-
+   on packet contains a resync code such as a GOB or slice start code.
+   PLEN>0 is allowed, since it may allow resync in the interior of the
+   packet.  The decoder may also be resynchronized at the next segment
+   or picture packet.
+
+   Here is an example of a follow-on packet (with PLEN=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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   RR    |0|V|0|0|0|0|0|0|0|0|0| bitstream data              ...
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+6. Use of this payload specification
+
+   There is no syntactical difference between a picture segment packet and
+   a Follow-on packet, other than the indication P=1 for picture segment or
+   sequence ending packets and P=0 for Follow-on packets.  See the
+   following for a summary of the entire packet types and ways to
+   distinguish between them.
+
+   It is possible to distinguish between the different packet types by
+   checking the P bit and the first 6 bits of the payload along with the
+   header information.  The following table shows the packet type for
+   permutations of this information (see also the picture/GOB/Slice header
+   descriptions in H.263+ for details):
+
+--------------+--------------+----------------------+-------------------
+ First 6 bits | P-Bit | PLEN |  Packet              |  Remarks
+ of Payload   |(payload hdr.)|                      |
+--------------+--------------+----------------------+-------------------
+ 100000       |   1   |  0   |  Picture             |  Typical Picture
+ 100000       |   1   | > 0  |  Picture             |  Note UFEP
+ 1xxxxx       |   1   |  0   |  GOB/Slice/EOS/EOSBS |  See possible GNs
+ 1xxxxx       |   1   | > 0  |  GOB/Slice           |  See possible GNs
+ Xxxxxx       |   0   |  0   |  Follow-on           |
+ Xxxxxx       |   0   | > 0  |  Follow-on           |  Interior Resync
+--------------+--------------+----------------------+-------------------
+
+   The details regarding the possible values of the five bit Group
+   Number (GN) field which follows the initial "1" bit when the P-bit is
+   "1" for a GOB, Slice, EOS, or EOSBS packet are found in section 5.2.3
+   of [4].
+
+   As defined in this specification, every start of a coded frame (as
+   indicated by the presence of a PSC) has to be encapsulated as a
+   picture segment packet.  If the whole coded picture fits into one
+
+
+
+Bormann, et. al.            Standards Track                    [Page 13]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   packet of reasonable size (which is dependent on the connection
+   characteristics), this is the only type of packet that may need to be
+   used.  Due to the high compression ratio achieved by H.263+ it is
+   often possible to use this mechanism, especially for small spatial
+   picture formats such as QCIF and typical Internet packet sizes around
+   1500 bytes.
+
+   If the complete coded frame does not fit into a single packet, two
+   different ways for the packetization may be chosen.  In case of very
+   low or zero packet loss probability, one or more Follow-on packets
+   may be used for coding the rest of the picture.  Doing so leads to
+   minimal coding and packetization overhead as well as to an optimal
+   use of the maximal packet size, but does not provide any added error
+   resilience.
+
+   The alternative is to break the picture into reasonably small
+   partitions - called Segments - (by using the Slice or GOB mechanism),
+   that do offer synchronization points.  By doing so and using the
+   Picture Segment payload with PLEN>0, decoding of the transmitted
+   packets is possible even in such cases in which the Picture packet
+   containing the picture header was lost (provided any necessary
+   reference picture is available). Picture Segment packets can also be
+   used in conjunction with Follow-on packets for large segment sizes.
+
+7. Security Considerations
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [1], and any appropriate RTP profile (for example [2]).
+   This implies that confidentiality of the media streams is achieved by
+   encryption.  Because the data compression used with this payload
+   format is applied end-to-end, encryption may be performed after
+   compression so there is no conflict between the two operations.
+
+   A potential denial-of-service threat exists for data encodings using
+   compression techniques that have non-uniform receiver-end
+   computational load.  The attacker can inject pathological datagrams
+   into the stream which are complex to decode and cause the receiver to
+   be overloaded.  However, this encoding does not exhibit any
+   significant non-uniformity.
+
+   As with any IP-based protocol, in some circumstances a receiver may
+   be overloaded simply by the receipt of too many packets, either
+   desired or undesired.  Network-layer authentication may be used to
+   discard packets from undesired sources, but the processing cost of
+   the authentication itself may be too high.  In a multicast
+
+
+
+
+
+Bormann, et. al.            Standards Track                    [Page 14]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   environment, pruning of specific sources may be implemented in future
+   versions of IGMP [5] and in multicast routing protocols to allow a
+   receiver to select which sources are allowed to reach it.
+
+   A security review of this payload format found no additional
+   considerations beyond those in the RTP specification.
+
+8. Addresses of Authors
+
+   Carsten Bormann
+   Universitaet Bremen FB3 TZI      EMail: cabo@tzi.org
+   Postfach 330440                  Phone: +49.421.218-7024
+   D-28334 Bremen, GERMANY          Fax:   +49.421.218-7000
+
+
+   Linda Cline
+   Intel Corp. M/S JF3-206          EMail: lscline@jf.intel.com
+   2111 NE 25th Avenue              Phone: +1 503 264 3501
+   Hillsboro, OR 97124, USA         Fax:   +1 503 264 3483
+
+
+   Gim Deisher
+   Intel Corp. M/S JF2-78           EMail: gim.l.deisher@intel.com
+   2111 NE 25th Avenue              Phone: +1 503 264 3758
+   Hillsboro, OR 97124, USA         Fax:   +1 503 264 9372
+
+
+   Tom Gardos
+   Intel Corp. M/S JF2-78           EMail: thomas.r.gardos@intel.com
+   2111 NE 25th Avenue              Phone: +1 503 264 6459
+   Hillsboro, OR 97124, USA         Fax:   +1 503 264 9372
+
+
+   Christian Maciocco
+   Intel Corp. M/S JF3-206          EMail: christian.maciocco@intel.com
+   2111 NE 25th Avenue              Phone: +1 503 264 1770
+   Hillsboro, OR 97124, USA         Fax:   +1 503 264 9428
+
+
+   Donald Newell
+   Intel Corp. M/S JF3-206          EMail: donald.newell@intel.com
+   2111 NE 25th Avenue              Phone: +1 503 264 9234
+   Hillsboro, OR 97124, USA         Fax:   +1 503 264 9428
+
+
+
+
+
+
+
+
+Bormann, et. al.            Standards Track                    [Page 15]
+
+RFC 2429                         H.263+                     October 1998
+
+
+   Joerg Ott
+   Universitaet Bremen FB3 TZI      EMail: jo@tzi.org
+   Postfach 330440                  Phone: +49.421.218-7024
+   D-28334 Bremen, GERMANY          Fax:   +49.421.218-7000
+
+
+   Gary Sullivan
+   PictureTel Corp. M/S 635         EMail: garys@pictel.com
+   100 Minuteman Road               Phone: +1 978 623 4324
+   Andover, MA 01810, USA           Fax:   +1 978 749 2804
+
+
+   Stephan Wenger
+   Technische Universitaet Berlin FB13
+   Sekr. FR 6-3                     EMail: stewe@cs.tu-berlin.de
+   Franklinstr. 28/29               Phone: +49.30.314-73160
+   D-10587 Berlin, GERMANY          Fax:   +49.30.314-25156
+
+
+   Chad Zhu
+   Intel Corp. M/S JF3-202          EMail: czhu@ix.netcom.com
+   2111 NE 25th Avenue              Phone: +1 503 264 6004
+   Hillsboro, OR 97124, USA         Fax:   +1 503 264 1805
+
+9. References
+
+   [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+       "RTP : A Transport Protocol for Real-Time Applications", RFC
+       1889, January 1996.
+
+   [2] Schulzrinne, H., "RTP Profile for Audio and Video Conference with
+       Minimal Control", RFC 1890, January 1996.
+
+   [3] "Video Coding for Low Bit Rate Communication," ITU-T
+       Recommendation H.263, March 1996.
+
+   [4] "Video Coding for Low Bit Rate Communication," ITU-T
+       Recommendation H.263, January 1998.
+
+   [5] Turletti, T. and C. Huitema, "RTP Payload Format for H.261 Video
+       Streams", RFC 2032, October 1996.
+
+   [6] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190,
+       September 1997.
+
+   [7] S. Wenger, "Video Redundancy Coding in H.263+," Proc. Audio-
+       Visual Services over Packet Networks, Aberdeen, U.K., September
+       1997.
+
+
+
+Bormann, et. al.            Standards Track                    [Page 16]
+
+RFC 2429                         H.263+                     October 1998
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et. al.            Standards Track                    [Page 17]
+