RTP Payload Format for Uncompressed Video
RFC 4175
| Document | Type |
RFC - Proposed Standard
(September 2005; Errata)
Updated by RFC 4421
|
|
|---|---|---|---|
| Authors | Ladan Gharai , Charles Perkins | ||
| Last updated | 2020-01-21 | ||
| Replaces | draft-gharai-avt-uncomp-video | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized with errata bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4175 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Allison Mankin | ||
| Send notices to | csp@csperkins.org, magnus.westerlund@ericsson.com | ||
Network Working Group L. Gharai
Request for Comments: 4175 USC/ISI
Category: Standards Track C. Perkins
University of Glasgow
September 2005
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 Notice
Copyright (C) The Internet Society (2005).
Abstract
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.
1. Introduction
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
[601], SMPTE 274M [274] and SMPTE 296M [296].
Formats for uncompressed standard definition television are defined
by ITU Recommendation BT.601 [601] along with bit-serial and parallel
interfaces in Recommendation BT.656 [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
representation.
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 [274] and 296M [296]. 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 [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
scan line numbers for field one (F=0) are from 21 to 560 and valid
scan line numbers for the second field (F=1) are from 584 to 1123.
For ITU-R BT.601 format video, the blanking intervals defined in
Gharai & Perkins Standards Track [Page 2]
Show full document text