Created attachment 114694 [details] Noisy screenshot from mplayer -vo xv On a Broadwell system (X1 Carbon 3rd generation), playing video through the default xv adaptor "Intel(R) Textured Video" adds piles of green and purple noise to the image. I can reliably reproduce this by playing back any video using "mplayer -vo xv". This noise doesn't appear when using some other video output (such as -vo gl) or when using xv adaptor #1: "Intel(R) Video Sprite" (though that has other issues). I'll attach three screenshots of the same video frame: one from mplayer -vo xv (showing the noise), one from mplayer -vo gl (not showing the noise), and one dumped via mplayer's internal screenshot mechanism by hitting alt-s (which turns a frame into a screenshot without sending it to the video output, so it doesn't include the noise). The noise doesn't dance around; it's consistent for any given frame, and slight changes to the frame seem to produce slight changes to the noise rather than completely different noise. Driver version: 2.99.917 Xorg server version: 7.7 Mesa version: 10.4.2 Kernel version: 4.0-rc5 Debian sid Will attach Xorg.0.log, glxinfo output, and xvinfo output. Graphics card (from lspci -vvv): 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 2227 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 54 Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=16M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 3000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00018 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915
Created attachment 114695 [details] Non-noisy screenshot from mplayer -vo gl
Created attachment 114696 [details] Non-noisy mplayer internal screenshot via alt-s
Created attachment 114697 [details] Xorg.0.log
Created attachment 114698 [details] glxinfo
Created attachment 114699 [details] xvinfo
Any particular sample video i.e. is it dependent upon planar or packed formats? Could you quickly jump around a couple of kernel and ddx versions just in case it is a regression? (I haven't touched the video paths for a while, but there might be some collateral damage.) Are the sprite problems just the usual issues of using an overlay? Or are they worth filing bug reports for?
(In reply to Chris Wilson from comment #6) > Any particular sample video i.e. is it dependent upon planar or packed > formats? Happens with every video I've tried, regardless of format. Any random youtube video downloaded with youtube-dl, for instance. AFAICT, mplayer is always using xv with planar YV12; it always shows a line like this (modulo resolution): VO: [xv] 1920x1080 => 1920x1080 Planar YV12 [zoom] > Could you quickly jump around a couple of kernel and ddx versions > just in case it is a regression? (I haven't touched the video paths for a > while, but there might be some collateral damage.) Kernel yes; I'll test a couple of kernels and report back. DDX not as easily, since I need a DDX new enough to understand Broadwell, and the version packaged in latest Debian unstable doesn't. I'm currently running 2:2.99.917-1~exp1 from Debian experimental. > Are the sprite problems just the usual issues of using an overlay? Or are > they worth filing bug reports for? Lack of scaling; with -vo xv:adaptor=1, the video only displays at its original size, regardless of the display window size (including fullscreen). Toggling fullscreen leaves the video centered at its original size with the rest of the screen filled with colorkey. (The mplayer -zoom option doesn't seem to make a difference there.)
3.19 (specifically 3.19.1, Debian package 3.19.1-1~exp1) shows the same behavior as 4.0-rc5. With 3.16 (specifically 3.16.7-ckt7, Debian package 3.16.7-ckt7-1), instead of scattered blocky noise that doesn't dance around, I get pixel-level green noise over the whole image that changes every frame.
(In reply to Josh Triplett from comment #7) > (In reply to Chris Wilson from comment #6) > > Are the sprite problems just the usual issues of using an overlay? Or are > > they worth filing bug reports for? > > Lack of scaling; with -vo xv:adaptor=1, the video only displays at its > original size, regardless of the display window size (including fullscreen). > Toggling fullscreen leaves the video centered at its original size with the > rest of the screen filled with colorkey. (The mplayer -zoom option doesn't > seem to make a difference there.) BDW sprite planes simply do not support scaling, so that's expected. To get mplayer to use another format you can pass eg. '-vf format=yuy2' to it. As for the corruption, I'm getting it on my BSW too. With both YV12 and YUY2. So a generic gen8 issue I suppose. For me it seems to depend on the horizontal position of the window. When I see the corruption and I pause mplayer, then move the window sideways a bit, the corruption remains in the image, but then if I hit '.' to have it render another frame the corruption shifts or disappears. And even when I get the position correct to eliminate the green/purple corruption, the results still look very blocky. Pretty much looks like it's doing linear interpolation exactly the wrong around or something. Not quite sure, but look like the vertical interpolation is the problem, horizontal might be OK.
(In reply to Ville Syrjala from comment #9) > To get mplayer to use another format you can pass eg. '-vf format=yuy2' to > it. yuy2 doesn't seem to work at all here; it gives a colorspace incompatibility error and exits. > As for the corruption, I'm getting it on my BSW too. With both YV12 and > YUY2. So a generic gen8 issue I suppose. For me it seems to depend on the > horizontal position of the window. When I see the corruption and I pause > mplayer, then move the window sideways a bit, the corruption remains in the > image, but then if I hit '.' to have it render another frame the corruption > shifts or disappears. I don't have that behavior at all; the corruption seems to be entirely position-independent here. Though it's possible that some combination of mplayer2 and compositing is causing the video decoding on my system to always occur at the same offset in an off-screen buffer unless fullscreened.
Created attachment 114728 [details] [review] [PATCH] gen8: Fix the YUV->RGB shader This patch seems to fix the problems on my BSW at least. Please test.
commit c43617b739e358064396912c7a7a8028ca91d201 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Apr 16 20:40:39 2015 +0300 gen8: Fix the YUV->RGB shader Use the correct register (Yn_01) with first half of the Y samples instead of using the register (Yn_23) with the second half twice when computing the green channel. Also use the Yn_01 register name instead of Yn for the red channel as well, just for a bit of extra consistency. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89807 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.