Files
libfreemkv/docs/videomap-mod.md
T
Matthew Jackson 6e14fc0c0c libfreemkv: 1.7.0 groundwork — sector-recycle soundness + CI hardening
Security
- Remove the unsafe Vec::set_len over recycled sector buffers — UB reachable
  from safe code (GHSA-j8ww-f5fg-9pmh, low). Uses Vec::resize; pooling unchanged.

CI / tooling
- clippy on stable with the MSRV single-sourced from Cargo.toml; cargo-deny
  dependency-audit gate with first-party git sources allowed (#15); audience-based
  comment-guard (#17).

Docs
- README (keydb ownership, BD-J parser count), drive-access transport/reset
  notes, mux timeline module-doc links.
2026-09-02 12:40:55 -07:00

28 lines
1.2 KiB
Markdown

# `src/mux/videomap.rs` — design notes
Each per-picture record's coding truth ([`PictureInfo`], off `frame.coding`)
and source provenance ([`SourcePos`], off `frame.source`) come from what the
highway already stamps on the frame — this module never re-parses the
elementary stream itself.
`VideoMap` is a STANDALONE PRIMITIVE, deliberately decoupled from any one
sink:
- The `fvi://` sink (`crate::mux::fvi_sink`) owns a `VideoMap`, appends each
video `PesFrame`, and serializes it.
- The same `VideoMap` can later be populated as a side-channel during ANY
mux (e.g. `iso → mkv` while ALSO emitting a `.fvi` sidecar), and reused for
seek-indexing, recovery loss-mapping, and diagnostics.
A different output format would be a DIFFERENT sink reusing this same model,
not a pluggable encoder inside `videomap.rs`.
## Regression: `fvi_colour_follows_hdr_and_measured_cicp`
An HDR10 BT.2020 title's real transfer is PQ (16); a measured CICP triplet
is authoritative and copied through verbatim. Before the fix, the FVI
`Colour` reported transfer=14 (the SDR default for BT.2020) while the MKV
container reported 16 — two sinks of one title disagreeing on the colour
code points.