Module sps 

The color an H.264 stream declares: read from a sequence parameter set, and written into one for a device that converts without saying what it converted with. The color a stream declares, read from an H.264 sequence parameter set and written into one.

An encoder that converts RGB itself decides the matrix and the range, and the stream is the only place a decoder learns which it was: with no video_signal_type in the VUI a browser guesses from the frame size, so one session is colored one way at 1080p and another at 800x600. Devices differ in whether they say: a Raspberry Pi with firmware from August 2024 or later converts and declares it, and the same board on an older firmware converts to full range BT.601 and declares nothing at all.

So this reads first. A stream that declares its color is left alone, whatever it declares, because the device knows what it did and we do not. Only a stream that declares nothing is written into, and then only with a value the caller can justify.

The VUI sits at the end of the SPS, ahead of the trailing bits, and the fields after the insertion point are copied as opaque bits rather than re-encoded: a writer that re-emits what it does not understand is a writer that corrupts streams on devices it was never run against.

The same VUI bounds reordering. Without a bitstream_restriction a decoder has to assume the stream may reorder as deep as its level’s decoded picture buffer, and Chromium’s hardware H.264 decoder (VA-API, D3D11, VideoToolbox) holds that many pictures back before it outputs one, up to sixteen at a small size. A stream whose pictures leave in the order they are shown is written a bound of zero. That write reads through the timing and HRD parameters to reach the restriction, still copying them as they came, and the read has to land on the stop bit, so a field it stepped over wrongly refuses the write instead of corrupting the set.

x264’s and NVENC’s frame_num are widened here too (WideFrameNum), the one write that reaches past the set into every slice header.

Structs

ColorSignal

What a stream says about the color it carries.

NoReorder

A device’s H.264 stream held to a reorder bound of zero: each sequence parameter set it sends is rewritten once and matched by its bytes after that, since a device repeats the same set with every key frame.

WideFrameNum

An x264 or NVENC stream with frame_num widened by a byte, in its sequence parameter sets and every slice header.

Functions

bound_reorder

The same SPS bounding reordering at zero, or None where it already does: a restriction written where the VUI carries none (a VUI created where there is none), with every other restriction field at the value a decoder infers in its absence and max_dec_frame_buffering at max_num_ref_frames; a declared max_num_reorder_frames above zero rewritten to zero. Only a stream that cannot reorder takes it: in_order where the session proves its pictures leave in the order they are shown, else a stream at picture order count type 2, whose output order is its decoding order.

h264_frame_num_range

How many values frame_num takes before it wraps, from the first SPS of an Annex-B H.264 stream.

read_color

What the stream says about its color, or None when it says nothing a decoder can use.

sequence_parameter_sets

Where each H.264 sequence parameter set sits in an Annex B access unit, as (start, end) of the NAL unit itself, the start code excluded. A set repeats with every key frame when the encoder is asked for headers on each one, and a stream whose first set alone is written says one thing to the client that connected first and another to the one that joined later.

write_color

The same SPS with signal declared in its VUI, replacing whatever it declared before.