Skip to content

fix: force even dimensions before H.264 encode (odd sizes broke ffmpeg CRF)#114

Merged
kenobijon merged 1 commit into
devfrom
fix/ffmpeg-odd-dimensions
Jun 19, 2026
Merged

fix: force even dimensions before H.264 encode (odd sizes broke ffmpeg CRF)#114
kenobijon merged 1 commit into
devfrom
fix/ffmpeg-odd-dimensions

Conversation

@kenobijon

@kenobijon kenobijon commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes the odd-dimension bug flagged by the Cursor bot review on #113.

_h264_roundtrip_ffmpeg encodes with libx264 -pix_fmt yuv420p, which rejects odd width/height. Any frame with an odd dimension made the ffmpeg subprocess exit non-zero, so the helper returned None and the robustness pass silently fell back to cv2 / per-frame JPEG — even with ffmpeg on PATH — while params["method"] could still imply a CRF roundtrip that never actually ran. The resolution ladder's max(2, round(...)) didn't guarantee evenness either.

Fix

Trim a trailing row/column to even dimensions once before encoding, covering both the ffmpeg -crf and cv2 avc1 paths (both are H.264/4:2:0):

even_h, even_w = H - (H % 2), W - (W % 2)
if (even_h, even_w) != (H, W) and even_h >= 2 and even_w >= 2:
    video_array = video_array[:, :even_h, :even_w, :]
    T, H, W, C = video_array.shape

At most one pixel per axis is dropped, and the frame is resized to target_size afterward, so the effect on the benchmark is nil. Guarded so a degenerate <2px axis is left untouched for the fallback to handle.

Verification

End-to-end with real numpy/opencv/Pillow/ffmpeg — all now engage method == "ffmpeg_crf":

Case Before After
97×131 (both dims odd) fell back to cv2/jpeg ffmpeg_crf
odd dims + scale_factor=0.5 fell back ffmpeg_crf
96×128 (even, regression) ffmpeg_crf ffmpeg_crf

🤖 Generated with Claude Code


Note

Low Risk
Localized preprocessing in the video robustness path with at most one pixel trimmed per axis; no auth, data, or API surface changes.

Overview
Video robustness now forces even width and height on frames immediately before the H.264 roundtrip in apply_video_robustness_augmentations, so libx264 / yuv420p (ffmpeg CRF and cv2 avc1) no longer fail on odd sizes.

When either dimension is odd, the code drops at most one trailing row or column (only if both sides stay ≥2), then re-reads T, H, W, C before choosing the encode path. That stops silent fallback to cv2 or per-frame JPEG when ffmpeg is available, and keeps reported params["method"] aligned with the encoder that actually ran. Frames are still resized to the model target afterward, so benchmark impact is negligible.

Reviewed by Cursor Bugbot for commit 098bd67. Bugbot is set up for automated code reviews on this repo. Configure here.

libx264 with yuv420p rejects odd width/height, so _h264_roundtrip_ffmpeg
exited non-zero on any frame with an odd dimension and the pass silently fell
back to cv2/per-frame JPEG — while params["method"] could still imply a CRF
roundtrip that never happened. The resolution ladder's max(2, round(...)) did
not guarantee evenness either.

Trim a trailing row/column to even dimensions once before encoding, covering
both the ffmpeg -crf and cv2 avc1 paths (both are H.264/4:2:0). At most one
pixel per axis is dropped, and the frame is resized to target afterward, so
the effect on the benchmark is nil. Guarded so a degenerate <2px axis is left
untouched for the fallback to handle.

Verified: 97x131 input (both dims odd), odd input with scale_factor=0.5, and
an even-dim regression case all now engage method="ffmpeg_crf".

Reported by Cursor bot review on #113.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@kenobijon kenobijon merged commit 5c50afb into dev Jun 19, 2026
1 check passed
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.

1 participant