mirror of
https://github.com/freemkv/libfreemkv.git
synced 2026-10-07 18:13:10 +00:00
Matthew Jackson
6e14fc0c0c
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.
1.2 KiB
1.2 KiB
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 aVideoMap, appends each videoPesFrame, and serializes it. - The same
VideoMapcan later be populated as a side-channel during ANY mux (e.g.iso → mkvwhile ALSO emitting a.fvisidecar), 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.