Repository navigation
Estimate the export's time left from its work and real progress - #192
Merged
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
ExportRenderernow 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:TimeLeftgives 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:
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:ExportProgresslooks as before.🤖 Generated with Claude Code