RTP Payload Format for JPEG-compressed Video
RFC 2435

Document Type RFC - Proposed Standard (October 1998; No errata)
Obsoletes RFC 2035
Authors Paul Stewart  , Steven McCanne  , Bill Fenner  , Lance Berc  , Ron Frederick 
Last updated 2020-07-29
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2435 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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.


   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-
   conf@es.net 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",
   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
Show full document text