forked from unom/punktfunk
enricobuehler
7a31f1089e
The second half of pf-vaadec: picture parameters, inverse-quantization matrices and one slice-parameter record per slice, over the same transaction discipline pf-dxvadec uses — validate, resolve references against the PRE-removal slot map, then apply removals and assign the setup slot last. A half-applied DPB update is the shape of a corrupt reference, so nothing mutates until every fallible step has passed. Three things VAAPI wants that neither other backend does, all of which the existing plan already carries: A bit offset. slice_data_bit_offset is where slice_data() begins, counted from and including the NAL header byte with emulation-prevention bytes removed — DXVA takes a byte offset, Vulkan takes nothing. It costs no new parsing: the vendored parser records exactly that as SliceHeader::header_bit_size, because cros-codecs' own production backend is VAAPI. The slice data without its start code, since that offset is relative to the NAL header byte. SlicePlan::data is start-code-inclusive and the prefix is three OR four bytes — the host emits four on every access unit — so it is measured per slice rather than assumed. Assuming it is the defect that made HEVC unplayable on every driver. The per-slice reference lists. DXVA's short-format slice control expresses no lists at all; VAAPI wants RefPicList0/1 in 8.2.4.2 order, which is what the plan's derived lists already are. And the distinction that cost M5 a defect, now written down in a third place: reference_frames is documented "in DPB", the same statement DXVA's RefFrameList makes and the opposite of Vulkan's pReferenceSlots. It is filled from the marked-DPB snapshot; the per-slice lists come from the slice's own. Getting that backwards loses a long-term reference no slice happens to name. Weight tables follow 7.3.3's presence rule rather than being copied unconditionally: flagged only where the PPS actually enables explicit weighting for that slice type and list. Flagging them otherwise hands the driver defaults as though the stream had coded them. The vendored PredWeightTable stores luma_offset_l0 as [i8; 32] but luma_offset_l1 as [i16; 32] — an upstream inconsistency, not a semantic one — so the narrow side widens. Envelope refusals are errors, never silent narrowings: slice groups, separate colour planes, a capacity mismatch, a reference holding no slot, lists past their array bounds, a slice range outside its access unit. Tests: 15. The one that matters walks all 250 access units of the vendored conformance vector through H264Planner and this conversion, asserting per slice that the range lies inside its access unit, that the declared size matches it, that the start code really was trimmed, and that the header neither is zero bits nor outruns the slice — plus that reference_frames carries exactly as many valid entries as the marked DPB and every entry past it is invalidated. It also asserts it saw a multi-slice picture and a non-empty reference set, so a splitter bug cannot make it vacuous. Gates: rustfmt, clippy, cargo doc with no unresolved links, and the container's clippy -D warnings, tests and workspace check.