Hmm - may need to check out my capture solution. I can capture 2160p25 Rec 709 Kodi menus, but the minute the Pi 4B goes into Rec 2020 HLG mode I can see an output, but Media Express (Black Magic recording application) doesn't work properly and just records audio. (The TV I'm feeding via an HDMI splitter still goes into HDR Rec 2020 mode). Will check my software version. I've captured 2160p50 Rec 2020 HLG using this set-up before - so I know it will capture and record Rec 2020 HLG stuff.
Posts by noggin
-
-
Display More
Here's a new testbuild, now with - hopefully - correct BT.2020 YCC->RGB conversion matrix:
LibreELEC-RPi4.arm-10.0-devel-20210412194217-d08d2e1.tar
noggin do you have a possibility to verify with your HD-fury if the conversion matrix is OK now? popcornmix's HDMI analyzer doesn't seem to have picture/color analysis features and visual testing is quite a PITA as I don't have an easy-to-use known-good reference to compare against (my TV's built-in player sucks, it completely exits after switching to HDMI input so I can't easily switch back-and-forth).
Of course feedback from others is highly welcome, too!
so long,
Hias
My HD Fury Vertex won't do that (as the RGB/YCbCr conversion matrix isn't an HDMI-signalled thing, as downstream devices don't need to know it) - but I MAY be able to grab the same Rec 2020 content via two player routes (Pi 4B vs Sony UHD BD player or AMLogic CoreElec box etc.) using a Black Magic 4K HDMI capture card if I get a chance, and then compare the results in Davinci Resolve Studio (Vector Scope images and pixel values should both be testable there).
I'll see if I've got Rec 2020 colour bars as a file on one of my test file archives.
** EDIT - The EBU have their nice new colour bars in 4:2:2 v210 10-bit HLG Rec 2020 format here : EBU Technology & Innovation - Colour Bars for use in the Production of Hybrid-Log Gamma (HDR) UHDTV
And they document the YCbCr snd RGB pixel values they should hit in the various areas in the PDF - in 10-bit (so divide by 4 for 8 bit)
These bars are also good for checking Rec 709 SDR tone-maps using both Scene Light and Display Light conversions **
(However BlackMagic HDMI captures from an RGB source may differ from those in YCbCr - they don't have the best reputation in this regard - and my other player may well be YCbCr native output - which is more usual for video players)
-
Sorry, I should have better avoided the term "whitepoint" in this context. What I meant was what you mentioned later, due to the wrong matrix the RGB values won't be quite correct, colors skewed, and white won't be white.
4kp50/60 output isn't implemented in this build, this is still in the queue (we tested an early patch a few weeks ago but it's not 100% there yet).
4kp50/60 HEVC decoding is more performant now, so 1080p50/60 output of such files will be a lot better (previously the decoder couldn't keep up resulting in a/v sync drifting away). These optimizations are still WIP but testing showed it's already mostly working fine.
so long,
Hias
Haven't tested 2160p50 HEVC yet - but ~45Mbs 1080p50 HEVC SDR 10-bit files are decoding and playing back very nicely (albeit in 8-bit)
-
The build also contains current WIP HEVC optimizations and latest kodi Matrix changes. High-bitrate and 50/60fps HEVC videos should perform better now but beware, there might still be bugs
Hias
Is 2160p50/59.94/60 output now supported in these builds? Or is this note about high bitrate & 50/60fps content just for output at 1080p50/59.94/60 and below?
-
Hi,
Thank you for the release,
It doesn't seems to work for me, I still see RGB 24 bits on my AV.
I have the following message :
Code
Display More2021-04-11 11:56:17.419 T:922 DEBUG <general>: CVideoLayerBridgeDRMPRIME::Configure - setting connector colorspace to BT2020_RGB 2021-04-11 11:56:17.423 T:922 DEBUG <general>: EGL Debugging: Error: EGL_BAD_SURFACE Command: eglSwapBuffers Type: EGL_DEBUG_MSG_ERROR_KHR Message: dri2_swap_buffers 2021-04-11 11:56:17.423 T:922 DEBUG <general>: CDRMAtomic::FlipPage - Execute modeset at next commit 2021-04-11 11:56:17.448 T:922 DEBUG <general>: CWinSystemGbmGLESContext::PresentRender - Sending display reset to all clients 2021-04-11 11:56:17.449 T:922 INFO <general>: VideoPlayer: OnResetDisplay received 2021-04-11 11:56:17.449 T:1095 DEBUG <general>: CVideoPlayerVideo - CDVDMsg::GENERAL_PAUSE: 0 2021-04-11 11:56:17.454 T:1090 DEBUG <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_PAUSE: 1 2021-04-11 11:56:17.454 T:1090 DEBUG <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_PAUSE: 0 2021-04-11 11:56:17.469 T:939 DEBUG <general>: OnAVChange: CApplication::OnAVChange 2021-04-11 11:56:18.552 T:1090 DEBUG <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:36434.317466, adjusted:36434.317466As HiassofT said - the output is still 8-bit (so will be RGB 24 bit if your AVR reports that) not 10- or 12-bit.
However it is now correctly flagged with Rec 2020 colour gamut, rather than Rec 709 :
"DEBUG <general>: CVideoLayerBridgeDRMPRIME::Configure - setting connector colorspace to BT2020_RGB"
So the colour primaries flagged to your display are now correct, as well as an HDR EOTF also being flagged (so the for HDR10 content the connected display will now go into Rec 2020 AND HDR mode, using a PQ/ST.2084 EOTF - i.e. the right wide colour gamut and the right dynamic range)
What isn't yet happening is 10-bit or 12-bit output (so the 10-bit HDR HEVC video is truncated to 8-bits, losing the two least-significant bits - potentially causing banding) and also the RGB<->YCbCr matrix being used is likely to be that for Rec 709 rather than Rec 2020 (the two standards use different matrixes to convert between the RGB that Kodi uses - and currently outputs - and the YCbCr video carried in the HEVC codec)
-
Display More
If you are in the mood for some experimental testing here's a new testbuild to try:
LibreELEC-RPi4.arm-10.0-devel-20210409193846-98e0bda.tar
Kodi and video driver now signal BT.2020 colorspace, my LG C8 now shows BT.2020 in status info (which it didn't before).
Conversion matrix in video driver is unchanged so whitepoint most certainly isn't right. 10/12bit output is still missing as well, but hopefully we're one step closer to correct HDR output.
The build also contains current WIP HEVC optimizations and latest kodi Matrix changes. High-bitrate and 50/60fps HEVC videos should perform better now but beware, there might still be bugs
so long,
Hias
Just tested - 2160p25 10-bit HEVC Rec 2020 HLG content is output 2160p25 RGB 8-bit Rec2020 flagged and with an HLG ARIB B67 EOTF. Progress!
Not sure I get the 'whitepoint' stuff - the whitepoint metadata (which is I think the CIE x and y co-ordinates of the mastering whitepoint used in the grading process) carried in HDMI InfoFrames (and in the HEVC video) is separate to the RGB<->YCbCr matrix stuff ? (This is the HDMI Infoframe stuff that is carried along with stuff like MaxCLL and MaxFALL mastering data in HDR10/PQ stuff)
However in the Rec 2020 YCbCr<->RGB matrix there is more Red and less Green and less Blue contribution to the Y signal - so if you use a Rec 709 matrix instead I think you'll get a picture skewed less red and more green/blue than it should be?
-
HDR doesnt work for anyone yet (rpi4 libreelec), they just think it does.I thought so too before comparing clips with lots of red with my tvs build in player vs libreelec.
hias told us to wait some more.
That's not 100% correct. HDR works - but Rec 2020 doesn't.
HDR works OK - the EOTF (Electro Optical Transfer Function) is correctly signalled over HDMI switching your TV from SDR to either PQ/ST.2084 or HLG/ARIB-B67 HDR display modes. This is what makes the video use the HDR range of the display rather than the SDR range, and it is flagged correctly.
HOWEVER - most HDR content is also in Rec 2020 colour gamut (i.e. Wide Colour Gamut) rather than the Rec 709 colour gamut used for HD SDR (and which is also similar to the colour gamut used for SD video too). The colour gamut defines the actual colours that the Red, Green and Blue primary colours used in a video signal are - and Rec 2020 effectively defines 'redder reds', 'greener greens' etc.
The Pi 4B HDR implementation currently DOESN'T send the correct Colour Gamut flags for Rec 2020 content - so you get the correct HDR EOTF (and your TV switches into HDR mode) but the video is treated by most TVs as Rec 709 (so appears to have far less vibrant colours). Some of us can force our TVs into Rec 2020 mode using a menu option - which gets much closer to showing HDR10 correctly.
(It may be that some models of TV automatically switch to Rec 2020 when they detect an HDR EOTF - which may be why some people are happier than others)
-
My Sony is not switching .... as long as I tell him to do so.
<snip>
This leads, in my case, to normal videos with colour space 'auto' and HDR videos with bt.2020.
Yes - this is a known issue.
At the moment the Pi 4B builds correctly send the HDR EOTF (HLG/ARIB B-67 or HDR10/ST.2084) signal to switch the TV from SDR mode into the right HDR mode.
However the other requirement for most HDR material (and all HDR10 material) is to switch from Rec 709 to Rec 2020 colour gamut (which is the Wide Colour Gamut used for all HDR10 and most other HDR content). The Rec 2020 colour gamut can be manually forced on your Sony TV, as it can be on mine.
That gets the colour into the right gamut for HDR10.
The two other issues are that the output is still RGB 8-bit not 10-bit - so banding is more likely to be an issue - and if the gamut is flagged as Rec 709 then there is no guarantee that the YCbCr->RGB colour matrices used to generate the RGB won't also still be the Rec 709 ones (which are slightly different to the Rec 2020 ones)
Rec 709 : Y = 0.2126 x R + 0.7152 x G + 0.0722 x B
Rec 2020 : Y = 0.2627 x R + 0.678 x G + 0.0593 x B
UHD TVs don't automatically assume all UHD inputs are Rec 2020 though - as some (most?) SDR UHD content is often still in Rec 709 gamut (the same gamut used for HD)
(For reference the SD Rec 601 RGB->YCbCr matrix is also different - Y = 0.299 x R + 0.587 x G + 0.114 x B)
-
That link was great. I stumbled across it yesterday when trying to fix HDR on my AVR X4200. The step which worked for me was:
"Disable the video conversion in the AVR."
Something as simple as that (default) setting was killing HDR, resulting in washed-out colors.
Now to see if my new RPi 4 with LE can reliably play 4K content for entire movies (my S912 with CoreElec struggled).
Cheers, Carl
I believe you may still be getting sub-par colours in the current Pi 4 HDR builds - as I don't believe Rec 2020 gamut (which is the gamut HDR10 and the 'in the wild' HLG uses) is being flagged, so whilst the colours look less washed-out than when the HDR EOTF was being blocked (and your PQ ST.2084 content was being displayed in SDR), the Pi 4 still outputs Rec 2020 as Rec 709.
Some TVs may switch to Rec 2020 when they detect an HDR EOTF I guess (though that's a bit of an 'out of spec' guess), but certainly my Sony TV will display Rec 709 gamut stuff in Rec 709 with an HDR EOTF (which means the colours will be less vibrant than if correctly flagged as Rec 2020 - which I can manually force and which brings things closer to what they should look like) (*)
(*) The YCbCr->RGB matrixes used for Rec 709 and Rec 2020 are slightly different - but the differences between them will be harder to tell. (The difference between Rec 601 SD and Rec 709 HD are more marked ISTR)
-
I was talking about 50/60Hz 4K modes. 12-bit works with 2160p/24/30Hz.
That's good progress - ISTR that in the earlier days it was 8-bit + dither for <50Hz 2160p modes too. I guess this is with RGB or YCbCr 4:4:4? (And not 4:2:2 ?)
For 2160p50 and above, if 4:2:2 isn't supported, then 4:2:0 will be the only HDMI 2.0 option for >8 bit output I guess (as 4:4:4/YCbCr is 8-bit only at 2160p50 and above in the specs - you have to use 4:2:0 or 4:2:2 for >8-bit output at 2160p50 and above)
-
chewitt .. quick question, i saw this on the LE blog "We are pretty confident RPi4 users will like the update since it brings HBR audio and initial HDR video support" .. what exactly does initial support mean?
So has anyone done "proper" passthru audio testing of the build in 502? Like does it finally fix the split second audio drop that occurs every few mintues?
Off topic - but the initial support I've seen for HDR on the Pi 4B means that it detects an ST.2084/PQ or ARIB-B67/HLG EOTF flagged (i.e. HDR10 or HLG) in a video file and correctly flags this over HDMI.
However at the moment it doesn't correctly detect and/or flag Rec 2020 video - so Rec 2020 content is output flagged as Rec 709 (or not flagged as Rec 2020). I've not been able to check whether a Rec 2020 or Rec 709 YCbCr->RGB conversion matrix is used for Rec 2020 video (They aren't the same)
At the moment I believe video output is restricted to RGB 8-bit too - so no 10-bit replay path yet.
So you get the correct EOTF flagged, but not the correct Colour Gamut, and with 8-bit not 10-bit or 12-bit output.
It's very early days - and the Pi Developers work through things methodically to deliver the best results they can with their available effort.
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.
Good news that 2160p60 is now supported.
YCbCr in 4:2:0 10-bit or 12-bit would be a good route to full 10-bit HDR output I guess. Dithering is a compromise that adds noise to hide banding. (Is the dithering done at output frame rate or source frame rate?)
-
Is there any update on a 10-bit replay path, 2160p60Hz output and/or 4:2:2 or 4:2:2 support?
Last time I trialled the Intel HDR route it was still 8-bit RGB only with an HDR EOTF ?
-
It's very unlikely you can hear a difference between HD audio formats and LPCM
However it's entirely possible that you can hear the difference between an AVR decode that also has the right metadata available to it to assist in additional processing (DialNorm, dynamic range compression information etc.) that is present in the bitstreamed version and an upstream decode to PCM where that metadata is discarded and not available to the AVR.
Dolby and DTS audio streams contain that metadata to allow the AVR to 'know' more about the audio than just the basic audio stream content.
The other big difference is that Atmos and DTS:x aren't carried as basic PCM - so that's another major reason to favour bitstreaming/passthrough over PCM decode upstream.
-
All of my HDR content is washed out. Is there a setting I need to get hdr working? I've tried the nightlies from the last few days only.
EDIT: I just noticed its a known problem, but I don't understand why it works for some people and not others.
I think some people may not see the gamut mismatch - where Rec 2020 content (which is pretty much all the HDR10 and HLG out in the wild apart from DIY stuff) designed for much wider gamut primaries is displayed with Rec 709 primaries (giving you far less vibrant colours)
If you aren't comparing with the content displayed properly - you may not see it as an issue. (Or maybe some TVs automatically go into Rec 2020 mode, incorrectly, when they see an HDR EOTF flagged over HDMI, even if there isn't a Rec 2020 flag present)
-
Froggy please read this topic and also this one:
Nightly builds Rpi4 Audio passthrough TrueHD/Master HD not working (huge stutter) anymore
In general, the test builds of libreelec are capable of handling 4k uhd, atmos passthrough but there are still some issues.
Yes. Worth pointing out that the only codec supported at 4K UHD is h.265/HEVC (h.264/AVC is still only supported for 1080p (*)) and that a lot of UHD h.265/HEVC content is also HDR10.
HDR replay is still very much a work-in-progress on the Pi 4B. They have HDR modes being triggered on TVs (i.e. the HDMI signals an HDR10 or HLG EOTF) but they have still got issues flagging Rec 2020 instead of Rec 709 primaries (so images look less colourful), and the output of 10-bit video is still 8-bit RGB (so you will potentially see banding, which 10-bit is designed to minimise)
(*) h.264/AVC decoding is handled by the legacy video decoder module that is largely the same as that on the previous generations of Pi, h.265/HEVC support was added via a separate module. (MPEG2 and VC-1 support is now software only, as the Pi foundation don't offer hardware decode licences for these codecs for the Pi 4B)
-
The encode option wasn't displayed in advanced or expert profile in the passthru section until I did a return to default values. To my surprise it appeared. bug maybe? Anyhow The transcoding works well. Just an observation. the screen blanks momentarily when changing settings.
Thanks again.
Chook
The Enable Transcode option may only appear if you have 2.0 output configured - as otherwise it is assumed that you'd prefer the higher quality PCM 5.1 output option I think. (The 2.0/5.1/7.1 output setting is really your PCM/analogue output config and isn't related to your passthrough/bitstream speaker config).
If you are using Toslink or ARC which is similarly limited to PCM 2.0 and SPDIF/Toslink bandwidth DD/AC3 (and in some cases DTS) then configuring for 2.0 should bring up the option for transcoding to DD/AC3 underneath the Bitstream DD/AC3 option.
-
OK - have installed the latest nightly LibreELEC-RPi4.arm-9.80-nightly-20210220-f768c9b downloaded this morning.
Running in 1080p mode (to allow >30fps content to be output) my 2160p50/59.94 files largely play - and HDR10 Rec 2020 stuff is played with a PQ ST.2084 EOTF (aka HDR10 HDR) but the output is 8 bit RGB and it looks as if it is being flagged as Rec 709 gamut (so colours are less vibrant as they are using the narrower primaries).
Content I have that flags 1000, 4000 and 10000 nit mastering displays correctly sends this metadata (as confirmed by my HD Fury Vertex)
I'm playing the content from a Samsung Evo+ 64GB uSD card and I'd say I'm getting some dropped frames on p50 and p59.94 content - though whether this is throttling because of high bitrate on the storage or on the HEVC decode and scale down to 1080p I can't say.
I've yet to see any YCbCr 4:2:2 output at any bit depth - I don't know if there is a config.txt or LibreElec setting (or something I can type in at command line level via SSH) to enable YCbCr 4:2:2 output?
HLG content appears to correctly trigger an HLG EOTF (i.e. ARIB B-67 EOTF) - though AIUI BBC iPlayer 1080p SDR and 720p-2160p HDR streams (iPlayer uses HLG for HDR) may now be DRMed preventing playback on non-certified devices.
I can force my TV into Rec 2020 gamut and that makes things look quite a lot better - though I can't say whether Rec 709 or Rec 2020 YCbCr->RGB matrices are being used (the differences are quite small between the two)
I can also only play a couple of files before playback stops working (I get left in the GUI with a play icon top of frame with the name of the file being played, but no video and have to reboot)
-
Display More
Hi HiassofT
my fault, i ask this not about Pi4. My AVR (Denon X4100) has HDMI 2.0 but only HDCP 1.4.
If i go from PI --> AVR --> TV i get no HDR.
If i go from PI --> TV i get HDR.
Is it not possible with HDCP 1.4 to get HDR?
I tried a HDCP Converter, but this doesnt work too.
If your AVR has HDMI 2.0 support but only supports HDCP 1.4 (and not HDCP 2.2) then that could mean it was one of the first gen UHD AVRs that had HDMI 1.4 inputs and outputs in hardware terms but that got very basic HDMI 2.0 support added (in the same way nVidia added HDMI 2.0 support to their HDMI 1.4 Graphics cards and Sony added HDMI 2.0 to existing HDMI 1.4 UHD TVs via a software upgrade)
The way they did this was to add support for just the 4:2:0 HDMI 2.0 mode for 2160p50 and 2160p60 modes - as HDMI 1.4b already supported 2160p23.976-30 at 8-bit in SDR using 4:4:4/RGB and 12-bit using 4:2:2 (though this mode may not have been supported).
Using the 4:2:0 subsampling introduced with HDMI 2.0 allowed HDMI 2.0 4:2:0 2160p50 and 60 modes to fit into the hardware restrictions of an HDMI 1.4b connection (i.e. you could add HDMI 2.0 basic compatibility using HDMI 1.4b hardware). AIUI this was 8-bit SDR only, and that may also have been true of the HDMI 1.4b 2160p30 and below support also supported. (i.e. you get UHD support at all frame rates in 8-bit, but you don't get HDR support as that would require 10 or 12-bit support - which may not be implemented)
The Pi 4B doesn't support 4:2:0 HDMI output as I understand it (as it would require both vertical and horizontal subsampling of chroma - and the Pi can only really do horizontal (?)
This may also mean your AVR is not HDR compatible ("passthrough" in AVRs isn't helpful in that regard)
The lack of HDCP 2.2 support is a strong suggestion that your AVR is one of those early HDMI 1.4 models that got a partial upgrade to HDMI 2.0 - though I may be wrong.
