[fritsch]

I think we need a section about "How to setup your TV". As this has - as you also pointed out - nothing to do with EGL / VAAPI anymore. It has been proven that this new method of colors processing and surface transfering is able to properly transfer colors.

Anyone with TV issues feel free to open a Thread in the Hardware Forum. I will link to it in the first post.

[Sunflux]

Yeah, I'm not seeing anything that's messing up colors in any way. Although, I still think the video drivers need to be hacked to allow a "Limited 16:235" mode that does NOT actually compress RGB, and instead outputs what its fed as-is.

[fritsch]

Yeah - the problem here is: what should happen if you quit Kodi and open A desktop application? Should the driver "clamp"? should it say < 16 and > 235 is SuperWhite?

Edit: Here is a kernel starting point: https://bugzilla.kernel.org/show_bug.cgi?id=55121

[Sunflux]

I guess that depends on how the range conversion process works now. Currently, I know xrandr resets the signal when going from full to limited, but I don't know if that's something necessitude by the process of enabling/disabling range conversion, or whether that's just a result of toggling the limited flag on/off which causes the TV to adjust itself.

If the latter, and range conversion could be enabled/disabled on the fly for at least "range aware" full-screen applications, then I would say that switching from Kodi back to the desktop should definitely return to compressing 0-255 as 16-235 as default. So, for example, have a desktop where 0-255 is automatically compressed as 16-235, and a "range aware" application where 0-255 remains as such. Seems like similar capabilities exist for hardware-accelerated video playback, where the video playback overlay can have entirely different color properties from everything else.

If that's impossible, and the only option would be to continue to crush blacks on the desktop, then I still say this feature would be useful for standalone media boxes like OpenElec, where there is no desktop to worry about, and the priority is providing a top-notch media experience.

[fritsch]

Here: have a look:

https://github.com/torvalds/linux/blob/m...dmi.c#L449

[fritsch]

As a hack: https://github.com/torvalds/linux/blob/m...ay.c#L8576

Just remove this and also further down.

[fritsch]

I started talking with the Intel folks:

09:57 < fritsch> vsyrjala: ping - you got another minute?
09:58 < fritsch> vsyrjala: https://bugs.freedesktop.org/show_bug.cgi?id=71769
09:58 < j4ni> fritsch: vsyrjala hasn't showed up at the office yet
09:58 < fritsch> j4ni: no hurry - it's for the backlog
09:58 < j4ni> yup
09:58 < fritsch> j4ni: you are also familiar with Limited vs Full Range?
09:59 < j4ni> fritsch: a little, but I'll happily defer that to vsyrjala
09:59 < fritsch> j4ni: vsyrjala use case: Kodi: Decode h264 to NV12 -> Limited RGB -> output on a Limited
Range TV with intel driver set to limited range
09:59 < fritsch> j4ni: vsyrjala problem: intel driver scales the colors again :-( so you end up with 24 ->
215
09:59 < fritsch> j4ni: vsyrjala workaround: Set intel to FULL range via xrandr and hope the TV does not read
the info frame and force it to Full Range
10:00 < fritsch> j4ni: vsyrjala Idea: "Limited 16:235" "Full" and "Passthrough" -> just let everything we
send go out as is, e.g. don't clamp / scale RGB ranges
10:00 < j4ni> oh I thought this was related to https://bugzilla.kernel.org/show_bug.cgi?id=105261
10:00 < fritsch> nope
10:00 < fritsch> no crash - just a question for best practice
10:01 < fritsch> how can we present Limited Range Video Data on a Limited Range screen without that this:
10:01 < fritsch> https://github.com/torvalds/linux/blob/m...ay.c#L8600
10:01 < danvet> airlied, ok I think I got them all
10:01 < fritsch> happens

So let's see.

Yeah - they exactly see the issue :-)

10:03 < daniels> fritsch: right, the problem is that intel narrows again, right? as there's no way to tell
it that the input data source is already clamped
10:04 < fritsch> daniels: exactly .-)
10:04 < daniels> fritsch: tbh i'd probably just put a modifier on the drm format
10:04 < fritsch> therefore I suggested this "passthrough" mode - cause new TVs actually read the info frame
10:04 < daniels> aye
10:05 < fritsch> and that means: for a "info frame" aware TV the only way to get out "a good gray ramp" is
to scale to 0..255 with dithering
10:05 < fritsch> from the kernel code - the passsthrough mode is "just" 20 lines, mainly if (! ...)
10:05 < fritsch> but "just" changes will degrade architecture :-)
10:05 < daniels> yeah, i know exactly the problem
10:05 < daniels> but it looks like slightly the wrong place to solve it
10:06 < fritsch> not sure - drm means: every video player needs to be adjusted
10:06 < daniels> really what you care about is the combination of the output mode (whether it claims limited
range), and the input _buffer_
10:06 < fritsch> but I admit: kernel would be a workaround
10:06 < daniels> every video player that uses drm directly, sure
10:06 < daniels> the ones that don't can rely on their wayland compositor or x11 driver to dtrt
10:06 < fritsch> kodi for example uses OpenGL for presentation
10:06 < daniels> gutted

[Sunflux]

Wait a minute, is that the ENTIRE thing? Comment out that calculation and limited mode gets outputted as full mode?

I'd love if that could be turned into a toggleable setting that could be enabled/disabled inside OpenElec, as my primary viewing TV can't be forced into limited mode.

[Sunflux]

"hope the TV does not read the info frame and force it to Full Range" -> exactly what needs to be worked around. We want the correct info frame so that televisions can operate properly, while sending 0-255 untouched.

[fritsch]

Yeah - that's exactly the problem.

Short term workaround, add a "passthrough" mode - that just skips the conversion, but still sends info frame limited :-)

What daniels wants: DRM buffers that have a color attribute and then intel handles it internally accordingly, which is - i have to admit the "king way" of doing things. But DRM / MESA is not there yet and kernel is also not.

So - let's come up with a passthrough kernel patch.

Who is up for the task?

1.) add passthrough
2.) add passsthrough_mode bool
3.) check for passthrough_mode -> don't clamp.
4.) add this attribute to the list where you find Full and "Limited 16:235"
5.) Passthrough should force "Limited 16:235" but not to scale :-)

@Sunflux: Sounds like a job for you, isn't it?

[Sunflux]

LOL, you keep trying that, but I still don't know C++! Nor, frankly, much about 'nix-style O/Ss or anything close to the complexity of kernel code. My experience is limited to good ol' Perl programming for web applications, which is basically not useful for anything.

[fritsch]

Yeah - I will take a look tonight :-)

[Hufvudet]

Yeah - I will take a look tonight :-)

I'll fix it over lunch!

My knowledge of computers is limited to turning on and off iPads and annoying fritsch in forums.

[lmyllari]

I have an old patch here: https://github.com/laurimyllari/OpenELEC...8b603144aa

[sat4all]

talking of annoying fritsch
As you know, since my upgrade to jarvis egl builds i've been struggling with a/v sync issues. so today i've decide to do a hard reset, unfortunately nothing changed. it's even worst using 28/9 build especially with some files ( most of them with ac3 track )
Starting playback results heavy skipped and dropped frames ( drop:13, skip:21 ) = a/v out of sync by arround 3s ( av: -2.xxx )
a rewind immediatly fix sync ( a/v: 0.0xx )
playing the same files with isengard build = no problems

debug log