Files
libfreemkv/docs/fvi-sink.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

1.4 KiB

fvi:// sink notes

Rationale and design notes for src/mux/fvi_sink.rs that don't belong in the public rustdoc contract.

Relationship to VideoMap

The sink is a thin consumer of the reusable, pure-data VideoMap model (MapHeader / PictureRecord): it builds the header from the title, then writes one record per video PesFrame straight to disk. Nothing here re-parses the elementary stream, and the whole index is never buffered.

Serialization is inlined in the sink itself.

Extensibility

A different output format would be a DIFFERENT sink reusing the same VideoMap model (e.g. a future fvi2://), not a pluggable encoder — extensibility is by adding a sink, like every other sink in this crate.

write_fvi_record: coding-derived members (§7.1)

Coding-derived members (§7.1) are produced via the codec-agnostic PictureInfo accessors, never the raw bitstream: field_order is emitted only when measured (OMITTED on codec-type-only HEVC/H.264/VC-1), progressive only when signalled.

write_fvi_record: dts / future recovered member

dts is MAY per the format spec — the highway carries no DTS on a frame, so it is always omitted.

TODO(provenance→recovery join): a recovered MAY member (sweep/patch mapfile overlap with this AU's src) belongs here; unreachable at PesFrame.