VAAPI playback crashes immediately

[jmbreuer]

On my system video playback shows heavy artifacts and fails within the first few seconds with most video streams when VAAPI is enabled. I'd have said all streams, but I've happened to see one or two videos work with VAAPI enabled - but perhaps VAAPI wasn't used for those streams (wrong codec for example).

This overview corresponds to this video in 720p, what the screen looks like when playback hangs within the first second: https://www.youtube.com/watch?v=LveBnP5MMs8

This closeup is from another position in the same video, and tries to show the pixel structure of the artifacts.

When this happens, [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung is logged to dmesg; there is nothing obvious in xbmc.log.

Xorg.0.0.log shows only this related to the error:

(WW) intel(0): I830DRI2GetMSC:1358 get vblank counter failed: Invalid argument
(WW) intel(0): first get vblank counter failed: Invalid argument

Here's the full Xorg.0.0.log anyway: http://filebin.ca/S1Q7WxafatM/Xorg.0.0.log

Video output stays stuck on the broken frame, requiring a reboot (from ssh) to recover.

This affects all OpenELEC 2.95.x versions, nightlies, local development builds since at least November 2012; on a i5 3470S CPU/GPU in an Intel DH77EB mainboard.

Capturing the i915_error_state was not easy, since trying to read it would always result in an ENOMEM.

I dug a bit deeper and patched i915_debugfs to truncate the memory page logging after a few pages each, that way I managed to obtain an error state log - hopefully with enough useful information. The truncation is annotated in the log.

http://filebin.ca/S1R3uofBcT0/i915_error_state

If you rather need the last instead of the first pages that should be no problem; if there is enough interest I might hack something together to expose the memory dumps from i915 in a more useful way.

I'll be happy to help in further analysis, just tell me what I can do.

[DeeGeeGit]

I'm also seeing this, not every video is affected, but it does seem to happen quite a bit.

[itechatmxc]

I experienced a similar issue with VAAPI playback. Solved by patching libva-intel-driver with haihao's fix. For detail see: https://bugs.freedesktop.org/show_bug.cgi?id=59050#c8

[jmbreuer]

itechatmxc: Thanks a lot for the pointer. Unfortunately VAAPI playback still crashes after a few seconds at the latest for me with the usual artifacts, even with both of haihao's fixes applied.

No new error state right now, I botched carrying that patch over to the new version. My take is that the underlying issue is not affected by haihao's patch and therefore the error state above is still applicable.

Is there anything more I can do to try and clear this up? Am I the only one experiencing this issue (VAAPI artifacts, crashes on i7 3740S cpu integrated graphics)?

[itechatmxc]

Maybe your issue is a bit different. However I'm a bit confused about your HW. Are you using the i5 3470S as mentioned in your initial post or i7 3740S? Anyway i5 or i7 the both CPUs should have the same GPU gen. I believe that this is a 7-th generation. If not, then patching the parts that belongs to the gen 7 hardware can not help. I also forgot to mention that all the intel drivers and libraries xf86-intel-driver, libvai-intel-driver and libva are "cloned" from the master branch of their git repositories.

[jmbreuer]

Argh sorry, it actually is an i5 3470S. Would Intel please stop using confusing number-swapping terminology games ;-)

OK, thanks for the hint about what the 'gen_7' is about; I'll try and find out which generation my graphics core really is and if it's not 7th gen I'll try porting the "make buffer large enough" patch to whichever gen is appropriate for me and test again.

Hm. The xf86-intel driver calls it "Integrated Graphics Chipset: Intel(R) Ivybridge Desktop (GT1)". Do you happen to know where I can find the table how that / the GPUs PCI IDs ([8086:0152] rev 09) etc. map to this "generation"?

But now, first to get the day job done :-/

[jmbreuer]

OK, I just got bold and applied https://bugs.freedesktop.org/attachment.cgi?id=73236 to gen7_mfd.c, and the equivalent change to gen6_mfd.c and gen75_mfd.c as well, since I can't be sure which code path is actually used on my system. [How would I find out? I don't see a logging facility or anything readily available within libva-driver-intel.]

With this (and the still-patched libva itself, https://bugs.freedesktop.org/attachment.cgi?id=72613 ) I see some change: Video playback no longer seems to crash the GPU.

But the artifacts are still there, same as ever.

To clarify these artifacts: They are not static but are flickering around all over the image; I'd guess different blocks are "hit" in every frame.

[jmbreuer]

OK, next data point: Using libva and and libva-driver-intel directly from freedesktop.org's git (master), VAAPI playback works without artifacts on my system. (Yay!)

So something definitely changed there; but I think even without this specific request OpenELEC will have enough reasons to track upcoming releases of libva / libva-driver-intel ;-)

[iamdb]

@jmbreuer -- I'm experiencing a similar issue. How did you go about installing the updated drivers from freedesktop.org into openelec?

[itechatmxc]

The most important thing is to change PKG_URL in the meta file that is located under packages/multimedia/libva and libva-intel-driver. Here is part my meta for libva:

PKG_NAME="libva" PKG_VERSION="master" PKG_REV="1" PKG_ARCH="i386 x86_64" PKG_LICENSE="GPL" PKG_SITE="http://freedesktop.org/wiki/Software/vaapi" PKG_URL="http://cgit.freedesktop.org/libva/snapshot/libva-master.tar.gz" PKG_DEPENDS="libX11 libXext libXfixes libdrm Mesa glu" PKG_BUILD_DEPENDS="toolchain libX11 libXext libXfixes libdrm Mesa glu" PKG_PRIORITY="optional" PKG_SECTION="multimedia" PKG_SHORTDESC="libva: The main motivation for VAAPI (Video Acceleration API) is to enable hardware accelerated video decode/encode at various entry-points (VLD, IDCT, Motion Compensation etc.) for the prevailing coding standards today (MPEG-2, MPEG-4 ASP/H.263, MPEG-4 AVC/H.264, and VC-1/VMW3)." PKG_LONGDESC="The main motivation for VAAPI (Video Acceleration API) is to enable hardware accelerated video decode/encode at various entry-points (VLD, IDCT, Motion Compensation etc.) for the prevailing coding standards today (MPEG-2, MPEG-4 ASP/H.263, MPEG-4 AVC/H.264, and VC-1/VMW3). Extending XvMC was considered, but due to its original design for MPEG-2 MotionComp only, it made more sense to design an interface from scratch that can fully expose the video decode capabilities in today's GPUs." PKG_IS_ADDON="no"

PKG_AUTORECONF="no"

get_graphicdrivers

for drv in $GRAPHIC_DRIVERS; do if [ "$drv" = i965 ]; then PKG_DEPENDS="$PKG_DEPENDS libva-driver-intel" fi done

[iamdb]

I'll give this a try, thanks!

[seddonm1]

About to receive my Intel NUC with the HD4000 so quite interested in this defect.

Can you guys confirm the status of this bug? it sounds like the freedesktop drivers are more developed than the other source so will these be merged into a nightly openelec build?

Is it possible to update the libva in Openelec without doing a complete build?

[itechatmxc]

If you have done the OpenELEC build it is not necessary to do a complete build. And by "complete build" I mean the build where the "make clean" was executed before the "PROJECT=Intel ARCH=x86_64 make release". You just need to re-build libva and libva-intel-driver. The easisest way is to delete libva and libva-intel-driver under a stamps subdirectory and then execute "PROJECT=Intel ARCH=x86_64 make release"

[seddonm1]

Thanks itechtmcx.

I have never done a build before but it is pretty straight forward.

People are reporting success then how do we go about merging this change into the master Openelec git so nightly build images will already include it?

[seddonm1]

Hi guys, I did a git clone and build using the master libva acceleration and it is not working well either.

Can you upload your image if it is working better?

[itechatmxc]

Here you go.

https://www.dropbox.com/s/vvw5vcui6xroez5/OpenELEC-Intel.x86_64-devel-20130203180329-r13156.tar.bz2

[seddonm1]

Thanks itech.

I think I actually made two changes at once (enabling the synch at startup) which may have affected this. I will check in a few days when I get home.

[ghost]

Thank you, i had the same ossue and getting libva & intel-driver from freedesktop (git-master) solved my problem ;-)

But i have a second similar problem with mpeg2 1080i, maybe i should try the staging-branch?

[itechatmxc]

You should rather keep your build sticked to the master branch. I've tried the staging branch in order to get more de-interlacers working (as the bob or reverse bob gives terrible results), but it was pretty unstable build. Playback crashed after ten or twenty seconds. YouTube videos didn't work at all except of the lowest resolutions. There is no interlaced MPEG2 HD content in my collection so I unable to test it.

[seddonm1]

Good work guys. Thanks for updating the log with your findings. Looking forward to testing it.

[Memesa]

I'm having issues with mpeg2 mkv movies obtained by Makemkv from the corresponding dvd .iso files. Opened a topic for it on the openelec.tv forums (http://openelec.tv/forum/116-vaapi-intel/62414-vaapi-green-artifacts-stutter-in-mpeg2-mkv-movies#63585). I have tested to see if itechatmxc's build solves the problems on my htpc (Pentium G630, Asrock H61M-ITX). However when I start a mpeg2 movie, the screen goes completely green and there is no audio. I'm able to bring up the on screen information (shows up after several seconds), but that doesn't show anything out of the ordinary. Playing h264 is fine, as it used to be. Funnily, if I stop playing a h264 and start a mpeg2 movie, then the mpeg2 movie does play, albeit starting with a couple of frame drops. Artifacts however, are exactly the same as they were on Openelec 3.0 RC1 (RC2 had the same issues as above, but I haven't tried playing a h264 file before a mpeg2 file). Any idea what to try to get my mpeg2 movies playing with vaapi support?

[itechatmxc]

Looks like h.264 playback left some of GPU registry changed in some way. But this is going beyond my capability :-) Sorry for that. I'm not a developer. My build, you have tested is based on libva, libva-intel-driver and intel-xorg-driver from master branch. Hovever libva-intel-driver is patched using a diff from Mr. Haihao @ Intel. This patch solves an issue with playback on IvyBridge architecture. As far I know your CPU is a SandyBridge. I'm pretty sure that IvyBridge is sometimes referred as generation 7. Do you know what generation is the SandyBridge? Take a look at the patch at https://bugs.freedesktop.org/show_bug.cgi?id=59050. If you found that your GPU is not a gen 7 then this patch can't solve anything. Good luck.

[Memesa]

Thanks for thinking along. At least I know that even with the latest version of libva, libva-intel-driver and intel-xorg-driver the issue still persists. The patched driver by Haihao mainly seems to solve irregular movie resolutions (from what I understood), so is unlikely to have an effect on the artifacts (I can possibly test it on an Ivy Bridge system, if wanted). Sandy bridge is generation 6 (http://www.x.org/wiki/IntelGraphicsDriver), so the patch likely doesn't have any effect on my system.

I noticed something weird, video playback in your build seems to be working.. sometimes. Sometimes it boots up and none of the movies will play, a few reboots later it somehow does. So it is independent of what I start first (h264 or mpeg2). I made my mkv's through makemkv, but I've just tried one of the original discs. Which plays perfectly fine, without artifacts. The only thing that might be causing the system to sometimes play, and sometimes not is the packages from the master branch. Isn't it?

[itechatmxc]

Just tested the video you have uploaded on Rapidshare. Despite the fact that my GPU is a IvyBridge it played with green artifacts as shown on your screenshot. So it's obvious that the issue is not caused by insufficient size of dvm buffer. The interrest thing is that I experienced similar green artifact while playing h.264 MKVs with certain resulution. However unlike your artifacts that are pretty spreaded on the screen, my artiffact was more concentrated on upper side of screen, mainly in the left corner. And the green blocks was significantly bigger. I don't have any of my videos made with makemkv, but all my mpeg2 videos from Handbrake (mkv container), original PAL DVDs(MPEG-TS) and PAL TV recordings (tvheadend'smkv container) plays fine.

[Farnsen]

@itechatmxc Your build works like a charm regarding the Video Playback on my Intel NUC (DC3217IYE). No Artefacts or Blackscreens anymore.

But on the downside, i can't play any DTS-HD anymore, i get only noise from the receiver. DTS & DD work fine.

So while its an improvement, i still cant watch videos proberly.

If i can contribute in any way, let me know (you still have to tell me exactly what to do, im really just a user)

[itechatmxc]

Weird thing. I'm just playing Megamind with DTS-HD Master audio track and it works like a charm. I'm using the build I've uploaded on Dropbox. The source for the build has patched alsa-libs package so it can play HD audio. Without the patch only a noise was heard. I tested several movies with TrueHD and DTS-HD Master -> no problem. I suppose that you have a correct XBMC audio setup HDMI, your receiver as passthrough device and right receiver's capability ticked.

[Memesa]

@itechatmxc Did some more testing on one of the problematic movies. And noticed that although the DVD was playing fine, when the individual movie .VOB files of the extracted .ISO were opened that the artifacts did show up. Transcoded with Handbrake the movies were fine, but I don't like transcoding because of the loss of quality and time consumption.

I do think there is some incompatibility of the movies with VAAPI, but that's likely some rarity that's currently showing up because of MakeMKV just ripping out the main movie file. Without the context it was used to be played in from within the DVD menu (maybe some settings are set through the DVD menu? As I doubt ff-mpeg2-vaapi makes a difference in the source of the file). Would it be worth to look into the log files of OpenELEC to search for clues?

[itechatmxc]

Didn't tried to play individual VOBs. I used to do a transcoding on SD content because it solves my problem with interlaced footage and I got an excellent h.264 format out of it. Can't see any loss of quality, however my RF is rather low.

[Farnsen]

DTS-HD worked like a charm with Openelec 2.99.1 & 2.99.2. (Only had VAAPI crashes on some movies). Nothing from the config has been changed. Still i only get Noise from DTS-HD on movies that just worked fine minutes ago. Can't say about TrueHD, i dont have any of them.

And the Problem is on every movie, not just one.

[seddonm1]

itechatmxc, can you provide an update on what the exact changes you made were to the build you posted. Was it just the intel (libva, libva-intel-driver) packages or more?

The image appears to be working for a lot of people so good work.

[itechatmxc]

libva, libva-intel-driver, xf86-video-intel, haihao's patch to enlarge dvm buffer on IB, HBR patch for alsa-lib to enable HD audio.

[seddonm1]

Thanks itechatmxc. Just want to know so that the devs can merge any required changes into the live branch. I have a build with just the libva, libva-intel-driver masters whcih I can test on the weekend.

[Farnsen]

@seddonm1

can you provide that build via dropbox? I would like to give it a shot too, to see if it fixes my DTS HD problem.

[itechatmxc]

@Farnsen Is your receiver able to do DTS-HD decoding? or you are just playing DTS core?. My first OpenELEC build was made due to 2.99.1 & 2.99.2.inability to handle HD audio. So I patched alsa-lib package. Yesterday I compiled another image without the patching of alsa-lib as few alsa patches were merged from upstream six days ago. Now the HD audio works out of the box, but on the other hand, another issue complicates audio track switching. Take look at https://github.com/OpenELEC/OpenELEC.tv/issues/1906

[Farnsen]

I got a DENON AVR-4310 wich is able to decode DTS-HD. Audio channel switching still does work like a charm. My workaround fpr the moment: toggle off DTS-HD capable Receiver, so i will downgrade the DTS-HD to DTS wich runs just fine. But still not satisfying.

[itechatmxc]

I've got exactly the same receiver. I suppose that your Intel NUC has a bit different audio hardware. I've read somewhere that there is an issue with SPDIF output which is connected to another sound card than the HDMI output. Wait couple of days if you can and I'll upload a new OpenELEC image with alsa-lib patches from upstream.

[ghost]

Blacklisting the Spdif-Kernel-Module should do the Job for you.

[od3m]

hey guys, same issues here on Intel Core i3-3220T / asus p8z77-i deluxe combo. playing files with vaapi crashes system immediately. without it works flawless.

building newest git doesnt work.

itechatmxc image works with vaapi, but no sound anymore.

so i hope there will soon be a patch out .....

[seddonm1]

@Farnsen Here is the build which I have made with only the libva and libva-intel-driver updated with their master. I haven't given it a good test as I enabled auto library updates at the same time which I thought was a defect with this build. At least we can fully isolate the changes required for VAAPI fix.

https://www.dropbox.com/s/0349bdg7t7j9d1m/OpenELEC-Intel.x86_64-devel-20130210001658-r13238.tar.bz2

[od3m]

@seddonm1 just tested your build. It works without any problems for me.

[Farnsen]

@seddonm1

I will test your build later today. Thank you!

[sraue]

@itechatmxc can you make a Pull request (or alternativly send me per mail) with the patches/change you have done reagrding intel driver, libva and xf86-video-intel please?

[Farnsen]

@seddonm1

I just tested you build. DTS-HD now works properly again, but VAAPI is crashing again.

[Memesa]

@seddonm1 Your build works fine, I noticed there is a flash for a split second when the system is started. VAAPI playback is fine (doesn't fix the artifacts in the mpeg2 movies though).

[itechatmxc]

@sraue I've made the Pull request. Hopping that is correct because I've never worked with Git until this evening.

[seddonm1]

Hi guys, As some people are reporting success with my built it looks like the patch that itechatmxc 'haihao's patch to enlarge dvm buffer on IB' applied has been applied to the master and should be in the next release of the intel libva, libva-intel-driver.

If this is true then we need to make sure the next Intel build is included in the Openelec 3.0 final.

Cheers, Mike

[jmbreuer]

If there's anyone still having problems with the builds above (thanks, guys!) I've uploaded my original build mentioned here https://github.com/OpenELEC/OpenELEC.tv/issues/1687#issuecomment-13006167 as well:

https://www.dropbox.com/s/yyy0v2hxjtdsqhh/OpenELEC-Intel.x86_64-devel-20130204170649-r13143.tar.bz2

So if one of the builds does not work for you please also try another, and if there's any difference in behavior please detail it in a comment - that way we can try to work out what's different.

[Farnsen]

After testing the builds from itechatmxc, seddonm1 & jmbreuer on my Intel NUC (DC3217IYE), this is what happend to me:

Itechatmxc: VAAPI no longer crashes, but DTS-HD doesnt work anymore seddonm1: VAAPI crashes jmbreuer: VAAPI crashes

Whatever the difference is, i will use itechatmxc's build and disable DTS-HD for the time beeing.

[elbugs]

Guys, I tried jmbreuer build. No DTS-HD. Tried the one from seddonm1 and it works. I have audio, video, all working fantastic.

[itechatmxc]

My pull request was merged into OpenELEC git so now VAAPI playback on IvyBridge should be fine. As for HD audio, alsa-lib now uses another approach so I stopped to use the initial patch in my build. Here is the new image: https://www.dropbox.com/s/bk9bq5k0jjz754w/OpenELEC-Intel.x86_64-devel-20130215101753-r13307.tar.bz2 Enjoy!

[Farnsen]

@itechatmxc

The new build works like a charm. Thanks, much appriciated!