Network Working Group L. Gharai
Request for Comments: 4175 USC/ISI
Category: Standards Track C. Perkins
University of Glasgow
RTP Payload Format for Uncompressed 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 (C) The Internet Society (2005).
This memo specifies a packetization scheme for encapsulating
uncompressed video into a payload format for the Real-time Transport
Protocol, RTP. It supports a range of standard- and high-definition
video formats, including common television formats such as ITU
BT.601, and standards from the Society of Motion Picture and
Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The
format is designed to be applicable and extensible to new video
formats as they are developed.
This memo defines a scheme to packetize uncompressed, studio-quality
video streams for transport using RTP [RTP]. It supports a range of
standard and high-definition video formats, including ITU-R BT.601
, SMPTE 274M  and SMPTE 296M .
Formats for uncompressed standard definition television are defined
by ITU Recommendation BT.601  along with bit-serial and parallel
interfaces in Recommendation BT.656 . These formats allow both
625-line and 525-line operation, with 720 samples per digital active
line, 4:2:2 color sub-sampling, and 8- or 10-bit digital
Gharai & Perkins Standards Track [Page 1]RFC 4175 RTP Payload Format for Uncompressed Video September 2005
The representation of uncompressed high-definition television is
specified in SMPTE standards 274M  and 296M . SMPTE 274M
defines a family of scanning systems with an image format of
1920x1080 pixels with progressive and interlaced scanning, while
SMPTE 296M defines systems with an image size of 1280x720 pixels and
progressive scanning. In progressive scanning, scan lines are
displayed in sequence from top to bottom of a full frame. In
interlaced scanning, a frame is divided into its odd and even scan
lines (called fields) and the two fields are displayed in succession.
SMPTE 274M and 296M define images with aspect ratios of 16:9, and
define the digital representation for RGB and YCbCr components. In
the case of YCbCr components, the Cb and Cr components are
horizontally sub-sampled by a factor of two (4:2:2 color encoding).
Although these formats differ in their details, they are structurally
very similar. This memo specifies a payload format to encapsulate
these and other similar video formats for transport within RTP.
2. Conventions Used in This Document
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 .
3. Payload Design
Each scan line of digital video is packetized into one or more RTP
packets. If the data for a complete scan line exceeds the network
MTU, the scan line SHOULD be fragmented into multiple RTP packets,
each smaller than the MTU. A single RTP packet MAY contain data for
more than one scan line. Only the active samples are included in the
RTP payload: inactive samples and the contents of horizontal and
vertical blanking SHOULD NOT be transported. In instances where
ancillary data is being transmitted, the sender and receiver can
disambiguate between ancillary and video data via scan line numbers.
That is, the ancillary data will use scan line numbers that are not
within the scope of the video frame.
Scan line numbers are included in the RTP payload header, along with
a field identifier for interlaced video.
For SMPTE 296M format video, valid scan line numbers are from 26
through 745, inclusive. For progressive scan SMPTE 274M format
video, valid scan lines are from scan line 42 through 1121,
inclusive. For interlaced scan SMPTE 274M format video, valid