Close the MEDIUM mutation gaps across transport, labels and codecs

The remaining triage items after tonight's HIGH fixes: 1,290 lines, almost
all tests. Covers disc/mod.rs's DVD scan path (with real minimal VMG/VTS IFO
fixtures rather than mocks), drive/mod.rs, labels/class_reader.rs and
labels/mod.rs — the two biggest untriaged survivor clusters in the crate —
plus hevc.rs and ps.rs.

One production change, and it is an extraction rather than a behaviour
change: MacScsiTransport::open mapped the shim's negative failure sentinels
to typed errors inline, where nothing could reach it without a real IOKit
FFI call. It is now map_shim_open_error, so the mapping can be pinned. It
matters because collapsing -5 into the DeviceNotFound catch-all turns
"another process holds the drive" into "no such drive", and an operator
chasing the wrong problem is worse than a blunt error.

Gate green on the pinned toolchain including the secrets scanner.
This commit is contained in:
Matthew Jackson
2026-08-01 15:00:01 -07:00
parent f8ed0b99f4
commit ff18d4c3c8
7 changed files with 1290 additions and 33 deletions
+105
View File
@@ -2272,6 +2272,56 @@ mod tests {
);
}
/// The wrap-vs-backstep test above (`cra_after_33bit_pts_wrap_not_rewritten`)
/// keeps `high_pts` near the very top of the 33-bit range, which is close
/// enough to the `PTS_WRAP_PERIOD / 2` threshold that `high - unwrapped`
/// and a hand-flipped `high + unwrapped` land on the SAME side of the
/// threshold at every step in that sequence — it does not actually
/// distinguish the two. This test uses PTS magnitudes around 3e9 (order
/// 2^32, well below the wrap threshold but large enough that a real
/// stream reaches it in well under an hour), where the subtraction and
/// the addition diverge: ordinary forward progression keeps
/// `high - unwrapped` small (no bogus wrap), but `high + unwrapped`
/// already exceeds `PTS_WRAP_PERIOD / 2` on the very next frame, which
/// pollutes `pts_wrap_offset` by a full period. That pollution then
/// masks the GENUINE two-clip splice that follows: the splice's small
/// reset PTS gets `+= pts_wrap_offset` and lands ABOVE the (also
/// polluted) high-water mark instead of below it, so the backward-step
/// detector never fires and the splice CRA is wrongly left as CRA
/// instead of being rewritten to BLA_W_LP.
#[test]
fn cra_splice_detected_at_large_pts_magnitude_not_masked_by_wrap_logic() {
let mut parser = HevcParser::new();
// Clip 1: two ordinary forward-progressing frames at ~3e9 ticks
// (order 2^32, comfortably below PTS_WRAP_PERIOD/2 = 2^32 exactly,
// and far from the actual 2^33 wrap point).
let clip1_base = 3_000_000_000i64;
parser.parse(&make_pes(cra_au(&[0x01]), Some(clip1_base)));
let dip = parser.parse(&make_pes(cra_au(&[0x02]), Some(clip1_base + 3750)));
assert_eq!(
nal_type_of(&nals_of(&dip[0].data)[0]),
NAL_CRA_NUT,
"ordinary forward progression at large PTS magnitude must not itself \
be mistaken for anything"
);
// Clip 2 splice: PES PTS resets to a small new-clip base — a genuine,
// large (~3e9-tick) backward step that is NOT a 2^33 wrap (the
// backward delta here is far short of PTS_WRAP_PERIOD/2).
let splice = parser.parse(&make_pes(cra_au(&[0x03]), Some(500)));
assert_eq!(
nal_type_of(&nals_of(&splice[0].data)[0]),
NAL_BLA_W_LP,
"a genuine large backward PTS reset at this magnitude must still be \
detected as a clip splice and rewrite the CRA to BLA_W_LP"
);
assert_eq!(
splice[0].pts_ns,
pts_to_ns(500),
"the emitted PTS must be the raw splice-clip PTS, unaffected by the \
internal unwrap bookkeeping"
);
}
/// Test 3: non-CRA NALs are never rewritten even when a boundary IS marked.
/// IDR (19), RASL (8/9), VPS/SPS/PPS, and a trailing slice all pass through
/// unmodified; the IDR clears the pending boundary so no later CRA is wrongly
@@ -3345,6 +3395,61 @@ mod tests {
);
}
/// The hvcC array length is a 16-bit big-endian field written as two
/// separate `push`es: `(len >> 8) as u8` then `len as u8`. Every VPS/SPS/
/// PPS the rest of the suite feeds is well under 256 bytes, so the high
/// byte is always 0 and a `>>` -> `<<` mutation (which also always
/// truncates to 0 for those inputs, since `(len << 8) as u8` masks off
/// exactly the low 8 bits) is unobservable there. A real HEVC SPS with an
/// extended VUI/HRD block can exceed 256 bytes, so use a 300+ byte VPS,
/// SPS and PPS here and decode the 16-bit length fields back to confirm
/// they round-trip to the exact NAL length, not merely a byte that
/// happens to be 0.
#[test]
fn hvcc_array_length_round_trips_above_256_bytes() {
let mut parser = HevcParser::new();
let mut data = Vec::new();
// VPS: 2-byte NAL header + 300 filler bytes -> NAL length 302.
data.extend_from_slice(&[0x00, 0x00, 0x01]);
data.extend_from_slice(&hevc_nal_header(32));
data.extend_from_slice(&vec![0x11u8; 300]);
// SPS: same size.
data.extend_from_slice(&[0x00, 0x00, 0x01]);
data.extend_from_slice(&hevc_nal_header(33));
data.extend_from_slice(&vec![0x11u8; 300]);
// PPS: same size.
data.extend_from_slice(&[0x00, 0x00, 0x01]);
data.extend_from_slice(&hevc_nal_header(34));
data.extend_from_slice(&vec![0x11u8; 300]);
parser.parse(&make_pes(data, Some(0)));
let cp = parser.codec_private().expect("hvcC");
let expected_nal_len = 2 + 300; // NAL header + payload
let mut o = 23; // past the 23-byte fixed header
assert_eq!(cp[o], 0x20 | 32, "VPS array nal_type byte");
let vps_len = u16::from_be_bytes([cp[o + 3], cp[o + 4]]) as usize;
assert_eq!(
vps_len, expected_nal_len,
"VPS length must round-trip above 256 bytes"
);
o += 5 + vps_len;
assert_eq!(cp[o], 0x20 | 33, "SPS array nal_type byte");
let sps_len = u16::from_be_bytes([cp[o + 3], cp[o + 4]]) as usize;
assert_eq!(
sps_len, expected_nal_len,
"SPS length must round-trip above 256 bytes"
);
o += 5 + sps_len;
assert_eq!(cp[o], 0x20 | 34, "PPS array nal_type byte");
let pps_len = u16::from_be_bytes([cp[o + 3], cp[o + 4]]) as usize;
assert_eq!(
pps_len, expected_nal_len,
"PPS length must round-trip above 256 bytes"
);
}
/// HEVC counterpart of `h264_ps_reorder_reconstructs_distinct_display_pts`.
///
/// A DVD/HD-DVD program stream stamps a PTS only on each GOP anchor, so the
+32
View File
@@ -1816,4 +1816,36 @@ mod tests {
);
assert_eq!(parsed.data, es);
}
/// A length-bounded PES (`pes_packet_len != 0`) must be emitted the
/// moment its declared length is EXACTLY satisfied by the buffer
/// (`sc + 6 > len`, then `e = sc + 6 + pes_packet_len; e > len`), not
/// held back waiting for a byte that will never arrive. Feed nothing
/// after the packet and don't flush — if the boundary checks were
/// `>=` instead of `>`, an exact fit would incorrectly be treated as
/// "not enough data yet" and the packet would never be produced.
#[test]
fn length_bounded_pes_exact_fit_is_emitted_not_awaited() {
let mut demuxer = PsDemuxer::new();
let payload = [0x11u8, 0x22, 0x33, 0x44, 0x55];
let mut data = vec![0x00, 0x00, 0x01, 0xC0]; // audio stream id
let pes_packet_len = (3 + payload.len()) as u16; // flags+header_len byte + payload
data.extend_from_slice(&pes_packet_len.to_be_bytes());
data.extend_from_slice(&[0x80, 0x00, 0x00]); // no PTS/DTS, header_data_len = 0
data.extend_from_slice(&payload);
assert_eq!(data.len(), 6 + pes_packet_len as usize, "sanity: exact fit");
let packets = demuxer.feed(&data);
assert_eq!(
packets.len(),
1,
"an exact-fit length-bounded PES must be emitted immediately, \
not held awaiting a byte that will never come"
);
assert_eq!(packets[0].data, payload);
assert!(
demuxer.buffer.is_empty(),
"the exact-fit PES must be fully consumed, leaving nothing buffered"
);
}
}