[hdmkv]

Hmm, I'm not seeing any mention of 3D in this video. Focus seems to be 4K...

[Wolly]

Amlogic S8xx has had 23.976(5) support for almost a year now. They got the AV sync and AVR compatibility problems sorted out only a few months ago.

you sure? a year? i never found amlogic box/player mentioned 23,976(5) support.

AFAIK, Amlogic released 23.976 feature in the latest SDK update, which is also the latest SDK of Minix X8-H Plus, v005. I've never heard Amlogic could support 23.976Hz before.

[wesk05]

There is a economic solution for test HDMI Hz out? maybe adb comand or tool?

Accurate refresh rate readings can be taken only from HDMI output. So, an external device has to be used.

you sure? a year? i never found amlogic box/player mentioned 23,976(5) support.

Yes, it is almost a year. First firmware with 23.976Hz mode for Minix X8-H was released on 7/11/14. It has been improved upon since. There was a "slow-motion" bug present in beta 9 firmware. Amlogic had to come up with an entirely new SDK to correct that bug. Adaptive refresh rate was first introduced for Kodi and later at system level in firmware 003 in Feb 2015. So, yeah Minix boxes have had 23.976Hz mode for a long time and they are probably the only Android boxes that have dynamic refresh rate switching at system level.

Currently, Amlogic has some problem on the compatibility between 23.976 and HD audio Passthrough. You can only choose one, 23.976 or HD audio passthrough.
This is a complicated problem that can't be solved with software. When they released their 64-bit chipset, this will be solved.

Yes, HD audio passthrough and 23.976Hz mode has some AVR compatibility issues on Vidon Kodi/XBMC.

AFAIK, Amlogic released 23.976 feature in the latest SDK update, which is also the latest SDK of Minix X8-H Plus, v005. I've never heard Amlogic could support 23.976Hz before.

It is not true. As mentioned above, Minix boxes have had 23.976Hz mode for a long time. If you want, you can check Minix forums.

[ars92]

There is a economic solution for test HDMI Hz out? maybe adb comand or tool?

Accurate refresh rate readings can be taken only from HDMI output. So, an external device has to be used.

you sure? a year? i never found amlogic box/player mentioned 23,976(5) support.

Yes, it is almost a year. First firmware with 23.976Hz mode for Minix X8-H was released on 7/11/14. It has been improved upon since. There was a "slow-motion" bug present in beta 9 firmware. Amlogic had to come up with an entirely new SDK to correct that bug. Adaptive refresh rate was first introduced for Kodi and later at system level in firmware 003 in Feb 2015. So, yeah Minix boxes have had 23.976Hz mode for a long time and they are probably the only Android boxes that have dynamic refresh rate switching at system level.

Currently, Amlogic has some problem on the compatibility between 23.976 and HD audio Passthrough. You can only choose one, 23.976 or HD audio passthrough.
This is a complicated problem that can't be solved with software. When they released their 64-bit chipset, this will be solved.

Yes, HD audio passthrough and 23.976Hz mode has some AVR compatibility issues on Vidon Kodi/XBMC.

AFAIK, Amlogic released 23.976 feature in the latest SDK update, which is also the latest SDK of Minix X8-H Plus, v005. I've never heard Amlogic could support 23.976Hz before.

It is not true. As mentioned above, Minix boxes have had 23.976Hz mode for a long time. If you want, you can check Minix forums.

Just want to confirm, you HAVE to use vidon xbmc and pay the yearly subscription to have hd audio passthrough on the minix x8h or can you just load up the latest kodi from the official website and it will work?

[wesk05]

Just want to confirm, you HAVE to use vidon xbmc and pay the yearly subscription to have hd audio passthrough on the minix x8h or can you just load up the latest kodi from the official website and it will work?

You have to use VidOn XBMC/Kodi and have the Pro subscription for HD audio passthrough on Minix boxes. There is no system level support for HD audio passthrough.

[wesk05]

I just tested a Raspberry Pi2. Oh, boy! I am very impressed what this $35 board can do. Every single output mode is perfect. 23.98 mode is 23.976, 24 is 24.000, 59.94 is 59.940... However, there are RGB bit errors very similar to the ones that I found on the SHIELD Android TV. That was a little disappointing .

[popcornmix]

I just tested a Raspberry Pi2. Oh, boy! I am very impressed what this $35 board can do. Every single output mode is perfect. 23.98 mode is 23.976, 24 is 24.000, 59.94 is 59.940... However, there are RGB bit errors very similar to the ones that I found on the SHIELD Android TV. That was a little disappointing .

Can you explain exactly what you measuring/observing?

[noggin]

However, there are RGB bit errors very similar to the ones that I found on the SHIELD Android TV. That was a little disappointing .

Can you define "RGB bit errors"?

Kodi will remap 16-235 YCrCb source material to 0-255 RGB internally, and then remap this back to 16-235 (RGB I think usually on the Pi) on output, which can mean you get some additional banding compared to native 16-235 solutions.

(You need a YCrCb to RGB or Alternative YCrCb conversion if you are playing SD content upscaled to HD as the SD material will be SD levelspace 601 YCrCb and the HD levelspace is 709 - which has different RGB <->YCrCb matrix values - you can't output SD YCrCb to HD YCrCb displays un-modified unless you can clearly flag the levelspace to the display. That way lie dragons...)

[Milhouse]

The hdmi_pixel_encoding setting (explained in this page) can be used to set 0-255 RGB mode.

[wesk05]

Can you define "RGB bit errors"?

It is the accuracy of RGB/YCbCr values of reference test patterns read from the HDMI output of the device. I use the Color Checker function of DVDO AVLab TPG 4K UHD Test Pattern generator to read the bit values from the output of the device under test. The function is similar to the "Pixel Cursor" function seen on Dolby Professional Reference Monitor- PRM-4220. The test patterns are MP4 files from Ted's LightSpace CMS calibration disk, the accuracy of which has been verified by several calibrators.

Kodi will remap 16-235 YCrCb source material to 0-255 RGB internally, and then remap this back to 16-235 (RGB I think usually on the Pi) on output, which can mean you get some additional banding compared to native 16-235 solutions.

Hmm... I wasn't aware of this. If this is true, the errors are actually Kodi conversion errors. For the Raspberry Pi2 and SHIELD Android TV I have used Kodi to play the MP4 test patterns. For the other Android devices that I have tested, I have used the native video player. I may have to repeat the test for the SHIELD using the native video player.



The top half of the table is the 21-point grayscale. Bottom half is the standard color checker pattern and gamut (100% stimulus, 100% saturation). dE2000 is given in the last column for both the devices. These errors are all trivial and below the threshold of visual perception (dE 2-3), but errors are still errors

[noggin]

Seriously - those are errors of 1LSB (Least Significant Bit). If I were marketing a product for a broadcast chain I'd be concerned - but for viewing at the end of the chain - far less so. Plasma displays hammered greyscale far more than this - and people raved about them...

[noggin]

The hdmi_pixel_encoding setting (explained in this page) can be used to set 0-255 RGB mode.

I think the issue is more that YCrCb 601/709 16-235 -> 0-255 RGB -> 0-255 RGB/16-235 YCrCb 709 can cause the odd error in rounding. In 709 YCrCb terms you don't always perfectly get out what you put in (you lose <16 and >235 content and get some rounding errors in the matrix conversions that mean you get errors of the order of an LSB in the chain) Personally this worries me far less than stuff like decent deinterlacing and frame drop/skips, though as we move to 10/12 bit production and distribution it will be more important I guess.

And then we have Rec 2020 to cope with... ... ... ... <Runs away screaming>

[looun]

Can you define "RGB bit errors"?

It is the accuracy of RGB/YCbCr values of reference test patterns read from the HDMI output of the device. I use the Color Checker function of DVDO AVLab TPG 4K UHD Test Pattern generator to read the bit values from the output of the device under test. The function is similar to the "Pixel Cursor" function seen on Dolby Professional Reference Monitor- PRM-4220. The test patterns are MP4 files from Ted's LightSpace CMS calibration disk, the accuracy of which has been verified by several calibrators.

Kodi will remap 16-235 YCrCb source material to 0-255 RGB internally, and then remap this back to 16-235 (RGB I think usually on the Pi) on output, which can mean you get some additional banding compared to native 16-235 solutions.

Hmm... I wasn't aware of this. If this is true, the errors are actually Kodi conversion errors. For the Raspberry Pi2 and SHIELD Android TV I have used Kodi to play the MP4 test patterns. For the other Android devices that I have tested, I have used the native video player. I may have to repeat the test for the SHIELD using the native video player.

ok , but The human eye can see 0.40-0.70 difference?

[noggin]

ok , but The human eye can see 0.40-0.70 difference?

Yes - if it is manifested as banding. The eyes are quite good at spotting that. If you hide the errors with dither you are less likely to see it. (Quantel patented a clever form of dither called Dynamic Rounding ™ in the 80s that helped mask 8 bit conversion artefacts.)

[wesk05]

Seriously - those are errors of 1LSB (Least Significant Bit). If I were marketing a product for a broadcast chain I'd be concerned - but for viewing at the end of the chain - far less so.

Yes, of course! I never said that these were significant errors, but there are consumer devices that have perfect output (several Samsung Blu-ray players, Oppo Blu-ray players, Amlogic SoCs).

Plasma displays hammered greyscale far more than this - and people raved about them...

This is why we have display calibration!