recorder: pad odd source dimensions before libx264 encode#246
Merged
Conversation
libx264 with yuv420p requires both width and height to be divisible by 2 (4:2:0 chroma subsampling). When the X display has an odd vertical pixel count, ffmpeg fails to open the encoder and exits almost immediately, leaving a zero-byte mp4 even though the recording API returned 200. Adding `-vf pad=ceil(iw/2)*2:ceil(ih/2)*2` pads odd dimensions by a single pixel of black so the encoder always sees an even-sized frame.
|
Firetiger deploy monitoring skipped This PR didn't match the auto-monitor filter configured on your GitHub connection:
Reason: This PR modifies the recorder package to fix ffmpeg encoding, which does not change API endpoints (packages/api/cmd/api/) or Temporal workflows (packages/api/lib/temporal) as specified in the filter. To monitor this PR anyway, reply with |
hiroTamada
approved these changes
May 21, 2026
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
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.
Summary
libx264 with
yuv420prequires both width and height to be divisible by 2 (4:2:0 chroma subsampling). When the captured display has an odd vertical (or horizontal) pixel count, ffmpeg fails to open the encoder withwidth/height not divisible by 2and exits almost immediately — butStart()only waits 250ms for a startup error, so the API still returns 200 and the caller is left with a zero-byte mp4.This change adds a
-vf pad=ceil(iw/2)*2:ceil(ih/2)*2filter so odd source dimensions are padded by a single pixel of black before encode. Even dimensions are unchanged.Repro
With the filter:
Test plan
go build ./...go test ./lib/recorder/... -v(existing tests pass, newTestFFmpegArgs_PadsOddDimensionscovers the args)Note
Medium Risk
Touches ffmpeg encoding arguments for all recordings, which could subtly affect output dimensions/compatibility if the filter order or padding behavior differs across inputs/platforms.
Overview
Prevents recordings from failing on odd-sized displays by adding
-vf pad=ceil(iw/2)*2:ceil(ih/2)*2to the ffmpeg output args beforelibx264/yuv420p, ensuring width/height are even.Adds
TestFFmpegArgs_PadsOddDimensionsto assert the new-vffilter is present in the generated argument list.Reviewed by Cursor Bugbot for commit 72b0e42. Bugbot is set up for automated code reviews on this repo. Configure here.