rfc2429.txt

其中为本人做媒体项目时搜集的一些有关rtp和h264方面的资料.

   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