rfc-3497

RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video

L. Gharai, C. Perkins, G. Goncher, A. Mankin
date2003-03 streamIETF arearai wgavt statusPROPOSED STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc3497 doi10.17487/RFC3497
This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS-TRACK]

Extracted elements (25)

design-rationale §4

A 148.5 MHz timestamp (matching the SMPTE 292M word clock) was chosen so that receivers can reconstruct stream timing without needing to know the specific source format. This provides a unique timestamp per 10-bit word and is format-agnostic across SMPTE 260M, 274M, 295M, and 296M sources.

rtp, realtime

design-rationale §4

The 11-bit line number is carried in the payload header to provide application-level resiliency: if the packet containing the EAV is lost, downstream receivers can still identify the current line. It also enables higher-level monitoring without full SMPTE 292M stream parsing.

rtp, realtime

design-rationale §4

The standard 16-bit RTP sequence number wraps around in approximately 336 milliseconds at 1.485 Gbps with 1000-octet packets, which is insufficient for detecting loss and reordering. Extending the sequence number to 32 bits via the payload header provides an approximately 6-hour wrap period under the same assumptions.

rtp, realtime

design-rationale §4

To satisfy both octet alignment and ALF (application-level framing) principles simultaneously for 4:2:2 YCrCb video with 10-bit words, the minimum packetization unit must represent 2 groups of 4 pixels (yielding a 40-bit = 5-octet boundary). This motivates the pgroup concept rather than permitting arbitrary octet splits.

rtp, realtime

interoperability-note §6

At 1.485 Gbps, the RTCP SR sender octet count wraps around in 23 seconds and the cumulative packets-lost counter wraps in 93 seconds. Applications requiring accurate long-running totals must track rollover counts at the application layer rather than relying solely on RTCP SR fields.

rtp, realtime

interoperability-note §1

Compressed HDTV is a subset of MPEG-2 and is fully handled by RFC 2250; this payload format addresses only uncompressed HDTV. Implementors supporting both compressed and uncompressed HDTV must use different payload types.

rtp, realtime

normative-requirement §9 SHOULD

Because congestion control is not possible for SMPTE 292M over RTP, use of this payload SHOULD be narrowly limited to suitably connected network endpoints or networks where QoS guarantees are available.

rtp, realtime, security, congestion

normative-requirement §4 MUST NOT

SAV and EAV+LN+CRC timing signals MUST NOT be fragmented across RTP packets, because the SMPTE 292M decoder relies on them to detect the start of scan lines.

rtp, realtime

normative-requirement §4 SHOULD NOT

The contents of the Digital Active Line SHOULD NOT be fragmented within a pgroup. A pgroup of 1 indicates that data may be split at any octet boundary.

rtp, realtime

normative-requirement §5.2 MUST

The Line No field in the payload header MUST correspond to the line number of the first 10-bit word in the packet, extracted from the SMPTE 292M timing signals.

rtp, realtime

normative-requirement §5.2 MUST

The Z field (2 bits) in the payload header SHOULD be set to zero by the sender and MUST be ignored by receivers.

rtp, realtime

normative-requirement §9 MUST

When best-effort service is used, RTP receivers MUST monitor packet loss to ensure the loss rate is within acceptable parameters and MUST leave the session if the loss rate is too high. The acceptable threshold is defined in terms of equivalent TCP throughput across the same path.

rtp, realtime, congestion, security

normative-requirement §9 SHOULD

When QoS-enhanced service is used, RTP receivers SHOULD monitor packet loss to verify the requested service is being delivered; if not, they SHOULD assume best-effort service and behave accordingly.

rtp, realtime, qos

normative-requirement §7 MUST

When the 148500000/1.001 Hz clock rate is used, a timestamp value of 148351648 MUST be signaled in the MIME 'rate' parameter, and receivers MUST interpret this value as 148500000/1.001 Hz.

rtp, realtime, registry

protocol-element §2

A SMPTE 292M television line comprises interleaved luminance (Y) and chrominance (CrCb) streams using 4:2:2 coding. Each stream is divided into four parts: SAV (start of active video), digital active line, EAV (end of active video), and digital line blanking. Ancillary data (H-ANC or V-ANC) may substitute for blanking or active line content.

rtp, realtime

protocol-element §4

The pgroup is the minimum packetization unit for digital active line content, defined as the smallest number of octets that is both octet-aligned and preserves ALF (application-level framing) integrity for a given color subsampling. For 4:2:2 sampling the pgroup is 5 octets; for 4:2:0 and 4:4:4 it is 15 octets; a pgroup of 1 allows splitting at any octet boundary.

rtp, realtime

protocol-element §5.1

The RTP Marker bit (M) denotes the end of a video frame; it is set to 1 for the last packet of the video frame (the packet containing the last sample before EAV) and 0 for all other packets.

rtp, realtime

protocol-element §5.2

The RTP sequence number is extended to 32 bits by appending a 16-bit high-order extension in the payload header. The standard RTP header carries the low 16 bits; the payload header carries the high 16 bits in network byte order. This extension accommodates HDTV's 1.485 Gbps data rate.

rtp, realtime

protocol-element §5.1

The RTP timestamp clock runs at 148.5 MHz (or 148.5/1.001 MHz), providing a unique timestamp for each 10-bit word in the SMPTE 292M stream. This allows the receiver to reconstruct stream timing without knowledge of the specific source format (e.g., SMPTE 274M or 296M). The 32-bit timestamp wraps around in approximately 21 seconds.

rtp, realtime

registry §7

This document registers the MIME media type video/SMPTE292M. Required parameter: 'rate' (RTP timestamp clock, either 148500000 or the encoded value 148351648 for 148500000/1.001 Hz). Optional parameter: 'pgroup' (octet grouping for 10-bit word alignment; defaults to 1).

registry, rtp, realtime

security-consideration §9

The payload bandwidth of 1.485 Gbps (excluding RTP overhead) creates a significant denial-of-service risk if transmitted onto typical Internet paths. Since congestion control is architecturally impossible for uncompressed SMPTE 292M flows, deployment must be confined to private or QoS-provisioned networks.

security, rtp, realtime, congestion

security-consideration §9

The payload format does not exhibit significant non-uniformity in receiver-side packet processing complexity, so it does not pose a computational denial-of-service threat to intended receivers.

security, rtp, realtime

wire-format §5

Each RTP packet consists of the standard RTP header followed by a 4-octet payload header and SMPTE 292M payload data. The payload header contains: sequence# high bits (16 bits), F flag (1 bit), V flag (1 bit), Z reserved (2 bits), and line number (11 bits).

rtp, realtime

wire-format §2

Line number is encoded in two 10-bit words LN0 and LN1 following EAV. LN0 carries bits L0–L6 of the 11-bit line number; LN1 carries bits L7–L10. Remaining bits are reserved and set to 0.

rtp, realtime

wire-format §2

The XYZ timing reference word is a 10-bit word (bit 9 always 1) carrying flags: F (field 1=0, field 2=1), V (field blanking=1), H (SAV=0, EAV=1), and six P bits (protected parity bits defined in SMPTE 292M Table 2). The EAV preamble is 3FF 000 000 XYZ; the SAV preamble is also 3FF 000 000 XYZ.

rtp, realtime