RFC 4175
RTP Payload Format for Uncompressed Video
RTP Payload Format for Uncompressed Video 🎀
Okay bestie, let's start with the title block tea ☕ This doc is RFC 4175 from the Network Working Group, written by L. Gharai (USC/ISI) and C. Perkins (University of Glasgow) in September 2005. It's a Standards Track doc, and the title block doesn't list anything it obsoletes or updates 💅
Status of This Memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract 🌸
This memo is all about a packetization scheme for wrapping uncompressed video into a payload format for the Real-time Transport Protocol, RTP 🦋 It covers a whole range of standard- and high-definition video formats, including common TV formats like ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), like SMPTE 274M and SMPTE 296M. The format is built to be applicable and extensible to new video formats as they come out, which is so smart 🧠✨
1. Introduction 💖
Okay so this memo defines a way to packetize uncompressed, studio-quality video streams so they can travel over RTP [RTP]. It handles a bunch of standard and high-definition formats, including ITU-R BT.601 [601], SMPTE 274M [274] and SMPTE 296M [296] 🎬
Uncompressed standard definition TV is defined by ITU Recommendation BT.601 [601], along with the 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 📺
HD gets its specs from SMPTE 274M [274] and 296M [296]. SMPTE 274M is a family of scanning systems with an image format of 1920x1080 pixels, with progressive and interlaced scanning. SMPTE 296M is systems with an image size of 1280x720 pixels and progressive scanning 🌈 In progressive scanning, scan lines get displayed in order from the top to the bottom of a full frame. In interlaced scanning, a frame gets split into its odd and even scan lines (called fields), and the two fields get displayed one after the other 🔥 Both SMPTE 274M and 296M define images with aspect ratios of 16:9, and they define the digital representation for RGB and YCbCr components. For YCbCr, the Cb and Cr components are horizontally sub-sampled by a factor of two (4:2:2 color encoding) 💅
Even though these formats differ in their details, they are structurally very similar 👑 So this memo specifies one payload format to wrap 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 gets packetized into one or more RTP packets. If the data for a complete scan line is bigger than the network MTU, the scan line SHOULD be fragmented into multiple RTP packets, each one smaller than the MTU 💜 A single RTP packet MAY contain data for more than one scan line. Only the active samples go in the RTP payload. Inactive samples and the contents of horizontal and vertical blanking SHOULD NOT be transported 🙈 When ancillary data is being sent, the sender and receiver can tell ancillary and video data apart by their scan line numbers. The ancillary data uses 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 🔍 Here are the valid ranges:
- For SMPTE 296M format video, valid scan line numbers are 26 through 745, inclusive.
- For progressive scan SMPTE 274M format video, valid scan lines are scan line 42 through 1121, inclusive.
- For interlaced scan SMPTE 274M format video, valid scan line numbers for field one (F=0) are 21 to 560, and valid scan line numbers for the second field (F=1) are 584 to 1123.
- For ITU-R BT.601 format video, the blanking intervals defined in BT.656 are used. For 625 line video, lines 24 to 310 of field one (F=0) and 337 to 623 of the second field (F=1) are valid. For 525 line video, lines 21 to 263 of the first field, and 284 to 525 of the second field, are valid.
- Other formats (e.g., [372]) may define different ranges of active lines.
The payload header has a 16-bit extension to the standard 16-bit RTP sequence number 🤯 That stretches the sequence number to 32 bits, so the payload format can handle high data rates without ambiguity. This is necessary because the 16-bit RTP sequence number rolls over super fast at high data rates. For example, a 1-Gbps video stream with packets of at least 1000 octets would have the standard RTP packet roll over in 0.5 seconds. That's a problem for detecting loss and out-of-order packets, especially when the round-trip time is more than half a second 😭 The extended 32-bit number gives a much longer wrap-around time of about nine hours 💀✨
Each scan line is made of an integer number of pixels, and each pixel is represented by a number of samples. Samples can be coded as 8-, 10-, 12-, or 16-bit values 🌸 A sample can represent a color component or a luminance component of the video. Color samples can be shared between adjacent pixels, and that sharing is known as color sub-sampling. It's typically done in the YCbCr color space to shrink the size of the image data 🦋
Pixels that share sample values MUST be transported together as a "pixel group" 🫶 If 10-bit or 12-bit samples are used, each pixel might also be a non-integer number of octets. In that case, several pixels MUST be combined into an octet-aligned pixel group for transmission. These restrictions make life easier for receivers. The whole payload stays octet aligned, and the samples for a single pixel don't get fragmented across multiple packets [ALF] 🔥
Here's an example. In YCbCr video with 4:1:1 color sub-sampling, each group of 4 adjacent pixels has 6 samples, Y1 Y2 Y3 Y4 Cr Cb, with the Cr and Cb values shared between all 4 pixels 🎀 If the samples are 8-bit values, the result is a group of 4 pixels made of 6 octets, easy peasy 🍰 But if the samples are 10-bit values, the resulting 60-bit group isn't octet aligned. To be both octet aligned and properly framed, you have to collect two groups of 4 adjacent pixels, which then line up on a 15-octet boundary 🧩 This length is called the pixel group size ("pgroup") 💜
Formally, the "pgroup" parameter is the size in octets of the smallest grouping of pixels such that 1) the grouping comprises an integer number of octets; and 2) if color sub-sampling is used, samples are only shared within the grouping. When packetizing digital active line content, video data MUST NOT be fragmented within a pgroup 🚫✨
Video content almost always comes with extra info, like audio tracks, time code, and so on 🎧 In professional digital video, this data is usually embedded in the non-active parts of the video stream (the horizontal and vertical blanking periods) so that precise and robust synchronization stays intact 🔐 This payload format requires that applications using that synchronized ancillary data SHOULD deliver it in separate RTP sessions that run alongside the video session. The normal RTP mechanisms SHOULD be used to synchronize the media 🌈
4. RTP Packetization 👑
The standard RTP header is followed by a 2-octet payload header that extends the RTP Sequence Number. After that comes a 6-octet payload header for each line (or partial line) of video included 🧚 One or more lines, or partial lines, of video data follow. This format keeps the payload header 32-bit aligned in the common case, where one scan line (or fragment) of video is in each RTP packet 🦋
For example, if two lines of video are encapsulated, the payload format looks like Figure 1 🎬
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Sequence Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Line No |C| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |F| Line No |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Offset | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Two (partial) lines of video data .
. .
+---------------------------------------------------------------+Figure 1: RTP Payload Format showing two (partial) lines of video ✨
4.1. The RTP Header ✨
okay bestie, the fixed RTP header keeps its normal meaning 🎀 but there are a few extra notes you need to know about:
Payload Type (PT): 7 bits 🦋 this is a dynamically allocated payload type field that tells you the payload is uncompressed video.
Timestamp: 32 bits ⏰ for progressive scan video, the timestamp is the sampling instant of the frame the RTP packet belongs to. Packets MUST NOT include data from multiple frames, and every packet in the same frame MUST have the same timestamp. no cap, this is a big rule 💅
for interlaced video, the timestamp is the sampling instant of the field instead. Packets MUST NOT include data from multiple fields, and every packet in the same field MUST have the same timestamp. Field timestamps (instead of a frame timestamp plus a field indicator bit) are needed to support reverse 3-2 pulldown, so it's not just extra work for no reason 🙈
a 90-kHz timestamp SHOULD be used in both cases. If the sampling instant doesn't line up with an integer value of the clock (which can happen when interleaving), the value SHALL be truncated to the next lowest integer, with no ambiguity. iconic, clean, no drama 👑
Marker bit (M): 1 bit 🚩 with progressive scan video, the marker bit marks the end of a video frame. With interlaced video, it marks the end of the field. The marker bit MUST be set to 1 for the last packet of the video frame/field, and MUST be set to 0 for every other packet. so it's basically the "that's the end, bestie" flag 💜
Sequence Number: 16 bits 🔢 this is the low-order bits of the RTP sequence number. The standard 16-bit sequence number gets a buddy: another 16 bits in the payload header, so wrap-around doesn't cause problems when you're running at really high rates 🚀
4.2. Payload Header 🎀
the payload header is where the real tea is ☕ it has these fields:
Extended Sequence Number: 16 bits ✨ these are the high-order bits of the extended 32-bit sequence number, in network byte order.
Length: 16 bits 📏 this is the number of octets of data included from this scan line, in network byte order. It MUST be a multiple of the pgroup value. not optional, periodt 💅
Line No.: 15 bits 📍 this is the scan line number of the encapsulated data, in network byte order. Successive RTP packets MAY contain parts of the same scan line (with an incremented RTP sequence number but the same timestamp) if the line needs to be fragmented. lowkey the most flexible field here 🦋
Offset: 15 bits 🧭 this is the offset of the first pixel of the payload data within the scan line. If YCbCr format data is being transported, it's the pixel offset of the luminance sample. If RGB format data is being transported, it's the pixel offset of the red sample. If BGR format data is being transported, it's the pixel offset of the blue sample. The value is in network byte order. The offset is zero if the first sample in the payload is the start of the line, and it goes up by one for each pixel 🌸
Field Identification (F): 1 bit 🌓 this tells you which field the scan line belongs to, for interlaced data. F=0 means the first field and F=1 means the second field. For progressive scan data (for example, SMPTE 296M format video), F MUST always be set to zero. no exceptions, bestie 🙅♀️
Continuation (C): 1 bit 🔗 this says whether an additional scan line header follows the current one in the RTP packet. It's set to 1 if another header follows, which means the packet is carrying data for more than one scan line. Otherwise it's set to 0. Several scan lines MAY be included in a single packet, up to the path MTU limit. The only way to figure out how many scan lines are in a packet is to parse the payload headers, so go parse them 🧚
4.3. Payload Data 🍓
depending on the video format, each RTP packet can hold a single complete scan line, a single fragment of a scan line, or one (or more) complete scan lines plus scan line fragments. The length of each scan line or scan line fragment MUST be an integer multiple of the pgroup size in octets. Scan lines SHOULD be fragmented so the resulting RTP packet is smaller than the path MTU. main character energy, keeping packets small 💖
it's possible that the scan line length doesn't divide evenly by the number of pixels in a pgroup, so the final pixel data of a scan line won't line up with an octet or a pgroup boundary. Even so, the payload MUST contain a whole number of pgroups. The sender MUST fill the remaining bits of the final pgroup with zero, and the receiver MUST ignore the fill data. (basically the trailing edge of the image gets black-filled up to a pgroup boundary 🖤)
RGB and BGR formats 🌈 for RGB video, samples are packed in the order Red-Green-Blue. For BGR video, they're packed Blue-Green-Red. For both, if 8-bit samples are used, the pgroup is 3 octets. If 10-bit samples are used, samples from 4 adjacent pixels form 15-octet pgroups. If 12-bit samples are used, samples from 2 adjacent pixels form 9-octet pgroups. If 16-bit samples are used, each pixel forms its own separate 6-octet pgroup.
RGBA and BGRA formats 🫧 for RGBA video, samples are packed Red-Green-Blue-Alpha. For BGRA video, they're packed Blue-Green-Red-Alpha. For 8-, 10-, 12-, or 16-bit samples, each pixel forms its own pgroup, with octet sizes of 4, 5, 6, and 8, respectively.
YCbCr formats 🎞️ if the video is YCbCr, the way samples get packed into the payload depends on the color sub-sampling used.
YCbCr 4:4:4 💜 samples are packed in the order Cb-Y-Cr for both interlaced and progressive frames. If 8-bit samples are used, the pgroup is 3 octets. If 10-bit samples are used, samples from 4 adjacent pixels form 15-octet pgroups. If 12-bit samples are used, samples from 2 adjacent pixels form 9-octet pgroups. If 16-bit samples are used, each pixel forms a separate 6-octet pgroup.
YCbCr 4:2:2 🩷 the Cb and Cr components are horizontally sub-sampled by a factor of two, so each Cb and Cr sample corresponds to two Y components. Samples are packed in the order Cb0-Y0-Cr0-Y1 for both interlaced and progressive scan lines. For 8-, 10-, 12-, or 16-bit samples, the pgroup is formed from two adjacent pixels (4, 5, 6, or 8 octets, respectively).
YCbCr 4:1:1 🍑 the Cb and Cr components are horizontally sub-sampled by a factor of four, so each Cb and Cr sample corresponds to four Y components. Samples are packed in the order Cb0-Y0-Y1-Cr0-Y2-Y3 for both interlaced and progressive scan lines. For 8-, 10-, 12-, or 16-bit samples, the pgroup is formed from four adjacent pixels (6, 15, 9, or 12 octets, respectively).
YCbCr 4:2:0 🌙 the Cb and Cr components are sub-sampled by a factor of two both horizontally and vertically, so chrominance samples get shared between certain adjacent lines. Figure 2 shows how the luminance and chrominance samples fit together for a 6x6 pixel grid of 4:2:0 YCbCr video. The pixel group is four pixels arranged in a 2x2 matrix. The octet size of the pgroup for progressive scan 4:2:0 video with sample sizes of 8, 10, 12, and 16 bits is 6, 15, 9, and 12 octets, respectively. For interlaced 4:2:0 video, the corresponding pgroups are 4, 5, 6, and 8 octets.
line 0: Y00 Y01 Y02 Y03 Y04 Y05
Cb00 Cr00 Cb01 Cr01 Cb02 Cr02
line 1: Y10 Y11 Y12 Y13 Y14 Y15
line 2: Y20 Y21 Y22 Y23 Y24 Y25
Cb10 Cr10 Cb11 Cr11 Cb12 Cr12
line 3: Y30 Y31 Y32 Y33 Y34 Y35
line 4: Y40 Y41 Y42 Y43 Y44 Y45
Cb20 Cr20 Cb21 Cr21 Cb22 Cr22
line 5: Y50 Y51 Y52 Y53 Y54 Y55Figure 2: Chrominance/luminance composition in 4:2:0 YCbCr video
when you packetize progressive scan 4:2:0 YCbCr video, samples from two consecutive scan lines go in each packet. The scan line number in the payload header is set to the number of the first scan line in the pair. Figure 3 shows it:
line 0/1:
Y00-Y01-Y10-Y11-Cb00-Cr00 Y02-Y03-Y12-Y13-Cb01-Cr01
Y04-Y05-Y14-Y15-Cb02-Cr02
line 2/3:
Y20-Y21-Y30-Y31-Cb10-Cr10 Y22-Y23-Y32-Y33-Cb11-Cr11
Y24-Y25-Y34-Y35-Cb12-Cr12
line 4/5:
Y40-Y41-Y50-Y51-Cb20-Cr20 Y42-Y43-Y52-Y53-Cb21-Cr21
Y44-Y45-Y54-Y55-Cb22-Cr22Figure 3: Packetization of progressive 4:2:0 YCbCr video
for interlaced transport, chrominance samples are sent with every other line. The first set of chrominance samples may go with either the first line of field 0 or the first line of field 1. Figure 4 shows chrominance samples starting with the first line of field 0, which is signaled by the "top-field-first" MIME parameter. 🎀
field 0:
line 0: Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02
line 2: Y20-Y21 Y22-Y23 Y24-Y25
line 4: Y40-Y41-Cb20-Cr20 Y42-Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22
field 1:
line 1: Y10-Y11 Y12-Y13 Y14-Y15
line 3: Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12
line 5: Y50-Y51 Y52-Y53 Y54-Y55Figure 4: Packetization of interlaced 4:2:0 YCbCr video with top-field-first.
chrominance values can be sampled with different offsets relative to the luminance values. For instance, in Figure 2 the chrominance values are sampled at the same distance from neighboring luminance samples. It's also possible for a chrominance sample to be co-sited with a luminance sample, like in Figure 5:
line 0: Y00-C Y01 Y02-C Y03 Y04-C Y05
line 1: Y10 Y11 Y12 Y13 Y14 Y15
line 2: Y20-C Y21 Y22-C Y23 Y24-C Y25
line 3: Y30 Y31 Y32 Y33 Y34 Y35
line 4: Y40-C Y41 Y42-C Y43 Y44-C Y45
line 5: Y50 Y51 Y52 Y53 Y54 Y55Figure 5: Co-sited video sampling in 4:2:0 YCbCr video where C designates a CbCr pair
in general, chrominance values may sit between luminance samples or be co-sited. Positions can be designated with an integer numbering system that goes from left to right and top to bottom. The position matrices in Figures 6, 7, and 8 apply to 4:2:0, 4:2:2, and 4:1:1 video, respectively:
line N: Y[0] [1] Y[2] Y[0] [1] Y[2]
[3] [4] Y[5] [3] [4] [5]
line N+1: Y[6] [7] Y[8] Y[6] [7] Y[8]Figure 6: Chrominance position matrix for 4:2:0 YCbCr video
line N: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3]
line N+1: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3]Figure 7: Chrominance position matrix for 4:2:2 YCbCr video
line N: Y[0] [1] Y[2] [3] Y[4] [5] Y[6]
line N+1: Y[0] [1] Y[2] [3] Y[4] [5] Y[6]Figure 8: Chrominance position matrix for 4:1:1 YCbCr video
although these positions don't change the packetization order of chrominance and luminance samples, the information is needed for interpolation before display, so it should be signaled to the receiver. ✨
5. RTCP Considerations 📡
RTCP SHOULD be used as specified in RFC 3550 [RTP]. Here's the tea 🫖: the sender's octet count in SR packets and the cumulative number of packets lost will wrap around really quickly for high data rate streams. That means these two fields may not accurately show the octet count and number of packets lost since the beginning of transmission, as defined in RFC 3550. So for network monitoring purposes, other means of keeping track of these variables SHOULD be used. 💅🔥
6. IANA Considerations 💅
okay so IANA (the folks who keep the official registries) got to register one brand new MIME subtype with its own RTP payload format, and they also made two sub-parameter registries. the tea is served 🫖
6.1. MIME type registration 🎀
here's the registration form, bestie:
- MIME media type name:
video - MIME subtype name:
raw
Required parameters:
rate: the RTP timestamp clock rate. Applications using this payload format SHOULD use a value of90000.sampling: decides the color (sub-)sampling mode of the video stream. Right now the defined values areRGB,RGBA,BGR,BGRA,YCbCr-4:4:4,YCbCr-4:2:2,YCbCr-4:2:0, andYCbCr-4:1:1. New values may be registered as described in section 6.2 of RFC 4175. 🌈width: the number of pixels per line. It's an integer between1and32767.height: the number of lines per frame. It's an integer between1and32767.depth: the number of bits per sample. It's an integer, and the typical values include8,10,12, and16.colorimetry: defines the set of colorimetric specifications and other transfer characteristics for the video source, by pointing at an external spec. The valid values and their specs are:
BT601-5 ITU Recommendation BT.601-5 [601]
BT709-2 ITU Recommendation BT.709-2 [709]
SMPTE240M SMPTE standard 240M [240]New values may be registered as described in section 6.2 of RFC 4175.
Optional parameters:
Interlace: if this OPTIONAL parameter is present, it means the video stream is interlaced. If it's absent, progressive scan is implied. 🦋Top-field-first: if this OPTIONAL parameter is present, chrominance samples get packetized starting with the first line of field 0. Its absence means they get packetized starting with the first line of field 1.chroma-position: this OPTIONAL parameter defines where the chrominance samples sit relative to the luminance samples. It's either a single integer or a comma separated pair of integers, and the integer values run from0to8, as specified in Figures 6-8 of RFC 4175. A single integer means Cb and Cr are co-sited. A comma separated pair designates the locations of the Cb and Cr samples, respectively. If it's absent, a single value of zero is assumed for color-subsampled video (chroma-position=0).gamma: an OPTIONAL floating point gamma correction value. ✨
Encoding considerations: uncompressed video is only transmitted over RTP as specified in RFC 4175. No file format media type has been defined to go with this transmission media type at this time.
Security considerations: See section 9 of RFC 4175. 🔒
Interoperability considerations: NONE.
Published specification: RFC 4175.
Applications which use this media type: Video communication.
Additional information: None
Person & email address to contact for further information:
Ladan Gharai <ladan@isi.edu> IETF Audio/Video Transport working group.
Intended usage: COMMON
Author: Ladan Gharai <ladan@isi.edu>
Change controller: IETF AVT Working Group, delegated from the IESG
6.2. Parameter Registration 🧚
new values of the sampling parameter MAY be registered with IANA, as long as they reference an RFC or another permanent and readily available specification (the Specification Required policy of RFC 2434 [2434]). A new registration MUST define the packing order of samples and a valid combinations of color and sub-sampling modes.
new values of the colorimetry parameter MAY be registered with IANA, provided they reference an RFC or other permanent and readily available specification if colorimetric parameters and other applicable transfer characteristics (the Specification Required policy of RFC 2434 [2434]).
7. Mapping MIME Parameters into SDP 🍓
the info in the MIME media type spec maps onto specific fields in the Session Description Protocol (SDP) [SDP], which is what people commonly use to describe RTP sessions. When SDP is used to set up sessions carrying uncompressed video, the mapping goes like this:
- The MIME type (
video) goes in the SDPm=line as the media name. - The MIME subtype (the payload format name) goes in the SDP
a=rtpmapline as the encoding name. - The remaining parameters go in the SDP
a=fmtpattribute. You copy them straight from the MIME media type string as a semicolon-separated list of parameter=value pairs.
here's a sample SDP mapping for uncompressed video:
m=video 30000 RTP/AVP 112
a=rtpmap:112 raw/90000
a=fmtp:112 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10;
colorimetry=BT.709-2; chroma-position=1in this example, dynamic payload type 112 is used for uncompressed video, and the RTP sampling clock is 90 kHz. the a=fmtp: line got wrapped so it fits on the page, but in the actual SDP file it's one long line 💖
8. Security Considerations 🔒
RTP packets using the payload format defined in this spec are subject to the security considerations in the RTP spec [RTP] and any appropriate RTP profile. This basically means that confidentiality of the media streams is achieved through encryption.
this payload type doesn't show any significant non-uniformity in receiver-side computational complexity for packet processing, so it doesn't pose a potential denial-of-service threat on that front.
it's important to know that uncompressed video can have immense bandwidth requirements. We're talking up to 270 Mbps for standard-definition video, and about 1 Gbps for high-definition video. That's enough to cause a potential denial-of-service problem if it's sent onto most currently available Internet paths. 🚨
so, if best-effort service is being used, users of this payload format MUST monitor packet loss to make sure the loss rate stays within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, going through the same network conditions, would achieve an average throughput (measured on a reasonable timescale) that's not less than what the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed to in a layered multicast session), or by arranging for a receiver to leave the session if the loss rate gets unacceptably high. 🌸
this payload format may also be used in networks that provide quality-of-service guarantees. If enhanced service is being used, receivers SHOULD monitor packet loss to make sure the service they requested is actually being delivered. If it isn't, they SHOULD assume they're receiving best-effort service and behave accordingly. 💅
9. Relation to RFC 2431 🎀
compared with RFC 2431, this memo specifies support for a much wider variety of uncompressed video, in terms of frame size, color sub-sampling, and sample sizes. Although [BT656] can transport up to 4096 scan lines and 2048 pixels per line, our payload type can support up to 32768 scan lines and pixels per line. Also, RFC 2431 only addresses 4:2:2 YCbCr data, while this memo covers YCbCr, RGB, RGBA, BGR, BGRA, and most common color sub-sampling schemes. Because we cover so many video types, this memo also assumes out-of-band signaling for sample size and data types, whereas RFC 2431 uses in-band signaling. 🦋
10. Relation to RFC 3497 🧚
RFC 3497 [292RTP] specifies an RTP payload format for encapsulating SMPTE 292M video. SMPTE 292M defines a bit-serial digital interface for local area High-Definition Television (HDTV) transport. As a transport medium, SMPTE 292M uses 10-bit words and a fixed 1.485 Gbps (and 1.485/1.001 Gbps) data rate. It's typically used in the broadcast industry to transport other video formats such as SMPTE 260M, SMPTE 295M, SMPTE 274M, and SMPTE 296M.
RFC 3497 defines a circuit emulation for transporting SMPTE 292M over RTP. It's very specific to SMPTE 292 and was designed to be interoperable with existing broadcast equipment at a constant rate of 1.485 Gbps.
this memo, on the other hand, defines a flexible native packetization scheme that can packetize any uncompressed video at varying data rates. And unlike RFC 3497, this memo only transports active video pixels (horizontal and vertical blanking are not transported). ✨
11. Acknowledgements 🫶
the authors are so grateful to Philippe Gentric, Chuck Harrison, Stephan Wenger, and Dave Singer for their feedback. 💜
this memo is based upon work supported by the U.S. National Science Foundation (NSF) under Grant No. 0230738. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of NSF.
Normative References 📚
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD
64, RFC 3550, July 2003.
[2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[601] International Telecommunication Union, "Studio encoding
parameters of digital television for standard 4:3 and wide
screen 16:9 aspect ratios", Recommendation BT.601, October
1995.
[709] International Telecommunication Union, "Parameter Values for
HDTV Standards for Production and International Programme
Exchange", Recommendation BT.709-2
[240] Society of Motion Picture and Television Engineers,
"Television - Signal Parameters - 1125-Line High-Definition
Production", SMPTE 240M-1999.Informative References 🌈
[274] Society of Motion Picture and Television Engineers,
"1920x1080 Scanning and Analog and Parallel Digital
Interfaces for Multiple Picture Rates", SMPTE 274M-1998.
[296] Society of Motion Picture and Television Engineers,
"1280x720 Scanning, Analog and Digital Representation and
Analog Interfaces", SMPTE 296M-1998.
[372] Society of Motion Picture and Television Engineers, "Dual
Link 292M Interface for 1920 x 1080 Picture Raster", SMPTE
372M-2002.
[ALF] Clark, D. D., and Tennenhouse, D. L., "Architectural
Considerations for a New Generation of Protocols", In
Proceedings of SIGCOMM '90 (Philadelphia, PA, Sept. 1990),
ACM.
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[BT656] Tynan, D., "RTP Payload Format for BT.656 Video Encoding",
RFC 2431, October 1998.
[292RTP] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP
Payload Format for Society of Motion Picture and Television
Engineers (SMPTE) 292M Video", RFC 3497, March 2003.
[656] International Telecommunication Union, "Interfaces for
Digital Component Video Signals in 525-line and 625-line
Television Systems Operating at the 4:2:2 Level of
Recommendation ITU-R BT.601 (Part A)", Recommendation
BT.656, April 1998.Authors' Addresses 💖
Okay bestie, here's where the authors are based 🌸 Ladan first:
Ladan Gharai
USC Information Sciences Institute
3811 N. Fairfax Drive, #200
Arlington, VA 22203
USA
EMail: ladan@isi.eduAnd Colin, at the University of Glasgow 🦋
Colin Perkins
University of Glasgow
Department of Computing Science
17 Lilybank Gardens
Glasgow G12 8QQ
United Kingdom
EMail: csp@csperkins.orgFull Copyright Statement 🎀
Okay, the legal bit, but make it cute ✨ The copyright belongs to The Internet Society (2005). Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So the authors keep their rights, no cap 💅
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧚
Lowkey important, so listen up 👑 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🫶
Acknowledgement 🌈
And finally, the thank-you moment 😭 Funding for the RFC Editor function is currently provided by the Internet Society. The RFC Editor is funded by the Internet Society, so that's who keeps the whole operation running ✨
📦 where this page comes from
- ietf: rfc4175 2005-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms