From 1b95d346bb7c2384c63a7ebd1d7039498c2a70ad Mon Sep 17 00:00:00 2001 From: Matthew Jackson <1085847+MattJackson@users.noreply.github.com> Date: Sat, 1 Aug 2026 13:49:47 -0700 Subject: [PATCH] Cite the H.264 spec directly, not a reference implementation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The escape-stripper comments named a third-party decoder as the authority for the cumulative-zero rule. This repo is public and does not cite other implementations; the rule is specified in ITU-T H.264 §7.3.1, which is the citation that belongs here anyway. No behaviour change — comments only. The scan-secrets gate caught it. --- src/mux/codec/h264.rs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/mux/codec/h264.rs b/src/mux/codec/h264.rs index ca65868..01f8f96 100644 --- a/src/mux/codec/h264.rs +++ b/src/mux/codec/h264.rs @@ -149,9 +149,9 @@ fn unescape_ebsp_prefix(ebsp: &[u8]) -> Vec { /// /// The zero run-length counter is cumulative across the whole scan and is /// reset only when an escape byte is actually dropped — matching the -/// reference decoding process (ITU-T H.264 §7.3.1 / the libavcodec RBSP -/// extractor), which discards a 0x03 following ANY run of two-or-more 0x00 -/// bytes, not just an exact `00 00 03` sliding window. A window-based scanner +/// reference decoding process in ITU-T H.264 §7.3.1, which discards a 0x03 +/// following ANY run of two-or-more 0x00 bytes, not just an exact +/// `00 00 03` sliding window. A window-based scanner /// that advances by 3 on a match and by 1 otherwise disagrees with this on a /// run of 3+ real zero bytes ahead of an 0x03: `00 00 00 03` decodes here as /// `00 00 00` (the run is escaped, matching every other H.264 decoder), where @@ -761,8 +761,8 @@ mod tests { /// the shared `unescape_ebsp`. On a run of 3+ real 0x00 bytes ahead of an /// 0x03 — non-conformant, but this is untrusted disc input, not a /// spec-clean encoder — the two disagreed: `unescape_ebsp`'s cumulative - /// zero counter (the same rule libavcodec's RBSP extractor and the H.264 - /// reference decoding process use) drops the 0x03 as an escape, while a + /// zero counter (the rule the H.264 reference decoding process in + /// §7.3.1 specifies) drops the 0x03 as an escape, while a /// fresh 3-byte window starting right after the non-matching first byte /// kept it as real payload. Pin the shared function's behaviour here so a /// second hand-rolled copy doesn't quietly reappear.