You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A full-screen recording of a 5K display (5120 x 2880 pixels, a 2560 x 1440 desktop at backing scale 2) produces an export canvas larger than the encoder can handle, and the export never completes. The cause is that the export canvas follows the source size with no upper bound.
Environment
Recordly 1.4.0 (signed arm64 release), reproduced against main at b3ea7754
macOS 26 (Darwin 25.6.0), MacBook Pro M4 Max
Display: Dell U4320Q, 5120 x 2880 panel, "looks like 2560 x 1440", backing scale 2
Source: 179 s full-screen capture, 5120 x 2880, H.264, variable frame rate around 55 fps
Steps to reproduce
Record the full screen of a 5K display.
Open the recording in the editor, set the aspect ratio to 9:16.
Export MP4 at quality Original, 24 fps.
What happens
The export runs for a long time and never finishes. There is no error, and no log is written.
The export settings menu shows the tier sizes as: Low 1728 x 3072, Medium 2160 x 3840, High 2592 x 4608, Original 2880 x 5120.
Why
calculateMp4SourceDimensions in src/components/video-editor/exportDimensions.ts builds the export canvas from the source dimensions. For a portrait aspect ratio it takes the source's short side (2880) as the width and derives the height from the ratio, giving a 2880 x 5120 canvas. That is 14.7 megapixels: about 58 MB of RGBA read back per frame, 4,300 frames at 24 fps, and a frame height beyond what H.264 hardware encoders accept.
The encoder support probe (probeSupportedMp4Dimensions) did not cap the size, so nothing warned the user.
Only the Original tier was tried before working around it. A 2560 x 1440 proxy recording of the same take, with a copy of the project pointing at it, exported normally at Medium (1080 x 1920).
Related reports
Export Never Works/Finishes #653 (Export Never Works/Finishes) covers the same class of display. The diagnosis in that thread is a different failure: on 1.3.4-beta.1 (Electron 39) the WebCodecs decoder accepted H.264 Level 6.0 chunks and emitted nothing, so exports sat at "Preparing" on every setting. My source is that same codec (avc1.64003c, Level 6.0), but on 1.4.0 and current main (Electron 43) it decodes: with the canvas capped, the export ran to completion from the original Level 6.0 file. So on current main the decoder deadlock did not reproduce for me, and the canvas size is the remaining blocker for 5K sources. The watchdog suggested in that thread would still be worth having; this report does not cover it.
Cap the export canvas at the pixel area of 4K UHD (3840 x 2160, about 8.3 megapixels), scaling an oversize canvas by the square root of the ratio so it keeps its shape. Sources at or below that area are unaffected, including 4K displays and ultrawides. On the 5K source above, the tiers become Low 1296 x 2304, Medium 1620 x 2880, High 1944 x 3456, Original 2160 x 3840, and the Medium export completes (verified: 1620 x 2880, 4,307 frames at 24 fps, the full take).
The trade-off: Original no longer means the source size for displays above 4K, and every tier on those displays scales from the capped canvas. I have this working in a fork and can open a pull request if a canvas ceiling is the direction you want. A capture-side option (recording a 5K screen at 1440p or 2160p) would be the other way to solve it.
Summary
A full-screen recording of a 5K display (5120 x 2880 pixels, a 2560 x 1440 desktop at backing scale 2) produces an export canvas larger than the encoder can handle, and the export never completes. The cause is that the export canvas follows the source size with no upper bound.
Environment
mainatb3ea7754Steps to reproduce
What happens
The export runs for a long time and never finishes. There is no error, and no log is written.
The export settings menu shows the tier sizes as: Low 1728 x 3072, Medium 2160 x 3840, High 2592 x 4608, Original 2880 x 5120.
Why
calculateMp4SourceDimensionsinsrc/components/video-editor/exportDimensions.tsbuilds the export canvas from the source dimensions. For a portrait aspect ratio it takes the source's short side (2880) as the width and derives the height from the ratio, giving a 2880 x 5120 canvas. That is 14.7 megapixels: about 58 MB of RGBA read back per frame, 4,300 frames at 24 fps, and a frame height beyond what H.264 hardware encoders accept.The encoder support probe (
probeSupportedMp4Dimensions) did not cap the size, so nothing warned the user.Only the Original tier was tried before working around it. A 2560 x 1440 proxy recording of the same take, with a copy of the project pointing at it, exported normally at Medium (1080 x 1920).
Related reports
avc1.64003c, Level 6.0), but on 1.4.0 and current main (Electron 43) it decodes: with the canvas capped, the export ran to completion from the original Level 6.0 file. So on current main the decoder deadlock did not reproduce for me, and the canvas size is the remaining blocker for 5K sources. The watchdog suggested in that thread would still be worth having; this report does not cover it.Suggested fix
Cap the export canvas at the pixel area of 4K UHD (3840 x 2160, about 8.3 megapixels), scaling an oversize canvas by the square root of the ratio so it keeps its shape. Sources at or below that area are unaffected, including 4K displays and ultrawides. On the 5K source above, the tiers become Low 1296 x 2304, Medium 1620 x 2880, High 1944 x 3456, Original 2160 x 3840, and the Medium export completes (verified: 1620 x 2880, 4,307 frames at 24 fps, the full take).
The trade-off: Original no longer means the source size for displays above 4K, and every tier on those displays scales from the capped canvas. I have this working in a fork and can open a pull request if a canvas ceiling is the direction you want. A capture-side option (recording a 5K screen at 1440p or 2160p) would be the other way to solve it.