RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
obsoleted by
- rfc-4629 — RTP Payload Format for ITU-T Rec. H.263 Video
Extracted elements (26)
An extra copy of the picture header (PLEN>0) is inserted into payload headers for GOB and slice packets to allow decoding even when the original Picture packet containing the picture header is lost. This provides error resilience at the cost of overhead.
EOS and EOSBS codes are discouraged because decoders may misinterpret the loss of such a packet as loss of essential video data and suppress subsequent video display. Since these codes do not affect picture decoding, sending them introduces unnecessary risk.
In the VRC scheme, thread 0 is the 'canonical' thread with highest priority; sync frame contents of higher-numbered threads are discarded when lower-numbered threads are received intact. Packets with lower thread numbers for a sync frame shall be delivered first under normal conditions.
Senders may find it advisable to always set UFEP='001' (full picture header) in high packet-loss environments to ensure decoders can always reassemble a complete picture header. Abbreviated headers (UFEP='000') are risky when header contents are not predictable.
The maximum assumed Picture Header size is 504 bits. H.263+ syntax does not explicitly prohibit larger sizes, but such use is not expected in practice, so this bound was chosen as sufficient for the payload header design.
The two leading zero bytes of H.263+ start codes are omitted from the payload and indicated by the P bit to improve compression ratio. A receiver reconstructs the full start code by prepending two zero bytes when P=1.
GOB start codes should be byte aligned for packetization purposes, but H.263+ does not require this. When GOB start codes are not aligned (e.g., when transmitting existing content or using non-compliant encoders), follow-on packets must be used.
Packet type can be distinguished by checking the P bit, first 6 bits of payload, and PLEN value. '100000' with P=1 and PLEN=0 indicates a typical Picture packet; '1xxxxx' with P=1 and PLEN=0 indicates GOB/Slice/EOS/EOSBS; P=0 indicates a Follow-on packet.
This format supersedes RFC 2190 for new implementations and can also be used with the 1996 version of H.263. RFC 2190 continues to be used by existing implementations and may be required for backward compatibility. Implementations using new H.263+ features shall use this format.
Both the RTP timestamp and the temporal reference (TR) in the H.263 picture header are required to carry the same relative timing information. The time increment between each coded H.263+ picture should be an integer multiple of (cd*cf)/20 using the 90 kHz clock.
For a packet beginning with an EOS or EOSBS code, PLEN shall be zero and no Picture, GOB, or Slice start codes shall be included within the same packet. Encoders are generally to be discouraged from sending EOS and EOSBS.
For H.263+ bitstreams coded with temporal, spatial, or SNR scalability, the temporal relations between layers shall be expressed using the RTP timestamp so they can be synchronized at receiving ends in multicast or unicast applications.
For packets starting at a Picture Start Code, PLEN shall be zero unless the picture header in the bitstream is incomplete (UFEP='000') AND the attached additional picture header is not incomplete (UFEP='001').
If ISD is used in conjunction with slice structure, the rectangular slice submode shall be enabled and the dimensions and quantity of slices present in a frame shall remain the same between each two intra-coded frames, as required by H.263+.
The RTP Marker bit shall be set to 1 when the current packet carries the end of the current frame, and 0 otherwise.
The RTP timestamp shall be the same on successive packets if a video frame spans more than one packet. In a multilayer scenario, all pictures corresponding to the same temporal reference should use the same timestamp. The RTP timestamp is based on a 90 kHz clock.
The slice structured mode is strongly recommended for any applications used in environments where significant packet loss occurs. In non-rectangular slice structured mode, only complete slices should be included in a packet.
When the payload of a packet begins with a Picture, GOB, Slice, EOS, or EOSBS start code, the first two all-zero bytes of the start code shall be removed and replaced by setting the P bit to 1 in the payload header.
A Follow-on Packet (P=0) contains H.263+ coded data that does not start at a synchronization point. It may or may not start at a macroblock boundary, and its data is not independently decodable. PLEN>0 is permitted to allow interior resynchronization.
A Picture Segment Packet (P=1) starts at the location of a Picture, GOB, or Slice start code in the H.263+ stream. The two leading zero bytes of the start code are omitted and their presence is indicated by P=1. An extra picture header may optionally be attached when PLEN>0.
The H.263+ payload header is a mandatory variable-length header present in every H.263+ RTP packet. It consists of a 16-bit base field, an optional 8-bit VRC field (when V=1), and an optional extra picture header of PLEN bytes.
Video Redundancy Coding (VRC) uses multiple independently inter-frame predicted 'threads' of pictures. All threads converge periodically to a sync frame; lower-numbered threads carry equal or higher quality representations and have higher delivery priority.
A potential DoS threat exists from injecting pathological datagrams that are complex to decode; however, H.263+ encoding does not exhibit significant non-uniformity in receiver-end computational load. Receivers may also be overloaded by receipt of too many packets in multicast environments.
Because data compression is applied end-to-end, encryption may be performed after compression with no conflict between the two operations. Confidentiality of media streams is achieved through encryption as discussed in the RTP specification.
The 16-bit base H.263+ payload header contains: RR (5 bits, reserved, shall be zero), P (1 bit, start code indicator), V (1 bit, VRC header present), PLEN (6 bits, extra picture header length in bytes), PEBIT (3 bits, padding bits in last picture header byte).
The optional 8-bit VRC header extension contains: TID (3 bits, thread ID, up to 7 threads), Trun (4 bits, monotonically increasing modulo-16 packet counter per thread), S (1 bit, indicates sync frame content).