rfc3984.txt

完整的RTP RTSP代码库

   sequence number for the order between STAPs, FUs, and single NAL unit
   packets.

   Signaling of the value of DON for NAL units carried in STAP-B, MTAP,
   and a series of fragmentation units starting with an FU-B is
   specified in sections 5.7.1, 5.7.2, and 5.8, respectively.  The DON
   value of the first NAL unit in transmission order MAY be set to any
   value.  Values of DON are in the range of 0 to 65535, inclusive.
   After reaching the maximum value, the value of DON wraps around to 0.

   The decoding order of two NAL units contained in any STAP-B, MTAP, or
   a series of fragmentation units starting with an FU-B is determined
   as follows.  Let DON(i) be the decoding order number of the NAL unit
   having index i in the transmission order.  Function don_diff(m,n) is
   specified as follows:

      If DON(m) == DON(n), don_diff(m,n) = 0

      If (DON(m) < DON(n) and DON(n) - DON(m) < 32768),
      don_diff(m,n) = DON(n) - DON(m)

      If (DON(m) > DON(n) and DON(m) - DON(n) >= 32768),
      don_diff(m,n) = 65536 - DON(m) + DON(n)

      If (DON(m) < DON(n) and DON(n) - DON(m) >= 32768),
      don_diff(m,n) = - (DON(m) + 65536 - DON(n))

      If (DON(m) > DON(n) and DON(m) - DON(n) < 32768),
      don_diff(m,n) = - (DON(m) - DON(n))

   A positive value of don_diff(m,n) indicates that the NAL unit having
   transmission order index n follows, in decoding order, the NAL unit
   having transmission order index m.  When don_diff(m,n) is equal to 0,



Wenger, et al.              Standards Track                    [Page 16]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


   then the NAL unit decoding order of the two NAL units can be in
   either order.  A negative value of don_diff(m,n) indicates that the
   NAL unit having transmission order index n precedes, in decoding
   order, the NAL unit having transmission order index m.

   Values of DON related fields (DON, DONB, and DOND; see section 5.7)
   MUST be such that the decoding order determined by the values of DON,
   as specified above, conforms to the NAL unit decoding order.  If the
   order of two NAL units in NAL unit decoding order is switched and the
   new order does not conform to the NAL unit decoding order, the NAL
   units MUST NOT have the same value of DON.  If the order of two
   consecutive NAL units in the NAL unit stream is switched and the new
   order still conforms to the NAL unit decoding order, the NAL units
   MAY have the same value of DON.  For example, when arbitrary slice
   order is allowed by the video coding profile in use, all the coded
   slice NAL units of a coded picture are allowed to have the same value
   of DON.  Consequently, NAL units having the same value of DON can be
   decoded in any order, and two NAL units having a different value of
   DON should be passed to the decoder in the order specified above.
   When two consecutive NAL units in the NAL unit decoding order have a
   different value of DON, the value of DON for the second NAL unit in
   decoding order SHOULD be the value of DON for the first, incremented
   by one.

   An example of the decapsulation process to recover the NAL unit
   decoding order is given in section 7.

      Informative note: Receivers should not expect that the absolute
      difference of values of DON for two consecutive NAL units in the
      NAL unit decoding order will be equal to one, even in error-free
      transmission.  An increment by one is not required, as at the time
      of associating values of DON to NAL units, it may not be known
      whether all NAL units are delivered to the receiver.  For example,
      a gateway may not forward coded slice NAL units of non-reference
      pictures or SEI NAL units when there is a shortage of bit rate in
      the network to which the packets are forwarded.  In another
      example, a live broadcast is interrupted by pre-encoded content,
      such as commercials, from time to time.  The first intra picture
      of a pre-encoded clip is transmitted in advance to ensure that it
      is readily available in the receiver.  When transmitting the first
      intra picture, the originator does not exactly know how many NAL
      units will be encoded before the first intra picture of the pre-
      encoded clip follows in decoding order.  Thus, the values of DON
      for the NAL units of the first intra picture of the pre-encoded
      clip have to be estimated when they are transmitted, and gaps in
      values of DON may occur.





Wenger, et al.              Standards Track                    [Page 17]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


5.6.  Single NAL Unit Packet

   The single NAL unit packet defined here MUST contain only one NAL
   unit, of the types defined in [1].  This means that neither an
   aggregation packet nor a fragmentation unit can be used within a
   single NAL unit packet.  A NAL unit stream composed by decapsulating
   single NAL unit packets in RTP sequence number order MUST conform to
   the NAL unit decoding order.  The structure of the single NAL unit
   packet is shown in Figure 2.

      Informative note: The first byte of a NAL unit co-serves as the
      RTP payload 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|NRI|  type   |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      |                                                               |
      |               Bytes 2..n of a Single NAL unit                 |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2.  RTP payload format for single NAL unit packet

5.7.  Aggregation Packets

   Aggregation packets are the NAL unit aggregation scheme of this
   payload specification.  The scheme is introduced to reflect the
   dramatically different MTU sizes of two key target networks:
   wireline IP networks (with an MTU size that is often limited by the
   Ethernet MTU size; roughly 1500 bytes), and IP or non-IP (e.g., ITU-T
   H.324/M) based wireless communication systems with preferred
   transmission unit sizes of 254 bytes or less.  To prevent media
   transcoding between the two worlds, and to avoid undesirable
   packetization overhead, a NAL unit aggregation scheme is introduced.

   Two types of aggregation packets are defined by this specification:

   o  Single-time aggregation packet (STAP): aggregates NAL units with
      identical NALU-time.  Two types of STAPs are defined, one without
      DON (STAP-A) and another including DON (STAP-B).

   o  Multi-time aggregation packet (MTAP): aggregates NAL units with
      potentially differing NALU-time.  Two different MTAPs are defined,
      differing in the length of the NAL unit timestamp offset.



Wenger, et al.              Standards Track                    [Page 18]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


   The term NALU-time is defined as the value that the RTP timestamp
   would have if that NAL unit would be transported in its own RTP
   packet.

   Each NAL unit to be carried in an aggregation packet is encapsulated
   in an aggregation unit.  Please see below for the four different
   aggregation units and their characteristics.

   The structure of the RTP payload format for aggregation packets is
   presented in Figure 3.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|NRI|  type   |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      |                                                               |
      |             one or more aggregation units                     |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :...OPTIONAL RTP padding        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 3.  RTP payload format for aggregation packets

   MTAPs and STAPs share the following packetization rules:  The RTP
   timestamp MUST be set to the earliest of the NALU times of all the
   NAL units to be aggregated.  The type field of the NAL unit type
   octet MUST be set to the appropriate value, as indicated in Table 4.
   The F bit MUST be cleared if all F bits of the aggregated NAL units
   are zero; otherwise, it MUST be set.  The value of NRI MUST be the
   maximum of all the NAL units carried in the aggregation packet.

      Table 4.  Type field for STAPs and MTAPs

      Type   Packet    Timestamp offset   DON related fields
                       field length       (DON, DONB, DOND)
                       (in bits)          present
      --------------------------------------------------------
      24     STAP-A       0                 no
      25     STAP-B       0                 yes
      26     MTAP16      16                 yes
      27     MTAP24      24                 yes

   The marker bit in the RTP header is set to the value that the marker
   bit of the last NAL unit of the aggregated packet would have if it
   were transported in its own RTP packet.




Wenger, et al.              Standards Track                    [Page 19]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


   The payload of an aggregation packet consists of one or more
   aggregation units.  See sections 5.7.1 and 5.7.2 for the four
   different types of aggregation units.  An aggregation packet can
   carry as many aggregation units as necessary; however, the total
   amount of data in an aggregation packet obviously MUST fit into an IP
   packet, and the size SHOULD be chosen so that the resulting IP packet
   is smaller than the MTU size.  An aggregation packet MUST NOT contain
   fragmentation units specified in section 5.8.  Aggregation packets
   MUST NOT be nested; i.e., an aggregation packet MUST NOT contain
   another aggregation packet.

5.7.1.  Single-Time Aggregation Packet

   Single-time aggregation packet (STAP) SHOULD be used whenever NAL
   units are aggregated that all share the same NALU-time.  The payload
   of an STAP-A does not include DON and consists of at least one
   single-time aggregation unit, as presented in Figure 4.  The payload
   of an STAP-B consists of a 16-bit unsigned decoding order number
   (DON) (in network byte order) followed by at least one single-time
   aggregation unit, as presented in Figure 5.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      :                                               |
      +-+-+-+-+-+-+-+-+                                               |
      |                                                               |
      |                single-time aggregation units                  |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4.  Payload format for STAP-A

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      :  decoding order number (DON)  |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      |                                                               |
      |                single-time aggregation units                  |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 5.  Payload format for STAP-B



Wenger, et al.              Standards Track                    [Page 20]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


   The DON field specifies the value of DON for the first NAL unit in an
   STAP-B in transmission order.  For each successive NAL unit in
   appearance order in an STAP-B, the value of DON is equal to (the
   value of DON of the previous NAL unit in the STAP-B + 1) % 65536, in
   which '%' stands for the modulo operation.

   A single-time aggregation unit consists of 16-bit unsigned size
   information (in network byte order) that indicates the size of the
   following NAL unit in bytes (excluding these two octets, but
   including the NAL unit type octet of the NAL unit), followed by the
   NAL unit itself, including its NAL unit type byte.  A single-time
   aggregation unit is byte aligned within the RTP payload, but it may
   not be aligned on a 32-bit word boundary.  Figure 6 presents the
   structure of the single-time aggregation unit.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      :        NAL unit size          |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      |                                                               |
      |                           NAL unit                            |