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.
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-
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",
"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
Show full document text