mirror of
https://github.com/freemkv/libfreemkv.git
synced 2026-10-07 18:13:10 +00:00
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.
28 lines
1.2 KiB
Markdown
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.
|
|
|