RTP Payload Format for H.261 Video Streams
obsoletes
- rfc-2032 — RTP Payload Format for H.261 Video Streams
Extracted elements (25)
A 90-kHz RTP clock rate is chosen because it is a multiple of the natural H.261 frame rate (~29.97 Hz), so the timestamp can be incremented by an exact integer per frame, avoiding cumulative rounding errors.
State information from the frame and GOB headers (GOB number, MBA predictor, quantizer, motion vectors) is carried in each packet header to enable independent decoding of MBs without requiring receipt of all prior packets.
The H.261 stream is carried without the 512-bit ISDN framing or BCH error correction; RTP/UDP provide multiplexing and other error-resilience mechanisms are used instead, since those ISDN-specific layers are unnecessary on the Internet.
The I and V flags in the H.261 RTP header are hint flags that can be inferred from the bitstream, but are included to allow decoders to make optimizations before decoding begins; therefore their values cannot change during the session.
The MB (macroblock) is chosen as the unit of fragmentation rather than the GOB, because a GOB can be too large for a single packet. Packets must start and end on MB boundaries to allow independent processing and resynchronization after packet loss.
If a receiver does not specify picture size/MPI parameters in SDP, it should be assumed to be an RFC 2032 implementation; it is RECOMMENDED to assume such a receiver supports QCIF resolution at MPI=1.
New implementations receiving the H261 payload type with no SDP parameters will assume the sender is an old (RFC 2032) implementation and will send H.261 at QCIF resolution and 30 frames per second.
If a video image occupies more than one packet, the RTP timestamp SHALL be the same on all of those packets. Packets from different video images MUST have a different timestamp so that frames may be distinguished.
Implementations following this specification SHALL specify at least one supported picture size in the SDP offer/answer exchange.
The H.261-specific control packets FIR and NACK (from RFC 2032) SHALL NOT be used to request image refreshment; new implementations SHALL ignore them and SHALL NOT use them.
The H.261 stream SHALL be used without BCH error correction and without error correction framing when transported over RTP.
The initial value of the RTP timestamp MUST be random (unpredictable) to make known-plaintext attacks on encryption more difficult.
The marker bit of the RTP header MUST be set to one in the last packet of a video frame; otherwise, it MUST be zero.
The media name in the SDP 'm=' line MUST be video, the encoding name in 'a=rtpmap' MUST be H261, and the clock rate MUST be 90000.
The SDP codec option 'D' MUST NOT appear unless the sender of the SDP message is able to decode this option; it SHALL be considered a receiver capability.
The usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED; SRTP is given as one example mechanism.
EBIT (3 bits): number of least significant bits to ignore in the last data octet of the H.261 payload.
GOBN (4 bits): encodes the GOB number in effect at the start of the packet; set to 0 if the packet begins with a GOB header.
HMVD and VMVD (5 bits each): reference horizontal and vertical motion vector data, encoded as 2's complement; the value -16 (bit pattern '10000') is forbidden. Set to 0 when V=0, at GOB header boundaries, or when previous MB was not motion-compensated.
MBAP (5 bits): encodes the macroblock address predictor (last MBA encoded in the previous packet), biased by -1; range 1-32 encoded as 0-31. Set to 0 if the packet begins with a GOB header.
SBIT (3 bits): number of most significant bits to ignore in the first data octet of the H.261 payload.
This document registers the MIME media type 'video/H261' with optional parameters CIF, QCIF, and D, updating the prior registration in RFC 3555.
Confidentiality of H.261 media streams is achieved by encrypting after compression (end-to-end); SRTP may be used for both encryption and integrity. There is no conflict between compression and encryption.
H.261 is vulnerable to denial-of-service attacks where an attacker injects pathological RTP packets containing frames that inflate receiver-side decoding complexity or corrupt future frame decoding. Authentication and integrity protection of RTP packets (e.g., via SRTP) is RECOMMENDED.
The H.261 RTP payload header is a 32-bit field containing: SBIT (3 bits), EBIT (3 bits), I (1 bit), V (1 bit), GOBN (4 bits), MBAP (5 bits), QUANT (5 bits), HMVD (5 bits), VMVD (5 bits).