Commit Graph
1 Commits
Author SHA1 Message Date
rsp2k 0912689301 Add an RTP/H.264 packetiser and a capture/replay pair
The packetiser is RFC 6184: single-NAL packets, FU-A fragmentation, and
STAP-A aggregation for parameter sets and SEI. Pure stdlib, because the
simulator ships in the package and cannot drag a media library behind it.
A VCL NAL is never aggregated and interleaved mode is absent; the docstring
says so rather than leaving it to be discovered.

Parameter sets repeat rather than appearing once at the head of the stream,
which is what the aircraft does and the only reason a viewer joining a flight
already in progress can recover. A start offset, random with a controllable
seed, exists to hand a decoder a stream that begins mid-GOP on purpose.

Capture and replay is the other half, and the two are different instruments.
The packetised path paces at a nominal frame rate, which proves a decoder and
a renderer work. A replay reproduces the recorded inter-packet gaps packet for
packet, which is what a latency or jitter measurement needs. The aircraft's
packet-type mix cannot be derived from first principles: the measurement we
have read only the outer header byte of each packet, so what its 740 FU-A
packets carried is still unknown, and only a real capture settles it.

The loop point is the one gap a file cannot describe. It is estimated from the
capture's mean frame period rather than its median packet gap, which was the
first thing tried and is wrong: with a dozen packets to a frame most gaps are
intra-frame, so the stream looped a frame early every time.
2026-10-02 12:07:26 -06:00