Kodi Community Forum
Intel NUC - Haswell (4th Generation CPU) - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Hardware (https://forum.kodi.tv/forumdisplay.php?fid=112)
+--- Thread: Intel NUC - Haswell (4th Generation CPU) (/showthread.php?tid=176718)



RE: Intel NUC - HTPC (Haswell Late 2013 edition) - fritsch - 2014-03-24

Once scaled from full to limited, it's non reversible.


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - axbmcuser - 2014-03-24

(2014-03-06, 20:21)zag Wrote: For me r17780 is the last working release using livetv and hardware acceleration.

Can anyone else confirm its broken in recent releases? It seems fine on videos, just not Live TV

I also get blocking/artefacts with all the latest nightlies with Live-TV on my D54250WYK(H). As you mentioned, videos are fine.

I tried an old build around the one you mentioned (i used r17733) and with that one hardware accerlation + Live TV works fine.

+1 from me regarding what you experience. Undecided


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - zag - 2014-03-24

(2014-03-24, 15:59)axbmcuser Wrote:
(2014-03-06, 20:21)zag Wrote: For me r17780 is the last working release using livetv and hardware acceleration.

Can anyone else confirm its broken in recent releases? It seems fine on videos, just not Live TV

I also get blocking/artefacts with all the latest nightlies with Live-TV on my D54250WYK(H). As you mentioned, videos are fine.

I tried an old build around the one you mentioned (i used r17733) and with that one hardware accerlation + Live TV works fine.

+1 from me regarding what you experience. Undecided

Post a debug log so we can see whats going on.

I have a feeling it was the openelec commit that has caused this. Every new nightly has blocking on live tv now.

EDIT: Going back to openelec nightly r17780 from 21st February, WORKING
EDIT2: Going back to openelec nightly r17824 from 27th Feburary, BROKEN


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - noggin - 2014-03-24

(2014-03-24, 14:56)fritsch Wrote: Once scaled from full to limited, it's non reversible.

Yes - but from Limited to Full it is (ignoring <16 BTB and >235 WTW clipping) isn't it? That was my point re: banding.

So if you have a Limited source file, scale to Full (introducing banding), and then scale back to Limited, that can remove the banding can't it?

Doesn't every Limited value scale to a unique Full value (with some Full values not being filled, creating the banding jumps?) thus allowing a lossless return to Limited (ignoring BTB and WTW) Won't this remove any banding that has been introduced by the Limited->Full scaling on the return Full->Limited scale. Isn't there a 1:1 mapping from Limited -> Full (which is thus reversible?)

Obviously if you start with a native Full signal, then you will lose information, but if your Full signal is itself derived from a Limited signal, won't that have no content in the areas where the information will be lost from?

I guess I'm imagining two 256 (or 1024 for 10 bit) value LUTS as that would be how I would have done it back in my hardware days! (256 bytes of ROM LUT - with the input video used to address the memory and the output video being the content of that memory location.)


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - fritsch - 2014-03-24

Check:
Input: Full Range 0 .. 255
Scale to Limited: sl(255) = ? sl(235) = ?
scale back to full: sf(sl(255)) = ? sf(sl(235) = ?

Assumption linear weighting. Please solve the equations.


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - noggin - 2014-03-24

(2014-03-20, 06:57)trsqr Wrote: August T210 should be supported in kernel 3.14. I've ordered one from China, but it takes weeks to arrive... I don't know any other USB T2 tuners that do work with Linux.

I've got 2 290e tuners, and might be interested in selling one if the August one works ok...

I took a punt on an August T210, and already have a PCTV 290e. I installed a 3.14 kernel on a fresh Ubuntu install, and built TV Headend. The T210 is seen by the kernel and registered as a DVB T and DVB C frontend. However I can only get it to tune DVB-T Freeview muxes. When I try DVB-T2 Freeview HD muxes it fails to find any services.

Hmm...

(2014-03-24, 17:30)fritsch Wrote: Check:
Input: Full Range 0 .. 255
Scale to Limited: sl(255) = ? sl(235) = ?
scale back to full: sf(sl(255)) = ? sf(sl(235) = ?

Assumption linear weighting. Please solve the equations.

You're missing my point. Your example is the opposite of the situation that I was discussing.

I'm assuming the input is Limited range - as almost all source video is (DVD, Blu-ray, DVB, ATSC etc.).
I'm assuming the output is Limited range, as many of us want our HDMI outputs to be (to match other consumer gear)
However there may be a Full range process (XBMC?) in the way.

There was a statement made that this double scaling introduced banding on the output as well as clipping <16 and >235 content. Whilst I agree about the <16 and >235 content - isn't the Limited-Full-Limited processing potentially transparent?

Input : Limited Range 16-235
Scale to Full
Scale back to Limited for output

I totally agree that in your case you will inevitably lose information as the scaling is from a wider range to a narrower range. However in the case I was talking about the scaling is from narrower range to wider range, which won't lose content, and back again, which won't lose content as there isn't any content at the levels that will be lost by the reverse scaling. In other words in the case of XBMC playing 16-235 video and outputting 16-235 video, my point was that the two scaling processes (Limited->Full followed by Full->Limited) don't inevitably create banding and can be lossless.

I think we are talking at crossed purposes.


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - lmyllari - 2014-03-24

(2014-03-24, 13:05)kouze Wrote:
(2013-12-05, 02:17)lmyllari Wrote: The banding comes from expanding luma from 16-235 to 0-255. This is done for typical PC monitors, which expect a full range signal. New Intel linux drivers by default give TVs a limited range signal, taking the expanded 0-255 and scaling it to 16-235. This does not eliminate the banding that was created by the original expansion, and original information below 16 and above 235 was already lost in that same step. (Why do they do it? It's the right thing according to the standards, and some TVs don't like full range -> crushed blacks.)

If the player software (xbmc in this case) decodes to 16-235 (meaning "don't change luminance, keep black at 16 and white at 235"), the video card outputs full range 0-255 (meaning "don't scale the levels, just output what you're given"), and display is set to limited range input (meaning "16 is black, 235 white"), we eliminate the banding in greyscale ramp (because the range is not scaled at any point) and keep blacker-than-black (luma values under 16) and white-than-white (luma values above 235).

If your plasma defaults to limited range RGB (and doesn't listen to the infoframes in the HDMI stream) or you can set limited range manually, you don't need anything special. Just set your player software to 16-235 (which you can now do with Gotham and software decoding) and make sure the video card doesn't change the signal (the xrandr broadcast range "Full" setting mentioned a lot in this thread). In my case, the monitor obeys the infoframes (and there are other devices connected to the same input preventing a manual setting), so I need a patch to switch it to limited range without altering the video signal.
Hi guys,

I'm actually facing this issue with my NUC Haswell I3 with the latest openelec gotham beta 2 with my Panasonic 50VT30 Plasma TV.

Using only software rendering is not really an option as I saw some slow rendering issue with 1080p mkv files.

I'm thinking using Gotham XBMC under Windows 8.1. Could it be an option to get good RGB signal on my TV?

Thanks !
With current OE you can use VAAPI decoding, SW filtering and 16-235 xbmc setting. You won't even need my passthrough patch with a Panasonic - it assumes limited range. You just need to use xrandr to set full range output (to avoid GPU scaling your limited range signal again).

The SW filtering downloads decoded frames and puts them through the same path as software decoded frames -> the 16-235 setting in xbmc works fine and you get a nice untouched signal.

No idea about Windows, sorry. Usually I don't associate Microsoft with "good RGB signal". Tongue (<- unfair stab at the whole xbox360 fiasco)

(2014-03-24, 18:19)noggin Wrote: There was a statement made that this double scaling introduced banding on the output as well as clipping <16 and >235 content. Whilst I agree about the <16 and >235 content - isn't the Limited-Full-Limited processing potentially transparent?
I think that would be ok if you were just scaling luminance back and forth, but you are also doing YCbCr -> RGB in the first step.


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - Roby77 - 2014-03-24

Mmhm has this bug from several month

Why it is not fixed yet ?

It's possible to use ycbr 709 ?


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - fritsch - 2014-03-24

Cause you did not fix it, quite easy. I await your PR even daily, but it does not come.


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - Roby77 - 2014-03-24

Mmh it wasn't a critique just a curiosity about the origin of the bug

Sorry for misanterpretation caused by my bad english


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - noggin - 2014-03-24

(2014-03-24, 20:12)lmyllari Wrote: I think that would be ok if you were just scaling luminance back and forth, but you are also doing YCbCr -> RGB in the first step.
That's a very good point. YCrCb/RGB round-tripping in 8-bit truncated space isn't a good idea is it...

I knocked up an Excel sheet to go from Limited to Full to Limited level space - with rounding to nearest integer - but hadn't considered the RGB matrix.

Presumably XBMC copes with ITU 601 and 709 levelspace on input content (either by reading header information or by taking a punt that <=720 horizontally is 601 and >720 horizontally is 709. I assume you'd use horizontal resolution rather than vertical to cope with the letterbox cropping that happens on >16:9 aspect ration 720p and 1080p sourced content?)

I assume there is some driver interaction on the output level space and RGB to YCrCb conversion - so no real control over whether output is 601 or 709 colour space if YCrCb?


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - kouze - 2014-03-24

(2014-03-24, 20:12)lmyllari Wrote: With current OE you can use VAAPI decoding, SW filtering and 16-235 xbmc setting. You won't even need my passthrough patch with a Panasonic - it assumes limited range. You just need to use xrandr to set full range output (to avoid GPU scaling your limited range signal again).

The SW filtering downloads decoded frames and puts them through the same path as software decoded frames -> the 16-235 setting in xbmc works fine and you get a nice untouched signal.

No idea about Windows, sorry. Usually I don't associate Microsoft with "good RGB signal". Tongue (<- unfair stab at the whole xbox360 fiasco)
Brilliant ! Thank you so much !


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - deaerator - 2014-03-26

(2014-03-24, 20:12)lmyllari Wrote: With current OE you can use VAAPI decoding, SW filtering and 16-235 xbmc setting. You won't even need my passthrough patch with a Panasonic - it assumes limited range. You just need to use xrandr to set full range output (to avoid GPU scaling your limited range signal again).

The SW filtering downloads decoded frames and puts them through the same path as software decoded frames -> the 16-235 setting in xbmc works fine and you get a nice untouched signal.

No idea about Windows, sorry. Usually I don't associate Microsoft with "good RGB signal". Tongue (<- unfair stab at the whole xbox360 fiasco)

Can you explain in detail how to set this up or is there a sticky somewhere.


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - kouze - 2014-03-26

(2014-03-26, 12:30)deaerator Wrote:
(2014-03-24, 20:12)lmyllari Wrote: With current OE you can use VAAPI decoding, SW filtering and 16-235 xbmc setting. You won't even need my passthrough patch with a Panasonic - it assumes limited range. You just need to use xrandr to set full range output (to avoid GPU scaling your limited range signal again).

The SW filtering downloads decoded frames and puts them through the same path as software decoded frames -> the 16-235 setting in xbmc works fine and you get a nice untouched signal.

No idea about Windows, sorry. Usually I don't associate Microsoft with "good RGB signal". Tongue (<- unfair stab at the whole xbox360 fiasco)

Can you explain in detail how to set this up or is there a sticky somewhere.
SSH to openelec box and type:

cd /storage/.config
touch autostart.sh
chmod 0777 autostart.sh
nano autostart.sh

# RGB fix
xrandr --output HDMI1 --set "Broadcast RGB" "Full"


The other parameters are found in XBMC directly in expert mode


RE: Intel NUC - HTPC (Haswell Late 2013 edition) - micoba - 2014-03-26

I got two external hdds connected via usb 3.0, but one just won't go into standby. Does anyone know how to force standby in win 8.1? It must be some driver issue, as the same hdd in the same external case didn't always cause this problem. Also, the copy speeds between win 7 and the nuc are too low - going down from 80 to under 40mb/s in about 2 minutes...