Duration accounting: info ignores transitions and at, and per-scene rounding adds a frame

[LeadcodeDev]

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

[LeadcodeDev]

Reopening for the half that #391 did not cover.

Done — info no longer re-derives the duration. It calls build_frame_tasks(...).len(), the same function render and validate use, so the three agree: 42 frames for the v1 transition repro, 90 for the v2 at repro.

Still open — per-scene rounding. build_slide_view_tasks rounds each scene's duration_frames independently, so two 1.05 s scenes give round(31.5) + round(31.5) = 64 where rounding the cumulative timeline once gives 63. The error accumulates with scene count.

info now faithfully reports whatever render produces, 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 against timing: v2, where at already places scenes on an absolute grid and the same rounding question arises for v2_scene_starts.

[LeadcodeDev]

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.rs has 14 sites computing frames from a duration, and in timing: v1 the timeline already subtracts transition durations — so "the cumulative time" is itself a function of the transition arithmetic, not a running sum of scene.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, where v2_scene_starts resolves at onto 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.