Skip to content

@remotion/renderer: Allow scale factors leading to uneven dimensions #5529

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 25, 2025

Conversation

Copilot
Copy link
Contributor

@Copilot Copilot AI commented Jul 25, 2025

When rendering videos with H264/H265 codecs, Remotion previously threw errors if scaling resulted in odd dimensions. This was particularly problematic when using scale factors that produced dimensions like 1400x907 (where 907 is odd).

This PR makes the validation more lenient by automatically rounding down odd dimensions to the nearest even number instead of throwing an error.

Changes

  • Modified validateEvenDimensionsWithCodec: Instead of throwing errors for odd dimensions, the function now rounds down to the nearest even number
  • Added comprehensive test suite: 13 new tests covering various scenarios including the original issue case
  • Preserved existing behavior: Other codecs (VP8, VP9, ProRes, etc.) and image sequences are unaffected
  • Added logging: Verbose logging when dimension rounding occurs for debugging

Example

Before this change:

// This would throw an error
validateEvenDimensionsWithCodec({
  width: 4000,
  height: 2592, 
  scale: 0.35,  // Results in 1400x907
  codec: 'h264'
});
// Error: height of 907px is an uneven number

After this change:

// This now works and returns { actualWidth: 1400, actualHeight: 906 }
validateEvenDimensionsWithCodec({
  width: 4000,
  height: 2592,
  scale: 0.35,  // Results in 1400x907 → 1400x906
  codec: 'h264'
});

Testing

  • ✅ All existing tests pass (257 tests)
  • ✅ New comprehensive test suite covers edge cases (13 tests)
  • ✅ Original issue case (4000x2592 with scale 0.35) now works correctly
  • ✅ Backward compatibility maintained for all other codecs
  • ✅ Image sequences continue to allow odd dimensions
  • ✅ Linting and formatting checks pass

Fixes #5528.


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Copy link

vercel bot commented Jul 25, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
bugs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 25, 2025 8:12am
remotion ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 25, 2025 8:12am

@Copilot Copilot AI changed the title [WIP] Be more lenient with scale factors Be more lenient with scale factors for H264/H265 codecs Jul 25, 2025
@Copilot Copilot AI requested a review from JonnyBurger July 25, 2025 08:08
Copilot finished work on behalf of JonnyBurger July 25, 2025 08:08
@JonnyBurger JonnyBurger marked this pull request as ready for review July 25, 2025 08:16
@JonnyBurger JonnyBurger changed the title Be more lenient with scale factors for H264/H265 codecs @remotion/renderer: Allow scale factors leading to uneven dimensions Jul 25, 2025
@JonnyBurger JonnyBurger merged commit 2766ca3 into main Jul 25, 2025
21 of 22 checks passed
@JonnyBurger JonnyBurger deleted the copilot/fix-5528 branch July 25, 2025 08:49
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.

Be more lenient with scale factors
2 participants