RTP Payload Format for H.261 Video Streams
obsoleted by
- rfc-4587 — RTP Payload Format for H.261 Video Streams
Extracted elements (20)
NACK control packets are sent immediately upon loss detection without random delays, unlike reliable multicast protocols, because interactive video tolerates some unreliability but is highly sensitive to delay. Multicasting NACKs would generate useless traffic since only the encoder acts on them.
The 512-bit ISDN framing (H.221) and audio/video multiplexing are deliberately omitted from the Internet packetization. UDP/RTP provides more efficient multiplexing, and error protection can be achieved by other means, so the raw Huffman-encoded output is transported directly.
The 90 kHz RTP clock was chosen because it is a multiple of the natural H.261 frame rate (30000/1001 ≈ 29.97 Hz), allowing the timestamp to be incremented by a fixed integer per frame with no accumulated rounding error. The initial timestamp value is random to resist known-plaintext attacks on encryption.
The macroblock (MB) was chosen as the unit of packetization fragmentation rather than GOB or frame level because a single GOB or frame can exceed the maximum packet size. MB-level fragmentation enables per-packet resynchronization after loss while minimizing the amount of H.261 bit stream that must be parsed (only Huffman encoding, no full decompression).
H.261-specific control packets (FIR and NACK) may only be used when no RTP mixers or translators intervene in the path from encoder to decoder, because the unicast reverse-channel mechanism relies on the encoder's network-level source address being visible to the decoder.
Support of H.261-specific control packets (FIR/NACK) by the H.261 sender is optional. Early experiments showed that their use can have very negative effects when the number of sites is large; they should be used with caution and, in practice (e.g., IVS), only in point-to-point or small (<10 participant) sessions.
Packets must start and end on a macroblock (MB) boundary; a MB cannot be split across multiple packets. Multiple MBs may be carried in a single packet when they fit within the maximum packet size, and this practice is recommended to reduce packet send rate and overhead.
The bit stream cannot be fragmented between a GOB header and MB 1 of that GOB. If a packet begins with a GOB header, GOBN, MBAP, and QUANT are all set to 0.
The I (INTRA-frame) and V (motion vector) flag bits in the H.261 header are hint flags whose sense may not change during the course of the RTP session. A conformant implementation may always set V=1 and I=0.
The RTP marker bit MUST be set to 1 in the last packet of a video frame and MUST be zero in all other packets. This allows a receiver to detect the end of a frame without waiting for the start code of the next frame.
The RTP timestamp for H.261 video streams is based on a 90 kHz clock, which is a multiple of the natural H.261 frame rate (~29.97 Hz). All packets carrying the same video image use the same timestamp; packets from different images must have different timestamps.
Each H.261 RTP packet carries per-packet state information — GOB number (GOBN), macroblock address predictor (MBAP), quantizer value (QUANT), and reference motion vector data (HMVD/VMVD) — so that the MBs in each packet can be decoded independently without requiring the preceding GOB or frame header.
H.261-specific RTCP control packets (FIR, PT=192; NACK, PT=193) are sent via unicast directly from the decoder to the coder's RTP source port, not to the session's normal RTCP destination address. This 'reverse' control path avoids multicast NACK implosion.
HMVD and VMVD are 5-bit 2's complement fields encoding the reference horizontal and vertical motion vector data. The value '10000' (−16) is forbidden; valid motion vector fields range from +/−15. Set to 0 when V=0, at a GOB header, or when the last MB's MTYPE was not motion-compensated.
MBAP encodes the last macroblock address (MBA) encoded in the previous packet, ranging 1–32 biased by -1 to fit 5 bits. For example, MBAP=0 means the MBA predictor value is 1. Set to 0 if the packet begins with a GOB header.
Three packet-loss mitigation strategies are described: (1) use only INTRA-frame coding with MB conditional replenishment; (2) adjust INTRA refresh rate based on observed loss (H.261 mandates INTRA refresh at least every 132 transmissions per MB); (3) send FIR/NACK after loss detection to trigger full or partial INTRA refresh.
Security issues are not discussed in this memo. The only security-relevant note is that the initial RTP timestamp value is randomized (unpredictable) to make known-plaintext attacks on encryption more difficult, as specified in the base RTP protocol.
The 32-bit H.261 payload header contains: SBIT (3 bits) — unused bits at start of first octet; EBIT (3 bits) — unused bits at end of last octet; I (1 bit) — INTRA-frame only flag; V (1 bit) — motion vector flag; GOBN (4 bits) — GOB number; MBAP (5 bits) — macroblock address predictor; QUANT (5 bits) — quantizer value; HMVD (5 bits) — horizontal motion vector data; VMVD (5 bits) — vertical motion vector data.
The Full INTRA-frame Request (FIR) RTCP control packet is 8 bytes: V=2 (2 bits), P (1 bit), MBZ (5 bits), PT=RTCP_FIR=192 (8 bits), length (16 bits), SSRC (32 bits). It requests the encoder to force the next frame to be fully INTRA-coded.
The Negative ACKnowledgement (NACK) RTCP packet is 12 bytes: V=2, P, MBZ, PT=RTCP_NACK=193 (8 bits), length (16 bits), SSRC (32 bits), FSN — First Sequence Number lost (16 bits), BLP — bitmask of following lost packets (16 bits, bit set=lost).