Does the camcorder record 4:2:0 or 4:2:2?
Intel GPUs only hardware accelerate 4:2:0 h.264 and h.265 - not 4:2:2.
What frame rate is the video - as that can also play a part with h.264 on some platforms. If you have a clip you can dropbox I can test it on a couple of boxes.
I'm afraid I can't comment on that model - it's not clear whether it has HDMI 2.0 or HDMI 1.4 output (I think that may be a motherboard issue as well as a SoC/CPU issue). As there are so many variables with Intel GPU HDMI implementations I think it's best for me to only talk about the model I know for sure does work - at least on initial testing.
LibreELEC-Generic.x86_64-9.80-devel-20200517175905-38764c8.img.gz
There is nothing new as far as HDR is concerned, only updated to a current Kodi master.
Many thanks - will give that a go. Will report back in more detail when I get a chance to play. I've ordered a cheap SSD to install in the spare 2.5" drive bay in the Hero Box so can dual boot Windows and LibreElec easily.
All the Intel HD600 series GPUs/VPUs support UHD/4K resolution h.265 and h.264 decode I believe.
However is the 4K content you want to play also HDR? If so then HDR support is not straightforward, not universal and is less to do with the Intel HD graphics version, and more to do with how the manufacturer and Intel have implemented the specific HDMI or DisplayPort output solution on the motherboard/SFF PC you are using.
If you want to watch SDR UHD/4K content then different rules apply.
Similarly Windows and Linux/LibreElec compatibility are different.
Well - I thought I'd take a punt on the cheapest Gemini Lake box I could find with quoted specs of HDMI 2.0 output (I wasn't sure about whether it used an LSPCon or not)
I bought the £179 Chuwi Herobox which has 8GB RAM and a 180GB Intel SSD, and a Quad Core Celeron N4100 CPU with HD600 Intel graphics. It comes with Windows 10 Home pre-installed (I haven't properly booted that yet) - but a USB live boot of LibreELEC-Generic.x86_64-9.80-devel-20200201013402-e776789.img.gz downloaded from this thread was the first thing I tried.
I don't have my AVR at the moment (it's in storage) - and haven't had time to check any audio stuff at all.
The first HDR10 2160p23.976 clip I played on it switched my TV into HDR10 EOTF mode (my Sony XF9005 switched into HDR mode and the test signal made sense and looked correct at first glance) This is pretty impressive! My HD Fury Vertex is also in storage so I haven't had time to confirm the exact format and check whether it's RGB, YCbCr 4:2:2 or 4:4:4, 8-bit, 10-bit or 12-bit. (You can send an HDR10 EOTF with 8-bit...)
Test clip from here HDR am TV: Testfilm zum kostenlosen Download - PC Magazin
I'll try some other stuff when I have more time tonight or tomorrow - but this is fantastic!
It's also fanless - so we'll see how that goes... (It also has an internal 2.5" SSD/HDD bay for a larger SSD or HDD, a VGA output, WiFi and Bluetooth, a uSD slot 2 x USB-A 3.0 front panel sockets, a USB-C - not sure if 3.0 or 2.0 on the front, 2 x USB 2.0 on the rear, along with a 3.5mm audio jack and DC input for a separate power brick, and it can be VESA mounted on the rear of a display with the included mounting bracket)
I've had far-from-great experiences with a previous Chuwi tablet - so YMMV - but for the price I thought it was worth a punt. I could/can always return it to Amazon if it hadn't been/isn't right for me.
Yes.
Yes. but the driver default to RGB 8-bit. A driver hack is required in order to switch to 2160p50/60 4:2:0 12-bit.
AMD behave a bit different - no 4:2:2 support either but the driver default to 4:2:0 12-bit for 2160p50/60 modes.
Great - so the industry standard for video production and post-production (4:2:2) - and the standard for connectivity in that area - is the one format that isn't supported...
I thought that was clarified back in February, not sure why you have to bring that up again.
4:2:2 is also irrelevant for any Intel hardware, not supported by the driver.
Apologies - I hadn't remembered I'd previously posted that information in the same forum.
So do Intel just support 4:2:0, 4:4:4 and RGB output?
If so then 4:2:0 is the only format that will support 2160p50/60 with >8-bit for HDR - unless you are in the realms of HDMI 2.1 (or was >8 bit RGB/4:4:4 added in HDMI 2.0b for 2160p50 and above)?
4K 4:2:0 with Deep color is not a part of HDMI spec. It should always be 8-bit.
No idea how to force YCbCr 4:4:4. Intel driver knows what's best for you and use RGB.
That's not correct, if by Deep Color you mean >8-bit bit depth. In fact it's quite the opposite.
4:2:0 is supported in 8, 10, 12 and 16-bin 2160p50/60 modes - it's the only sub-sampling format supported in all bit-depth outputs for 2160p50/60 modes. 4:2:0 was added to HDMI 2.0 - and is only supported for 2160p50/60 modes, with no support in 2160p24-30.
RGB/4:4:4 are only supported in 8-bit at 2160p50/60 - so whilst you may be able to flag an HDR EOTF with 2160p50/60 RGB/4:4:4 output - you can't output 10-bit sources in 10-bit or 12-bit in an RGB or 4:4:4 mode with a 2160p50/60 output format. (RGB/4:4:4 is only an option for HDR at 2160p24-30)
4:2:2 is the only >8 bit format supported for all 2160p frame rates - from 24p-60p. It is supported with 12-bit bit depth only. (So 8-bit SDR and 10-bit SDR or HDR (*) video is padded - there are no 8-bit, 10-bit or 16-bit onions for 4:2:2 output at any frame rate in the spec)
4:2:2 is thus the ideal preferred mode for 2160p HDR output - as it is supported at all frame rates. (This is why it is used by a lot of consumer products)
4:2:0 is the second best option for 2160p HDR output at 2160p50/60 - but can't be used for 2160p24-30.
4:4:4/RGB is only an option for 2160p HDR in 2160p24-30 modes.
Therefore if you can't use 4:2:2 for HDR output of 10-bit HDR material properly (i.e. without truncating to 8-bit) you have to use RGB/4:4:4 output for 2160p24-30, and 4:2:0 output for 2160p50/60. The only format supported in all frame rates is 4:2:2
See attached HDMI 2.0 timings chart downloaded from the HDMI site. HDMI 2.0b or HDMI 2.1 may have added >8-bit depth support for RGB/4:4:4 in 2160p50/60 modes - but it certainly wasn't supported in HDMI 2.0 (or 2.0a AFAIK)
(*) I watch quite a lot of self-mastered HD SDR 10-bit content - it looks so much nicer than 8-bit content covered in quantisation banding 
My pi3b can handle 10 bit HEVC files with MMAL disallowed, has trouble with it allowed but tries. No codec license.
My pi4b 1gb handles the file fine no MMAL.
I don't know what paying for the license would do on a pi3 or pi4.
You can't purchase codec licences for the Pi 4B - they are only available for the Pi 3B+ and below. It's assumed that MPEG2 and VC-1 (the two licensable codecs) can be decoded in software on the Pi 4B.
On the Pi 3B+ and below the MPEG2 and VC-1 software licences can reduce the CPU load on content that could otherwise be decoded in software, and for interlaced MPEG2 and VC-1 this can be significant. I'm not saying you need the licences - just that having them will reduce your CPU load (which in some cases may be desirable). On the single core Pis (Original A and B, A+ and B+, Zero, CM1 etc.) the hardware licences are even more important if you want to decode MPEG2 or VC-1 (particularly interlaced HD)
4K 4:2:0 with Deep color is not a part of HDMI spec. It should always be 8-bit.
No idea how to force YCbCr 4:4:4. Intel driver knows what's best for you and use RGB.
That's not correct. Image below from the HDMI.org website (Had to go to wayback machine as they have updated to HDMI 2.1)
HDMI :: Manufacturer :: HDMI 2.0 :: FAQ for HDMI 2.0
The HDMI 2.0 spec supports the following formats and bit depths :
2160p24-30 :
2160p50-60 :
So for 2160p24-30 4:2:0 is not supported at all and RGB, 4:4:4 and 4:2:2 are all supported at >8-bit depth. (4:2:2 is 12-bit only)
For 2160p50-60 RGB and 4:4:4 are only supported at 8-bit, so not suitable for HDR, whereas 4:2:0 supports all bit-depths, and 4:2:2 is 12-bit only.
For a single, fixed, chroma subsampling format at UHD for all frame rates , that supports HDR, 4:2:2 YCbCr 12-bit is the only option. (No problem outputting 10-bit content padded to 12-bit - that's what a lot of consumer electronics devices do)
Why do you need licenses for pi3 pi4? Mine work fine without. Only needed in the Dark Ages of pi1b maybe pi2 (don't recall on pi2 didn't have one).
Something wrong with hardware decoding?
I think it's fine for SD MPEG2 interlaced content - but decent deinterlacing of HD MPEG2 on a 3B may be pushing it. 4B will be fine I think (which is why they don't include an MPEG2 licence option for the 4B)
Software deinterlaced media will play terribly if forced to 25/29.97/30 modes as Kodi currently renders each half-frame as a whole frame, so you need the "double" refresh rate to get all the frames rendered. If you force 25Hz content to play on a (4k)30Hz mode you're probably missing 50% of the half-frames in the video stream. I have Kodi set to 1080p60 and I whitelisted the 4K resolutions and 1080p 23.976/24/50/59.79/60 modes. The GUI plane is rendered at 1080p by default so you won't see any real-world difference from having the resolution at 4k but the GUI takes less effort to render so navigation is a little snappier and Kodi will still switch to 4k modes if you play 4k media. If you mostly watch deinterlaced 1080p PAL media 1080p50 may be a better default as this avoids the 60>50 mode change.
Absolutely spot on - I have pretty much every LibreElec and CoreElec Kodi device I run configured like this, and watch a lot of interlaced content, but also quite a lot of 23.976/24Hz stuff, and some UHD/4K.
I have nothing in my whitelist and the "resolution" is 4096x2160p, "refresh rate" 30, "limit gui size 1080p.
If I whitelist 1920x1080p the TV switches resolution when I watch HD TV and it works, but is obviously slow to switch as it renegotiates.
But my TV won't take SD content like DVDs so can't pull the whitelist trick. Or any SD TV channels.
If you want decent deinterlacing of broadcast TV you need to ensure your refresh rate includes 50 and/or 59.94 modes (50 if you are in a 50Hz territory - Europe/Aus/NZ, most - if not all? - of Africa and lots of Asia and bits of South America, 59.94 if you are in a 60Hz territory like North America, Mexico Japan, Korea, Brazil and some other bits of Asia and South America)
2160p 30Hz modes are going to be very juddery for native interlaced content - which will be running at a higher rate than can be displayed cleanly at 30Hz.
I’m having this exact problem with an LG C9 and a Raspberry pi 4. Did anyone figure out what to look for when buying a cable/converter? Would appreciate not having to buy a bunch of different cables
A few posts earlier an Amazon Basics cable is said to be working when a Pimoroni Micro HDMI adaptor was not previously.
Apologies for necro-posting again - but I've been running both add ons listed here - KodiDisplayInfo (which uses web access to Kodi, but has far less advanced display functionality) and Kodisplay (which is the main topic of discussion here - but seems to be an internal add on only)
The advantage of KodisplayInfo using web access is that the SPI display and display code can be running on a small and cheap Pi Zero W or similar and SPI display, independent of your Kodi platform - which could be anything that supports LibreElec, CoreElec or Android Kodi I guess - and the Kodi device itself doesn't need to have SPI support and the code to drive SPI or similar displays.
The advantage of Kodisplay is that it has far, far more functionality and is far more extendible.
A question to those who know - is all the functionality available to an add-on, in Kodi status terms, available to an IP connected device via IP calls (JSON? http?) allowing an external device to be set-up as a comprehensive second display?
I've played with Frontvew+ on Windows on a little Windows tablet - and it also offers a lot of functionality - but doesn't quite do what I'd hoped.
(My aim is to have a bit more detail than the OpenVFD/LCDProc or similar displays - so PVR Channel logo and programme name, time elapsed/left bar graph for Live TV, Album art for Music - along with track number, track title and album title, time elapsed/left, movie name and art along with time elapsed/left etc. on a 2-3" display, possibly even something bigger like a DPI-connected Hyperpixel?)
Thanks for the prompt reply, Klojum. Makes sense, lightning symbol and all. Would never have thought so because I sent for the complete package from Amazon just so as I would get the proper PSU with it. Ah well, live and learn!
That's just a bunch of bits that a third party re-seller has collected to sell as a bundle. It's not an official complete package, and chances are the USB PSU they're bundling isn't particularly good, and it's not capable of delivering the required current and voltage.
I'd always recommend people to buy the Raspberry Pi official PSUs. They are good value and 'just work'.
https://www.amazon.co.uk/raspberry-pi-power-adapter-uk/dp/b01ccr5p8u/
Hi,
thanks for answer. I always had enabled audio passthrough and wanted to do all decoding in my receiver.
So passthrough isn't supported at all?
Is there any time window when it will be supported?
Thanks.
Only DD, DTS (and possibly DD+) passthrough is currently supported (same as original Pi models)
The new Pi 4B hardware supports 8 channel 192KHz PCM (so full lossless decode of all Dolby True HD and DTS HD MA/HRA HD Audio tracks) - and should support HD Audio passthrough when the software / firmware is written to support it (which is needed for True HD + Atmos and DTS:x support)
No timescale that I'm aware of. Until then it's lossless decode (which should be audibly the same unless your AVR does metadata driven processing - after all you're just moving the PCM decoding process from your AVR to your Pi - it has to happen somewhere in the chain)
