[noggin]

Hi all

Trying to get an installation working with both HD Audio bitstreaming and 16-235 levelspace (i.e. standard TV-friendly HDMI) with an Intel G630.

Any hints? Looks like both require some kernel patching (though the HD Audio may be in kernels >3.7?)

If anyone has got this working - would be great to know how. Am happy to do stuff in the command line - and have compiled from sources before - just not that experienced in patching and compiling kernel stuff.

Latest OpenElec build seems to do HD Audio - but doesn't have the Intel driver patches to allow xrandr to set 16-235 Broadcast levels? As a result I end up with video expanded to the 0-255 levelspace. As I'm routing through an AV Amp alongside other sources (Blu-ray player, Satellite receiver etc.) I need 16-235 levels - I can't recalibrate.

A kind XBMC user has sent me links to a patched kernel that allows xrandr to set 16-235 Broadcast levels, but I can't make this do HD Audio.

Be great to get some input on this.

[fritsch]

We have those patches and also provide a simple script to make it usable without problems: https://github.com/OpenELEC/OpenELEC.tv/...635806404c

[noggin]

We have those patches and also provide a simple script to make it usable without problems: https://github.com/OpenELEC/OpenELEC.tv/...635806404c

Great news. How do I go about installing / building them - and where is the script?

[noggin]

Right - after some very helpful advice in the OpenElec IRC I've managed to use the set-intel-color-space limited and set-intel-color-space full scripts - but they don't appear to do quite what I thought they would?

AIUI set-intel-color-space limited should set OpenElec up such that it feeds a Limited range display - one where black is at digital 16 and white is at digital 235, and set-intel-color-space full should set OpenElec up such that it feeds a Full range display - one where black is at digital 0 and white is at digital 255?

That's not what I see though. set-intel-color-space full gives a very set-up black level, much higher than digital 16 (let alone digital 0) It looks like it is doing the opposite of what it should?

Thinking about a standard 4:2:0 MPEG2 or H264 video from a DVD, Blu-ray or DVB broadcast - which will have studio (aka limited) levels.

Source MPEG2/H264 video is in 16-235 levelspace (as used by ITU 601 or 709). Black is at 16, White is at 235.
My understanding is that XBMC decodes this, and remaps the 16-235 -> 0-255 internally (clipping any content <16 or >235 - which could make PLUGE tricky ?)
For a Full range display, then nothing else needs to happen - the 0-255 remapped video is now in the correct levelspace. Black is 0, White is 255.
For a Limited range display the 0-255 video needs to be mapped back to 16->235 levelspace, otherwise you end up with crushed blacks and overblown whites. You need black to be back at 16 and white at 235.

So - for Limited you'd expect black picture content to be at 16, and white at 235, and for Full you'd expect black at 0 and white at 255. However the scripts deliver something very different to that for Full range. Black appears to be much higher than 16.

On my Limited range display - calibrated for black at 16, broadcast video looks a bit black crushed with the Limited script (haven't had time to do proper analysis with PLUGE yet) However with the Full script, blacks are much higher (not lower and even more crushed as you'd expect) and appear to be much higher than 16 (i.e. very grey and washed out)

What am I missing?

[fritsch]

Ouuutsch :-)
look again at the script.

You can discuss with us, here: https://github.com/OpenELEC/OpenELEC.tv/...nt-2683125

[fritsch]

I am reading the register docu again.

[noggin]

There does seem to be an annoying, and fundamental, issue with XBMC though. If it remaps 16-235 to 0-255, that means it will crush <16 and clip >235 content - which is a pain if you are using standard test signals like PLUGE for lining up your display. It's difficult though - because there is no right answer to a single level-space.

Have joined the discussion!

[Drae]

Why not just take the kernel patch(es) developed by Ville Syrjala and attached to the bug report I made? With that you don't need to mess with the registers because it hooks everything up internally. You can then set via xrandr or use the default auto mode (which unfortunately fails for non-integer refresh rates) - the auto mode isn't in the patch attached to the report, you can grab the whole patch series from the intel-gfx mailing list (or Ville's repo - or the 3.9 kernel to which its set to be included afaik).

[fritsch]

We are not sure it solves the issue as we see it, that is the whole problem here. And kernel patches involve recompiling and using non distribution kernels.

As you can see on OE github, noggin has pointed out some issues, that are of a more general nature.
The non working full rgb with 23.976 issue is in deed a show stopper, as this is exactly the refresh rate you really want to have correct colors.

[noggin]

Hmm. Have posted some observations to the Github but repeating here. Compared the output of a standard black level test signal played on a Popcorn Hour in Full 0-255 and Limited 16-235 mode. (And calibrated my display for both Full and Limited levelspace)

Currently OpenElec appears to do the following :

OpenElec "Limited" is actually normal "Full" levelspace. Standard broadcast levels 16-235 in a source file are output at 0-255 - i.e. in Full Mode. (Exactly the same as the Popcorn Hour in 0-255 mode) In this mode, normal video content replayed on a standard HDMI HDTV in Limited Mode appears black crushed (detail lost in blacks)

OpenElec "Full" is actually even more Limited than Limited... Standard broadcast black level at 16 is output at massively higher than 16 (32 possibly?) - so on a limited display things are very washed out (because of raised black levels). On a full display things are even more washed out! I can't see any use for this mode. (In fact this is giving me flashbacks to the longstanding Windows Media Center bug where 16-235 video was similarly badly set-up - and ISTR ATI cards required the BT601CSC registry hack)

The two modes should do the following :

Limited (16-235) : Ensure source 16 is output as 16, ensure source 235 is output at 235. If XBMC resamples 16-235 to 0-255 internally, then the Intel output stage needs to reverse this by remapping 0 to 16 and 255 to 235. (This will mean that <16 and >235 content is clipped away - but this is the lesser of two evils)

Full (0-255) : Ensure that source 16 is output as 0, ensure source 235 is output at 255 (*) If XBMC resamples 16-235 to 0-255 internally then the Intel output stage needs to do nothing more than pass the remapped video straight through.

(*) 0 and 255 may be reserved levels and instead 1-254 used. In ITU 601 level video 0 and 255 are reserved for SAV and EAV (Start and End of Active Video) signalling and only 1-15 carry sub-black and 236-254 carry super-white information.

[Drae]

We are not sure it solves the issue as we see it, that is the whole problem here. And kernel patches involve recompiling and using non distribution kernels.

As you can see on OE github, noggin has pointed out some issues, that are of a more general nature.
The non working full rgb with 23.976 issue is in deed a show stopper, as this is exactly the refresh rate you really want to have correct colors.

I guess I'm not seeing the same issue (I'm the one who submitted the bug report to Intel btw if that wasn't clear - and thus have been involved in its testing/discovery). You don't need to mess with setting the registers with the (even the basic) patch applied. Indeed setting the registers as mentioned in that bug report (for me at least) was just to "test" whether the driver still contained the necessary "inner workings" to even switch full range/limited. It fails to retain the setting on a res change (it basically goes super bright requiring one of the registers to be reset). Hence the development of this patch - which doesn't suffer that issue and works across refresh rate changes. For me it now behaves identically with the nvidia drivers.

To add, I didn't mean to suggest the patches don't work with 23.976 (or whatever you may get from the Sandybridge/Ivybridge processors), it's just the default (in the 3.9 kernel) "auto" mode doesn't pick up on it being a CEA mode (and thus to use limited range). That's a limitation (apparently) within the DRM with fractional frame rates. You can however still force limited range via xrandr - again I tested this and it worked out fine. There remain ongoing other issues with Intel drivers/Audioengine/etc. that just caused me to give up and return to nvidia for the time being. Maybe Haswell will sort it all ...

As for how XBMC handles this - I can remember in the past such discussions occurring, particularly with bonobo.

[fritsch]

@Drae:
Thanks for this explanation.

[noggin]

Installing a custom 3.8 kernel (not my work - kindly supplied by someone on the forums) with the Intel patches (I think Ville Syrjala's work) and an xrandr RGB Limited line run at start up I seem to get proper 16-235 Limited output as confirmed with my 0-25 black bar test signal, just the same as my Popcorn Hour in 16-235 limited output. (I think the xrandr line is only needed to ensure non-integer CEA modes also run in 16-235, otherwise I think only integer CEA modes default to 16-235) With the CTLINDEX edits to the Intel HD Audio .conf file I also get HD bitstreaming.

Great result.

I believe the Intel changes will be part of the 3.9 kernel.

[DrowningApe]

This seems like heaps of work. Would you mind posting your build somewhere downloadable?

[noggin]

As I said, the kernel build is not my work, it is someone else's, though AIUI it is a 3.8 kernel with the Intel patches applied. I've not patched kernels before, and it appears that the Intel video levels fix will be in the 3.9 kernel.

The CTLINDEX HD Audio edits are detailed in the wiki here : http://wiki.xbmc.org/index.php?title=Int...conf_-_Fix

To ensure 16-235 levels in non-integer modes I added the following line :

Code:

su xbmc -c 'sleep 4;xrandr -d :0 --output HDMI2 --set "Broadcast RGB" "Limited 16:235"' &

to

Code:

/etc/rc.local

This is based on your login being xbmc.

AIUI otherwise only integer CEA modes will be output 16-235 (i.e. 1080i, 1080p and 720p at 24/50/60Hz) - but not non-integer modes (23.976/59.94Hz) The xrandr edit forces all output to 16-235 irrespective of resolution and frame rate. Your setup may not be HDMI2 - so doing an

Code:

xrandr -q

to query your displays will confirm which display you need to apply the xrandr command to.