Closed jmbreuer closed 11 years ago
@itechatmxc Just tested and it works for me on the problematic videos on my Intel NUC.
You have also done some stuff with splash screens etc. but if the pull request has been processed then we are on track for OpenElec 3.0.
Can everyone test this one and report back with your hardware spec if it doesn't work?
I've been testing the builds in the chat as well, these are the VAAPI results for my hardware config: itechatmxc build1 (3 feb): crashes (and network issues it seems) seddonm1 build (10 feb): works jmbreuer build (4 feb): works itechatmxc build2 (15 feb): works (but also here I'm having network issues; takes a long time to receive an ip or even somehow crashes my entire network) RC1: works RC2: crashes
For now, I'll keep using RC1
If you are having network problems you should raise a new "Issue" with some HW info, NIC type, logs and so on. Please take into account that my OpenELEC build was builded from git (r13307) with linux kernel kernel 3.7.7 whereas RC2 was builded with 3.7.4 (correct me if I'm wrong) so some of network drivers might be a bit changed. Since my pull request ( https://github.com/OpenELEC/OpenELEC.tv/pull/1910 ) was recently merged, you can easy build your own image from master branch of OpenELEC git and see how it works.
For what it's worth, I've tried RC3 and my issues appear to be gone.
Hi guys, Also confirming Openelec RC3 is working correctly on my Intel NUC i3 (HD4000).
I just tested the BBC Planet Earth 1080p 'birds scene' which did about 40mbit and no dropped frames.
Good work guys and go open source!
For me as well, OpenELEC RC3 works fine for vaapi on the Intel G630.
Somehow I still have network issues (router reboots when I turn off/hibernate the HTPC), but this happens at all other Linux distro's I tried as well. Currently fixed it by putting a switch (actually a spare router with dhcp server turned off) between my router and the HTPC.
@fritsch what do you think?
Please retry version 3.0.2 which disable RC6 by default, which is the culprit here.
Alternatively check a nightly build, e.g.: http://openelec.tv/forum/116-vaapi-intel/64006-vaapi-deinterlacing-testing?limitstart=0
@fritsch isn't this fixed in latest testing already ? closing. @jmbreuer pls ask to reopen if still an issue
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:
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.