RTP Payload Format for JPEG-compressed Video
obsoleted by
- rfc-2435 — RTP Payload Format for JPEG-compressed Video
Extracted elements (25)
Fragmentation is performed at the RTP level rather than delegating to IP fragmentation so that the sender can rate-control the packet stream and receivers can perform partial delivery in the presence of packet loss. IP fragmentation does not deliver partial datagrams to applications.
RTP/JPEG uses abbreviated JPEG format (tables omitted from the bitstream) because table-specification data rarely changes between frames in a video stream. A compact 64-bit RTP/JPEG header replaces the per-frame JPEG frame and scan headers, reducing per-packet overhead.
The Fragment Offset field is included (rather than relying solely on RTP sequence numbers and marker bit) to enable efficient single-copy reassembly with misordered packets, and to detect a lost final packet (marker bit) from the previous frame.
The Q field encodes quantization tables as a small integer rather than transmitting the full tables per-packet, because only a small set of quantization tables is typically used in practice. Dynamic tables (Q >= 100) are supported for rare cases requiring session-negotiated quality.
Width and Height are encoded in 8-pixel multiples (one byte each) because JPEG operates on 8x8 pixel blocks, keeping the header compact while covering all practical JPEG image sizes.
Receivers MAY treat types 4/5 as types 2/3, reassembling the entire frame before decoding, thereby ignoring the restart-interval packet alignment and partial decode capability.
RTP/JPEG restricts the predefined type codes to sequential DCT mode, single-scan, interleaved images to maximize interoperability with hardware codecs, which typically cannot decode non-interleaved scans even though baseline JPEG permits them.
For type codes 0/1, the Type specific field is unused and MUST be zero. For types 4/5, the Type specific field (TSPEC) carries the restart interval count (RCOUNT), with intermediate packets set to 254 and the final packet of a restart interval set to 255.
Frames SHOULD be fragmented into packets in a manner that avoids fragmentation at lower network layers (e.g., IP). When restart markers are used, frames SHOULD be fragmented so each packet starts with a restart interval.
The RTP marker bit MUST be set in the last packet of a frame, indicating frame completion to receivers.
The RTP timestamp for JPEG video MUST be in units of 90000 Hz. The same timestamp MUST appear in all packets belonging to a single frame.
The Type field MUST remain constant for the duration of a session; it encodes the abbreviated table-specification and JFIF-style parameters not present in the transmitted JPEG data.
For Q values 1–99, quantization tables are derived from JPEG standard Tables K.1 (luma) and K.2 (chroma) scaled by S = 5000/Q for Q <= 50, or S = 200 - 2*Q for Q 51–99, with each entry saturated to 8 bits.
For types 4/5, the TSPEC field in each packet carries RCOUNT (restart interval counter starting at 0) for the first packet of an interval, 254 for interior packets, and 255 for the final packet. This enables a receiver to identify and independently decode complete restart intervals.
For types 4/5, the X and Y tile offset of the first MCU in a restart interval is: tile_offset = RCOUNT * restart_interval * 2; x_offset = tile_offset % frame_width_in_tiles; y_offset = tile_offset / frame_width_in_tiles.
Restart markers (RST0–RST7) are the only JPEG markers permitted within the entropy-coded segment. If restart markers are present, a 6-byte DRI segment precedes the scan. The type code determines whether a restart interval is defined and whether intervals align with RTP packets.
Six RTP/JPEG type codes (0–5) are defined. Even types (0/2/4) use 4:2:2 chroma subsampling; odd types (1/3/5) use 4:2:0. Pairs (0/1) have no restart markers; (2/3) have restart markers with a DRI segment but no packet alignment; (4/5) align restart intervals with RTP packets for partial decode.
The data payload following the RTP/JPEG header is a single entropy-coded scan with the scan header omitted (inferred from the RTP/JPEG header). The scan is terminated implicitly or with an EOI marker, and may be padded with undefined bytes.
The document explicitly states that security issues are not discussed in this memo. No confidentiality, integrity, or authentication mechanisms are defined for the RTP/JPEG payload format.
Frame reassembly: a complete frame is identified by a sequence of packets starting with Fragment Offset = 0 and ending with the RTP marker bit set. Receivers may detect missing packets via RTP sequence numbers or by comparing Fragment Offset + packet length against the next packet's offset.
Fragment Offset is a 24-bit field encoding the byte offset of the current packet's data within the full JPEG scan, enabling reassembly of fragmented frames.
The Q field is 8 bits and defines the quantization tables for the frame. For Q 1–99 the IJG scaling formula is applied to JPEG standard Tables K.1 and K.2; Q >= 100 signals a dynamically defined table; Q = 0 is reserved.
The RTP/JPEG header is 64 bits placed between the RTP header and JPEG scan data, present in every packet. Fields: Type specific (8 bits), Fragment Offset (24 bits), Type (8 bits), Q (8 bits), Width (8 bits), Height (8 bits).
The Type field is 8 bits. Types 0–127 are reserved as fixed, well-known mappings defined by this document and future revisions; types 128–255 may be dynamically defined by a session setup protocol.
Width and Height are each 8-bit fields encoding image dimensions in 8-pixel multiples (e.g., Width=40 means 320 pixels wide; Height=30 means 240 pixels tall).