rfc3984.txt

目前的流媒体服务器代码有Darwin(苹果公司）

Network Working Group                                          S. Wenger
Request for Comments: 3984                               M.M. Hannuksela
Category: Standards Track                                 T. Stockhammer
                                                           M. Westerlund
                                                               D. Singer
                                                           February 2005


                   RTP Payload Format for H.264 Video

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo describes an RTP Payload format for the ITU-T
   Recommendation H.264 video codec and the technically identical
   ISO/IEC International Standard 14496-10 video codec.  The RTP payload
   format allows for packetization of one or more Network Abstraction
   Layer Units (NALUs), produced by an H.264 video encoder, in each RTP
   payload.  The payload format has wide applicability, as it supports
   applications from simple low bit-rate conversational usage, to
   Internet video streaming with interleaved transmission, to high bit-
   rate video-on-demand.

Table of Contents

   1.  Introduction..................................................  3
       1.1.  The H.264 Codec.........................................  3
       1.2.  Parameter Set Concept...................................  4
       1.3.  Network Abstraction Layer Unit Types....................  5
   2.  Conventions...................................................  6
   3.  Scope.........................................................  6
   4.  Definitions and Abbreviations.................................  6
       4.1.  Definitions.............................................  6
   5.  RTP Payload Format............................................  8
       5.1.  RTP Header Usage........................................  8
       5.2.  Common Structure of the RTP Payload Format.............. 11
       5.3.  NAL Unit Octet Usage.................................... 12



Wenger, et al.              Standards Track                     [Page 1]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


       5.4.  Packetization Modes..................................... 14
       5.5.  Decoding Order Number (DON)............................. 15
       5.6.  Single NAL Unit Packet.................................. 18
       5.7.  Aggregation Packets..................................... 18
       5.8.  Fragmentation Units (FUs)............................... 27
   6.  Packetization Rules........................................... 31
       6.1.  Common Packetization Rules.............................. 31
       6.2.  Single NAL Unit Mode.................................... 32
       6.3.  Non-Interleaved Mode.................................... 32
       6.4.  Interleaved Mode........................................ 33
   7.  De-Packetization Process (Informative)........................ 33
       7.1.  Single NAL Unit and Non-Interleaved Mode................ 33
       7.2.  Interleaved Mode........................................ 34
       7.3.  Additional De-Packetization Guidelines.................. 36
   8.  Payload Format Parameters..................................... 37
       8.1.  MIME Registration....................................... 37
       8.2.  SDP Parameters.......................................... 52
       8.3.  Examples................................................ 58
       8.4.  Parameter Set Considerations............................ 60
   9.  Security Considerations....................................... 62
   10. Congestion Control............................................ 63
   11. IANA Considerations........................................... 64
   12. Informative Appendix: Application Examples.................... 65
       12.1. Video Telephony according to ITU-T Recommendation H.241
             Annex A................................................. 65
       12.2. Video Telephony, No Slice Data Partitioning, No NAL
             Unit Aggregation........................................ 65
       12.3. Video Telephony, Interleaved Packetization Using NAL
             Unit Aggregation........................................ 66
       12.4. Video Telephony with Data Partitioning.................. 66
       12.5. Video Telephony or Streaming with FUs and Forward
             Error Correction........................................ 67
       12.6. Low Bit-Rate Streaming.................................. 69
       12.7. Robust Packet Scheduling in Video Streaming............. 70
   13. Informative Appendix: Rationale for Decoding Order Number..... 71
       13.1. Introduction............................................ 71
       13.2. Example of Multi-Picture Slice Interleaving............. 71
       13.3. Example of Robust Packet Scheduling..................... 73
       13.4. Robust Transmission Scheduling of Redundant Coded
             Slices.................................................. 77
       13.5. Remarks on Other Design Possibilities................... 77
   14. Acknowledgements.............................................. 78
   15. References.................................................... 78
       15.1. Normative References.................................... 78
       15.2. Informative References.................................. 79
   Authors' Addresses................................................ 81
   Full Copyright Statement.......................................... 83




Wenger, et al.              Standards Track                     [Page 2]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


1.  Introduction

1.1.  The H.264 Codec

   This memo specifies an RTP payload specification for the video coding
   standard known as ITU-T Recommendation H.264 [1] and ISO/IEC
   International Standard 14496 Part 10 [2] (both also known as Advanced
   Video Coding, or AVC).  Recommendation H.264 was approved by ITU-T on
   May 2003, and the approved draft specification is available for
   public review [8].  In this memo the H.264 acronym is used for the
   codec and the standard, but the memo is equally applicable to the
   ISO/IEC counterpart of the coding standard.

   The H.264 video codec has a very broad application range that covers
   all forms of digital compressed video from, low bit-rate Internet
   streaming applications to HDTV broadcast and Digital Cinema
   applications with nearly lossless coding.  Compared to the current
   state of technology, the overall performance of H.264 is such that
   bit rate savings of 50% or more are reported.  Digital Satellite TV
   quality, for example, was reported to be achievable at 1.5 Mbit/s,
   compared to the current operation point of MPEG 2 video at around 3.5
   Mbit/s [9].

   The codec specification [1] itself distinguishes conceptually between
   a video coding layer (VCL) and a network abstraction layer (NAL).
   The VCL contains the signal processing functionality of the codec;
   mechanisms such as transform, quantization, and motion compensated
   prediction; and a loop filter.  It follows the general concept of
   most of today's video codecs, a macroblock-based coder that uses
   inter picture prediction with motion compensation and transform
   coding of the residual signal.  The VCL encoder outputs slices: a bit
   string that contains the macroblock data of an integer number of
   macroblocks, and the information of the slice header (containing the
   spatial address of the first macroblock in the slice, the initial
   quantization parameter, and similar information).  Macroblocks in
   slices are arranged in scan order unless a different macroblock
   allocation is specified, by using the so-called Flexible Macroblock
   Ordering syntax.  In-picture prediction is used only within a slice.
   More information is provided in [9].

   The Network Abstraction Layer (NAL) encoder encapsulates the slice
   output of the VCL encoder into Network Abstraction Layer Units (NAL
   units), which are suitable for transmission over packet networks or
   use in packet oriented multiplex environments.  Annex B of H.264
   defines an encapsulation process to transmit such NAL units over
   byte-stream oriented networks.  In the scope of this memo, Annex B is
   not relevant.




Wenger, et al.              Standards Track                     [Page 3]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


   Internally, the NAL uses NAL units.  A NAL unit consists of a one-
   byte header and the payload byte string.  The header indicates the
   type of the NAL unit, the (potential) presence of bit errors or
   syntax violations in the NAL unit payload, and information regarding
   the relative importance of the NAL unit for the decoding process.
   This RTP payload specification is designed to be unaware of the bit
   string in the NAL unit payload.

   One of the main properties of H.264 is the complete decoupling of the
   transmission time, the decoding time, and the sampling or
   presentation time of slices and pictures.  The decoding process
   specified in H.264 is unaware of time, and the H.264 syntax does not
   carry information such as the number of skipped frames (as is common
   in the form of the Temporal Reference in earlier video compression
   standards).  Also, there are NAL units that affect many pictures and
   that are, therefore, inherently timeless.  For this reason, the
   handling of the RTP timestamp requires some special considerations
   for NAL units for which the sampling or presentation time is not
   defined or, at transmission time, unknown.

1.2.  Parameter Set Concept

   One very fundamental design concept of H.264 is to generate self-
   contained packets, to make mechanisms such as the header duplication
   of RFC 2429 [10] or MPEG-4's Header Extension Code (HEC) [11]
   unnecessary.  This was achieved by decoupling information relevant to
   more than one slice from the media stream.  This higher layer meta
   information should be sent reliably, asynchronously, and in advance
   from the RTP packet stream that contains the slice packets.
   (Provisions for sending this information in-band are also available
   for applications that do not have an out-of-band transport channel
   appropriate for the purpose.)  The combination of the higher-level
   parameters is called a parameter set.  The H.264 specification
   includes two types of parameter sets: sequence parameter set and
   picture parameter set.  An active sequence parameter set remains
   unchanged throughout a coded video sequence, and an active picture
   parameter set remains unchanged within a coded picture.  The sequence
   and picture parameter set structures contain information such as
   picture size, optional coding modes employed, and macroblock to slice
   group map.

   To be able to change picture parameters (such as the picture size)
   without having to transmit parameter set updates synchronously to the
   slice packet stream, the encoder and decoder can maintain a list of
   more than one sequence and picture parameter set.  Each slice header
   contains a codeword that indicates the sequence and picture parameter
   set to be used.




Wenger, et al.              Standards Track                     [Page 4]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


   This mechanism allows the decoupling of the transmission of parameter
   sets from the packet stream, and the transmission of them by external
   means (e.g., as a side effect of the capability exchange), or through
   a (reliable or unreliable) control protocol.  It may even be possible
   that they are never transmitted but are fixed by an application
   design specification.

1.3.  Network Abstraction Layer Unit Types

   Tutorial information on the NAL design can be found in [12], [13],
   and [14].

   All NAL units consist of a single NAL unit type octet, which also
   co-serves as the payload header of this RTP payload format.  The
   payload of a NAL unit follows immediately.

   The syntax and semantics of the NAL unit type octet are specified in
   [1], but the essential properties of the NAL unit type octet are
   summarized below.  The NAL unit type octet has the following format:

      +---------------+
      |0|1|2|3|4|5|6|7|
      +-+-+-+-+-+-+-+-+
      |F|NRI|  Type   |
      +---------------+

   The semantics of the components of the NAL unit type octet, as
   specified in the H.264 specification, are described briefly below.

   F: 1 bit
      forbidden_zero_bit.  The H.264 specification declares a value of
      1 as a syntax violation.

   NRI: 2 bits
      nal_ref_idc.  A value of 00 indicates that the content of the NAL
      unit is not used to reconstruct reference pictures for inter
      picture prediction.  Such NAL units can be discarded without
      risking the integrity of the reference pictures.  Values greater
      than 00 indicate that the decoding of the NAL unit is required to
      maintain the integrity of the reference pictures.

   Type: 5 bits
      nal_unit_type.  This component specifies the NAL unit payload type
      as defined in table 7-1 of [1], and later within this memo.  For a
      reference of all currently defined NAL unit types and their
      semantics, please refer to section 7.4.1 in [1].





Wenger, et al.              Standards Track                     [Page 5]

RFC 3984           RTP Payload Format for H.264 Video      February 2005


   This memo introduces new NAL unit types, which are presented in