Kodi Community Forum

(2014-03-20, 07:56)Crssi Wrote: [ -> ]Is this NUC Haswell thread?

It is!

Although you probably would not know this by last few pages of posts.

Hey there!

i got a D54250WYKH Haswell-i5-NUC and use
OpenELEC + DVB-C Live-TV + a "Limited RGB Range only" LCD.

Im quiet happy with 3.2.4 (very stable Live-TV!) - but if i understand correctly there is nothing i can do to fix the greyish Blacks on my setup - switching to Full RGB Range is way too dark (and wrong for my Limited RGB Range LCD).


I tried out some Nightlies and - yeah - the Black is fine - but in the Nightlies Live-TV is very unsteady/unusable for my setup.


What can i do?


Is there a mirror of the lmyllari old 3.2 based build with his RGB-Range fixes - or something else?


Thank you very much.

Greets

(2014-03-20, 15:13)axbmcuser Wrote: [ -> ]Hey there!

i got a D54250WYKH Haswell-i5-NUC and use
OpenELEC + DVB-C Live-TV + a "Limited RGB Range only" LCD.

Im quiet happy with 3.2.4 (very stable Live-TV!) - but if i understand correctly there is nothing i can do to fix the greyish Blacks on my setup - switching to Full RGB Range is way too dark (and wrong for my Limited RGB Range LCD).


I tried out some Nightlies and - yeah - the Black is fine - but in the Nightlies Live-TV is very unsteady/unusable for my setup.


What can i do?


Is there a mirror of the lmyllari old 3.2 based build with his RGB-Range fixes - or something else?


Thank you very much.

Greets

This should still be available:

(2013-11-27, 07:50)lmyllari Wrote: [ -> ]I've uploaded a 3.2 with color/black fixes to https://www.dropbox.com/s/htrw49uctfo1d0...r15940.tar

Not tested, good luck


edit: full disclosure - I use the builds from git master

(2014-03-19, 06:51)genyus Wrote: [ -> ]

(2014-03-15, 17:51)OmBreNoiRe Wrote: [ -> ]

(2014-02-22, 06:04)millercentral Wrote: [ -> ]No it is not the same remote codes, or even the same protocol (MCE is RC6, the Xbox One remote is nec1 protocol).

Hi ! Is it possible to make the nuvoton CIR working with the xbox one remote ?

Yes, I have it working on Openelec. I'd say that it's my favorite remote so far.

Did it work out of the box or did you have to make changes? If so, how did you get it to work?

This thread has all you need to know really but if you want the exact code I used for the files then send me a private message.

http://openelec.tv/forum/103-infared-rem...rk-with-oe

I found that each Xbox One remote used the same IR codes. I was able to use the same files for each NUC I have and they all work great.

(2014-03-22, 05:38)genyus Wrote: [ -> ]This thread has all you need to know really but if you want the exact code I used for the files then send me a private message.

http://openelec.tv/forum/103-infared-rem...rk-with-oe

I found that each Xbox One remote used the same IR codes. I was able to use the same files for each NUC I have and they all work great.

Excellent thread. Thank you!

Hey there,

all was fine, till yesterday when i decided to create mysql database in my synology nas so i did also fresh OE beta2 reinstall.
the problem is: xbmc start showing black bars for every single file i try. look at screenshot



1916x1076 > 1920x1027 WTF!!! why is does upscale x and downscale y!
tried both hard and soft decoding > same result.
last snapshot r17990 > same..
file over mysql database or local file doesn't matter.
hard reset > same...
Quick shot with ubuntu live stick and latest beta xbmc, the problem is not there.

any suggestions?

switching off adjust display refresh rate to match video which is not an option for me, fixed the problem.
so this is about 24p?

Don't use zoom?

being replying to my self for the last few posts but finaly found it!!!
it was guisetiings.xml problem:
i found almost 1080p refresh rates except 60hz got wrong wrong pixel ration <pixelratio>0.952476</pixelratio> instead of <pixelratio>1.000000</pixelratio>
how on earth we have these mess as default?

---

(2014-03-22, 16:27)xbs08 Wrote: [ -> ]Don't use zoom?

sure there was no zoom.
thx anyway.

Hey again,

lmyllaris 3.2 build worked well for me. Tried it for some days now. Thanks again!


Unfortunately i got a new problem today when i upgraded my D54250WYKH from BIOS version 0024 to 0025.
With 0025 my DVB-C stick now freezes on the initial scan. I tried multiple installs and it's clearly a issue starting today after the update.

So i downgraded to 0024 via removing the jumper. Loaded BIOS default settings (F9) and made the device powerless in between.

No chance: My DVB-C stick now also crashes with 0024 as it started with with 0025.

So - only way for a TRUE cmos reset is removing battery?

(2014-03-20, 11:36)Peppin Wrote: [ -> ]Im currently experiencing troubles with DTS-MA rips.
Both in Beta 1 and Beta 2 (just updated). After resetting everything, one DTS-MA movie plays fine. Stopping the movie and starting another one results in no sound, stuttering. After that, no video is playable anymore.

---

(2014-03-20, 11:36)Peppin Wrote: [ -> ]Im currently experiencing troubles with DTS-MA rips.
Both in Beta 1 and Beta 2 (just updated). After resetting everything, one DTS-MA movie plays fine. Stopping the movie and starting another one results in no sound, stuttering. After that, no video is playable anymore.

Allright a quick fix, I had sync vid to display (Video Clock) on. Turned it off, no issues now. But I understood that having it on is best practice? Had it on since I got my NUC.

@fritsch, I followed your advice to run with sync vid to display (Video Clock), even with Haswell. Do you know anything about this "bug" with OE4 B1/2? Or is it just me..
Thanks a lot

No - but I am already developing for gotham +1 which means ffmpeg bump and other features. Currently only doing PulseAudio backports that are really needed for gotham.

Edit: I hope you also combine that with Adjust Refreshrate to match video _and_ you have the relevant modes, if those are missing (see my last lengthy post).

(2013-12-05, 02:17)lmyllari Wrote: [ -> ]

(2013-12-05, 00:51)furii Wrote: [ -> ]

(2013-12-04, 22:27)lmyllari Wrote: [ -> ]The only thing missing is my hack that allows you to output full range and tell the display it is a limited range signal. It is only usable with software decoding and Gotham. Consider it an expert setting for now. See https://github.com/laurimyllari/OpenELEC...e8b603144a

can you explain why one would want to output full range but tell the display it is a limited range signal?

i'm currently using an nvidia card but am strongly considering switching to haswell and have been following your fixes which i assume translate to haswell in general and is not confined simply to the nuc. i have a vt50 and have yet to have it professionally calibrated (why bother when you aren't getting perfect input?) because of an issue i see with 1-Grayscale Ramp.mp4 where there is banding. from other posts on the forum it seems this is a result of xbmc expanding from limited to full and back or something. the comment in your commit leads me to believe this would be fixed.

I have a professionally calibrated plasma and can recommend it.

I think you mostly got the idea. It's not really about outputting full range, but rather not modifying the signal.

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 !

lmyllari I follow what you say about losing <16 and >235 levels when 16-235 is scaled to 0-255, and that banding is introduced by spreading the 220 levels in the Limited source across 255 levels of the Full output.

However shouldn't the scaling be complimentary, so that if you reverse it, the banding is removed - as the initial scale is across a wider range not a narrower range?

Or are you saying that the two scales (LImited->Full and Full->Limited) that in an ideal world we want to avoid - aren't complimentary?

I'm thinking of how the signal would fair through a basic LUT approach and how that would work for the mapping (without any dithering - as I don't believe dithering is usually used to mask the level scaling). Each Limited source level will still map to a unique Full output level, so it should be possible to reverse this with zero loss of original data (other than <16 and >235 that is inevitably losses as it is clipped) removing any banding that has been introduced?

Or am I missing something - or do "real world" implementations make a mess of this?