Kodi Community Forum
v17 LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Linux (https://forum.kodi.tv/forumdisplay.php?fid=52)
---- Thread: v17 LibreELEC Testbuilds for x86_64 (Kodi 17.0) (/showthread.php?tid=269815)



RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Brian B - 2016-08-09

(2016-08-09, 01:24)n2vwz Wrote:
(2016-08-08, 04:47)Milhouse Wrote:
(2016-08-08, 03:54)n2vwz Wrote: Running Chrome Box. Jumped from #708 to #806. Blacks are too light with 0 - 255 setting. Did anything change that would cause this?
See build #0731.

So, Have the Intel-EGL drivers been totally scrapped? If so, This is a major step backward! The video improvements were dramatic between the Kodi 15/16 builds and the early Alpha 17 builds. Now the video looks like crap again!

The video driver software should be robust enough to recognize Intel graphics or Nvidia graphics and optimize accordingly. Worst case, a check box should be added to the setup menu to select Intel optimization or Nvidia optimization.

What are the future plans?

Yeah, I'm with you. I just don't get this. I'm currently just running an older version, but who knows what I'll be missing in the future...I suppose it would be nice to have an addendum in the first post for the exact process to re-enable for Intel.

B.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - delphiactual - 2016-08-09

Milhouse just provides builds, it is up to the developers to submit a PR that detects intel vs nvidia and then I'm sure we will get our precious intel-egl drivers back.

(2016-08-01, 08:45)Milhouse Wrote:
(2016-08-01, 07:39)atoulmin Wrote: Understand, but why fix something for Nvidia users by screwing over Intel users in the process?

It's not so much fixing anything for Nvidia users, the simple fact is that these Intel patches (in their current form) are not going to be merged so why continue using them in these test builds?

The purpose of these builds is to test changes that *will* be committed upstream. By including commits that are only in these builds and are never merged upstream I could be introducing problems that are not seen in official releases. Or worse, I could be masking problems that are then only seen in official releases once it affects tens of thousands of users.

Yes, I/we realise it sucks to drop these Intel commits. Patches welcome. Smile



RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Milhouse - 2016-08-09

New LibreELEC.tv Krypton build #0808: Generic
(Supercedes previous build)

Code:
# uname -a
Linux NUC 4.7.0 #1 SMP Mon Aug 8 23:15:10 BST 2016 x86_64 GNU/Linux

# lsb_release
LibreELEC (Milhouse) - Version: devel-20160808225133-#0808-gada1c1e [Build #0808]

Based on tip of LibreELEC.tv master (ada1c1ef, changelog) and tip of XBMC master (4a61bf52, changelog) with the following modifications: Build Highlights:
  1. (Clean build)
  2. Minors
  3. Drop PR:10253: [estuary] skin sync - conflict with PR10248 (async PVR startup)
Build Details:
  1. LibreELEC.tv:
    • syncthing: upgrade to 0.14.3 (PR:613, 1 commit, 2 files changed)
    • busybox: Default to UNIVERSE scope, fixes 9141 (PR:615, 1 commit, 1 file changed)
    • addons: clean up (PR:610, 6 commits, 6 files changed)
    • init: Report out of space when unable to extract archive/compressed i… (PR:609, 1 commit, 1 file changed)
    • linux: disable UAS on pi kernels (PR:607, 1 commit, 2 files changed)
    • WeTek_Core:Revised install/update procedure (PR:578, 1 commit, 1 file changed)
  2. XBMC:
    • [depends/win32] Update mini wdk with files from 10.0.14393.0 as (PR:10255, 1 commit, 1 file changed)
    • Add python functions to set and get ratings (PR:10147, 2 commits, 7 files changed)
    • VideoPlayer: rework rtmp options for ffmpeg-demuxer (PR:10251, 1 commit, 2 files changed)
  3. inputstream.mpd:



RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - n2vwz - 2016-08-09

(2016-08-09, 02:20)delphiactual Wrote: Milhouse just provides builds, it is up to the developers to submit a PR that detects intel vs nvidia and then I'm sure we will get our precious intel-egl drivers back.

(2016-08-01, 08:45)Milhouse Wrote:
(2016-08-01, 07:39)atoulmin Wrote: Understand, but why fix something for Nvidia users by screwing over Intel users in the process?

It's not so much fixing anything for Nvidia users, the simple fact is that these Intel patches (in their current form) are not going to be merged so why continue using them in these test builds?

The purpose of these builds is to test changes that *will* be committed upstream. By including commits that are only in these builds and are never merged upstream I could be introducing problems that are not seen in official releases. Or worse, I could be masking problems that are then only seen in official releases once it affects tens of thousands of users.

Yes, I/we realise it sucks to drop these Intel commits. Patches welcome. Smile
If this is the case, then it would seem that "Incorrect Black Levels on Intel Hardware" should be reported as a BUG.

Now, is it a LibreElec/OpenElec BUG or is it a KODI bug? Is the BUG present with Windows or full blown Linux running on the same hardware?

Where is the proper place to report such a BUG?


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - FernetMenta - 2016-08-09

This is no bug, just a missing feature of outputting limited colour range. Set Kodi and TV to full range and your colours will be ok. Or set driver and TV to limited range. The feature you won't get is wtw / btb.
With support of Wayland (maybe v18) this issue will be history.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - n2vwz - 2016-08-09

(2016-08-09, 07:50)FernetMenta Wrote: This is no bug, just a missing feature of outputting limited colour range. Set Kodi and TV to full range and your colours will be ok. Or set driver and TV to limited range. The feature you won't get is wtw / btb.
With support of Wayland (maybe v18) this issue will be history.

KODI / LibreELEC is set to full. This results in Black Levels at 16-255. When KODI is set to Limited, Black Levels are higher ~32-255.

This is considered a BUG. The KODI Full setting does not work correctly on Intel Hardware (Chromebox & NUC).


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - fritsch - 2016-08-09

You are wrong ... and you don't have an idea what you are talking about. It's the driver that messes things up.

But the explanation is not that easy, so I will forgive you :-) ... in short: Intel kernel / xorg has two modes:

A) Full: Don't clamp anything let 0 .. 255 through and signal the TV that it is full
B) Limited 16:235: Clamp (!) everything, by scaling it to 16:235 - cause it is assumed that input is Full Range. Signal the TV to be limited.

Obvious problems:
A)
1) the TV gets signalled FULL with the info frames and might switch to full (!) - if this is the case the only thing from kodi that helps is: Use Limited Range: off Dithering: 8 bit
2) The TV ignores the infoframe and stays "Limited" itself. Then you can tell kodi: "Use Limited Range", cause the TV will blindly ignore 236 to 255 and 0 to 15 and kodi only outputs 16:235 - which means: original video content without touching colors. Pictures which are full range on the other side, are downscaled by kodi

B)
1) If you tick Use Limited in Kodi, kodi will output 16:235 only, but NOW the driver downscales again and you end up with no blacks and no whites at all. <- You now get _why_ the setting "works" as it works?
2) In that mode (which btw. is _the_ _default_ driver mode) the only thing that helps in kodi is "unticking" Use Limited Range, and also enabling Dithering 8 bit - every content (video) is now upscaled to full range _and_ afterwards downscaled by the GPU itself again.

Now - the sane reader has the questions:
Why isn't there a "Just output what i put in without messing and honoring the Limited Range that _most_ TVs are anyways"?

Answer: There is. I implemented a kernel patch that use the famous: "Video Range 16:235" without touching anything. How does it do this?

- Signal Limited in the info frames (which most TVs are and all video content also is)
- Don't touch the colors that are input

This patch _is_ in OpenELEC since several months. And until the patch, which btw. only enabled this on Intel hardware, was dropped - the kernel automatically was in the correct mode. The only thing the user had to do was:
Tick "Use Limited Range" to on, if the TV is in Limited Range. Or tick it "Off" - if not.

As most TVs are in limited Range by default - I ticked that setting "default" to on. In that combination most intel users had a perfect setup out of the box.

Issues with that approach:
- Nvidia users would have had "Use Limited Range" by default, too .... which is not what they wanted

So, what is missing:
- A simple LibreElec / OpenELEC integration patch that toggles the "Use Limited Setting" dependend on:
a) Is the Video Range 16:235 mode used?
b) Did the user disable it by self and we should not automatically set it.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - _Spook_ - 2016-08-09

But this patch (autostart.sh) re-enables that on intel again, right?

https://github.com/MilhouseVH/LibreELEC.tv/blob/3c2175510bb494bc37eab2d5fa360f4633899d84/projects/Generic/filesystem/usr/bin/intel-fullrange.sh


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - neox387 - 2016-08-09

Question about pixel ratio:

Long time ago still on openelec builds, something changed and I have some weird problem with pixel ratio..

in settings - system - display -> video calibration, pixel ratio adjustment is at 1.000, when measured this is a square.

however video playback 1920x1080p 23.976, I need to put it on zoom amount 1 - pixel ratio 0.75 for a normal picture ?

but then .. anything other then 23.976 goes to almost a 4:3 ratio, & I need to put it on zoom amount 1 - pixel ratio 0.92 Huh? :/


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Roby77 - 2016-08-09

So for newbie like me #731 build is the best to achieve best video quality ?


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - _Spook_ - 2016-08-09

(2016-08-09, 18:18)Roby77 Wrote: So for newbie like me #731 build is the best to achieve best video quality ?

Or just implement the patch I linked to.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - n2vwz - 2016-08-09

(2016-08-09, 18:51)_Spook_ Wrote:
(2016-08-09, 18:18)Roby77 Wrote: So for newbie like me #731 build is the best to achieve best video quality ?

Or just implement the patch I linked to.

Does the patch get blown away every time an update is performed?


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - n2vwz - 2016-08-09

(2016-08-09, 18:18)Roby77 Wrote: So for newbie like me #731 build is the best to achieve best video quality ?

You would want Build 730. The Black Level problem started with Build 731.


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - Roby77 - 2016-08-09

(2016-08-09, 19:48)n2vwz Wrote:
(2016-08-09, 18:18)Roby77 Wrote: So for newbie like me #731 build is the best to achieve best video quality ?

You would want Build 730. The Black Level problem started with Build 731.

Thank you


RE: LibreELEC Testbuilds for x86_64 (Kodi 17.0) - fritsch - 2016-08-09

(2016-08-09, 10:59)_Spook_ Wrote: But this patch (autostart.sh) re-enables that on intel again, right?

https://github.com/MilhouseVH/LibreELEC.tv/blob/3c2175510bb494bc37eab2d5fa360f4633899d84/projects/Generic/filesystem/usr/bin/intel-fullrange.sh
Exactly... in combination with the use limited setting.