Skip to content

Estimate the export's time left from its work and real progress - #192

Merged
bpacholek merged 3 commits into
mainfrom
183-time-left
Nov 1, 2026
Merged

bpacholek merged 3 commits into
mainfrom
183-time-left

Conversation

@bpacholek

Copy link
Copy Markdown
Contributor

Closes #183

"About N s left" kept going up during exports. There were two causes.

1. The progress was wrong. Transformer's progress is the average of every sequence's. Clipra's composition has one video sequence (the canvas the layer compositor draws on) and one sound sequence per layer with sound, and the sound is done long before the picture. On the demo project the export stood at 50% after 10 s, then crawled. ExportRenderer now takes progress from the frames the compositor has drawn (LayerCompositor.Listener), so the percent and "Frame N of M" are the video's.

2. The estimate was by time. It assumed every second of the timeline costs the same. ExportWork (core:model) weighs each tenth of a second of the timeline:

  • 1 for drawing and encoding the frame;
  • each visible video's source pixels against the output's, times its speed;
  • 0.1 for a photo, 0.05 for text, 0.3 for an adjustment.

TimeLeft gives the work still to do at the pace of the work done so far.

How the estimator was chosen. I logged a full export of the demo project on the emulator (a 535 s export: 4K HEVC street clips, photos, a 4K talk, screen recordings as overlays) and replayed it through several estimators against the true time left:

Estimator Median error Worst error
By time, as before (with the right progress) 27% 113%
Pace of the work so far (this PR) 9% 27%
Pace of the work over the last 10 s 32% unbounded
Pace over the last 30 s 24% 1024%

The pace over recent seconds fails because, on the emulator, a decoder starting at a clip change held the frames for about ten seconds, twice. The estimate then went to hours.

Checked on the emulator. With this build, the same export showed (estimate / true seconds left): 512/478, 413/449, 336/335, 282/223, 175/166, 129/108, 84/80, 28/27. From 30 s in, the median error was 8%. The worst was 68%, in the first half minute.

Tests: ExportWorkTest:

  • the work is in the video, not the photos, and an export at that pace is right from 10% on;
  • a 10 s stall at a clip change keeps it within 30% (28% at worst, just after it);
  • nothing is shown before 2%.

ExportProgress looks as before.

🤖 Generated with Claude Code

bpacholek and others added 3 commits November 1, 2026 18:06
The time left came from the average speed since the start, so a slow
stretch after a quick one made it rise until the end. It now weighs the
timeline by its work (each video's source size against the output; photos
and text are cheap) and takes the pace of the last ten seconds, so a
stretch slower than its work says shows within seconds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Transformer's progress is the average of every sequence's, and the
sound's are done long before the picture, so an export stood at half
after seconds and crawled from there; the time left jumped between two
and five minutes. The compositor's frames tell how far the video is.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Replayed on a logged export of the demo project, the pace over the last
ten seconds was off by hours whenever a decoder took ten seconds to
start at a clip change. The pace of all the work done so far was within
27% from 30 s in (9% at the median), against up to 113% for time alone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@bpacholek
bpacholek merged commit ba97128 into main Nov 1, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Export time left keeps going up when the rest of the project renders slower

1 participant