Commit Graph
8 Commits
Author SHA1 Message Date
JonRC d0e7e09ecb Export: write a colr atom in ProRes MOVs (#2801)
ProRes renders had no colr atom, so the stream reported no primaries,
transfer or matrix. Write an nclc atom, as FilmCraft does for MOV, with
the codes of what the render path makes: the project's output space when
it has a working space, BT.709 otherwise.

sRGB output stays at transfer 1, which is still open on #340 and #464.
The frames don't change, so the pinned ProRes bytes move by exactly the
atom's 18 bytes.
2026-11-01 22:28:23 -03:00
bflatasticandClaude Opus 5.5 eedd1dfaae Merge main into #1736; clean merge, no conflicts
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 07:42:03 +07:00
bflatastic 0039081952 Merge main into #2567; keep both test modules, and convert four layer stacks main's new render tests assign as Vec<Layer> with .into() 2026-10-30 06:01:06 +07:00
tylerjenningsw 4daff9a74a Export tests: say why the H.264 pin moved with FilmCraft 09aaf9b (#1701) 2026-10-29 18:20:09 -04:00
tylerjenningsw 393a7aa565 Export tests: pin the H.264 bytes FilmCraft 09aaf9b writes (#1701)
The encoder's first-frame user_data_unregistered SEI now lists its settings
("... - options: rc=vbr bitrate=10000 ... scenecut=1", 211 bytes where
"filmcraft-h264enc 0.1.1 - clean-room H.264 encoder" took 50): +161 bytes.
The same build gives (104322, 11051847956767423392), the pin Linux CI took on
a base before the 19-byte nclx colr box, when that box is left out, so the
bytes match across platforms.
2026-10-29 17:57:08 -04:00
bflatasticandClaude Opus 5.5 3f00560f00 Export tests: re-pin the H.264 MP4 bytes for its BT.709 nclx colr box (+19 bytes)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-30 01:10:42 +07:00
Eduardo EspinosaandClaude Opus 5.5 e1d66a3c5c perf: share unchanged layers between undo states
Every undoable edit keeps the previous project for undo, so the comp it touches
is shared and Arc::make_mut deep-copies it: every layer and every keyframe. An
edit therefore costs time in proportion to the comp's size, and a script that
sets many keyframes in a big comp goes quadratic (a 1,600-layer build with
~100k sampled keys took ~45 minutes).

Comp::layers is now a Layers collection backed by Vec<Arc<Layer>>: copying the
stack copies pointers, and only the layer an edit changes is copied. The API
mirrors Vec<Layer>; serialized form is unchanged (a list of layers).
Comp::layer_mut and the iter_mut().filter/find call sites use find_mut /
iter_mut_where so they copy only the layers they actually change.

- prop.addKey in a 400-layer comp: 1.36 ms -> 0.16 ms per key (flat in comp size)
- the 1,600-layer script build: ~45 min -> 47 s, frames pixel-identical
- regression tests: an edit leaves the other layers shared with undo; layers
  round-trip as a plain list

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VkpGcKfWyCudfSsQNiWAaG
2026-10-28 22:20:23 -04:00
NetterSilverandClaude Opus 5.5 94399e62ff Pin movie export bytes
H.264 and ProRes exports of a 60-frame comp (several render batches, a
rotating stroked ring, a fading solid at a fractional position, a
Screen-mode shape, 8 bpc) must keep the exact bytes main wrote before the
two previous commits.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-27 17:40:41 +01:00