Repository navigation
Duration accounting: info ignores transitions and at, and per-scene rounding adds a frame #372
Description
Context
The studies size voice-over beats and soundtracks from the announced duration. Three places compute it, and they disagree.
1. rustmotion info sums scene durations
crates/rustmotion/src/cli/commands/info.rs:15-18 computes total_duration as the sum of scene.duration, and total frames as the sum of round(duration × fps). It ignores legacy transition overlap and the v2 at placement.
| Scenario | info |
validate |
frames rendered |
|---|---|---|---|
v1, two 1.0 s scenes, the second with a 0.6 s iris |
2.0 s (60 frames) | 1.4 s | 42 |
v2, at: 0 and at: 1.0, both 2.0 s |
4.0 s (120 frames) | 3.0 s | 90 |
{"version":"1.0","timing":"v2","video":{"width":320,"height":180,"fps":30,"background":"#000000"},
"composition":[{"type":"slide","scenes":[
{"at":0,"duration":2.0,"children":[]},
{"at":1.0,"duration":2.0,"children":[]}]}]}Expected: info reports the frame count the render will produce, from the same function the encoder uses.
2. A scene duration that falls on a half frame adds one frame per scene
{"version":"1.0","video":{"width":160,"height":90,"fps":30,"background":"#000000"},
"scenes":[{"duration":1.05,"children":[]},{"duration":1.05,"children":[]}]}validate announces 2.1 s, which is 63 frames at 30 fps. render writes 64: each scene rounds 31.5 up to 32, and the error accumulates across scenes. The same happens with timing: "v2". With 20 beats of 0.35 s at 30 fps, the video ends 10 frames after the soundtrack.
Expected: scene boundaries are computed as round(cumulative_time × fps), so the total is round(total × fps). Or validate warns when a duration isn't a whole number of frames, which the beat grid of #336 could also snap.
Also relevant: SKILL.md shows rustmotion info scenario.json, which the CLI rejects (filed in the SKILL.md issue).
Found in: 9styles, reel 4
Activity
fix(geometry,info,docs): line/arrow/connector bbox honours endpoints;…
fix(geometry,info,docs): line/arrow/connector bbox honours endpoints;…
LeadcodeDev commentedon Sep 27, 2026
Reopening for the half that #391 did not cover.
Done —
infono longer re-derives the duration. It callsbuild_frame_tasks(...).len(), the same functionrenderandvalidateuse, so the three agree: 42 frames for the v1 transition repro, 90 for the v2atrepro.Still open — per-scene rounding.
build_slide_view_tasksrounds each scene'sduration_framesindependently, so two 1.05 s scenes giveround(31.5) + round(31.5) = 64where rounding the cumulative timeline once gives 63. The error accumulates with scene count.infonow faithfully reports whateverrenderproduces, so the two no longer disagree with each other — they disagree together with the arithmetic. That is a smaller problem than the one that was there, but it is still the wrong number.The fix belongs in
encode/video/tasks.rs: round the cumulative timeline once rather than each scene. Worth checking againsttiming: v2, whereatalready places scenes on an absolute grid and the same rounding question arises forv2_scene_starts.LeadcodeDev commentedon Sep 27, 2026
Parked rather than half-done, with the reason.
The per-scene rounding is real and the arithmetic in the issue is right. But
encode/video/tasks.rshas 14 sites computing frames from a duration, and intiming: v1the timeline already subtracts transition durations — so "the cumulative time" is itself a function of the transition arithmetic, not a running sum ofscene.duration.A correct fix defines the view's timeline in seconds first and quantises once, then derives every scene's frame count as a difference of two rounded cumulative positions. That is a change to the timing model, not a one-line rounding swap, and getting it wrong shifts every existing render by a frame.
It also needs deciding for
v2, wherev2_scene_startsresolvesatonto an absolute grid and has the same question independently.Leaving this open with that shape written down rather than attempting it under conditions where I could not iterate on it safely.