• 1
  • 104
  • 105
  • 106(current)
  • 107
  • 108
  • 342
Intel VAAPI howto with Leia v18 nightly based on Ubuntu 18.04 server
(2015-10-09, 17:58)briancl Wrote: I am using a video test pattern to count bars. It's pretty easy to see the different because they are either flashing or not.

I have nothing in my autostart.sh.. what should I be using?

Assuming your PC is outputting on HDMI1, you need to add

Code:
xrandr --output HDMI1 --off; xrandr --output HDMI1 --auto

to your autostart.sh for passthrough to work correctly. This won't harm other settings.

Incidentally... you state you have nothing in your autostart.sh... are you setting your xrandr setting via SSH or something? Because that does NOT work correctly for passthrough mode. It's doesn't reset the display correctly, and thus doesn't take effect until you change refresh rates.

Otherwise, your color range setting should ALWAYS be in autostart.sh, for example

Code:
xrandr --output HDMI1 --set "Broadcast RGB" "Video 16:235 pass-through"
xrandr --output HDMI1 --off; xrandr --output HDMI1 --auto
Reply
(2015-10-09, 18:06)Sunflux Wrote:
(2015-10-09, 17:58)briancl Wrote: I am using a video test pattern to count bars. It's pretty easy to see the different because they are either flashing or not.

I have nothing in my autostart.sh.. what should I be using?

Assuming your PC is outputting on HDMI1, you need to add

Code:
xrandr --output HDMI1 --off; xrandr --output HDMI1 --auto

to your autostart.sh for passthrough to work correctly. This won't harm other settings.

Incidentally... you state you have nothing in your autostart.sh... are you setting your xrandr setting via SSH or something? Because that does NOT work correctly for passthrough mode. It's doesn't reset the display correctly, and thus doesn't take effect until you change refresh rates.

Otherwise, your color range setting should ALWAYS be in autostart.sh, for example

Code:
xrandr --output HDMI1 --set "Broadcast RGB" "Video 16:235 pass-through"
xrandr --output HDMI1 --off; xrandr --output HDMI1 --auto

I am setting via SSH... I will go back and try the testing again with setting color range in autostart.sh.

Thanks!
Reply
The workaround also is in my Jarvis builds ... nothing to do.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
Okay.. so this time I used the following syntax between each color range setting and ensured the refresh rate changed by stopping/starting black bar video.

Code:
xrandr --output HDMI1 --off; xrandr --output HDMI1 --auto

The results are slightly different. It is still not making sense to me and no clear winner of a setting. The big question I have is why do I see black bars flashing below 16 when the driver is set to limited or passthrough? That is odd.

Code:
xrandr          kodi            lowest  banding         comments
                                black
----------------------------------------------------------------
full            limited         12      high            blacks look okay, but bars below 17 flash
full            full            30      high            black crush. no detail in shadows
limited         limited         0       low             blacks all the way to 0
limited         full            18      low             looks good, but cant get 16 or 17 black bar to flash
pass            limited         12      low             looks good, but bars flash down to 12
pass            full            30      low             black crush. no detail in shadow
Reply
Driver limited: all content no matter what range is rescaled.
Driver pasdthrough: limited is signalled and video colors are untouched when! kodi is set to limited range.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
(2015-10-09, 18:34)fritsch Wrote: The workaround also is in my Jarvis builds ... nothing to do.

You said the exact opposite a few days ago... hard to keep track when nothing's announced! :-)


(2015-10-09, 18:50)briancl Wrote: Okay.. so this time I used the following syntax between each color range setting and ensured the refresh rate changed by stopping/starting black bar video.

Code:
xrandr --output HDMI1 --off; xrandr --output HDMI1 --auto

The results are slightly different. It is still not making sense to me and no clear winner of a setting. The big question I have is why do I see black bars flashing below 16 when the driver is set to limited or passthrough? That is odd.

Code:
xrandr          kodi            lowest  banding         comments
                                black
----------------------------------------------------------------
full            limited         12      high            blacks look okay, but bars below 17 flash
full            full            30      high            black crush. no detail in shadows
limited         limited         0       low             blacks all the way to 0
limited         full            18      low             looks good, but cant get 16 or 17 black bar to flash
pass            limited         12      low             looks good, but bars flash down to 12
pass            full            30      low             black crush. no detail in shadow

Okay... any banding you see in passthrough mode is going to be from your projector (or the test pattern), and not Kodi.

However, I am still mystified as to why the Kodi internal "Use Limited" setting is affecting the range of video output. Can you answer that one, Fritsch?

I would take Passthrough and Limited and adjust your projector's contrast/brightness until the values show as correct. When in "Full" mode (which is what Passthrough is using) all data below 16 is being sent, and it's up to your display device to only show the correct ones. It's normal for adjusting the contrast/brightness to reveal "blacker than black".or "super white". That's a part of proper calibration.
Reply
(2015-10-09, 19:00)Sunflux Wrote:
(2015-10-09, 18:34)fritsch Wrote: The workaround also is in my Jarvis builds ... nothing to do.

You said the exact opposite a few days ago... hard to keep track when nothing's announced! :-)


(2015-10-09, 18:50)briancl Wrote: Okay.. so this time I used the following syntax between each color range setting and ensured the refresh rate changed by stopping/starting black bar video.

Code:
xrandr --output HDMI1 --off; xrandr --output HDMI1 --auto

The results are slightly different. It is still not making sense to me and no clear winner of a setting. The big question I have is why do I see black bars flashing below 16 when the driver is set to limited or passthrough? That is odd.

Code:
xrandr          kodi            lowest  banding         comments
                                black
----------------------------------------------------------------
full            limited         12      high            blacks look okay, but bars below 17 flash
full            full            30      high            black crush. no detail in shadows
limited         limited         0       low             blacks all the way to 0
limited         full            18      low             looks good, but cant get 16 or 17 black bar to flash
pass            limited         12      low             looks good, but bars flash down to 12
pass            full            30      low             black crush. no detail in shadow

Okay... any banding you see in passthrough mode is going to be from your projector (or the test pattern), and not Kodi.

However, I am still mystified as to why the Kodi internal "Use Limited" setting is affecting the range of video output. Can you answer that one, Fritsch?

I would take Passthrough and Limited and adjust your projector's contrast/brightness until the values show as correct. When in "Full" mode (which is what Passthrough is using) all data below 16 is being sent, and it's up to your display device to only show the correct ones. It's normal for adjusting the contrast/brightness to reveal "blacker than black".or "super white". That's a part of proper calibration.
As the workaround worked I added it to Jarvis, too. See my post from a week ago.

Answer: when limited in kodi is not ticked the display shader upscales to full range when doing nv12 to rgb. No need to touch it twice.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
Okay.. sounds reasonable... I'll go with Passthrough with Limited.

Thanks for the help.. I appreciate it.
Reply
Okay, I thought I had read somewhere that the in-kodi setting didn't affect video rendering, but now I'm thinking that's only if VAAPI is disabled.

In which case, I would definitely suggest that briancl work at calibrating the passthrough/limited option to see if it can be made acceptable.

As for the workaround, I was still going off this!

(2015-10-04, 22:00)fritsch Wrote: I added sunflux workaround to the Isengard build only .... for Jarvis you need autostart.sh workarounds.
Reply
(2015-10-09, 19:14)Sunflux Wrote: Okay, I thought I had read somewhere that the in-kodi setting didn't affect video rendering, but now I'm thinking that's only if VAAPI is disabled.

In which case, I would definitely suggest that briancl work at calibrating the passthrough/limited option to see if it can be made acceptable.

As for the workaround, I was still going off this!

(2015-10-04, 22:00)fritsch Wrote: I added sunflux workaround to the Isengard build only .... for Jarvis you need autostart.sh workarounds.

Everything you read before this thread's code is most likely wrong. See my suggested settings some pages ago :-)

This setting is a critical one. Directly hooks in after decode. Without it ticked everything is upscaled for vaapi and sw decode. Even vdpau uses it under a different name.

Valid for this code in this thread.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
(2015-10-02, 22:45)lexi81 Wrote:
(2015-10-02, 22:14)fritsch Wrote:
(2015-10-02, 11:45)Sunflux Wrote: Just in case you were wondering, here's a stress test log with VAAPI render disabled. Certainly not problem-free, but the system didn't crash and video was still playing fine when I rebooted.

http://paste.ubuntu.com/12637308/

It looks good. Fernet found a bug that could have caused the "mem leak". The EGLContext was not destroyed and probably all allocated surfaces would remain unfreed: https://github.com/FernetMenta/xbmc/comm...65734453c7

I will be travelling until Sunday ... so don't expect any new build until then.

When I run Kodi in limited 16-235 mode I can easily lock Kodi. The skin doesn't rebuild totally and I have to reboot through JSON. Is that related to the mem leak fix? It doesn't happen when I run Kodi in full configuration.

Log: http://xbmclogs.com/purnggoap

The log wil show I'm running Arctic Zephyr, but it happens with Confluence as well. Depending on the amount of video or sequence of videos, I get garbled video like the YouTube video above or the skin artefacts.

Video: https://youtu.be/2coGdXzwZ9Q

(don't mind the black levels, that's the camera playing tricks Wink)

Fritsch, did that debug log give you any info. Or do you need a new one with a new build?
My XBMC / Kodi history.
XBMC for XBOX -> XBMC for Windows -> XBMC for Android -> Kodi for Android - > Kodi v16 OE (Amlogic) -> Kodi v17 LE (NUC 2x) -> Kodi v18.5 LE (NUC 2x)
Reply
Limited Range just replaces the shader. It's even less it uses the same shader but with other coefficients.

As you run the old nightmare sandybridge based Celeron 847 which gets hot like hell - check the temperatures, please.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
I'm running the older fritsch OpenElec build: r21263
Am I missing anything with this latest test build? should I update?
Reply
Starting to have some issues with my install from the old 14.04 thread.

Considering doing a reinstall using this new method

Is the OP post still pretty reasonable to follow, or do I need to read through over a hundred forum pages of incremental changes to get to the latest best practice?

Thanks,
Matt
Livingroom: 65" Panasonic Plasma, Denon AVR-x3300w, Parasound A31, Fronts: RBH SX-6300 Towers, Center: RBH 441-se, Surrounds: RBH 41-se Sub: Dual SVS PC13-Ultra, Source: Custom Kodi Box
Desk: DAC: Schiit Modi Multibit,Headphones: Schiit Jotunheim -> Sennheiser HD650 & Beyerdynamic DT770 Pro, Speakers: Parasound 275v2-> RBH 41-se & SVS SB12-NSD
Reply
Starting to have some issues with my install from the old 14.04 thread.

Considering doing a reinstall using this new method

Is the OP post still pretty reasonable to follow, or do I need to read through over a hundred forum pages of incremental changes to get to the latest best practice?

Thanks,
Matt
Livingroom: 65" Panasonic Plasma, Denon AVR-x3300w, Parasound A31, Fronts: RBH SX-6300 Towers, Center: RBH 441-se, Surrounds: RBH 41-se Sub: Dual SVS PC13-Ultra, Source: Custom Kodi Box
Desk: DAC: Schiit Modi Multibit,Headphones: Schiit Jotunheim -> Sennheiser HD650 & Beyerdynamic DT770 Pro, Speakers: Parasound 275v2-> RBH 41-se & SVS SB12-NSD
Reply
  • 1
  • 104
  • 105
  • 106(current)
  • 107
  • 108
  • 342

Logout Mark Read Team Forum Stats Members Help
Intel VAAPI howto with Leia v18 nightly based on Ubuntu 18.04 server18