rfc2343.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页


RFC 2343          RTP Payload Format for Bundled MPEG           May 1998


    Audio offset is a signed integer in two's complement form. It allows
    a ~ +/- 750 msec offset at 44.1 KHz audio sampling rate. For a very
    low video frame rate (e.g., a frame per second), this offset may not
    be sufficient and this payload format may not be usable.

    If  B frames are present, audio frames are not re-ordered along with
    video.  Instead, they are packetized along with video frames in
    their transmission order  (e.g., an audio segment packetized with a
    video segment corresponding to a P picture may belong to a B
    picture, which will be transmitted later and should be rendered at
    the same time with this audio segment.) Even though the video
    segments are reordered, the audio offset for a particular audio
    segment is still relative to the RTP timestamp in the packet
    containing that audio segment.

    Since a special picture counter, such as  the "temporal reference
    (TR)" field of [3], is not included in this payload format, lost GOP
    headers may not be detected.  The only effect of this may be
    incorrect decoding of the B pictures immediately following the lost
    GOP header for some edited video material.

3. Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [1]. 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.

   This payload type does not exhibit any significant non-uniformity in
   the receiver side computational complexity for packet processing  to
   cause a potential denial-of-service threat.

   A security review of this payload format found no additional
   considerations beyond those in the RTP specification.














Civanlar, et. al.             Experimental                      [Page 5]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998


Appendix 1. Error Recovery

   Packet losses can be detected from a combination of the sequence
   number and the timestamp fields of the RTP fixed header. The extent
   of the loss can be determined from the timestamp, the slice number
   and the horizontal location of the first slice in the packet. The
   slice number and the horizontal location can be determined from the
   slice header and the first macroblock address increment, which are
   located at fixed bit positions.

   If lost data consists of slices all from the same picture, new data
   following the loss may simply be given to the video decoder which
   will normally repeat missing pixels from a previous picture. The next
   audio frame must be played at the appropriate time determined by the
   timestamp and the audio offset contained in the received packet.
   Appropriate audio frames (e.g., representing background noise) may
   need to be fed to the audio decoder in place of the lost audio frames
   to keep the lip-synch and/or to conceal the effects of the losses.

   If the received new data after a loss is from the next picture (i.e.
   no complete picture loss) and the N bit is not set, previously
   received headers for the particular picture type (determined from the
   P bits) can be given to the video decoder followed by the new data.
   If N is set, data deletion until a new picture start code is
   advisable unless headers are made available to the receiver through
   some other channel.

   If data for more than one picture is lost and headers are not
   available, unless N is zero and 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, resynchronization to a new video
   sequence header is advisable.

   In all cases of heavy packet losses, if the correct headers for the
   missing Pictures are available, they can be given to the video
   decoder and the received data can be used irrespective of the N bit
   value or the number of lost pictures.

Appendix 2. Resynchronization

   As described in [3], use of frequent video sequence headers makes it
   possible to join in a program at arbitrary times. Also, it reduces
   the resynchronization time after severe losses.








Civanlar, et. al.             Experimental                      [Page 6]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998


References

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

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


   [3] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP
       Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.

   [4] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.

Authors'  Addresses

   M. Reha Civanlar
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

   EMail: [e-mail]


   Glenn L. Cash
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

   EMail: [e-mail]


   Barry G. Haskell
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

   EMail: [e-mail]








Civanlar, et. al.             Experimental                      [Page 7]

RFC 2343          RTP Payload Format for Bundled MPEG           May 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.
























Civanlar, et. al.             Experimental                      [Page 8]