rfc-2029

RTP Payload Format of Sun's CellB Video Encoding

M. Speer, D. Hoffman
date1996-10 streamIETF arearai wgavt statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc2029 doi10.17487/RFC2029
This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. [STANDARDS-TRACK]

Extracted elements (15)

design-rationale §2.2

Frame width and height are carried in every CellB packet header even though they can only change between frames. This simplifies packet encoding and makes each packet self-describing, supporting robust handling of packet loss.

rtp, realtime

design-rationale §2.2

The CellB packetization adds a per-packet header identifying the location of the first cell within the current frame. This is explicitly designed to make the packet stream robust to packet loss by allowing receivers to reconstruct partial frames.

rtp, realtime

design-rationale §A.3

The Y/Y and U/V quantization table update codes are defined in the CellB bytestream spec but the sample encoder/decoder described in this memo does not implement them; future CellB codecs may implement this feature.

realtime

interoperability-note §1

CellA and CellB are distinct versions of Cell compression technology. CellA is designed for stored video intended for local display and is not addressed by this RTP payload format specification, which covers CellB only.

realtime

interoperability-note §B

Sun Microsystems states that CellB is publicly available for use without any license, removing IP barriers to interoperable implementations.

realtime

normative-requirement §2.3 MUST

All multi-byte CellB codes MUST be completely contained within a single RTP packet; they may not span packet boundaries.

rtp, realtime

normative-requirement §2.3 SHOULD

Implementors SHOULD avoid packet sizes that result in IP fragmentation by the network; packet size is otherwise unconstrained up to a full frame.

rtp, realtime

normative-requirement §2.1 MUST

The RTP marker bit MUST be set to denote the end of a video frame.

rtp, realtime

normative-requirement §2.1 MUST

The RTP timestamp for CellB packets MUST be in units of 90KHz, and the same timestamp value MUST be used for all packet payloads belonging to the same frame.

rtp, realtime

protocol-element §2.2

Cell X Location and Cell Y Location in the payload header are expressed in cell coordinates (not pixel coordinates). Because cells represent 4x4 pixel blocks, the range of each coordinate is 0 through 1/4 of the corresponding pixel dimension.

rtp, realtime

wire-format §A.1

A CellB cell code is 4 bytes: a 15-bit 4x4 bitmask (MSB always 0) followed by an 8-bit U/V chrominance index and an 8-bit Y/Y luminance index. Each bit in the bitmask selects one of two luminance values for the corresponding pixel.

realtime

wire-format §2.2

The CellB RTP payload header is 8 bytes: four 16-bit unsigned integer fields in network byte order — Cell X Location, Cell Y Location, Width of Image, Height of Image — prepended to the compressed CellB data.

rtp, realtime

wire-format §A.2

The CellB skip code is a 1-byte code with bit pattern '10 0 SSSSS', instructing the decoder to skip S+1 cells; the maximum skip count is 32 cells.

realtime

wire-format §A.4

The CellB U/V table code is the single byte 0xFF (11111111). It signals that the following 512 bytes are a new chrominance quantization table of 256 (U_N, V_N) pairs in sequential order.

realtime

wire-format §A.3

The CellB Y/Y table code is the single byte 0xFE (11111110). It signals that the following 512 bytes are a new luminance quantization table of 256 pairs of Y values (Y1_N, Y2_N) in sequential order.

realtime