[Sunflux]

Drop out for a month, and tons of stuff happens! Going to try the Chromebox Isengard build.

[fritsch]

Read the Readme.txt that I added.

[Sunflux]

Heh, edited my post because I saw that right after I posted! DOH! You're too quick!

EDIT: Hmm. The last build I had (October 10th I think?) was working correctly without the manual HDMI off/on hack. This build does not work like that - everything comes up in too-bright limited mode until I change refresh rates. Back to the hack I guess!

[Sunflux]

Wowsers, 97 is NOT working well for me. First, suddenly it's outputting 36-bit color depth for whatever reason. Second, you know that high-bitrate test file I used to break VAAPI with fast seeking? Well, with VAAPI enabled I don't even get a picture. Just a black screen, about 10 seconds of sound, and a counter that doesn't tick up.

I wasn't in debug mode, but the log captured this:

http://paste.ubuntu.com/13225439/

[fritsch]

@Sunflux, concerning the "bright image": https://github.com/fritsch/OpenELEC.tv/c...5f35f785ee

Code:

touch /storage/.config/forcedisplay

should be enough to simulate this behaviour. Yeah - also test "the .96" build - but it should have the very same issue with your ffwd ... .95 should work fine again.

[Sunflux]

Just tried the 96 build... exact same behavior. Why is it outputting 36-bit now? And I'm not doing any fast-forwarding... I'm literally just hitting play and getting a black screen followed by nastiness.

I'll try 95.

[VirtualRain]

The official OpenELEC version from www.openelec.tv is in no way to be compared / confused with the version in this thread.

The builds posted here, use:

"Passthrough 16:235" Mode by default in combination with kodi's Limited Range Setting. All Video colors are transfered untouched to the TV, which should be Limited Range. All Pictures are scaled to 16:235 range within kodi and then output without further scaling. To add, if you disable "Use Limited Range" in this kodi version, the Video data is expanded to 0..255 and banding is cared for by adding dithering. Pictures and menu are output as full rgb (0..255) and not touched. If your TV is limited range - disabling that "Use Limited range" setting makes kodi look much too dark. If your TV is full range - it should look okay - as our kernel mode does not interfer, it just lets everything you set out onto the display.

Official OE release uses:
A fucked up mode, called "Limited 16:235" - where the driver rescales everything it gets to 16:235 by its own while it is assuming full range input (!). So it is perfectly clear, that when you enable "Use Limited Range in kodi", that kodi scales to 16:235 but then _the driver_ does that again ... you end up with a super bright menus. For the Video output of VAAPI that does not count - as this nightmare code has blown up the Limited to full range by itself while the surfaces were copied. (Read the first post, please).

If you run the ubuntu tutorial version without a "Passthrough 16:235" kernel - you should set the kernel to Full Range and then use kodi's setting to choose the Range as described in the first post.

In short:
Official OpenELEC should not be used if you care a single bit about colors ...

This is a good summary, and should go into post #1 or #2.

BTW, there is a third alternative for effective passthrough which can work for some folks using the Official OE... (Works for me on good old OE 5)... Set Kodi Limited, disable VAAPI rendering, force the driver (xrandr) Full at startup, and set your TV to Limited.

[Sunflux]

Okay, 95 is working MUCH better. The video plays fine, and so far I've been unable to break it through seeking. Still... without range conversion going on, 12-bit/36-bit output does not do anything but create a higher bandwidth image. I've checked the bars on my greyscale chart, and there's no smoothing or anything going on, so no benefit over 8-bit/24-bit.

BTW, there is a third alternative for effective passthrough which can work for some folks using the Official OE... (Works for me on good old OE 5)... Set Kodi Limited, disable VAAPI rendering, force the driver (xrandr) Full at startup, and set your TV to Limited.

Main issue with that workaround is you need to be able to force your TV into limited mode, as auto detection will think the signal is full-range. This gets around that. Secondary issue is without VAAPI, CPU usage is higher.

[fritsch]

The official OpenELEC version from www.openelec.tv is in no way to be compared / confused with the version in this thread.

The builds posted here, use:

"Passthrough 16:235" Mode by default in combination with kodi's Limited Range Setting. All Video colors are transfered untouched to the TV, which should be Limited Range. All Pictures are scaled to 16:235 range within kodi and then output without further scaling. To add, if you disable "Use Limited Range" in this kodi version, the Video data is expanded to 0..255 and banding is cared for by adding dithering. Pictures and menu are output as full rgb (0..255) and not touched. If your TV is limited range - disabling that "Use Limited range" setting makes kodi look much too dark. If your TV is full range - it should look okay - as our kernel mode does not interfer, it just lets everything you set out onto the display.

Official OE release uses:
A fucked up mode, called "Limited 16:235" - where the driver rescales everything it gets to 16:235 by its own while it is assuming full range input (!). So it is perfectly clear, that when you enable "Use Limited Range in kodi", that kodi scales to 16:235 but then _the driver_ does that again ... you end up with a super bright menus. For the Video output of VAAPI that does not count - as this nightmare code has blown up the Limited to full range by itself while the surfaces were copied. (Read the first post, please).

If you run the ubuntu tutorial version without a "Passthrough 16:235" kernel - you should set the kernel to Full Range and then use kodi's setting to choose the Range as described in the first post.

In short:
Official OpenELEC should not be used if you care a single bit about colors ...

This is a good summary, and should go into post #1 or #2.

BTW, there is a third alternative for effective passthrough which can work for some folks using the Official OE... (Works for me on good old OE 5)... Set Kodi Limited, disable VAAPI rendering, force the driver (xrandr) Full at startup, and set your TV to Limited.

Won't work the very moment you use VAAPI's deinterlacing and also not with surfaces > 1920 x 1088.

[Sunflux]

Version 95 seems to be working better than any prior VAAPI implementation I've tried (96/97 is definitely broken for me), however I still find VAAPI has some glitches... like, when seeking, there's often a half-second of corruption in part of the picture when playback resumes (same on Jarvis), and when fast-forwarding on high-bitrate remuxed BD rips, the picture repeatedly breaks up/becomes garbled even at 2X speed, while CPU rendering can maintain flawless smooth motion up to 8X, and even beyond that when it begins to lurch a bit, it never breaks up.

[fritsch]

As the guy, that screams loudest seems to win :-) - I reverted that patch and will rebuild when I get home to release now - a really final 6.0.98 version ... after that I really stop caring ... https://github.com/fritsch/OpenELEC.tv/commits/EGL

[Sunflux]

Well... don't do it just for me! So long as VAAPI continues to have the [relatively minor] seek/ffwd corruption issue (and if 95 has it, I suspect 98 will have it too)... I think I'll still be running with it turned off.

Although, I guess anyone who wants to use 96/97 will be well served with a fix!

Any idea what causes all these getbuffer errors, only with VAAPI? Is it the kind of thing that will be fixed in Jarvis, or is it a VAAPI architecture issue?

[fritsch]

In fact - you are the only one with issues with 96/97 for now :-) Jarvis uses the very same code in that regard. So you should have the very same issue running this version.

Fixes can only be done with proper Debug Log. FFWD is a minor both fernet and me consider absolutely not useful as we both don't use it - we rather skip forth and back.

[Sunflux]

I would normally agree with you on fast forward - digital media players have always had awful fast forward performance (sometimes even locking up or crashing), to the point that I've conditioned myself to never use it. But, it's really quite good on Kodi (when it works), like a 30gb MKV played over the network can fast-forward at 8X with totally smooth and fluid motion on a Chromebox!

But yes, I'm more inclined to skip as well - but I see the corruption when skipping, too. Normally it's like the first decoded frame doesn't have all the necessary data, and part of the image will be corrupted or offset, and this eventually corrects in a half second or so. Happens maybe 40-60% of the time. Doesn't happen at all with CPU rendering, though.

[Manic D]

Still getting dots and lines across the screen. Here's a log after I rebooted & played two short videos. Dots and lines appeared during playback of the second video.

http://xbmclogs.com/p7v4ukzre