Repository navigation
Chromium video: odd-size videos no longer one column narrower - #613
Merged
Merged
Conversation
omacvm-vdecd rounds its CAPTURE buffers up to even (853x480 VP9 gets 854x480 buffers). Chromium imports each frame at the picture's size, and Mesa's virgl drops an import's size, so the Mac sampled the whole buffer: the picture came out one column (and row) narrower than it is. When the Mac's runtime can sample a texture at a size the guest gives (OMACVM_VALOGICAL=1, 3.2.11 and newer), the daemon now tells it the picture's size for each buffer before Chromium gets them: one NOP with the OMLS payload per 8 buffers, on the DRM file that made them. Even sizes send nothing. OMACVM_VA_LOGICAL=0 turns it off, as for the shim. Test: src/tests/vdecd-logical.sh (CI guest job), a stand-in for the kernel's ioctls; fails on main (no vdecd-logical.h).
…e picture's size) video-decode.md (Chromium limits, tests), AGENTS.md's Chromium video row, CHANGELOG 3.2.12. Rows (mini, Chromium 153, 3.2.11 app): 853x480 xratio 0.99864 -> 1.0002, 1001x563 0.99808/0.99892 -> 1.00005/1.00007; even sizes unchanged; OMACVM_VA_LOGICAL=0 as before.
…ssues) Motion-adaptive deinterlacing gives green: the Mac's GL samples Mesa's field buffer (2D array) as zero; Mesa alone the same. YUV to YUV video processing (vavpp bob/weave, deinterlace_vaapi, vapostproc) averages row pairs: Mesa's gfx compositor takes the weave shader for progressive surfaces. Measured on 3.2.11 (Mesa 26.2.5): FFmpeg texels, mpv on screen, a VA test program.
gillesgoetsch
marked this pull request as ready for review
October 29, 2026 07:50
This was referenced Oct 29, 2026
CHANGELOG 3.2.12 and docs/video-decode.md said "every size YouTube sends" was exact; that was not measured. Measured: 854x480, 720p, 1080p and 1000x562 exact, nothing sent. The CHANGELOG's "853x480 and 1001x563 exact" is now their line ratios (1.0002; 1.00005/1.00007), as with CPU decoding: video-geometry's verdict still counts the test card's red band at odd sizes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The known issue "VA-API conversions on the GPU give black pictures" was out of date: the three shader problems it named were fixed in 3.2.0 (Chrome's converted frames). Measured on 3.2.11 (h264-edge's rows, H.264 1920x1080 and HEVC 1000x562): hwdownload,format=bgra and scale_vaapi=format=bgra show the test card in place. What stays: they are RGB (not bit for bit), and YUV to YUV has the row pairs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mesa's deinterlacer declares its samplers without views (SAMP only) and reads the decoded pictures, plain 2D textures, with 2D-array lookups. virgl-shader-array-sampler-2d-view.patch maps such lookups to 2D only for samplers declared with a view, so the Mac's GL read zeros. A renderer test shows it (test-const-ubo.c case 25: black on the current runtime); the fix is #615, not yet measured in a VM. The bullet said the Mac's GL did not sample the deinterlacer's own buffer: wrong. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each pair of rows comes out alike on surfaces whose height is a multiple of 16 and on all of them with Mesa alone; surfaces the shim declares at their own size come out in another pattern (1000x562: 556 557 558 559 560 560; a 1000x568 surface: 556 557 559 559 561 561). Every row stays within one row of its place. Still Mesa's weave path, not OmacVM's. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gillesgoetsch
added a commit
that referenced
this pull request
Oct 29, 2026
Merged
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.
Lane v4l2-vavpp, 3.2.12 set. Not merged by the lane (the coordinator merges the 3.2.12 set).
Odd-size video in Omarchy's Chromium (fixed here). Arch Linux ARM's Chromium decodes through OmacVM's V4L2 device. omacvm-vdecd makes its CAPTURE buffers at the picture's size rounded up to even (
omacvm-vdecd.c:648, the module's step), and Chromium's GPU process imports each frame as one AR24 dma-buf at the picture's own size (853x480 of an 854x480 buffer). Mesa's virgl drops an import's size, so the Mac sampled the whole buffer: odd-size VP9 came out one column (853x480) or one column and row (1001x563) narrower. The visible size itself is not lost (the module answers COMPOSE with it, Chromium 153 wraps every frame with it).The daemon now tells the Mac the picture's size for such buffers before Chromium gets them: one NOP with the OMLS payload of
virgl-resource-logical-size.patchper 8 buffers, on the render node GBM made them on (src/vdec/guest/vdecd-logical.h). Only when the runtime saysomacvm.valogical=1(3.2.11 and newer);OMACVM_VA_LOGICAL=0turns it off; even sizes send nothing. Guest only (Update VM), no module change.Test:
src/tests/vdecd-logical.sh(CI guest job, a stand-in for the kernel's ioctls): branch 16 ok; origin/main'ssrc/vdec/guestfails (novdecd-logical.h), on macOS and in the VM (Arch, GCC 16).Rows (Mac mini M4, hidden 3 GB clone, 3.2.11 test app 9d2105b, Chromium 153.0.8010.36, video-geometry, all 6 VP9 clips each):
(The odd clips stay "WRONG" in video-geometry's verdict only by the test card's red-band count at odd sizes: mpv's CPU decoding has the same; the ratios are exact.) Chromium's imports (logged) unchanged. tccd 0, GPU restarts 0, cores 0.
Docs (
docs/video-decode.mdknown issues), from #610's rows and this lane's:vavppdefault (motion-adaptive) deinterlacing draws green: OmacVM's runtime, not Mesa. Mesa's deinterlacer (vl_deint_filter.c) declares its samplers without views (SAMPonly) and reads the decoded pictures, plain 2D textures, with 2D-array lookups;virgl-shader-array-sampler-2d-view.patchmaps such lookups to 2D only for samplers declared with a view, so the Mac's GL read zeros (Y=U=V=0). Mesa's driver alone the same, so not the shim. Row:Tests/virgl/test-const-ubo.ccase 25 black on the current runtime, right with the fix. Fix: virgl: 2D_ARRAY lookups on samplers without a view read a 2D texture (motion-adaptive deinterlacing) #615 (runtime patch + test,run-regressions.pyOK); not yet measured in a VM.vl_compositor.cin 26.2.5 and main). Each pair of rows comes out alike on surfaces whose height is a multiple of 16 (854x480, 1080p in 1088 rows) and on all of them with Mesa alone; with the shim, surfaces of other heights come out in another pattern (1000x562: last rows 556 557 558 559 560 560; 1000x568: 556 557 559 559 561 561), every row within one row of its place (the height decides: the shim declares 854x480 too, and it still pairs); with Mesa alone the last chroma row of 1000x562 is far off (32 for 80). Not OmacVM's. This is the "about one row off" of mpvvavpp=deint=bobon HEVC 1000x562 with Video: H.264 1080p and other coded-size videos at their own size in Chrome and mpv #610: Video: H.264 1080p and other coded-size videos at their own size in Chrome and mpv #610 shows the video processing's output exactly. The upstream draft (not posted) runs on OmacVM's 2D-view patch; it needs a reproduction on a stock driver before anyone posts it.hwdownload,format=bgraandscale_vaapi=format=bgrashow the test card in place on 3.2.11 (h264-edge's rows, H.264 1080p and HEVC 1000x562). Rewritten to what holds (RGB, not bit for bit).Track: work/tracks/v4l2-vavpp-odd.md.