Constant MOVIE_FORMAT_VERSION 

pub const MOVIE_FORMAT_VERSION: u16 = 6;

Current movie container-format version.

• v1 (v1.1.0 ..): the format documented above.
• v2 (v2.0.0 “Timebase” rc.1, ADR 0028): on-wire layout unchanged — this is purely an epoch marker. A .rnm with format_version < 2 was necessarily recorded on a pre-promote (pre-beta.4) build; per the determinism contract, its INPUT STREAM still replays fine (nothing about frame timing or button semantics changed), but the frame-for-frame bit-identical reproduction guarantee the movie format depends on is only proven within a single engine timebase — the one-clock promote changed how master-clock/PPU/CPU phase advances internally, so a v1-recorded movie’s exact framebuffer/audio replay on the v2.0.0-line engine is unverified, not guaranteed. Do NOT attempt timeline transcoding (re-deriving a v2-native recording from a v1 one) — that is out of scope; the honest move is surfacing the epoch, not silently promising equivalence. See recorded_before_v2_timebase for the check callers (TAS tooling, frontend movie-load UI) should use before relying on verify-replay.
• v3 (v2.9.8, ADR 0028’s epoch rule): an OPTIONS block follows the fixed header, carrying every emulation-affecting host option the movie was recorded with (HardwareOptions) and, for a recorded movie, the cartridge board the header described (BoardDescription). Playback applies the options before frame 0 and refuses a board or region that differs, so a replay runs the recorded machine whatever the player’s own settings are. A v1 or v2 movie does not say which machine it ran on, so it is refused (MIN_MOVIE_FORMAT_VERSION) rather than replayed on a guess; the maintainer accepted breaking them (2026-10-01).
• v4 (v2.9.9, core re-audit NC-10): the BoardDescription gains the PRG-ROM and CHR-ROM sizes and the raw header nametable bits. v3 could not tell two headers that split one body differently, or that differ only in the bits mappers 30 and 218 wire from, so a movie replayed silently on a different machine. v3 is refused, as v1 and v2 are, under the same “enduring over compatible” rule.
• v5 (v3.0.0, ADR 0045): the fixed header carries the EMULATION_EPOCH the movie was recorded under, straight after the format version so a tool can read it without parsing the rest. v2.9.9 and v3.0.0 emulate MMC3 games with the background at $1000 differently (T-MMC3-BG-A12), and a format-4 movie does not say which behaviour it assumes, so v4 is refused. A v5 movie from another epoch is refused with MovieError::EpochMismatch.
• v6 (v3.1.0): the crate::HardwareOptions record gains the CPU-multiplier overclock and the sprite-limit option (T-CPU-OVERCLOCK, T-SPRITE-LIMIT). A v5 options record is one field shorter and would decode as garbage, so v5 is refused. No replayable movie is lost: every v5 movie was recorded under epoch 1 or 2, which v3.1.0 (epoch 3) refuses anyway.