Repository navigation
Description
Problem
hyperframes render --resolution has no 1440p (2560x1440) preset. In 0.8.191 the accepted values are landscape, portrait, landscape-4k, portrait-4k, square and square-4k, plus their aliases. The shared CANVAS_DIMENSIONS table already has 720p and 480p entries, but none for 1440p.
A 1920x1080 composition also cannot reach 2560x1440 through supersampling. The output-resolution check rejects any non-integer device scale factor ("requires a non-integer device scale factor ... Pick a preset that's an integer multiple, or rescale the composition"), and 2560 / 1920 = 1.333.
Use case: long-form YouTube videos. A 1440p upload is a common delivery target for creators, and it gives sharper text and graphics than 1080p, with a much smaller render cost and file size than 4K.
Our current workaround is to render at --resolution landscape-4k and then scale the result down to 2560x1440 with ffmpeg. This works, but it captures 2.25x more pixels than 1440p needs and adds a second encode.
Proposed solution
- Add
landscape-1440p(2560x1440),portrait-1440p(1440x2560) andsquare-1440p(1440x1440) to the canvas and output-resolution presets, with aliases such as1440p,2kandqhd. - Allow a non-integer device scale factor for output-resolution supersampling when the aspect ratio matches, so a 1920x1080 composition can render with
--resolution 1440p(scale 4/3). Chrome accepts fractionaldeviceScaleFactorvalues, andPage.captureScreenshottakes a fractionalclip.scale.
Example:
hyperframes render . --quality delivery --resolution 1440p --output renders/main_1440p.mp4If fractional scale factors are a concern (for example sub-pixel layout or text rounding), item 1 alone helps: authors could create 2560x1440 compositions, and a 1280x720 composition could supersample to 1440p at an integer 2x.
Alternatives considered
- Render at 4K and scale down with ffmpeg (current workaround): more capture time and a second encode.
- Author the composition at 2560x1440: this means changing every pixel value in an existing 1920x1080 project.
- Wrap the 1920x1080 stage in a CSS
transform: scale(1.3333)inside a 2560x1440 root: possible, but fragile, and it relies on the browser rasterizing the scaled layers at the final size.
Additional context
- Version: hyperframes 0.8.191 (macOS, hardware GPU, screenshot capture).
- The
--resolutionhelp text already states the rule: "Aspect ratio must match the composition; the scale must be an integer multiple."
Plain simple English
HyperFrames can render a video at 1080p or 4K, but not at 1440p. Many YouTube creators upload at 1440p because it looks sharper than 1080p and costs less to make than 4K. Today they must render the video at 4K and then make it smaller, which takes more time.
Created with LLM: Opus 5.5 | high | Harness: Claude Code
Activity
miguel-heygen commentedon Oct 25, 2026
Thanks for the clear write-up and the use case.
I checked current main:
--resolutionaccepts onlylandscape,portrait,squareand their-4kforms (packages/cli/src/commands/render.ts:341, validated inrender/plan.ts:323), and the help text states the integer-multiple rule, so 1920x1080 to 2560x1440 is rejected today as you describe.This is a feature request, and whether to add presets, and whether to allow fractional scale factors, is a maintainer decision, so I can't promise it. Your point that fractional scales raise sub-pixel layout and text-rounding questions is the part that needs deciding. Until then, your 4K render followed by an ffmpeg downscale is the supported route, and authoring the composition at 2560x1440 gives a native 1440p render.
krishs0404 commentedon Nov 8, 2026
Hi, I'd like to take a narrowed version of this for my Stanford CS146S open source contribution (Contribution 2; the first was #5872). Miguel noted that fractional scale factors are a maintainer decision, so this leaves them out entirely.
Proposed scope (item 1 only):
landscape-1440p(2560×1440),portrait-1440p(1440×2560) andsquare-1440p(1440×1440) toCANVAS_DIMENSIONS, next to the existing 720p and 480p tiers, with aliases1440p,2kandqhdplus the-portrait/-squareforms.1440pjoins the aspect-agnostic aliases, like720pand480p.VALID_CANVAS_RESOLUTIONSfeeds the CLI, producer and studio-server validators), so no logic changes. Update the--resolutionhelp text, the invalid-value error,docs/packages/cli.mdx, and the CLI skill reference, plus tests.What this enables: a 4K composition rendered to 1440p (the existing smaller-preset path), a 1280×720 composition supersampled to 1440p at an exact 2×, and authoring a project at 2560×1440 (
init --resolution 1440p).What this does not change: a 1920×1080 composition with
--resolution 1440pis still refused by the existingnon-integer-scalecheck (4/3). That is item 2, so the issue should stay open after this lands. I would not touch the scale-factor logic.Could a maintainer confirm this scope is OK before I open a PR? I'll start on it now so it is ready for review.
feat(cli): add 1440p resolution presets to --resolution (heygen-com#7418