Expose size-targeted export (“fit under N MB”) in the UI - #55
Merged
Conversation
The two-pass encoder already knew how to land under a byte cap; nothing in the UI could turn it on. Add a megabyte limit in Settings and the editor export panel, pass it through as sizeTargetBytes, and show the achieved size (plus a downscale/over-budget note) after the file is written. Closes #48 Co-authored-by: Jeremy Smith <JeremySNR@users.noreply.github.com>
JeremySNR
marked this pull request as ready for review
September 6, 2026 11:32
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix prepared a fix for the issue found in the latest run.
- ✅ Fixed: Size cap can be exceeded
- Added a post-export cap-exceeded warning when finished bytes exceed sizeTargetBytes, stopped downscale/overBudget copy from implying the file fits, and corrected the planner and ExportResult docs about the 150 kbps floor.
You can send follow-ups to the cloud agent here.
Reviewed by Cursor Bugbot for commit 8343bcb. Configure here.
| <p className="mt-2 text-[11px] leading-relaxed text-amber-400"> | ||
| This edit is long for the size cap — the picture may look soft. A shorter trim would | ||
| hold up better. | ||
| </p> |
Contributor
There was a problem hiding this comment.
Size cap can be exceeded
Medium Severity
The overBudget note and ExportResult comment say the file still meets the cap. The encoder’s 150 kbps floor can push long edits over sizeTargetBytes, so a whole-video export at an 8 MB Discord preset can finish around 18 MB and get rejected.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 8343bcb. Configure here.
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
2 participants
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.
What does this change?
Closes #48. The two-pass size-targeted encoder was already in
uploadBudget.ts/render.tswith no UI. This adds a megabyte cap in Settings → Export and in the editor export panel, passes it asRenderJob.sizeTargetBytes, and shows the achieved file size after export (plus a note when the planner had to downscale, or when the clip is simply too long for the cap).Why?
Discord, email, WhatsApp and similar destinations reject large files. Rendering once to a budget beats rendering at a quality target and re-compressing.
How did you test it?
npm test(231 tests)npm run typechecknpm run lintscripts/test-uploadsize.ts— 18 MB cap → 17.87 MB; 4 MB cap → 3.93 MB (downscaled)scripts/smoke-test.sh— editor export panel and Settings → Export both show the new controlAnything to watch out for?
Preview is unchanged: this only affects export encoding. Quality and GPU encoder are ignored while a size cap is on (same as the existing renderer contract — the cap decides bitrate, on CPU x264). Export all uses the same Settings value as the editor.