Promote a public codec::annexb module (NAL/param-set helpers exist 3x, exported 0x) #49

New issue

Open

opened 2026-07-14 15:40:06 +00:00 by p13marc · 0 comments

p13marc commented

2026-07-14 15:40:06 +00:00

(Migrated from github.com)

Annex-B / NAL utilities exist three times in the tree and are exported zero times.

contains_idr — a private free fn (src/elements/codec/h264.rs:644, no pub).
Mp4FileSink::extract_sps_pps(&[u8]) -> (Option<Vec<u8>>, Option<Vec<u8>>) — src/elements/mux/mp4.rs:669, an associated fn on a file sink, behind the mp4-demux feature.
Mp4FileSink::annex_b_to_avcc(&[u8]) -> Vec<u8> — mp4.rs:735, same.

So anyone doing anything with an H.264 elementary stream outside of muxing it to MP4 — inspecting NAL types, splitting access units, converting Annex-B to AVCC for a container or a WebCodecs consumer — reimplements them.

Ask

Promote a public, feature-independent codec::annexb module: nal_units(), has_idr(), extract_param_sets(), prepend_param_sets(), annex_b_to_avcc().

Priority: low — this no longer blocks anything

Recording why, since it's a nice outcome: the zensight sensor carries its own annexb.rs (has_idr, extract_param_sets, prepend_param_sets) written to make every IDR a self-contained decoder entry point for late joiners. 0.2.0 made all of it redundant:

has_idr — superseded by the SYNC_POINT flag, which now reflects the encoded bitstream rather than the input (fixed in #22). It can just be trusted.
prepend_param_sets — unnecessary: OpenH264 writes SPS/PPS at the start of every IDR under every SpsPpsStrategy, proven by the mid-stream-join regression test at h264.rs:1686.

So this is hygiene, not a blocker. Filing it because the duplication is real and the next consumer will pay it.

Annex-B / NAL utilities exist three times in the tree and are exported zero times. - `contains_idr` — a **private** free fn (`src/elements/codec/h264.rs:644`, no `pub`). - `Mp4FileSink::extract_sps_pps(&[u8]) -> (Option<Vec<u8>>, Option<Vec<u8>>)` — `src/elements/mux/mp4.rs:669`, an associated fn on a **file sink**, behind the `mp4-demux` feature. - `Mp4FileSink::annex_b_to_avcc(&[u8]) -> Vec<u8>` — `mp4.rs:735`, same. So anyone doing anything with an H.264 elementary stream outside of muxing it to MP4 — inspecting NAL types, splitting access units, converting Annex-B to AVCC for a container or a WebCodecs consumer — reimplements them. ## Ask Promote a public, feature-independent `codec::annexb` module: `nal_units()`, `has_idr()`, `extract_param_sets()`, `prepend_param_sets()`, `annex_b_to_avcc()`. ## Priority: low — this no longer blocks anything Recording why, since it's a nice outcome: the zensight sensor carries its own `annexb.rs` (`has_idr`, `extract_param_sets`, `prepend_param_sets`) written to make every IDR a self-contained decoder entry point for late joiners. **0.2.0 made all of it redundant**: - `has_idr` — superseded by the `SYNC_POINT` flag, which now reflects the *encoded* bitstream rather than the input (fixed in #22). It can just be trusted. - `prepend_param_sets` — unnecessary: OpenH264 writes SPS/PPS at the start of **every** IDR under every `SpsPpsStrategy`, proven by the mid-stream-join regression test at `h264.rs:1686`. So this is hygiene, not a blocker. Filing it because the duplication is real and the next consumer will pay it.