rfc2250.txt

RFC 的详细文档！

   An implementation based on this encapsulation assumes that the
   Video_Sequence_Header is repeated periodically in the MPEG bit-
   stream.  In practice (though not required by MPEG standard) this is
   used to allow channel switching and to receive and start decoding a
   continuously relayed MPEG bit-stream at arbitrary points in the media
   stream.  It is suggested that when playing back from an MPEG stream
   from a file format (where the Video_Sequence_Header may only be
   represented at the beginning of the stream) that the first
   Video_Sequence_Header (preceded by an end-of-stream indicator) be
   saved by the packetizer for periodic injection in to the network
   stream.

3.2 MPEG Audio elementary streams

   MPEG1 Audio can be distinguished from MPEG2 Audio from the MPEG
   ancillary_data() header.  For either MPEG1 or MPEG2 Audio, distinct
   Presentation Time Stamps may be present for frames which correspond
   to either 384 samples for Layer-I, or 1152 samples for Layer-II or
   Layer-III.  The actual number of bytes required to represent this
   number of samples will vary depending on the encoder parameters.

   Multiple audio frames may be encapsulated within one RTP packet.  In
   this case, an integral number of audio frames must be contained
   within the packet and the fragmentation header defined in Section 3.5
   shall be set to 0.

   Also, if relatively short packets are to be used, one frame may be so
   large that it may straddle multiple RTP packets.  For example, for
   Layer-II MPEG audio sampled at a rate of 44.1 KHz each frame would
   represent a time slot of 26.1 msec. At this sampling rate if the
   compressed bit-rate is 384 kbits/sec (i.e.  48 kBytes/sec) then the
   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.



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


   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 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  |T|         TR        | |N|S|B|E|  P  | | BFC | | FFC |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   AN              FBV     FFV

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

        T: MPEG-2 (Two) specific header extension present (1 bit).
           Set to 1 when the MPEG-2 video-specific header extension (see
           Section 3.4.1) follows this header. This extension may be
           needed for improved error resilience; however, its inclusion
           in an RTP packet is optional. (See Appendix 1.)





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


        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.

        AN: Active N bit for error resilience (1 bit). Set to 1 when
           the following bit (N) is used to signal changes in the
           picture header information for MPEG-2 payloads. It must be
           set to 0 for MPEG-1 payloads or when N bit is not used.

        N: New picture header (1 bit). Used for MPEG-2 payloads when
           the previous bit (AN) is set to 1. Otherwise, it must be set
           to zero. Set to 1 when the information contained in the
           previously transmitted Picture Headers can't be used to
           reconstruct a header for the current picture. This happens
           when the current picture is encoded using a different set of
           parameters than the previous pictures of the same type. The N
           bit must be constant for all RTP packets that belong to the
           same picture so that receipt of any packet from a picture
           allows detecting whether information necessary for
           reconstruction was contained in that picture (N = 1) or a
           previous one (N = 0).

        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
           Obtained from the most recent picture header, and are
           constant for each RTP packet of a given picture. For I frames
           none of these values are present in the picture header and




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


           they 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.4.1 MPEG-2 Video-specific header extension

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|E|f_[0,0]|f_[0,1]|f_[1,0]|f_[1,1]| DC| PS|T|P|C|Q|V|A|R|H|G|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        X: Unused (1 bit). Must be set to zero in current
           specification. This space is reserved for future use.

        E: Extensions present (1 bit). If set to 1, this header
           extension, including the composite display extension when D =
           1, will be followed by one or more of the following
           extensions: quant matrix extension, picture display
           extension, picture temporal scalable extension, picture
           spatial scalable extension and copyright extension.

           The first byte of these extensions data gives the length of
           the extensions in 32 bit words including the length field
           itself. Zero padding bytes are used at the end if required to
           align the extensions to 32 bit boundary.

           Since they may not be vital in decoding of a picture, the
           inclusion of any one of these extensions in an RTP packet is
           optional even when the MPEG-2 video-specific header extension
           is included in the packet (T = 1). (See Appendix 1.) If
           present, they should be copied from the corresponding
           extensions following the most recent MPEG-2 picture coding
           extension and they remain constant for each RTP packet of a
           given picture.

           The extension start code (32 bits) and the extension start
           code ID (4 bits) are included. Therefore the extensions are
           self identifying.

        f_[0,0]: forward horizontal f_code (4 bits)
        f_[0,1]: forward vertical f_code (4 bits)
        f_[1,0]: backward horizontal f_code (4 bits)
        f_[1,1]: backward vertical f_code (4 bits)
        DC: intra_DC_precision (2 bits)
        PS: picture_structure (2 bits)



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


        T: top_field_first (1 bit)
        P: frame_predicted_frame_dct (1 bit)
        C: concealment_motion_vectors (1 bit)
        Q: q_scale type (1 bit)
        V: intra_vlc_format (1 bit)
        A: alternate scan (1 bit)
        R: repeat_first_field (1 bit)
        H: chroma_420_type (1 bit)
        G: progressive frame (1 bit)
        D: composite_display_flag (1 bit). If set to 1, next 32 bits
           following this one contains 12 zeros followed by 20 bits
           of composite display information.

        These values are copied from the most recent picture coding
        extension and are constant for each RTP packet of a given
        picture. Their meanings are as explained in the MPEG-2 standard.

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.

4. Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [3], and any appropriate RTP profile (for example [4]).
   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.




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


   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
   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.