RTP Payload Format for ITU-T Rec. H.263 Video
obsoletes
- rfc-2429 — RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
updates
- rfc-3555 — MIME Type Registration of RTP Payload Formats
Extracted elements (25)
A copy of the picture header is inserted into the payload header when appropriate so that received packets can be decoded even when the original picture header packet is lost. This design choice directly addresses error resilience over lossy networks.
Encoders are generally discouraged from sending EOS and EOSBS codes because some decoders may misinterpret the loss of such a packet as loss of essential video data, causing them to suppress display of subsequent video — even though EOS/EOSBS do not affect picture decoding.
The use of slice structured mode is strongly recommended for lossy environments because slices can be dynamically sized to fit packet sizes and shaped rectangularly to minimize error propagation in motion-compensated prediction.
Old implementations will ignore the new optional SDP parameters added in this document. New implementations receiving H263-1998 or H263-2000 payload types with no parameters should behave as if the other side can accept H.263 at QCIF resolution at no more than approximately 14.985 frames per second.
RFC 2190 payload format should only be used to interact with legacy systems; this document mandates RFC 2429/4629 format for all new H.263 implementations.
An answerer SHALL NOT change the PROFILE parameter and MUST reject the payload type containing an unsupported profile. A decoder that supports a profile SHALL also support H.263 baseline profile (profile 0).
Each RTP packet SHALL carry only one H.263+ video packet, and the H.263+ payload header SHALL always be present for each H.263+ video packet.
For a sequence ending packet (EOS or EOSBS), PLEN shall be zero, and no Picture, GOB, or Slice start codes shall be included within the same packet.
For H.263+ video streams, the RTP timestamp is based on a 90 kHz clock. The time increment between each coded H.263+ picture should be an integer multiple of (cd*cf)/20, where cd is an integer from 1 to 127 and cf is either 1000 or 1001.
For multicast sessions, an answerer SHALL NOT change any parameters in an answer; if the indicated values are not supported, the payload type MUST be rejected.
For packets starting at the location of 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 complete (UFEP='001').
In non-rectangular slice structured mode, only complete slices SHOULD be included in a packet; slices should not be fragmented across packet boundaries except when the encoder cannot be influenced by packetization awareness.
In the SDP Offer/Answer model, codec options (F, I, J, K, N, P, T) MUST NOT appear unless the sender of the SDP parameters is able to decode those options — they designate receiver capabilities even in a 'sendonly' offer.
New implementations supporting H.263 SHALL use the payload format described in this document (RFC 4629), replacing RFC 2190 which moves to historic status.
The PROFILE and LEVEL optional SDP parameters SHALL NOT be used with any of the other optional parameters when using the H263-2000 media type. A system that specifies a PROFILE MUST also specify the supported LEVEL.
The RR (reserved) bits in the payload header SHALL be zero and MUST be ignored by receivers.
A Picture Segment Packet (P=1) starts at the location of a Picture, GOB, or Slice start code. A Follow-on Packet (P=0) contains H.263+ data not starting at a synchronization point and may or may not start at a macroblock boundary.
The RTP Marker bit (M bit) is set to 1 when the current packet carries the end of the current frame and 0 otherwise. The RTP timestamp encodes the sampling instance of the first video frame data and shall be the same on successive packets if a video frame occupies more than one packet.
Video Redundancy Coding (VRC) uses multiple independently inter-frame predicted threads; damage to one frame distorts only its own thread. Threads periodically converge to sync frames (INTRA or redundantly represented non-INTRA pictures) from which independent threads restart.
When a packet payload 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, improving compression ratio.
This document updates the IANA media type registrations for video/H263-1998 and video/H263-2000, previously registered in RFC 3555, adding new optional SDP parameters including CPCF, PAR, BPP, HRD for H263-1998 and PROFILE, LEVEL, INTERLACE for H263-2000.
A denial-of-service threat exists from injection of pathological datagrams that are complex to decode and overload the receiver. Authentication of at least the RTP packet is RECOMMENDED to mitigate this threat.
Confidentiality of media streams is achieved by encryption applied after end-to-end compression, with no conflict between the two operations. In multicast environments, source pruning via IGMP or multicast routing protocols may help receivers limit unwanted traffic.
The general H.263+ payload header is a 16-bit field containing: RR (5 bits, reserved, SHALL be zero), P (1 bit, picture/segment start indicator), V (1 bit, VRC header presence), PLEN (6 bits, extra picture header length in bytes), and PEBIT (3 bits, ignored bits in last byte of picture header).
The optional Video Redundancy Coding (VRC) header extension is an 8-bit field containing: TID (3 bits, thread ID, up to 7 threads), Trun (4 bits, monotonically increasing packet count modulo 16 per thread), and S (1 bit, sync frame indicator).