I have random screen corruption in XBMC when watching videos with VAAPI. Sometimes it starts after a few minutes, sometimes as soon as I start the video, it is completely random. It was working fine before I reinstalled the machine recently, so I guess this must have been caused by some update. I have another Sandy Bridge machine with the exact same software configuration which does not have any problems (Core i5 2500, Intel DH67GD). I doubt that this is a XBMC problem because I have seen no other reports of this problem and it is working fine on the other machine. I've seen this in multiple videos (all x264 afaik). See video here: http://www.youtube.com/watch?v=hYi5QKt2KfA ------------------- Output of vainfo: libva: libva version 0.32.0 libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/i965_drv_video.so libva: va_openDriver() returns 0 vainfo: VA API version: 0.32 vainfo: Driver version: i965 Driver 0.1 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264Baseline : VAEntrypointVLD VAProfileH264Baseline : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD ------------------- System: Arch Linux Kernel 3.0 libva 1.0.14 XBMC Git 2011-09-28 Intel Pentium G620T MSI H61I-E35
I just tested mplayer with -vo vaapi -va vaapi. It has the exact same problem, so it is definitively not an XBMC bug. Additionally the video is stuttering in mplayer although the CPU usage stays below 10% (no stuttering in XBMC). Not sure if this is related...
You mentioned it works fine with another machine, what is the difference between your two machines?
(In reply to comment #2) > You mentioned it works fine with another machine, what is the difference > between your two machines? Machine with the problem: Intel Pentium G620T MSI H61I-E35 (B3) 2GB RAM Machine which is working fine: Intel DH67GD (B3) Intel Core i5 2500 4GB RAM Both of them are running Arch Linux with Kernel 3.0 and libva 1.0.14. The software configuration is basically the same, so the only difference is the hardware. Is it possible that is a hardware problem (GPU defect)?
In fact the GPU of G620T is different with the GPU of i5 2500. Please see the following link to get the detailed information. http://ark.intel.com/products/53481/Intel-Pentium-Processor-G620T-%283M-Cache-2_20-GHz%29 Maybe it is a bug about chip ID. It should not support VC-1 hardware decoding and H.264 hardware encoding for G620T, while vainfo showes it support.
so what does this mean? that this is a bug in the graphics driver itself? anything I can do to narrow down the problem, debugging, logs etc.?
Could you attach the output of 'lspci -n' ?
Created attachment 52425 [details] output of "lspci -n"
So the kernel gets 0x0102 as the device ID of G620T which is same as sandy bridge. But I am afraid it is wrong.
I already noticed that the GPU of the Core i5 2500 has the exact same id. So does this mean the kernel thinks the G620T is a "Intel HD Graphics 2000" GPU while it actually is a "Intel HD Graphics" GPU?! So is this a kernel bug? A BIOS bug? Is there a workaround?
Is there any issue when running a 3D application on this machine? BTW could you attach the detail output of 'lspci -nnvv'?
Created attachment 52523 [details] output of "lspci -vvnn"
All I can tell you is that XBMC and Mupen64plus (n64 emulator) are both working fine without any graphic glitches.
Created attachment 52524 [details] output of "sudo lspci -vvnn" Just realized that lspci shows more info as root.
Could you test mplayer with the following options? 1. -vo vaapi (without -va vaapi) 2. -vo xv 3. -vo x11
I saw something very interesting. When I was testing the -vo x11 option in XFCE and I switched back from mplayer to a terminal window, I saw some of the "VAAPI screen corruption" within the terminal window(!), while there was none in the video. It was still there when I quit mplayer and it even scrolled together with the content in the terminal window. It disappeared when I tried to take a screenshot of it. This doesn't really make sense to me. To me this looks like a GPU defect, but XBMC and mupen64plus are working fine. I'm really confused... I'm gonna try to get my hand on another Sandy Bridge CPU, maybe this really is a hardware problem!? Or could this also be caused by the chip id problem?! Although this doesn't seem to be VAAPI specific problem after all, here are my testing results: -vo vaapi -va vaapi - Screen corruption begins after a few minutes -vo vaapi - Screen corruption begins after a few minutes -vo xv - tearing, random video/audio hangs, but no screen corruption after 20 minutes of watching -vo x11 - the same as xv, but less hangs btw, the stuttering with -vo vaapi -va vaapi I mentioned earlier was happening because I started mplayer directly from my login manager because I was too lazy to install a desktop environment (I use this machine for XBMC only and XBMC has a standalone mode to run without a desktop environment). I installed XFCE and there is no stuttering if I run mplayer -vo vaapi -va vaapi from a XFCE session.
It sounds this is a rendering issue instead of decoding issue.
I am OOP on vacation today. E-mail response might be late. Hai Lan
As if the confusion wasn't big enough already, I can now suddenly not reproduce the problem anymore. I just watched a whole movie with VAAPI without any problems and tested several other videos that showed screen corruption within minutes before. I made a system upgrade a few days ago, part of the update was the linux kernel (3.0.6 -> 3.0.7), so I thought this was responsible. Out of curiousity, I downgraded back to 3.0.6 - still couldn't reproduce it. All other updated package imho wouldn't fix such an issue, so I've actually no idea what's going on. But feel free to correct me, these packages were updated: glib2 gtk-update-icon-cache gtk2 linux mplayer-vaapi openssh initscripts krb5 lame libarchive libltdl libpulse libtool poppler poppler-glib util-linux I'm starting to think the system just wants to mess with me or something, maybe the problem is going to return tomorrow, who knows...
(In reply to comment #18) > mplayer-vaapi This one certainly looks like as a possible suspect. But perhaps it is one of those random issues which go away by themselves :/..
nevermind, it's back again... I'm gonna replace the CPU/GPU and see if it helps...
Replaced the CPU with a G630T - didn't fix it Replaced the mainboard with a ASUS P8H61-I - didn't fix it Replaced the memory - didn't fix it So I guess this rules out a hardware problem...
Now I noticed some problems in the XBMC GUI as well. Not sure if this happened for the first time or if I just didn't notice it before. If you look closely in the attached picture, you can see that the bars in the images are not "corrupted" but actually transparent. btw, since this is not a VAAPI problem after all, shouldn't this bug be assigned to someone else? Just asking...
Created attachment 53009 [details] XBMC GUI "Corruption"
I will close this bug as notourbug. Please file a new bug to track the new issue you found and assign it the owner of 2D/3D driver. If you still experience screen corruption issue with vaapi after fix the new bug, please feel free to reopen this bug.
created new bug #42506
It seems like this has all been fixed in kernel 3.3-rc1, running for 3 days without any problems. :) However, vainfo still shows the wrong information. I personally don't really have a problem with this, but if one of the developers would like to find out why this is happening, I'd be happy to provide more information.
(In reply to comment #26) > It seems like this has all been fixed in kernel 3.3-rc1, running for 3 days > without any problems. :) > However, vainfo still shows the wrong information. What is the wrong information?
(In reply to comment #27) > (In reply to comment #26) > > It seems like this has all been fixed in kernel 3.3-rc1, running for 3 days > > without any problems. :) > > However, vainfo still shows the wrong information. > > What is the wrong information? See comment #4 by Hai, vainfo shows the GPU supports VC1 decoding/H264 encoding although it actually doesn't. The vainfo output is still the same as in my original bug description.
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.