Skip to content

Add a 1440p (2560x1440) preset to render --resolution #6309

Closed

Description

@richkuo

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

  1. Add landscape-1440p (2560x1440), portrait-1440p (1440x2560) and square-1440p (1440x1440) to the canvas and output-resolution presets, with aliases such as 1440p, 2k and qhd.
  2. 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 fractional deviceScaleFactor values, and Page.captureScreenshot takes a fractional clip.scale.

Example:

hyperframes render . --quality delivery --resolution 1440p --output renders/main_1440p.mp4

If 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 --resolution help 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

  1. miguel-heygen commented on Oct 25, 2026

    @miguel-heygen
    Collaborator

    Thanks for the clear write-up and the use case.

    I checked current main: --resolution accepts only landscape, portrait, square and their -4k forms (packages/cli/src/commands/render.ts:341, validated in render/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.

  2. added
    enhancementNew feature or request
    triage/needs-designEvidence is adequate; desired behavior or scope needs a maintainer decision.
    on Oct 28, 2026
  3. krishs0404 commented on Nov 8, 2026

    @krishs0404
    Contributor

    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):

    • Add landscape-1440p (2560×1440), portrait-1440p (1440×2560) and square-1440p (1440×1440) to CANVAS_DIMENSIONS, next to the existing 720p and 480p tiers, with aliases 1440p, 2k and qhd plus the -portrait / -square forms. 1440p joins the aspect-agnostic aliases, like 720p and 480p.
    • Everything else already derives from that table (VALID_CANVAS_RESOLUTIONS feeds the CLI, producer and studio-server validators), so no logic changes. Update the --resolution help 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 1440p is still refused by the existing non-integer-scale check (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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesttriage/needs-designEvidence is adequate; desired behavior or scope needs a maintainer decision.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions