rfc2038.txt

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

   average audio frame size would be 1.25 KBytes.  If packets were to be
   500 Bytes long, then each audio frame would straddle 3 RTP packets.
   The audio fragmentation indicator header (See Section 3.5) shall be
   present for an MPEG1/2 Audio payload type to provide for this
   fragmentation.

3.3 RTP Fixed Header for MPEG ES encapsulation

   The RTP header fields are used as follows:

        Payload Type: Distinct payload types should be assigned
          for video elementary streams and audio elementary streams.
          See [4] for payload type assignments.

        M bit:  For video, set to 1 on packet containing MPEG frame
          end code, 0 otherwise.  For audio, set to 1 on first packet
          of a "talk-spurt," 0 otherwise.

        PT:  MPEG video or audio stream ID.

        timestamp: 32-bit 90K Hz timestamp representing presentation
          time of MPEG picture or audio frame.  Same for all packets
          that make up a picture or audio frame.  May not be
          monotonically increasing in video stream if B pictures



Hoffman, et. al.            Standards Track                     [Page 6]

RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996


          present in stream.  For packets that contain only a video
          sequence and/or GOP header, the timestamp is that of the
          subsequent picture.

3.4 MPEG Video-specific header

   This header shall be attached to each RTP packet after the RTP fixed
   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    MBZ    |         TR        |MBZ|S|B|E|  P  | | BFC | | FFC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                FBV     FFV

        MBZ: Unused. Must be set to zero in current
           specification. This space is reserved for future use.

        TR: Temporal-Reference (10 bits). The temporal reference of
           the current picture within the current GOP. This value
           ranges from 0-1023 and is constant for all RTP packets of a
           given picture.

        MBZ: Unused. Must be set to zero in current
           specification. This space is reserved for future use.

        S: Sequence-header-present (1 bit). Normally 0 and set to 1 at
           the occurrence of each MPEG sequence header.  Used to
           detect presence of sequence header in RTP packet.

        B: Beginning-of-slice (BS) (1 bit). Set when the start of the
           packet payload is a slice start code, or when a slice start
           code is preceded only by one or more of a
           Video_Sequence_Header, GOP_header and/or Picture_Header.

        E: End-of-slice (ES) (1 bit). Set when the last byte of the
           payload is the end of an MPEG slice.

        P: Picture-Type (3 bits). I (1), P (2), B (3) or D (4). This
           value is constant for each RTP packet of a given picture.
           Value 000B is forbidden and 101B - 111B are reserved to
           support future extensions to the MPEG ES specification.

        FBV: full_pel_backward_vector
        BFC: backward_f_code
        FFV: full_pel_forward_vector
        FFC: forward_f_code



Hoffman, et. al.            Standards Track                     [Page 7]

RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996


           Obtained from the most recent picture header, and are
           constant for each RTP packet of a given picture. None of
           these values are used for I frames and must be set to zero
           in the RTP header. For P frames only the last two values
           are present and FBV and BFC must be set to zero in the RTP
           header. For B frames all the four values are present.

3.5 MPEG Audio-specific header

   This header shall be attached to each RTP packet at the start of the
   payload and after any RTP headers for an MPEG1/2 Audio payload type.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             MBZ               |          Frag_offset          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Frag_offset: Byte offset into the audio frame for the data
           in this packet.































Hoffman, et. al.            Standards Track                     [Page 8]

RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996


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 9]

RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996


   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.

   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] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
       "RTP: A Transport Protocol for Real-Time Applications",
       RFC 1889, January 1996.

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
























Hoffman, et. al.            Standards Track                    [Page 10]

RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996


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]


   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]



















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