rfc2429.txt

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

   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: [e-mail]
   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: [e-mail]
   2111 NE 25th Avenue              Phone: [phone]
   Hillsboro, OR 97124, USA         Fax:   [phone]


   Gim Deisher
   Intel Corp. M/S JF2-78           EMail: [e-mail]
   2111 NE 25th Avenue              Phone: [phone]
   Hillsboro, OR 97124, USA         Fax:   [phone]


   Tom Gardos
   Intel Corp. M/S JF2-78           EMail: [e-mail]
   2111 NE 25th Avenue              Phone: [phone]
   Hillsboro, OR 97124, USA         Fax:   [phone]


   Christian Maciocco
   Intel Corp. M/S JF3-206          EMail: [e-mail]
   2111 NE 25th Avenue              Phone: [phone]
   Hillsboro, OR 97124, USA         Fax:   [phone]


   Donald Newell
   Intel Corp. M/S JF3-206          EMail: [e-mail]
   2111 NE 25th Avenue              Phone: [phone]
   Hillsboro, OR 97124, USA         Fax:   [phone]








Bormann, et. al.            Standards Track                    [Page 15]

RFC 2429                         H.263+                     October 1998


   Joerg Ott
   Universitaet Bremen FB3 TZI      EMail: [e-mail]
   Postfach 330440                  Phone: +49.421.218-7024
   D-28334 Bremen, GERMANY          Fax:   +49.421.218-7000


   Gary Sullivan
   PictureTel Corp. M/S 635         EMail: [e-mail]
   100 Minuteman Road               Phone: [phone]
   Andover, MA 01810, USA           Fax:   [phone]


   Stephan Wenger
   Technische Universitaet Berlin FB13
   Sekr. FR 6-3                     EMail: [e-mail]
   Franklinstr. 28/29               Phone: [phone]
   D-10587 Berlin, GERMANY          Fax:   [phone]


   Chad Zhu
   Intel Corp. M/S JF3-202          EMail: [e-mail]
   2111 NE 25th Avenue              Phone: [phone]
   Hillsboro, OR 97124, USA         Fax:   [phone]

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]