Repository navigation
fix(engine): keep the rightmost 8 columns of SDR MP4 at widths like 1080 - #5559
Conversation
#4564 routes SDR colour through `format=gbrp`. Without accurate_rnd, swscale's yuv-to-gbrp conversion leaves the last 8 columns black when the width is 16n + 8 (1000, 1080, 1112...), so every 1080x1920 portrait MP4 since 0.8.81 has had an 8 px black strip on the right. The same step in SDR jpg frame extraction blanked the right edge of footage at those widths. Set accurate_rnd on the yuv-to-gbrp scale in both chains. It is also the more accurate rounding: on a testsrc2 frame, worst luma error against a float reference drops from 1.85 to 0.90 codes. Fixes #5551 Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
jerrai-bot-heygen
left a comment
jerrai-bot-heygen
left a comment
There was a problem hiding this comment.
The patch adds accurate_rnd only to the SDR BT.601→gbrp conversion in both the encode and JPEG extraction paths; HDR routing and the downstream BT.709 scale remain unchanged. The 1080-wide edge regressions in chunkEncoder.test.ts and videoFrameExtractor.test.ts executed in the hosted engine runtime suite (99 and 200 tests in those files), alongside green lint, format, build, producer integration and Windows checks. The full 1080×1920 end-to-end render and before/after mutation are author-reported, not independently reproduced by this reviewer; remaining regression/accuracy shards were still running. Approval is not merge or publication of 0.8.155. — Jerrai
Edit accuracy: accurate 2061 (base branch 2061), smooth 1589 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (1)
|
What
Adds
accurate_rndto the yuv-to-gbrp scale in the SDR colour chains: the MP4/streaming encode filter (sdrCaptureColor.ts) and the SDR jpg frame-extraction filter (videoFrameExtractor.ts).Why
Since 0.8.81 (#4564), SDR colour goes through
format=gbrp. Withoutaccurate_rnd, swscale's yuv-to-gbrp conversion leaves the last 8 columns black when the width is 16n + 8 (1000, 1080, 1112...). So every 1080x1920 portrait MP4 has had an 8 px black strip on the right. The same step in jpg frame extraction blanks the right edge of footage at those widths.It depends on the ffmpeg version. A 1080-wide white frame through the current filter loses its last 8 columns on ffmpeg 7.1 and 8.0.1, and is correct on 5.1 (the
Dockerfile.testimage) and 6.1. Withaccurate_rndall four are correct. That is why the regression goldens, rendered on 5.1, never showed it, and why #4564's pixel tests (64 px wide) missed it.Related work
Fixes #5551. Regressed in #4564, whose commit notes
accurate_rndas "redundant" once nearest-neighbour chroma was added.How
flags=neighborbecomesflags=neighbor+accurate_rnd.testsrc2frame (a width the bug doesn't hit), the worst luma error against a float BT.601-full to BT.709-limited reference drops from 1.85 to 0.90 codes, and the mean error drops from 0.325 to 0.304.No visible change
This is an engine-only change, with no Studio or player UI.
Test plan
chunkEncoder.test.tschecks that a 1080-wide#C83C28capture keeps its last 8 columns in the MP4 (within 2 codes).videoFrameExtractor.test.tschecks that a 1080-wide clip's last 8 columns survive jpg extraction (within 5). Fails without the fix: withaccurate_rndremoved, both new tests fail; with it, both pass.#C83C28composition, the luma of the last 10 columns at mid-height:[email protected]:97 97 0 0 0 0 0 0 0 098 98 98 98 98 98 98 98 98 98accurate_rndchanges a small share of pixel values by about a code, so CI's PSNR comparisons will show whether any golden needs regenerating.🤖 Generated with Claude Code