Posts by noggin

Quote from slappy

RPI4 development is a big deception. No 3D mvc support and no HDR after over one year. We will have it running at the same time everything will move to 8k or other newest tech. In the 2000 years the RPI development was able to catch up but not anymore. Better to go Vero 4k or stick with PC with madvr for 3D and 4K hdr.

I think it's deeply unfair to accuse the developers of 'deception'. They've always been pretty clear that these features will take time to implement and that time was not weeks but likely to be months or years.

The time it takes developers to implement features and support new hardware is simply the time it takes to do that. The more of us who work on supporting our colleagues in adding these features, or providing useful feedback, the better. None of us pay anything for Kodi or LibreElec - it's not a commercial product. We can't expect stuff to happen instantly just because we want it to.

HDR (HDR10 and HLG) with Rec 2020 Wide Colour Gamut colour is implemented for 2160p30 and below output in Pi4B nightlies and is working effectively. AIUI this is working using the mainline V4L2 Linux framework that should continue to be supported long-term. Most other HDR implementations on Linux are using workarounds that are likely to no longer be supported moving forward AIUI.

HD Audio bit streaming has also been supported in nightlies for quite a while now. progress.

I don't think HDR and HBR now working on a Pi 4B in nightlies is 'deception', it's a sign of good progress...

Quote from CvH

Post

RE: LE10 & deinterlacing in RPi4

[…]

Hi , Just tested 9.95.2 and found out that de-interlacing is not available yet. (Clearly "alpha" fits the description )

I just want to make sure you know de-interlacing is Top priority for PVR usage (and even playing old DVDs).

Not only without de-interlacing the playback is jaggy we are viewing it half fps which make a lot of content unwatchable.

While saying that keep up the great work and hoping to se de-interlacing support gets bumped up (I can help with testing if needed).

hagaygo

April 23, 2021 at 11:05 AM

Understood - and if it's all interlaced content - then that's pretty much everything I watch in Kodi!

TV Headend h.264 1080i25 stuff is the bulk of my viewing on my Pi Kodi clients.

(I'm not complaining - I know interlaced video is a pain and one that many wish would go away, but it hasn't yet..)

Quote from chewitt

The obvious solution is to re-encode legacy formats into modern formats so they are playable on the modern device.

Though to be fair interlaced MPEG2 isn't a legacy format- it's a current broadcast format, as is DVD (there are still significant numbers of commercial releases that are DVD-only and don't include Blu-ray)

Quote from smp

What is the advantage of bitstreaming the audio vs.sending the decoded LPCM to AVR? Just trying to understand why people care so much about audio passthrough. I'd like to hear a valid technical reason why bitstreaming is supposed to be better than decoding to LPCM. Since Kodi can decode all known HBR audio formats and send LPCM 7.1 over HDMI I don't see a single good reason why anyone should bother with passthrough.

Two reasons mainly :

1. Spatial audio like Dolby True HD with Atmos and DTS:x can't be decoded to PCM without losing the height information - they need to be bitstreamed with passthrough for the extensions to be decoded by an AVR alongside the spatial metadata. If you decode in Kodi you end up with just straight 5.1 or 7.1 - rather than 5.1.2, 5.1.4, 7.1.2, 7.1.4, 9.1.2 etc. you'd get with a receiver fed a bitstream which contains additional audio content and additional object metadata etc.

2. When you bitstream even non-spatial audio, you still pass through additional metadata alongside the audio - containing information like Dialogue Normalisation values, Line/RF mode compression, Centre and Surround downmix levels, Lt/Rt vs Lo/Ro downmix, original mastering information etc. etc. These all provide additional information that can inform processing in the AVR that is just not present with PCM 5.1/7.1. If you output PCM 5.1/7.1 the receiver doesn't receive this metadata. In some situations this may not be an issue - but if you want to do any dynamic range processing, any down- or up-mixing etc., or want to follow the Dolby spec properly, then PCM won't help.

dolby-metadata-guide.pdf

(The above talks about both Dolby E and Dolby Digital - but gives a good overview of the use of metadata)

In some ways you can think of some of the DD metadata as a bit like the HDR10 metadata that is used with HDR video - it provides the output device with more information than just the picture or audio samples that let output devices optimise things based on information from the person who mastered that content.

Quote from nsnhd

Ok, it's sad. So, if not the RPi4, then any other box running LibreElec or CoreElec could do tone-mapping better ? Lots of HDR stuffs are there and I dont want to buy any HDR display soon.

You will almost universally find that a 1080p Rec 709 SDR movie will look nicer played back on a 4K SDR display than a 4k HDR Rec 2020 movie tone mapped to 4K SDR.

HDR->SDR tone mapping is essentially a lossy process and the decisions taken when grading content for an HDR display both usually mean that the end result is often sub-ideal in most situations.

If your display is also Rec 709 only and can't cope with Rec 2020 wide colour gamut - you also have to contend with tone mapping to reduce the colour gamut of the Rec 2020 source.

Tone-mapping on replay on a consumer device is an automatic process, whereas the grading process that generates the Rec 709 SDR 1080p version of a movie, even if starting from a UHD Rec 2020 HDR master, will have a degree of optimisation and care taken over it (and information is available to the conversion process that isn't available to an end consumer). (DV could - in theory - provide more optimisation - but I don't know how many DV playback devices do anything special for SDR displays)

Quote from Phoskam

The other hdr stuff I watch is mostly dolby vision on Netflix or hdr movies on YouTube.

Both of these look much brighter, especially dolby vision.

Tonight were going to watch a movie, then the living room is also much darker.

There should be no significant difference in brightness watching the same content on Netflix in HDR10 or DolbyVision - the DV version should optimise better for your display and may display some scenes subtly differently to the HDR10 version - but the overall brightness should be very similar. (The DV metadata carries information scene-by-scene (or shot-by-shot) to assist your TV in tone mapping stuff it can't display correctly, whereas HDR10 stuff just has basic metadata for the whole show or movie)

If you are saying one series you have watched in HDR10 doesn't look as bright as a different series you have watched in DolbyVision - well that's comparing apples with oranges (as the two series will have been graded separately with different grading decisions taken about SDR content vs HDR content in the HDR10 and DV grade)

HDR10 and DV are conventionally graded to keep the SDR elements in the 100nit range, only going over 100nits for highlight detail, speculars etc. that in SDR would be clipped to peak (or have to be heavily compressed down to retain detail). Some people grading content will push more conventional SDR stuff into the HDR range to make it 'look HDR' - Amazon's 'The Man In The High Castle' was a real offender in that regard ISTR. However most shows keep the HDR range just for 'HDR' stuff.

One difference between DV and HDR10 is that many TVs allow you to adjust far more picture settings when displaying HDR10 than they do with DV (with DV taking more 'control' over your display settings when displaying DV content)

Quote from HiassofT

IIRC tone mapping is only supported in Kodi for Windows (via d3d shaders) and Android (via the mediacodec framework, if implemented by a device). I've read reports that it works fine on the Nvidia Shield, not sure about other devices.

so long,

Hias

I think AMLogic devices in CoreElec have some degree of Tonemapping for HDR->SDR conversion too, as well as HLG->HDR10 conversion.

Quote from harun-cuk17

First I make a new fresh install of:

LibreELEC-RPi4.arm-10.0-nightly-20210417-e3f1165.img

After that I put your file:

LibreELEC-RPi4.arm-10.0-devel-20210409193846-98e0bda

in the UPDATE folder to update

But When open HDR video the colors are still dark I think. Maybe it is the video itself. Do you have any tips to change in the settings or do you have a sample file that I could test?

So long

Display More

Do you have the same video on an original source - comparing an HDR10 UHD Blu-ray played on a UHD Blu-ray player, compared with the same disc ripped as a file (without remastering/transcoding) and played back on the Pi 4B would be the obvious route.

What I can say is that the video levels leaving the Pi 4B are what is expected within the standard, and the EOTF is being correctly flagged.

I haven't checked what the MaxCLL and MaxFALL and mastering metadata situation is - but I wouldn't expect that to change the replay level (though it may change how highlights are treated)

(As I've said above - HDR content is often accused of being too dark when it follows the official HDR10 specs, largely because the specs are based on the SDR range - 0-100nits - being unrealistically low for domestic settings, and the reality is that people watch SDR content at far brighter levels than the spec is based on, meaning they watch SDR pushed well into the HDR10 HDR range of >100 nits)

Properly mastered SDR will keep almost all content but highlights and speculars in the 0-100nit range - so HDR often appears dark as a result (particularly HDR10 content that has a set-in-stone video level to light level mapping, unlike HLG)

Quote from Phoskam

Working for me now, my Sony 65XE9305 switches to hdr, but only thing is that in hdr the overall image looks pretty dark.

Is there a way to up the brightness in libreelec/kodi somewhere in the settings?

Have you watched the same content in HDR via alternate sources such as a UHD HDR Blu-ray player? Is that brighter?

If not - then chances are you're just seeing the normally reported issue with HDR10 from people who have HDR TVs but normally watch SDR on them.

Most people with HDR displays are watching SDR content with the SDR peak brightness pushed well into the HDR range of brightness levels. The SDR range in HDR10 (and other specs) is officially 0-100nits (i.e. anything over 100nits is reserved for HDR speculars, detail in bright areas etc.). However this feels really dim to many people watching in regular light level rooms, and the reality is that most people watching SDR will have their peak SDR well over 100nits on an HDR TV.

As a result HDR stuff (which will keep most of the detail in the SDR range of 0-100nits) often looks a lot darker than people are expecting (particularly as many people think HDR = brighter picture, rather than more detail in highlights)

This is also somewhat complicated by HDR10 officially using PQ (Perceptive Quantisation) where the ST.2084 EOTF (video level - > display light level conversion) according to the standard is fixed to a 1:1 mapping - rather than relative (like SDR and HLG HDR) - so in theory you shouldn't be able to make an HDR picture brighter or darker with user controls (as that stops it being properly compliant with the HDR10 spec). (*)

Of course you will often find this can be overridden on many TVs - though it does mean that you are then likely to be clipping/squeezing more and more HDR detail (reducing the benefits of the HDR source), as the brighter you make the SDR picture, the less dynamic range you have left for the HDR elements.

Dolby Vision modes on TVs often go one step further and specifically stop you altering the display brightness levels at all.

(*) Arguably this is why HLG HDR makes a tonne more sense for domestic viewing (particularly as it has ambient light compensation built into the standard - rather than bolted on as a bolted-on afterthought like Dolby Vision IQ)

Changing the brightness/contrast of an image should really be a display function not a Kodi function?

Quote from HiassofT

Awesome, this is really good news! Huge thanks for going through all the effort and checking this!

so long,

Hias

No problem. I'm not a Resolve Expert - but things do look good.

Next step - 10-bit RGB (2160p30 and below) and/or YCbCr 4:2:2 12-bit so we can have HDR (and SDR 10-bit) at all frame rates

(Interesting that some OTT providers are now using h.265 10-bit SDR for some content - SVT Play in Sweden are - as a route to higher quality SDR with far less banding than 8-bit SDR. 10-bit isn't restricted to HDR these days - it has benefits for SDR too )

Update - just compared the captured bars from the Pi 4B, playing back an h.265 conversion of the source file from the EBU, along with the native bars from the EBU test file in Resolve and they appear identical. I think this suggests that things are good.

I transcoded the EBU v210 source to h.265 using libx265 with the following ffmpeg command, played it on the Pi 4B and captured the result in RGB 10-bit uncompressed :

ffmpeg -i "EBU_HDR_COLOUR_BARS_2160p_v210.mov" -filter_complex loop=loop=20:size=100 -codec:v libx265 -crf 15 -pix_fmt yuv420p10le -color_primaries bt2020 -colorspace bt2020_ncl -color_trc arib-std-b67 "EBU_HDR_COLOUR_BARS_2160p_v210.2020hlg.mov"

(You have to tell ffmpeg the colour space and EOTF to flag on the output - but those flags don't process the video, they just add metadata AIUI)

OK - for some reason I had to capture in 10-bit RGB Uncompressed rather than 10-bit YCbCr... Anyway - first glance suggests that the 75% Rec 2020 bars are in the right place on Da Vinci Resolve's vector scope (i.e. in the 75% RGBYCM squares). I'm not a DaVinci Resolve expert by any means - but with a Rec 2020 timeline, and a capture that is correctly flagged as Rec 2020 in Media Info, then I think this is looking good.

On the luminance ramp below the 4 sets of colour bars you can clearly see truncation to 8-bits from the 10-bit source.

Video
ID                                       : 1
Format                                   : RGB
Codec ID                                 : r210
Codec ID/Hint                            : Blackmagic Design
Bit rate mode                            : Constant
Bit rate                                 : 6 636 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUV
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 32.000
Stream size                              : 1.76 GiB (100%)
Language                                 : English
Encoded date                             : UTC 2021-04-15 10:51:44
Tagged date                              : UTC 2021-04-15 10:51:44
Color primaries                          : BT.2020
Transfer characteristics                 : HLG
Matrix coefficients                      : BT.2020 non-constant

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.

Quote from HiassofT

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

Display More

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)

Quote from HiassofT

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)

Quote from HiassofT

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?

Quote from LcSz

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

2021-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.317466

Display More

As 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)

Quote from HiassofT

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

Display More

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?

Quote from marantz

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)