[Satkid]

Hi Guys,

Read lots of threads, and the stickies about what hardware, but not really been able to get a definitive answer.

I am coming from an oppo blu Ray, and ideally wanted to get a box that is of the same in quality (audio and video) but is slicker like kodi's ui. I have all blu rays in none compressed mkv with either dts/tru hd on a gigabit linked cat 6 win10 machine with lots of disks with all disks and dvd's. Just need a kodi box.

What's the equivalent kodi box (not that concerned around price), just wanted to get the best available kodi' box. Don't need streaming or any app stuff as my Samsung TV does all that ;-)

whilst I think the 2 front runners are the shield or a htpc really keen to get that excellent picture and sound quality I have now.

Thanks,

[couto27]

None of the current players around playing Kodi will match the Oppo audio Quality.

Some may argue that when doing bitstreaming it shouldn't be any different from source perspective, but the Oppo built-in power supply, components, isolations etc can prevents degradation in sound.
If you have a good set of expensive speakers you might be really disappointed with some players.

Ps: i notice some time ago, that i prefer the sound & video from Oppo physical disk VS a little less inferior Oppo file reading USB/streaming player

None of the current players around playing Kodi will do source direct like the Oppo, in terms of PQ its the step in right direction to get less issues, but none of the players manufacturers or Kodi support source direct.....source direct its a unique feature in Oppo player by streaming or USB.


In resume if you search for flaws about audio & video reproduction when comparing any player with Kodi VS Oppo you will find it, a bigger screen and nice set of speakers will help, or use topics like this one

In my opinion Kodi is a universal player, supporting too much hardware versions, and by this reason it will never achieve premium audio & video integration with random hardware.
I want get rid of my Oppo anytime soon, but I've being a happy camper using the Nvidia shield... the 3.2 beta version (final version coming in the end of this month) is promising alot

The new YCbCr 4:4:4 mode is flawless when it comes to color accuracy.

[lmyllari]

whilst I think the 2 front runners are the shield or a htpc really keen to get that excellent picture and sound quality I have now.

NUC or Chromebox, if you don't need interlaced VC-1 or deinterlacing.

The Intel GPU (Haswell or later) gives you flawless output. I have compared against my Oppo and would trust my NUC more for accurate reproduction of 720p/1080p h264 material at the correct refresh rate. If you find issues, both Kodi and Intel developers are responsive to bug reports. Oppo is limited to their SOC vendor's SDK.

If you want to move beyond what you have now, get a colorimeter (like i1display pro) and dispcalgui.

[Roby77]

+1 for intel using librelec v17 (with fritsch and fernentmenta egl improvement)

[wesk05]

The Intel GPU (Haswell or later) gives you flawless output.

This is not exactly right. Intel/AMD/nVIDIA GPUs are not flawless in RGB or YCbCr conversions. There are errors (visually imperceptible) that can be measured using capable test equipment.

[lmyllari]

This is not exactly right. Intel/AMD/nVIDIA GPUs are not flawless in RGB or YCbCr conversions. There are errors (visually imperceptible) that can be measured using capable test equipment.

YCbCr won't work properly with the current software stack, but what kind of errors have you seen or measured in the Intel RGB output?

[wesk05]

YCbCr won't work properly with the current software stack, but what kind of errors have you seen or measured in the Intel RGB output?

Errors like these. Test system running LibreELEC x86 #0610 on Intel Haswell 4570 (S)/HD Graphics 4600. Broadcast RGB set to "video 16-235 passthrough". The chart shows pixel values of reference RGB triplet patterns read using DVDO AVLab TPG & Murideo Fresco SIX-A analyzer. I had done a similar test a few months back on one of the OpenELEC x86 builds. I don't remember seeing these many errors at that time. There were some errors in the color checker patterns, but grayscale patterns didn't have errors. I am not sure what is going on with this particular build. When I get time, I will check one of the older builds. The errors are all less than dE94 3.0. So they can be "considered" as visually imperceptible.

****Edit****
See post #13

[Jdiesel]

YCbCr won't work properly with the current software stack, but what kind of errors have you seen or measured in the Intel RGB output?

Errors like these. Test system running LibreELEC x86 #0610 on Intel Haswell 4570 (S)/HD Graphics 4600. Broadcast RGB set to "video 16-235 passthrough". The chart shows pixel values of reference RGB triplet patterns read using DVDO AVLab TPG & Murideo Fresco SIX-A analyzer. I had done a similar test a few months back on one of the OpenELEC x86 builds. I don't remember seeing these many errors at that time. There were some errors in the color checker patterns, but grayscale patterns didn't have errors. I am not sure what is going on with this particular build. When I get time, I will check one of the older builds. The errors are all less than dE94 3.0. So they can be "considered" as visually imperceptible.

Is this consistent with all videos? If so a 3dlut should be able to correct for this somewhat. Thankfully lmyllari has been working on implementing 3dlut support into Kodi.

[wesk05]

Is this consistent with all videos? If so a 3dlut should be able to correct for this somewhat. Thankfully lmyllari has been working on implementing 3dlut support into Kodi.

If you create a 3D LUT based on a pattern generator that has errors, the error is carried forward. I have to emphasize again that these errors are below threshold and for all practical purposes should be considered as imperceptible. I brought it up only because @lmyllari commented that Intel RGB output is flawless.

On the other hand, nVIDIA Shield's YCbCr 4:4:4 output in upcoming 3.2 firmware is indeed flawless. So is the output from Amlogic SoCs.

[lmyllari]

Errors like these. Test system running LibreELEC x86 #0610 on Intel Haswell 4570 (S)/HD Graphics 4600. Broadcast RGB set to "video 16-235 passthrough". The chart shows pixel values of reference RGB triplet patterns read using DVDO AVLab TPG & Murideo Fresco SIX-A analyzer. I had done a similar test a few months back on one of the OpenELEC x86 builds. I don't remember seeing these many errors at that time. There were some errors in the color checker patterns, but grayscale patterns didn't have errors. I am not sure what is going on with this particular build. When I get time, I will check one of the older builds. The errors are all less than dE94 3.0. So they can be "considered" as visually imperceptible.

What's your signal source and could you share the YCbCr values? Does disabling VAAPI make a difference?

Can you see banding in a grayscale ramp test pattern with dithering disabled?

Looking at those values my guess is that VAAPI outputs full range video and Kodi scales it back to limited range. If such a configuration is still possible, it should probably be disabled so that nobody uses it by accident.

edit: if you can check the output of BtB and WtW that will tell whether limited->full->limited range conversions are happening

[lmyllari]

I have to emphasize again that these errors are below threshold and for all practical purposes should be considered as imperceptible. I brought it up only because @lmyllari commented that Intel RGB output is flawless.

If this is more than a configuration error, I'd like to get to the bottom of it and fix it.

[Satkid]

Thanks Guys,

What was the audio like in comparison to the oppo on the nuc?

Am i right in thinking that a higher spec htpc with additional graphics card, and sound card would be an improvement over the nuc design?

Thanks for the tips around calibration, if i can better the output, that would be nice.

Does the nuc not handle interlaced vc-1 (tbh not sure i have any br's with this, as have only tested a few) been waiting to get kodi machine..


Sent from my iPhone

[wesk05]

What's your signal source and could you share the YCbCr values? Does disabling VAAPI make a difference?
Can you see banding in a grayscale ramp test pattern with dithering disabled?
Looking at those values my guess is that VAAPI outputs full range video and Kodi scales it back to limited range. If such a configuration is still possible, it should probably be disabled so that nobody uses it by accident.
edit: if you can check the output of BtB and WtW that will tell whether limited->full->limited range conversions are happening

I use MP4 test pattern files from Ted's LightSpace Calibration - http://www.displaycalibrations.com/
I am not sure what YCbCr values you are asking for.
This particular build #0610 seems to be broken. I can't access "video" or "appearance" in settings. I may have try another build and check whether disabling VAAPI makes a difference.
As mentioned earlier, Broadcast RGB is set to video 16-235 passthrough and Kodi is also set to limited. In this configuration, BtB and WtW are passed through.

If this is more than a configuration error, I'd like to get to the bottom of it and fix it.

There was indeed a configuration issue. I had dithering enabled. The table below is with dithering disabled. It is now similar to what I have seen in previous builds. While the grayscale is error free, there are very small rounding errors in the color checker patterns.

[lmyllari]

I use MP4 test pattern files from Ted's LightSpace Calibration - http://www.displaycalibrations.com/
I am not sure what YCbCr values you are asking for.

What the test patterns decode to. I would like to know what are the exact values encoded in the patterns with differing results. I have a copy so I can check mine.

If this is more than a configuration error, I'd like to get to the bottom of it and fix it.

There was indeed a configuration issue. I had dithering enabled. The table below is with dithering disabled. It is now similar to what I have seen in previous builds. While the grayscale is error free, there are very small rounding errors in the color checker patterns.

That looks much better. The dithering shouldn't cause such large variations though (unless you have it configured for lower than 8 bit output).

I remember reading a discussion on AVS about something like this, and HCFR has an option to configure for the rounding used by the pattern source.

Ted's disk has some issues, I'd personally trust AVSHD709 more.

[lmyllari]

@wesk05, I took the "Dark Skin" pattern (MP4 Media Files (Free Version)/03. Verify Calibration Tools/02. CalMAN/Color Checker Classic/08. Dark Skin.mp4) and dumped a frame with ffmpeg. The YCbCr value for the pattern is 91, 118, 143.

I converted that to RGB with formulas from http://www.compression.ru/download/artic...e/ch03.pdf and got 114.1, 85.945, 72.84 which rounds to 114, 86, 73. That matches your measured numbers from LE #601.

Would you expect a different result? Do other players give different output from the same pattern?