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