On Gemini Lake 2160p60Hz is only possible with RGB 8-bit (default), YCbCr 4:4:4 8-bit (with a driver hack).
I'm not sure if YCbCr 4:2:0 12-bit could be enabled with a hack or otherwise. 4:2:2 is not supported by the driver.
It is possible to enable GPU dithering for 8-bit modes (with a driver hack). It certainly eliminates the banding on my test videos and looks ok to me.
Deinterlacing is not available when using your build
Switch off "Allow using DRM PRIME decoder" and VAAPI deinterlacing will be available. There is no other way at the moment.
But at the location on the screen where the subtitles should be, is a bar which contains a stretched version of the running movie but only the red portion.
Yes, I can also reproduce this on my Gemini Lake box. An issue with subtitle rendering.
The specs page say that it only supports 2160p at 50/60Hz. Maybe that is the problem?
My question; is it possible to install Libreelec (desgined for RPi 1/B+) on this board.
No.
I have not tested for long, because unfortunately the TVHeadend server on the build isnt working (requires a kernel-module which is not there - most likely due to the kernel-change?) and I needed to watch some TV
Yes, Tvheadend that was compiled for X11 version of LE doesn't work.
I compiled Tvheadend 4.2 and 4.3 that will work with my builds.
NUC6AYH has HDMI 2.0 port (MCDP2800 LSPCON), J3455 Apollo Lake SoC with Gen9 Graphics. It should be capable to support HDR in Linux.
Windows HDR support is irrelevant, Gemini Lake also doesn't support HDR in Windows.
and you cant roll back the update
In theory it should be possible with a Flashrom utility under DOS as long as somebody provides a bios dump from the same NUC.
Try to test with a short (< 2m) known good cable connected directly to a TV. Intermittent blanking in 4K modes could be caused by a bad or too-long cable.
the screen seems to go black intermittently for a few seconds and then the picture comes back on
Does this happen with all video modes or only with 4K?
NUC6AYH : No-go for HDR.
NUC7i3BN : Works with HDR (on the previous build you posted about roughly a week or two ago)
That's interesting.
According to Intel's support pages for those NUCs they use the same MCDP2800 LSPCON chip.
Can you retest NUC6AYH with the build from post #502?
Also note that there is an issue with those builds. If you turn the TV off and then on (while the NUC is connected and working) - HDR will stop working until Kodi is restarted (maybe a bug in EDID parser code).
You can install LE to a USB drive.
I'd rather not.
Master branch is almost identical to a Matrix branch at this point anyway.
Yes, that one is working.
Haven't tested it properly yet though but I did saw the HDR icon show up on my tv.
That's good news. You are the first one who reported a working HDR on older LSPCON hardware. It looks like that NUC has MegaChips MCDP2800BC LSPCON.
I uploaded an updated image.
- Linux kernel 5.12-rc4
- Kodi e04f7d6
Everything else is identical to a build from post #494.
No. I forked lrusak repo and merged kodi master branch into drmprime-2img-no-ffmpeg-bump branch.
Updated build with HDR:
Current Kodi master (83387b9)
Linux kernel 5.11.7
Mesa 21.0.0
Full-feature Intel media-driver with fixed VAAPI DI
HDR patches from Commits · lrusak/xbmc · GitHub
how can a NUC decode audio same then a 1k AV.
Very easily. If you extract the same .rar archive on a $10000 computer and on a $100 computer - the extracted content of the archive will be bit-identical on both PCs.
Same goes with lossless audio formats.
Those HBR audio formats like DTS-HD MA, Dolby TrueHD or flac are merely a lossless compression of data. It makes no difference where the decompression takes place. Bitstreaming and decoding to LPCM are just 2 different methods of delivering the same audio data to the AVR.
Bitstreaming makes sense on those devices that for whatever reason cannot decode the above mentioned formats. Since Kodi can do a lossless decode of any HBR format - the absence of bitstreaming should never be an issue.
