Fun Fact: This same sort of thing also happened on the Classic Macintosh Quadra 840AV, when running in 8-bit (256 color) mode. Playback of realtime video capture reserved color index #243 (a very dark green in the system palette), and ANYWHERE that color was used, it would be replaced with the live video. I created some cool effects using this back in the 90s.
Long time back I'd play PS2 games in a chat window in EverQuest while waiting for mobs to spawn. I had a capture card that would overlay over a particular shade of purple that I discovered while trying to screen shot something from a game. I made an empty chat window in EQ that color and where it overlapped the card's application window behind the video would render. Was super jank picture in picture, but it worked.
> These special surfaces were called “overlays” because they appeared to overlay the desktop.
I have some vague memory of programs whose windows had funky shapes (i.e. not rectangular) also using overlays of some kind. Maybe that's a different sort of overlay?
I had a Matrox Millenium card with a breakout box for capturing RCA, S-Video, and Cable TV; I'd watch TV on my Windows 98 SE2 computer, which was the craziest thing back then, but I always felt like the green-screen like effect was some kind of mysterious bug that I'd better not mess with, or video capture would break. Windows 98 was barely working on a good day, so it felt like the computer was in the process of failing in a graceful and useful way, so I'd better not push my luck.
Every so often you could get a glimpse of the man behind the curtain, by dragging the window quickly or the drivers stuttering, which would momentarily reveal the green color (or whatever color it was) before the video card resumed doing its thing. Switching between full screen and windowed mode probably also revealed the magic, or starting a game that attempted to grab the video hardware context. And of course sometimes other graphical content would have the exact right shade of color, and have video-displaying pixels.
A green stripe on the right/bottom is usually due to a different issue: interpolation errors in chroma planes when decoding YCbCr video. The chroma planes use a biased encoding where 0 (no color) is mapped to 128. A sloppy YCbCr to RGB conversion without proper clamping can interpolate against 0 at edges, which is interpreted as max negative chroma red/blue -- which combined together produces green. This can happen either due to an incorrectly padded texture or failing to handle the special final sample case for 4:2:2 chroma.
This issue can happen with overlays, but also non-overlay GPU drawing or CPU conversion routines.
Video rendering can still be done with overlays, but it's a little more substantial, involving separate planes with the locations configurable on the graphics card. Look up MPO, Multi-Plane Overlay.
Your green stripe is likely because of the classic combination of unclamped bilinear filtering and a texture that's larger than the output region being used as the drawing surface for the video.
They still use "overlays" - just they're a lot more featureful in modern implementations than "Replace all of one colour with another surface" - so they tend not to have the same limitations and quirks.
MS started exposing some capabilities using MPO in the windows 8 era [0], and they've pretty much always had pretty comprehensive composition pipes in hardware for mobile platforms due to the power/bandwidth limitations meaning compositing the display can be a significant fraction of the total device's performance.
I suspect green (or other block colour) artifacts on video edges are due to bugs/mismatches in specification with the hardware video decoder and how the app displays it, and the bugs that often fall out of that.
Most video compression requires pretty large blocks, normally from 16x16 up 64x64 depending on format, and that may not align with the actual video size (e.g. 1080 does not divide by either). But often implementations still need that extra surface, as things like motion vectors may still refer to data in the "invisible" portion. And it has to be filled with something. It's then real easy to fall into bugs where small numeric errors in things like blending, or even just mix-ups between the different "sizes" that surface has, to cause issues at the edges.
I suspect the other comment about using ANGLE/dx9/dx11-on-12 may be effective as it /also/ causes the hardware video decoder not to be used, which is often a source of "unexpected" differences or limitations that commonly cause errors like that.
This reminds me of the time when Quake started rendering inside the start button of the Windows 95 desktop (or maybe Win 98). I wish I could remember the details but it think it was something to do with alt-tab.
That quirky effect is a known quirk of early DirectDraw/WinQuake on Windows 95/98. When a game grabbed the primary surface in certain modes, parts of the desktop GDI (like the Start button/taskbar) could briefly be overdrawn or show the game’s backbuffer due to how DirectDraw managed the primary surface and cooperative levels in fullscreen and windowed modes on those systems.
Readit News
I have some vague memory of programs whose windows had funky shapes (i.e. not rectangular) also using overlays of some kind. Maybe that's a different sort of overlay?
Every so often you could get a glimpse of the man behind the curtain, by dragging the window quickly or the drivers stuttering, which would momentarily reveal the green color (or whatever color it was) before the video card resumed doing its thing. Switching between full screen and windowed mode probably also revealed the magic, or starting a game that attempted to grab the video hardware context. And of course sometimes other graphical content would have the exact right shade of color, and have video-displaying pixels.
Darn, I thought this explained why, after upgrading my GPU, videos playing in Chrome have a thin green stripe on their right edge.
This issue can happen with overlays, but also non-overlay GPU drawing or CPU conversion routines.
Your green stripe is likely because of the classic combination of unclamped bilinear filtering and a texture that's larger than the output region being used as the drawing surface for the video.
MS started exposing some capabilities using MPO in the windows 8 era [0], and they've pretty much always had pretty comprehensive composition pipes in hardware for mobile platforms due to the power/bandwidth limitations meaning compositing the display can be a significant fraction of the total device's performance.
I suspect green (or other block colour) artifacts on video edges are due to bugs/mismatches in specification with the hardware video decoder and how the app displays it, and the bugs that often fall out of that.
Most video compression requires pretty large blocks, normally from 16x16 up 64x64 depending on format, and that may not align with the actual video size (e.g. 1080 does not divide by either). But often implementations still need that extra surface, as things like motion vectors may still refer to data in the "invisible" portion. And it has to be filled with something. It's then real easy to fall into bugs where small numeric errors in things like blending, or even just mix-ups between the different "sizes" that surface has, to cause issues at the edges.
I suspect the other comment about using ANGLE/dx9/dx11-on-12 may be effective as it /also/ causes the hardware video decoder not to be used, which is often a source of "unexpected" differences or limitations that commonly cause errors like that.
[0] https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
https://old.reddit.com/r/OLED_Gaming/comments/1kovgdx/green_...
I'd make sure your drivers are up to date before fiddling with Chrome flags though.
If video rendering used overlays, then YouTube could not put the toolbar or subtitles on top of the video, and they’ve been doing so for a long time.
Dead Comment