RTP Payload Format for Uncompressed Video
updated by
- rfc-4421 — RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes
Extracted elements (30)
For interlaced video, field-level timestamps are used rather than a frame timestamp plus a field indicator bit. This is specifically required to support reverse 3-2 pulldown, where fields within a frame have different sampling instants.
The payload header extends the RTP sequence number from 16 to 32 bits because at 1 Gbps with 1000-octet packets, the standard 16-bit sequence number wraps in approximately 0.5 seconds — less than a round-trip time — making loss and reordering detection unreliable. The 32-bit number allows a wrap-around time of roughly nine hours.
Unlike RFC 2431, this format assumes out-of-band signaling (via MIME parameters and SDP) for sample size and data type, rather than in-band signaling. This design choice accommodates the wide variety of video types covered by the format.
RFC 3497 (SMPTE 292M RTP payload) defines a circuit emulation at a fixed 1.485 Gbps targeting broadcast equipment interoperability; this format instead provides flexible native packetization at variable data rates transporting only active pixels, and is not interoperable with RFC 3497 equipment.
This format supersedes RFC 2431 (BT.656 payload format): it supports scan sizes up to 32767 lines and pixels per line (vs. 4096/2048), and adds support for RGB, RGBA, BGR, BGRA, YCbCr 4:4:4, 4:2:0, and 4:1:1 color formats beyond the 4:2:2-only RFC 2431.
A 90-kHz RTP timestamp SHOULD be used for both progressive and interlaced video. If the sampling instant does not correspond to an integer clock value, the value SHALL be truncated to the next lowest integer.
Applications using synchronized ancillary data SHOULD deliver it in separate RTP sessions operating concurrently with the video session, using normal RTP mechanisms for synchronization.
For progressive scan video F MUST always be set to zero. For interlaced video, F=0 identifies the first field and F=1 the second field.
For progressive scan video, packets MUST NOT include data from multiple frames, and all packets belonging to the same frame MUST have the same timestamp. For interlaced video, the same constraints apply per field.
If best-effort service is used, senders MUST monitor packet loss to ensure the rate is within acceptable parameters, satisfying a TCP-friendliness condition or causing a receiver to leave the session if loss is unacceptably high.
If scan line data 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 active samples MUST be included in the RTP payload; inactive samples and the contents of horizontal and vertical blanking SHOULD NOT be transported.
Pixels that share sample values MUST be transported together as a pixel group. If 10-bit or 12-bit samples are used, several pixels MUST be combined into an octet-aligned pixel group for transmission.
RTCP SHOULD be used as specified in RFC 3550. For high-data-rate streams where RTCP SR octet count and cumulative loss fields wrap quickly, other means of tracking these variables SHOULD be used for network monitoring.
The marker bit MUST be set to 1 for the last packet of the video frame or field, and MUST be set to 0 for all other packets.
The payload MUST contain a whole number of pgroups; the sender MUST fill remaining bits of the final pgroup with zero and the receiver MUST ignore fill data, effectively black-filling the trailing edge of the image to a pgroup boundary.
Video data MUST NOT be fragmented within a pgroup when packetizing digital active line content. The length of each scan line or scan line fragment MUST be an integer multiple of the pgroup size in octets.
The Continuation (C) bit in the line header determines whether an additional scan line header follows the current one. It is set to 1 if more than one scan line's data is carried in the RTP packet; otherwise 0. The only way to determine the number of scan lines per packet is to parse the payload headers.
The payload header consists of a 2-octet Extended Sequence Number followed by one or more 6-octet line headers (Length, F, Line No, C, Offset fields), making the header 32-bit aligned in the common single-scan-line case.
The pixel group (pgroup) is defined as 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.
IANA created a sub-parameter registry for new values of the 'colorimetry' parameter. New values MAY be registered under the Specification Required policy and must reference a specification of colorimetric parameters and applicable transfer characteristics.
IANA registered the MIME media type video/raw for uncompressed video transported over RTP per RFC 4175. Required parameters are rate, sampling, width, height, depth, and colorimetry; optional parameters include Interlace, Top-field-first, chroma-position, and gamma.
Confidentiality of media streams is achieved by encryption as specified in the RTP specification and applicable RTP profile. This payload type does not exhibit significant non-uniformity in receiver-side computational complexity.
Uncompressed video can require up to 270 Mbps for standard-definition and approximately 1 Gbps for high-definition video, which is sufficient to cause denial-of-service if transmitted onto most currently available Internet paths.
Each per-line payload header is 6 octets: a 16-bit Length (octets of data for this line, network byte order, MUST be multiple of pgroup), a 1-bit F (field ID), a 15-bit Line No (network byte order), a 1-bit C (continuation), and a 15-bit Offset (first pixel within scan line, network byte order).
Extended Sequence Number is a 16-bit field in the payload header carrying the high-order bits of a 32-bit sequence number (network byte order), augmenting the 16-bit RTP sequence number to avoid wrap-around at high data rates.
For progressive scan YCbCr 4:2:0 video, the pgroup is a 2x2 pixel matrix (chrominance shared horizontally and vertically); two consecutive scan lines are included per packet, with the scan line number in the header set to the first line of the pair.
For RGB and BGR video with 10-bit samples, four adjacent pixels form 15-octet pgroups. For 12-bit samples, two adjacent pixels form 9-octet pgroups. For 8-bit samples, pgroup is 3 octets. For 16-bit samples, each pixel forms a 6-octet pgroup.
For YCbCr 4:1:1 video, samples are packed Cb0-Y0-Y1-Cr0-Y2-Y3; pgroup is formed from four adjacent pixels: 6, 15, 9, or 12 octets for 8-, 10-, 12-, or 16-bit samples respectively.
For YCbCr 4:2:2 video, samples are packed Cb0-Y0-Cr0-Y1; pgroup is formed from two adjacent pixels: 4, 5, 6, or 8 octets for 8-, 10-, 12-, or 16-bit samples respectively.