rfc2250.txt

RFC 的详细文档！

Hoffman, et. al.            Standards Track                    [Page 11]

RFC 2250            RTP Format for MPEG1/MPEG2 Video        January 1998


Appendix 1. Error Recovery and Resynchronization Strategies.

   The following error recovery and resynchronization strategies are
   intended to be guidelines only.  A compliant receiver is free to
   employ alternative (or no) strategies.

   When initially decoding an RTP-encapsulated MPEG Elementary Stream,
   the receiver may discard all packets until the Sequence-header-
   present bit is set to 1.  At this point, sufficient state information
   is contained in the stream to allow processing by an MPEG decoder.

   Loss of packets containing the GOP_header and/or Picture_Header are
   detected by an unexpected change in the Temporal-Reference and
   Picture-Type values.  Consider the following example GOP sequence:

        In display order: 0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B ...
        In stream order:  2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I ...

   Consider also two counters:

        ref_pic_temp (Reference Picture (I,P) Temporal Reference)
        dep_pic_temp (Dependent Picture (B) Temporal Reference)

   At each GOP beginning, set these counters to the temporal reference
   value of the corresponding picture type. For our example GOP
   sequence, ref_pic_temp = 2 and dep_pic_temp = 0. Keep incrementing
   BOTH counters by unity with each following picture. Ref_pic_temp
   should match the temporal references of the I and P frames, and
   dep_pic_temp should match the temporal references of the B frames.

       dep_pic_temp: -  0  1  2  3  4  5  6  7        8  9
   In stream order:  2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_H 2I 0B 1B ...
       ref_pic_temp: 2  3  4  5  6  7  8  9  10  ^    11
                     --------------------------  |    ^
                                Match            Drop |
                                                      Mismatch
                                                       in ref_pic_temp

   The loss of a GOP header can be detected by matching the appropriate
   counter (based on picture type) to the temporal reference value. A
   mismatch indicates a lost GOP header. If desired, a GOP header can be
   re-constructed using a "null" time_code, repeating the closed_gop
   flag from previous GOP headers, and setting the broken_link flag to
   1.

   The loss of a Picture_Header can also be detected by a mismatch in
   the Temporal Reference contained in the RTP packet from the
   appropriate dep_pic_temp or ref_pic_temp counters at the receiver.



Hoffman, et. al.            Standards Track                    [Page 12]

RFC 2250            RTP Format for MPEG1/MPEG2 Video        January 1998


   For MPEG-1 payloads, after scanning to the next Beginning-of-slice
   the Picture_Header is reconstructed from the P, TR, FBV, BFC, FFV and
   FFC contained in that packet, and from stream-dependent default
   values.

   For MPEG-2, additional information is needed for the reconstruction.
   This information is provided by the MPEG-2 video specific header
   extension contained in that packet if the T bit is set to 1, or the
   Picture Header for the current picture may be available from previous
   packets belonging to the same picture. The transmitter's strategy for
   inclusion of the MPEG-2 video specific header extension may depend
   upon a number of factors. This header may not be needed when:

      1. the information has been transmitted a sufficient number of
      times in previous packets to assure reception with the desired
      probability, or

      2. the information is transmitted over a separate reliable
      channel, or

      3. expected loss rates are low enough that missed frames are not a
      concern, or

      4. conserving bandwidth is more important than error resilience,
      etc.

   If T=1 and E=0, there may be extensions present in the original video
   bitstream that are not included in the current packet. The
   transmitter may choose not to include extensions in a packet when
   they are not necessary for decoding or if one of the cases listed
   above for not including the MPEG-2 video specific header extension in
   a packet applies only to the extension data.

   If N=0, then the Picture Header from a previous picture of the same
   type (I,P or B) may be used so long as at least one packet has been
   received for every intervening picture of the same type and that the
   N bit was 0 for each of those pictures. This may involve:

      1. Saving the relevant picture header information that can be
      obtained from the MPEG-2 video specific header extension or
      directly from the video bitstream for each picture type,

      2. Keeping validity indicators for this saved information based on
      the received N bits and lost packets, and,

      3. Updating the data whenever a packet with N=1 is received.





Hoffman, et. al.            Standards Track                    [Page 13]

RFC 2250            RTP Format for MPEG1/MPEG2 Video        January 1998


   If the necessary information is not available from any of these
   sources, data deletion until a new picture start code is advised.

   Any time an RTP packet is lost (as indicated by a gap in the RTP
   sequence number), the receiver may discard all packets until the
   Beginning-of-slice bit is set.  At this point, sufficient state
   information is contained in the stream to allow processing by an MPEG
   decoder starting at the next slice boundary (possibly after
   reconstruction of the GOP_header and/or Picture_Header as described
   above).

References

   [1] ISO/IEC International Standard 11172; "Coding of moving pictures
       and associated audio for digital storage media up to about 1,5
       Mbits/s", November 1993.

   [2] ISO/IEC International Standard 13818; "Generic coding of moving
       pictures and associated audio information", November 1994.

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

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

   [5] Deering, S., "Host Extensions for IP Multicasting", STD 5,
       RFC 1112, August 1989.

Authors' Addresses

   Gerard Fernando
   Sun Microsystems, Inc.
   Mail-stop UMPK14-305
   2550 Garcia Avenue
   Mountain View, California 94043-1100
   USA

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










Hoffman, et. al.            Standards Track                    [Page 14]

RFC 2250            RTP Format for MPEG1/MPEG2 Video        January 1998


   Vivek Goyal
   Precept Software, Inc.
   1072 Arastradero Rd,
   Palo Alto, CA 94304
   USA

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


   Don Hoffman
   Sun Microsystems, Inc.
   Mail-stop UMPK14-305
   2550 Garcia Avenue
   Mountain View, California 94043-1100
   USA

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


   M. Reha Civanlar
   AT&T Labs - Research
   100 Schutlz Drive, 3-213
   Red Bank, NJ 07701-7033
   USA

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






















Hoffman, et. al.            Standards Track                    [Page 15]

RFC 2250            RTP Format for MPEG1/MPEG2 Video        January 1998


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.
























Hoffman, et. al.            Standards Track                    [Page 16]