rfc2435.txt

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

Network Working Group                                            L. Berc
Request for Comments: 2435                 Digital Equipment Corporation
Obsoletes: 2035                                                W. Fenner
Category: Standards Track                                     Xerox PARC
                                                            R. Frederick
                                                              Xerox PARC
                                                              S. McCanne
                                            Lawrence Berkeley Laboratory
                                                              P. Stewart
                                                              Xerox PARC
                                                            October 1998


              RTP Payload Format for JPEG-compressed 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 (1998).  All Rights Reserved.

Abstract

   This memo describes the RTP payload format for JPEG video streams.
   The packet format is optimized for real-time video streams where
   codec parameters change rarely from frame to frame.

   This document is a product of the Audio-Video Transport working group
   within the Internet Engineering Task Force.  Comments are solicited
   and should be addressed to the working group's mailing list at rem-
   [e-mail] and/or the author(s).

Changes from RFC 2035

   Most of this memo is identical to RFC 2035.  The changes made to the
   protocol are summarized in Appendix D.









Berc, et. al.               Standards Track                     [Page 1]

RFC 2435              RTP Payload Format for JPEG           October 1998


Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [9].

1.  Introduction

   The Joint Photographic Experts Group (JPEG) standard [1,2,3] defines
   a family of compression algorithms for continuous-tone, still images.
   This still image compression standard can be applied to video by
   compressing each frame of video as an independent still image and
   transmitting them in series.  Video coded in this fashion is often
   called Motion-JPEG.

   We first give an overview of JPEG and then describe the specific
   subset of JPEG that is supported in RTP and the mechanism by which
   JPEG frames are carried as RTP payloads.

   The JPEG standard defines four modes of operation: the sequential DCT
   mode, the progressive DCT mode, the lossless mode, and the
   hierarchical mode.  Depending on the mode, the image is represented
   in one or more passes.  Each pass (called a frame in the JPEG
   standard) is further broken down into one or more scans.  Within each
   scan, there are one to four components, which represent the three
   components of a color signal (e.g., "red, green, and blue", or a
   luminance signal and two chrominance signals).  These components can
   be encoded as separate scans or interleaved into a single scan.

   Each frame and scan is preceded with a header containing optional
   definitions for compression parameters like quantization tables and
   Huffman coding tables.  The headers and optional parameters are
   identified with "markers" and comprise a marker segment; each scan
   appears as an entropy-coded bit stream within two marker segments.
   Markers are aligned to byte boundaries and (in general) cannot appear
   in the entropy-coded segment, allowing scan boundaries to be
   determined without parsing the bit stream.

   Compressed data is represented in one of three formats: the
   interchange format, the abbreviated format, or the table-
   specification format.  The interchange format contains definitions
   for all the tables used by the entropy-coded segments, while the
   abbreviated format might omit some assuming they were defined out-
   of-band or by a "previous" image.

   The JPEG standard does not define the meaning or format of the
   components that comprise the image.  Attributes like the color space
   and pixel aspect ratio must be specified out-of-band with respect to



Berc, et. al.               Standards Track                     [Page 2]

RFC 2435              RTP Payload Format for JPEG           October 1998


   the JPEG bit stream.  The JPEG File Interchange Format (JFIF) [4] is
   a de-facto standard that provides this extra information using an
   application marker segment (APP0).  Note that a JFIF file is simply a
   JPEG interchange format image along with the APP0 segment.  In the
   case of video, additional parameters must be defined out-of-band
   (e.g., frame rate, interlaced vs. non-interlaced, etc.).

   While the JPEG standard provides a rich set of algorithms for
   flexible compression, cost-effective hardware implementations of the
   full standard have not appeared.  Instead, most hardware JPEG video
   codecs implement only a subset of the sequential DCT mode of
   operation.  Typically, marker segments are interpreted in software
   (which "re-programs" the hardware) and the hardware is presented with
   a single, interleaved entropy-coded scan represented in the YUV color
   space.

   The scan contains an ordered sequence of Minimum Coded Units, or
   MCUs, which are the smallest group of image data coded in a JPEG bit
   stream.  Each MCU defines the image data for a small rectangular
   block of the output image.

   Restart markers in the JPEG data denote a point where the decoder
   should reset its state.  As defined by JPEG, restart markers are the
   only type of marker that may appear embedded in the entropy-coded
   segment, and they may only appear on an MCU boundary.  A "restart
   interval" is defined to be a block of data containing a restart
   marker followed by some fixed number of MCUs.  An exception is made
   for the first restart interval in each frame, which omits the initial
   restart marker and just begins with the MCU data.  When these markers
   are used, each frame is composed of some fixed number of back-to-back
   restart intervals.

2.  JPEG Over RTP

   To maximize interoperability among hardware-based codecs, we assume
   the sequential DCT operating mode [1,Annex F] and restrict the set of
   predefined RTP/JPEG "type codes" (defined below) to single-scan,
   interleaved images.  While this is more restrictive than even
   baseline JPEG, many hardware implementation fall short of the
   baseline specification (e.g., most hardware cannot decode non-
   interleaved scans).

   In practice, most of the table-specification data rarely changes from
   frame to frame within a single video stream.  Therefore RTP/JPEG data
   is represented in abbreviated format, with all of the tables omitted
   from the bit stream where possible.  Each frame begins immediately
   with the (single) entropy-coded scan.  The information that would
   otherwise be in both the frame and scan headers is represented



Berc, et. al.               Standards Track                     [Page 3]

RFC 2435              RTP Payload Format for JPEG           October 1998


   entirely within the RTP/JPEG header (defined below) that lies between
   the RTP header and the JPEG payload.

   While parameters like Huffman tables and color space are likely to
   remain fixed for the lifetime of the video stream, other parameters
   should be allowed to vary, notably the quantization tables and image
   size (e.g., to implement rate-adaptive transmission or allow a user
   to adjust the "quality level" or resolution manually).  Thus explicit
   fields in the RTP/JPEG header are allocated to represent this
   information.  Since only a small set of quantization tables are
   typically used, we encode the entire set of quantization tables in a
   small integer field.  Customized quantization tables are accommodated
   by using a special range of values in this field, and then placing
   the table before the beginning of the JPEG payload.  The image width
   and height are encoded explicitly.

   Because JPEG frames are typically larger than the underlying
   network's maximum packet size, frames must often be fragmented into
   several packets.  One approach is to allow the network layer below
   RTP (e.g., IP) to perform the fragmentation.  However, this precludes
   rate-controlling the resulting packet stream or partial delivery in
   the presence of loss, and frames may be larger than the maximum
   network layer reassembly length (see [10] for more information).  To
   avoid these limitations, RTP/JPEG defines a simple fragmentation and
   reassembly scheme at the RTP level.

3.  RTP/JPEG Packet Format

   The RTP timestamp is in units of 90000Hz.  The same timestamp MUST
   appear in each fragment of a given frame.  The RTP marker bit MUST be
   set in the last packet of a frame.

3.1.  JPEG header

   Each packet contains a special JPEG header which immediately follows
   the RTP header.  The first 8 bytes of this header, called the "main
   JPEG header", are as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type-specific |              Fragment Offset                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |       Q       |     Width     |     Height    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Berc, et. al.               Standards Track                     [Page 4]

RFC 2435              RTP Payload Format for JPEG           October 1998


   All fields in this header except for the Fragment Offset field MUST
   remain the same in all packets that correspond to the same JPEG
   frame.

   A Restart Marker header and/or Quantization Table header may follow
   this header, depending on the values of the Type and Q fields.

3.1.1.  Type-specific: 8 bits

   Interpretation depends on the value of the type field.  If no
   interpretation is specified, this field MUST be zeroed on
   transmission and ignored on reception.

3.1.2.  Fragment Offset: 24 bits

   The Fragment Offset is the offset in bytes of the current packet in
   the JPEG frame data. This value is encoded in network byte order
   (most significant byte first). The Fragment Offset plus the length of
   the payload data in the packet MUST NOT exceed 2^24 bytes.

3.1.3.  Type: 8 bits

   The type field specifies the information that would otherwise be
   present in a JPEG abbreviated table-specification as well as the
   additional JFIF-style parameters not defined by JPEG.  Types 0-63 are
   reserved as fixed, well-known mappings to be defined by this document
   and future revisions of this document.  Types 64-127 are the same as
   types 0-63, except that restart markers are present in the JPEG data
   and a Restart Marker header appears immediately following the main
   JPEG header.  Types 128-255 are free to be dynamically defined by a
   session setup protocol (which is beyond the scope of this document).

3.1.4.  Q: 8 bits

   The Q field defines the quantization tables for this frame.  Q values
   0-127 indicate the quantization tables are computed using an
   algorithm determined by the Type field (see below).  Q values 128-255
   indicate that a Quantization Table header appears after the main JPEG
   header (and the Restart Marker header, if present) in the first
   packet of the frame (fragment offset 0).  This header can be used to
   explicitly specify the quantization tables in-band.

3.1.5.  Width: 8 bits

   This field encodes the width of the image in 8-pixel multiples (e.g.,
   a width of 40 denotes an image 320 pixels wide).  The maximum width
   is 2040 pixels.




Berc, et. al.               Standards Track                     [Page 5]

RFC 2435              RTP Payload Format for JPEG           October 1998


3.1.6.  Height: 8 bits

   This field encodes the height of the image in 8-pixel multiples
   (e.g., a height of 30 denotes an image 240 pixels tall). When
   encoding interlaced video, this is the height of a video field, since
   fields are individually JPEG encoded. The maximum height is 2040
   pixels.

3.1.7.  Restart Marker header

   This header MUST be present immediately after the main JPEG header
   when using types 64-127.  It provides the additional information
   required to properly decode a data stream containing restart markers.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Restart Interval        |F|L|       Restart Count       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Restart Interval field specifies the number of MCUs that appear
   between restart markers.  It is identical to the 16 bit value that
   would appear in the DRI marker segment of a JFIF header.  This value
   MUST NOT be zero.

   If the restart intervals in a frame are not guaranteed to be aligned
   with packet boundaries, the F (first) and L (last) bits MUST be set
   to 1 and the Restart Count MUST be set to 0x3FFF.  This indicates
   that a receiver MUST reassemble the entire frame before decoding it.

   To support partial frame decoding, the frame is broken into "chunks"
   each containing an integral number of restart intervals. The Restart
   Count field contains the position of the first restart interval in
   the current "chunk" so that receivers know which part of the frame
   this data corresponds to.  A Restart Interval value SHOULD be chosen
   to allow a "chunk" to completely fit within a single packet.  In this
   case, both the F and L bits of the packet are set to 1.  However, if
   a chunk needs to be spread across multiple packets, the F bit will be
   set to 1 in the first packet of the chunk (and only that one) and the
   L bit will be set to 1 in the last packet of the chunk (and only that
   one).

3.1.8.  Quantization Table header

   This header MUST be present after the main JPEG header (and after the
   Restart Marker header, if present) when using Q values 128-255.  It
   provides a way to specify the quantization tables associated with
   this Q value in-band.



Berc, et. al.               Standards Track                     [Page 6]

RFC 2435              RTP Payload Format for JPEG           October 1998


    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      |   Precision   |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Quantization Table Data                    |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Length field is set to the length in bytes of the quantization
   table data to follow.  The Length field MAY be set to zero to
   indicate that no quantization table data is included in this frame.
   See section 4.2 for more information.  If the Length field in a
   received packet is larger than the remaining number of bytes, the
   packet MUST be discarded.

   When table data is included, the number of tables present depends on
   the JPEG type field.  For example, type 0 uses two tables (one for
   the luminance component and one shared by the chrominance
   components).  Each table is an array of 64 values given in zig-zag
   order, identical to the format used in a JFIF DQT marker segment.

   For each quantization table present, a bit in the Precision field
   specifies the size of the coefficients in that table.  If the bit is
   zero, the coefficients are 8 bits yielding a table length of 64
   bytes.  If the bit is one, the coefficients are 16 bits for a table
   length of 128 bytes.  For 16 bit tables, the coefficients are
   presented in network byte order.  The rightmost bit in the Precision
   field (bit 15 in the diagram above) corresponds to the first table
   and each additional table uses the next bit to the left.  Bits beyond
   those corresponding to the tables needed by the type in use MUST be
   ignored.

   For Q values from 128 to 254, the Q value to quantization table data
   mapping MUST be static, i.e., the receivers are guaranteed that they
   only need to read the table data once in order to correctly decode
   frames sent with that Q value.  A Q value of 255 denotes that the