* Image sequences: a gap in the numbering holds the previous frame, as After Effects
Split out of #1876 (originally 7850cbf4), because it reverses the colour bars
documented in #297 and needs its own discussion.
After Effects 2026 shows the last existing file across a gap in a sequence's
numbering (files 1, 2, 4, 5 show frame 2 at frame 3; read back from After
Effects). EffectCraft drew colour bars there. The media pool now holds the
previous file (Footage::sequence_file_held); colour bars remain only where no
file precedes the frame. Missing-frame reports on import are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Image sequences: hold the first file of the preceding number across a gap; fix the import warning
A gap now holds the file sequence_file picks for the preceding number, so
files sharing a number do not switch at the gap. The Report Missing Frames
warning says the previous frame is held instead of "shown as placeholders".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Image sequences: Interpret Footage says a gap holds the previous frame
The Interpret Footage note for a numbered sequence with gaps still said the
missing frames are shown as colour bars; the media pool holds the previous
frame there now. The note, its comment and two test doc comments say so,
and a forms test checks the note's wording.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
Review follow-ups:
- Files in use are never dropped from the channel cache: planes an effect
holds, the files of the last 4 pictures made of their planes until their
effects ask for the channels, and decodes in progress, which now count
the planes they will allocate (from the header) against the budget. With
4 frames at once over a budget of one file, each file decodes once (test).
- A decode that panics removes its entry instead of leaving it decoding.
- One decode allocates at most 8 GiB of planes (512 MiB on 32-bit and
wasm); a header asking for more is refused with the reason.
- A shared picture whose file has no cached channels (a failed read, a
broken part it doesn't use) is decoded from its own channels.
- Comment why waiting on a decode may block a rayon worker; drop the
subsampling check and test (the exr crate refuses subsampled files).
- Docs: the cache is a soft bound; a single-part file still decompresses
every channel; the first frame and the image crate's route decode twice.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Adds tiled (ZIP16, RLE), tiled mip-mapped (ZIP16, PIZ), decreasing line
order, uncompressed, a uint R/G/B picture and a multi-part file whose first
R/G/B part is depth-named (the planes can't stand in for the image crate's
picture there). The new hashes were taken with main's crates/media/src at
a646bdcc (extracted with git archive) and the same test, before the decode
rework.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Synthetic single-layer, multi-layer, multi-part and windowed files in
half, float and uint, with RLE, ZIP, PIZ and DWAA, decoded through the
media pool picture first and channels first. The hashes are taken on
main before the decode is reworked.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
FilmCraft's EDL reader keeps source timecodes as media time and leaves the
rebase to the caller after probing. The probe now keeps the file's start
timecode (Footage::file_timecode), and an EDL import rebases each found
file's clips with filmcraft_interchange::rebase_source_timecode before the
layers are made, as FilmCraft's own import does.
VmHWM is per process; the other tests in the binary ran on parallel threads
and their allocations failed the 64 MiB bound intermittently.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ffmpeg 4.2 writes 2 in the sample entry of an AAC PCE layout and FilmCraft
decodes as many channels as that names, so the 6.1 check now reads a copy
naming all seven instead of skipping. Configuration 12 moves to the
synthetic layout tests.
Tones encoded with FilmCraft's AAC encoder, with the configuration rewritten
to 11, 12 or ffmpeg's 6.1 PCE where the coded elements fit it, so nothing
depends on ffmpeg or skips. Expected gains come from each channel's speaker.
The gains of an AAC source now come from the configuration FilmCraft decodes
it with, read from MP4/MOV (esds), Matroska (CodecPrivate) and LATM in MPEG
TS/PS (its first StreamMuxConfig). Channel configurations 3 to 6, 11 and 12
arrive reordered to WAVE order, 4 as L R C Cs, 7 in element order. A program
config element goes by its element positions, except the six structures in
which ffmpeg's encoder fills its own channel order across them (an LFE in a
side SCE, a back centre in a side pair), recognised by its "Lavc" comment.
ADTS can only signal configurations 1 to 7 that FilmCraft decodes, which the
channel count tells apart. A decode of fewer channels than the layout keeps
its first ones (7 of configuration 7's 8 in MPEG-TS LATM).
FilmCraft reorders AAC configurations 3 to 6, 11 and 12 to WAVE/SMPTE order
and leaves configuration 7 and program config elements as coded, so the
channel count alone can't say which order arrives: ffmpeg writes 7.1 as
configuration 7 (C L R first) and 6.1 as a PCE it fills in its own order
(L R C LFE Cs Ls Rs), while FilmCraft's encoder writes a centre-first PCE.
The order is now read from an MP4/MOV's AudioSpecificConfig when the source
opens; other containers keep a channel-count guess.
The ffmpeg oracle test gains configuration 12 (ffmpeg's 7.1 relabelled) and
skips PCE files ffmpeg 4.2 marks as stereo, which FilmCraft reads as two
channels.
Conflicts:
- viewer.rs: the undecodable-footage notice moved into phase_scene on main; it now
collects its layers in footage_problems, which keeps the proxy and collapsed-precomp
rules of #1701.
- project.rs: main's row layout, with the problem marker going by item_problem.
- movie_bytes.rs: the H.264 pin is FilmCraft 09aaf9b's bytes plus main's 19-byte
BT.709 colr box (104_322 + 19 = 104_341).
render/footage.rs imports ItemKind now that main names its imports.
CodeRabbit's leftover nitpick: h264_mp4 hard-coded -preset medium -crf 18 for
whatever encoder the build ships, but libopenh264 (and the hardware backends)
reject both — so a build whose picked encoder is not libx264 failed the fixture
and silently skipped every check gated on it. libx264 keeps its constant-quality
pair; everything else gets -b:v. Pinned by a small test over the option sets.
- Exported HEVC/AV1 nclx says BT.709 and limited range where the pipeline
means it, matching what the players we tested assume; the round-trip
tests pin the box values.
- The ffmpeg oracle helpers no longer read the flags column of
`ffmpeg -decoders` for "is a decoder" — every row of that listing is a
decoder, and the trailing D there is "supports direct rendering method
1", which a build's hevc decoder may legitimately lack. Decoders are
matched by the codec-name column alone.
- Fixtures a given ffmpeg build cannot actually encode (a listed encoder
that fails at run time: hardware backends without their device, the
noopenh264 stub) skip with a note instead of failing the run.
* Dev profile: line tables only for workspace crates, no debug info for dependencies
* xtask ci: dev-profile gate, nextest, tests without examples, wasm --keep-going
* One integration-test binary per crate
* xtask ci: run effectcraft-gpu's shared-device tests in one cargo test process
* xtask ci: run every stage and report all failures
* xtask ci: name the stage type (clippy type_complexity)
* xtask ci: run every test pass and report all failures
* cargo fmt
JonRC
Brandon ThomasandClaude Opus 5.5
tylerjenningsw
tylerjenningsw
Kaedo17
aiongg
aiongg