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).


   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

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",
   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