Posts by noggin

Quote from silentsound

Do you have any recommendations on that? I've only ever used Handbrake, not sure if it can strip HDR meta data off a file.

Afraid it's not just stripping metadata off - it's a case of transcoding and tone mapping from Rec 2020 PQ (aka HDR1) to Rec 709 SDR at the same time.

HDR10 content is almost always in a new, wider gamut, Rec 2020 colour-space (i.e. based around different Red, Green and Blue primary colours that are redder, greener and bluer), whereas most SDR UHD content is in the same colour space as HD (Rec 709), and HDR10 has a totally different way of handling video levels from black to the brightest whites to SDR (that's what gives it the HDR-ness). Because conversion of HDR Rec 2020 to SDR Rec 709 requires converting colours that can't be shown in Rec 709, it requires some reasonably complex processing to reduce the visibility of the lost content in the conversion process (so that hues don't change and highlights and lowlights don't get totally lost)

This requires a process called Tone Mapping - which means the h265 UHD video needs to be decoded, tone mapped, and then re-encoded to h265 (the Pi 4B won't play UHD h264) for playback in UHD SDR on a Pi 4B.

If your SDR UHD display supports Rec 2020 then you only need to convert the dynamic range (or EOTF) not the colour space - but I think most SDR UHD displays are usually also Rec 709 only.

I believe ffmpeg includes some functionality that may help with this : https://forum.doom9.org/showthread.php?t=175125 is a thread detailing some approaches - I've not tried them.

You'll need a pretty beefy CPU and/or hardware GPU acceleration on an x86 platform to do this transcoding at a reasonable speed I suspect.

Quote from g7ruh

Yes I am happy to try it.

I have two, one in the case and one 'barebones'. I modified the case with a heatsink for CM3 to connect CPU to case via some copper when I upgraded.

Pictures here:CM3 heatsink

It runs quite warm especially with video, so a CM4 may well be more of a heat problem, apart from if it will work with Libreelec / Kodi.

Mine are used nearly every day for music streaming or for playing my FLAC based music collection. Occasional use for video.

Roger

Display More

Yep - I upgraded my Slice with a CM3 and a heatsink - but it doesn't get much use at the moment I'm afraid

Quote from heitbaum

Here are a couple of channels (Melbourne Australia) via Jellyfin / HDHomeRun Quatro

Channel 2 - ABC TV

Code

/videos/d416a5a9-b0e4-4114-f4b1-5d1f0c74232c/live.m3u8

{"Protocol":1,"Id":"native_bbba5a6de96521ff4b73e891b4afe6e8_19bc6d59fc4da242e1841cb157dbe97a","Path":"http://192.168.42.63:8096/LiveTv/LiveStreamFiles/8630d86ba17d49f289dd4abf962984de/stream.ts","EncoderPath":null,"EncoderProtocol":null,"Type":0,"Container":"mpegts","Size":null,"Name":null,"IsRemote":false,"ETag":null,"RunTimeTicks":null,"ReadAtNativeFramerate":false,"IgnoreDts":true,"IgnoreIndex":false,"GenPtsInput":false,"SupportsTranscoding":true,"SupportsDirectStream":true,"SupportsDirectPlay":false,"IsInfiniteStream":true,"RequiresOpening":true,"OpenToken":null,"RequiresClosing":true,"LiveStreamId":"a17c75760a04e99b68cf766e11316e1c_09efa0d56b934a82adec00a87b837fb0_native_bbba5a6de96521ff4b73e891b4afe6e8_19bc6d59fc4da242e1841cb157dbe97a","BufferMs":0,"RequiresLooping":false,"SupportsProbing":true,"VideoType":null,"IsoType":null,"Video3DFormat":null,"MediaStreams":[{"Codec":"mpeg2video","CodecTag":null,"Language":null,"ColorRange":"tv","ColorSpace":"bt470bg","ColorTransfer":"bt470bg","ColorPrimaries":"bt470bg","Comment":null,"TimeBase":"1/90000","CodecTimeBase":null,"Title":null,"VideoRange":"SDR","LocalizedUndefined":null,"LocalizedDefault":null,"LocalizedForced":null,"LocalizedExternal":null,"DisplayTitle":"576i MPEG2VIDEO SDR","NalLengthSize":null,"IsInterlaced":true,"IsAVC":null,"ChannelLayout":null,"BitRate":2000000,"BitDepth":8,"RefFrames":1,"PacketLength":null,"Channels":null,"SampleRate":null,"IsDefault":false,"IsForced":false,"Height":576,"Width":720,"AverageFrameRate":25,"RealFrameRate":25,"Profile":"Main","Type":1,"AspectRatio":"16:9","Index":-1,"Score":null,"IsExternal":false,"DeliveryMethod":null,"DeliveryUrl":null,"IsExternalUrl":null,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Path":null,"PixelFormat":"yuv420p","Level":8,"IsAnamorphic":false},{"Codec":"mp2","CodecTag":null,"Language":null,"ColorRange":null,"ColorSpace":null,"ColorTransfer":null,"ColorPrimaries":null,"Comment":null,"TimeBase":"1/90000","CodecTimeBase":null,"Title":null,"VideoRange":null,"LocalizedUndefined":null,"LocalizedDefault":null,"LocalizedForced":null,"LocalizedExternal":null,"DisplayTitle":"MP2 - Stereo","NalLengthSize":null,"IsInterlaced":false,"IsAVC":null,"ChannelLayout":"stereo","BitRate":256000,"BitDepth":null,"RefFrames":null,"PacketLength":null,"Channels":2,"SampleRate":48000,"IsDefault":false,"IsForced":false,"Height":null,"Width":null,"AverageFrameRate":null,"RealFrameRate":null,"Profile":null,"Type":0,"AspectRatio":null,"Index":-1,"Score":null,"IsExternal":false,"DeliveryMethod":null,"DeliveryUrl":null,"IsExternalUrl":null,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Path":null,"PixelFormat":null,"Level":0,"IsAnamorphic":null}],"MediaAttachments":[],"Formats":[],"Bitrate":2256000,"Timestamp":null,"RequiredHttpHeaders":{},"TranscodingUrl":null,"TranscodingSubProtocol":null,"TranscodingContainer":null,"AnalyzeDurationMs":3000,"DefaultAudioStreamIndex":null,"DefaultSubtitleStreamIndex":null}

Channel 20 - ABCTV HD

Code

/videos/917e45a5-3062-6668-0814-0bf638be0f1c/live.m3u8

{"Protocol":1,"Id":"native_99cdadf4d11aa557bb4b0a89e0e189a3_19bc6d59fc4da242e1841cb157dbe97a","Path":"http://192.168.42.63:8096/LiveTv/LiveStreamFiles/48695eb3e5604dfcb27ee88112cc6ad2/stream.ts","EncoderPath":null,"EncoderProtocol":null,"Type":0,"Container":"mpegts","Size":null,"Name":null,"IsRemote":false,"ETag":null,"RunTimeTicks":null,"ReadAtNativeFramerate":false,"IgnoreDts":true,"IgnoreIndex":false,"GenPtsInput":false,"SupportsTranscoding":true,"SupportsDirectStream":true,"SupportsDirectPlay":false,"IsInfiniteStream":true,"RequiresOpening":true,"OpenToken":null,"RequiresClosing":true,"LiveStreamId":"a17c75760a04e99b68cf766e11316e1c_09efa0d56b934a82adec00a87b837fb0_native_99cdadf4d11aa557bb4b0a89e0e189a3_19bc6d59fc4da242e1841cb157dbe97a","BufferMs":0,"RequiresLooping":false,"SupportsProbing":true,"VideoType":null,"IsoType":null,"Video3DFormat":null,"MediaStreams":[{"Codec":"h264","CodecTag":null,"Language":null,"ColorRange":"tv","ColorSpace":null,"ColorTransfer":null,"ColorPrimaries":null,"Comment":null,"TimeBase":"1/90000","CodecTimeBase":null,"Title":null,"VideoRange":"SDR","LocalizedUndefined":null,"LocalizedDefault":null,"LocalizedForced":null,"LocalizedExternal":null,"DisplayTitle":"1080i H264 SDR","NalLengthSize":"0","IsInterlaced":true,"IsAVC":null,"ChannelLayout":null,"BitRate":20000000,"BitDepth":8,"RefFrames":1,"PacketLength":null,"Channels":null,"SampleRate":null,"IsDefault":false,"IsForced":false,"Height":1080,"Width":1920,"AverageFrameRate":25,"RealFrameRate":25,"Profile":"High","Type":1,"AspectRatio":"16:9","Index":-1,"Score":null,"IsExternal":false,"DeliveryMethod":null,"DeliveryUrl":null,"IsExternalUrl":null,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Path":null,"PixelFormat":"yuv420p","Level":40,"IsAnamorphic":false},{"Codec":"mp2","CodecTag":null,"Language":null,"ColorRange":null,"ColorSpace":null,"ColorTransfer":null,"ColorPrimaries":null,"Comment":null,"TimeBase":"1/90000","CodecTimeBase":null,"Title":null,"VideoRange":null,"LocalizedUndefined":null,"LocalizedDefault":null,"LocalizedForced":null,"LocalizedExternal":null,"DisplayTitle":"MP2 - Stereo","NalLengthSize":null,"IsInterlaced":false,"IsAVC":null,"ChannelLayout":"stereo","BitRate":256000,"BitDepth":null,"RefFrames":null,"PacketLength":null,"Channels":2,"SampleRate":48000,"IsDefault":false,"IsForced":false,"Height":null,"Width":null,"AverageFrameRate":null,"RealFrameRate":null,"Profile":null,"Type":0,"AspectRatio":null,"Index":-1,"Score":null,"IsExternal":false,"DeliveryMethod":null,"DeliveryUrl":null,"IsExternalUrl":null,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Path":null,"PixelFormat":null,"Level":0,"IsAnamorphic":null}],"MediaAttachments":[],"Formats":[],"Bitrate":20256000,"Timestamp":null,"RequiredHttpHeaders":{},"TranscodingUrl":null,"TranscodingSubProtocol":null,"TranscodingContainer":null,"AnalyzeDurationMs":3000,"DefaultAudioStreamIndex":null,"DefaultSubtitleStreamIndex":null}

Are you able to share any short .ts recordings ? (Assuming sunny is in Aus)

The metadata posted above shows that ABC SD is 576i25 MPEG2 and ABC HD is 1080i25 h.264.

sunny Are you in Australia? If so I thought that Aus might still be using MPEG2 rather than h.264 (sometimes referred to as 'MPEG4') for HD broadcasts - but looking at digital bitrate, Aus - like most of Europe - is now h.264 for HD.

Might be useful to post a short .ts recording of one of the channels that is proving problematic so we can have a look? Doesn't need to be more than 20-30" via GoogleDrive/Dropbox etc.

Quote from sunny

With LE10.0.2 on my Pi4 compared to LE10.0.0, I've noticed that the H264 encoded *.TS files from my TVHeadend server, recorded in 1080p @ 50ps with interlacing, now play with distinct 'judder' or 'jerkiness', especially when the image has a slowly panning background.

The same file played on my Pi3 with OSMC (Kodi19.4), shows the video with interlacing, but at least the image pans smoothly and the irritating jerky visual effect on the background is not present. Kodi on both Pis has been set with identical display and video settings.

I think the de-interlacing using hardware decoding on the Pi4 still has some a way to go yet. In the meanwhile, I've disable de-interlacing by default for all videos, as I prefer the result.

Where are you based ? What is your TV backend ?

In 50Hz countries broadcast satellite, terrestrial and cable HDTV is broadcast in one of these formats. IPTV may be different :

720p50 aka 720/50p (i.e. 720 lines progressive at 50 full-resolution progressive frames each second)

1080i25 aka 1080/50i (i.e. 1080 lines interlaced, with 50 half-resolution interlaced fields each second, making 25 interlaced frames) (*)

1080p50 aka 1080/50p (i.e. 1080 lines progressive, with 50 full-resolution progressive frames each second)

(*) The UK Freeview HD platform uses an unusual encoding system of dynamic switching between 1080p25 (aka 1080/25p) and 1080i25 (aka 1080/50i) switching the encoder between 25fps progressive - when it detects native 25Hz motion (i.e. film or drama & documentary shot with a 'film look') - and 25fps interlaced - when it detects 50Hz motion (i.e. sport, entertainment, news etc.)

1080i25 requires deinterlacing to 1080p50 by the receiving device, and is usually broadcast in h.264/AVC in 50Hz territories (Australia went early with MPEG2 but is an outlier). h.265/HEVC isn't widely used for 1080i25 as h.265 doesn't have optimisations for interlaced content - unlike h.264.

1080p50 is usually only broadcast in h.265/HEVC (as the h.264 platforms previously defined usually topped out at 1080i25/720p50 and newer platforms benefit from h.265/HEVC's improved efficiency)

720p50 is broadcast in h.264 mostly, but some newer DVB-T2 platforms are using h.265/HEVC for 720p50.

You mention 1080p @ 50fps is the format your recordings are in - that would only be the case if you were receiving progressive 1080p50 h.265/HEVC, or were deinterlacing to 1080p50 as part of your recording process? Either case would mean there was no real issue with deinterlacing on playback.

It sounds as if you are actually receiving 1080i @ 25fps and need your Pi 4B to deinterlace to 1080p @ 50fps to ensure you get fluid 50Hz motion on sources with 50Hz motion.

Having a sample clip would assist fault finding.

Quote from hagaygo

De-interlacing not only "resolving" the jagged image visuals which happens when playing interlaced content without de-interlacing, it also increases the temporal resolution, resulting twice the fps (if the content was shot at 50fps , it should be really noticeable).

You need to set your display to 50hz (not 25) in order to see the effect properly and have smooth playback.

Also , if your display has some sort of motion interpolation feature , it should be turned off.

Yes - and no - it depends on the source material.

A lot of broadcast TV material isn't native interlaced, so has no motion over >25Hz. Most drama and documentary is now shot at 25fps progressive, and so has no >25Hz motion. In this case deinterlacing is about preserving the full vertical resolution.

You are correct that when you are deinterlacing native interlaced content (or content shot at 50fps progressive and converted to interlace - which is now common for sport shot UHD at 2160p50), the deinterlacing process is also about retaining the 50Hz motion inherent in a 50 field-per-second interlaced signal.

What this means is that you need to check for 50Hz motion on source material you know actually has it! Most (but not all) studio entertainment shows will have 50Hz interlaced motion, as will almost all sport. Recording these shows is a good way of testing for proper 50Hz deinterlacing. Also continues news channels with tickers are a good test - as the tickers usually run at 50Hz.

Quote from chewitt

Looks interesting and makes sense for industrial users. If it's an official RPi Foundation created module? we can probably get a sample sent to HiassofT who has my Slice3 box in his collection since last summer now. That said, there are now only ~45 Slice boxes showing in stats (down from ~100 pre-Covid) so it's probably not high on the to-do list.

It appears to be a response from the Pi Foundation (though possibly developed in association with a specific CM1-3 form factor product vendor) to the extreme shortage of pre-CM4 modules due to the lack of the earlier SoCs based on the 40nm process?

My Slice has been sitting in a box for a couple of years so won't be showing up on the stats. Beautiful piece of hardware design

If this https://www.tomshardware.com/uk/news/raspbe…ously-announced is correct - there is likely to be a CM4S module in the Slice-compatible CM1-3 form factor, but with the SoC from the CM4 on it...

If this becomes a product available to end users - will anyone try it in a Slice?

Quote from chewitt

It's a software issue, not hardware. You might be able to run the older LE9.2 image (which supports 3D). I have fuzzy memeory there may be newer iterations of the 400 that need firmware newer than what's shipped in the 9.2 image. I could be confusing it with RPi Zero2 though? (easiest way is to image an SD card and test).

Has there ever been support for 3D MVC decode and Frame Packed HDMI output on the SoC used in the Pi 4B and Pi 400? I thought it was only implemented for the SoCs in Pi3B+ and earlier?

Quote from HiassofT

For 4kp50/60 yes, but 4kp30 and below will use 12bit RGB 4:4:4 if supported by the TV.

So lots of 10-bit videos (eg 4kp24 or 1080p) now can have 50% higher clocks than before.

so long,

Hias

And that higher clock rate can sometimes expose things that you really don't expect to cause problems - like HDMI Cables that can't cope with the increased bandwidth.

When I installed players that output 4:2:2 2160p50/p59.94 12-bit YCbCr output a couple of my HDMI cables just wouldn't support it, and my TV would fail to display anything (and report no signal or invalid signal). Swapping them out for higher (electrical) quality cables solved the problem. Normally you wouldn't suspect HDMI cables - they usually 'just work' - but the move to higher bandwidth signals does expose limitations in the electrical quality of the cables.

NB by higher electrical quality cables I don't mean expensive 'Monster' or similar cables, just cables that are certified 'HDMI Premium' with the hologram. They aren't expensive, but are certified to pass the higher bandwidth HDMI 2.0 signals that are required for UHD HDR at all bit depths, frame rates and colour formats...

Quote from msderganc

Buyer beware - I have two Odroid N2+ units that have failed within a couple months of each other and HardKernel has basically told me that they won't do anything. I would have to pay shipping both ways (nearly the cost of a new unit) to MAYBE get a replacement. I've never experienced such bad service.

Out of the blue, the USB ports failed on both devices, which were running Libreelec Kodi Matrix. USB Power was turned off within Kodi. One failed after just about a year, and the other after a year and a few months. I can't find too many threads on this topic, so I'm posting this in case anyone is considering one of these units.

Hard Kernel has a very poor attitude to failures, and a minimal warranty. I would always recommend to buy through an EU or UK reseller if you're in the EU or UK, as you will potentially have better consumer rights that way.

I've heard a number of stories of terrible customer service once things break.

Quote from olympia

One more question (back to one of the original one): is there any cons compared to having a dedicated tuner card like the TBS6909?

One big pro is that you can run your TV Headend server on a NAS or a small, low-cost ARM SBC like a Raspberry Pi, you don't need to have an x86 PC with a PCI-E slot that will draw a lot more power when on 24/7.

The only con is that occasionally my DigiBit R1 has needed to be power cycled - but only occasionally.

You can also run third party firmware on the R1 (Sat Axe) booted from an external USB device, that allows you to have additional configuration options, and to tune some of the DVB-S2 Multistream services that are used to distribute DVB-T/T2 in France and Italy for instance. (That allows you to receive the main French FTA DVB-T terrestrial services like TF1, FR2 etc. without needing to worry about decryption)

Quote from chewitt

The concept of "pass-through" doesn't exist for video.

Precisely this - whilst HD Audio can bit bitstreamed/passed-through retaining the source compression, video is always decompressed from a lossy compressed format (h.264/AVC, h.265/HEVC, VC-1, MPEG2, AV1 etc.) to an uncompressed stream of RGB or YCbCr (ignoring Dolby Vision) carried over HDMI (or similar)

It's the equivalent of MP3 or AAC being decoded to PCM.

If you didn't decode the video you wouldn't be easily able to overlay a GUI etc. (unless you sent two video streams over HDMI and your TV composited them together)

When it comes to HDR PQ / HDR HLG / SDR (*) EOTF and Rec 601, Rec 709 and Rec 2020 Gamut signalling, and then static and dynamic EOTF metadata - different codecs will do this in different ways (I think some codecs have multiple options in some cases?), and each will need to be then decoded, and converted into a format that HDMI Infoframes etc. can carry to a display. This is driver specific AIUI - so different HDMI output systems on different platforms will have different ways of doing this?

Quote from Nekromantik

Is it just licensing issue rather then hardware dont support it?

HDR10+ is an open format AFAIK.

Quote from elonesna

In relation to the VHF band, I challenge you to tell me the name of a single public TV broadcast that broadcasts in this band in ATSC, DTMB, DVB-T/DVB-T2 and ISDB-T digital format anywhere in the world ( I obviously exclude military and industrial applications). Will not be able!

I'm afraid you're very mistaken - it's quite easy to document current VHF TV broadcasts...

Off the top of my head DVB-T/T2 services in VHF are in use in Australia, were introduced in Sweden with DVB-T2 HD, and have also been used in Finland. ATSC in the US uses VHF widely too.

In Australia VHF Band III is currently used for DVB across large parts of the country (VHF's wider coverage areas make a lot of sense for a large country like Aus).

As an example here are the frequencies for DVB-T broadcasts in Perth, Australia : https://www.digitalbitrate.com/dtv.php?mux=SB…live=36&lang=en - all 5 DVB-T muxes are in VHF Band III (177.5MHz to 226.5MHz range) , not the UHF Band IV/V frequency range

In Sweden their DVB-T2 Nät 7 mux is currently carried on Channels 5,6,7 and 8 in VHF Band III in some parts of the country - such as Skellefteå, where Channel 6 is used (Sweden re-introduced VHF Band III broadcasting, previously only used in TV terms for analogue PAL, when they introduced more muxes for DVB-T2 HD services). (For reference - in Europe, any RF channel below C21 is VHF, with the UHF TV Bands IV and V running from 21-69, though >800MHz has been cleared and >700MHz are being cleared in most countries)

Swedish TV broadcasting authority link here where you'll see a few transmitters using RF channels 5,6,7 and 8 in VHF Band III for their 7th mux :

https://www.teracom.se/privat/Support/frekvenstabeller-tv/

In both Sweden and Australia, Band III is used for both DVB-T/T2 digital TV services and DAB/DAB+ Digital Radio services. (In other European countries like the UK, DVB-T/T2 is only in UHF, and VHF Band III is used for DAB/DAB+ only in consumer broadcasting terms, if it's used at all)

I'm not sure if Finland is still using VHF - but it was at one point.

In the US - VHF Band I and Band III are both used for ATSC digital TV.

Here's the Rabbit Ears listing for New York : https://www.rabbitears.info/market.php?mktid=1

If you look at the RF Physical Channel numbers you will see there are lots of channels below Channel 14 (which is the first US channel in the US UHF band numbering scheme) - anything below 14 is a VHF channel. VHF Band III contains channels 7 to 13, VHF Band I contains channels 2-6. Even the main ABC station - WABC - is on RF channel 7 (which is around 174MHz).

(NB The US and Europe use different VHF/UHF channel numbers because the US uses 6MHz wide channels, whereas Europe uses 7MHz in VHF and 8MHz in UHF. I think Aus is 7MHz in both.)

Quote from Jedrusia

I have a new RPI 4 set with the "Astrometa" DVB-T2 receiver and the latest LibreElec operating system (LibreELEC-RPi4.arm-10.0.1.img.gz). My problem is that no MUXs operating in the VHF band are detected or scanned (for example in Poland MUX8 in the 184.5MHz band.)

Is there any way that I can receive signals in this band?

My receiver is built around integrated circuits: R828D; RTL2832U and Sony CXD2837ER.

The next question is how (also the VHF band) can I receive FM and DAB + radio signals via the KODI application.

Where in the world are you based and what channels are you trying to receive.

The Astrometa DVB-T/T2 tuner is likely to be limited to DVB-T/T2 only (and DVB-T2 may be tricky - at one point only DVB-T was supported because of the split demodulator arrangement and only drivers for the DVB-T demod being originally available)

Whilst the tuner may also be advertised as supporting FM and DAB radio - that requires the tuner to be used with totally different, SDR-style drivers, which are totally separate to DVB drivers, and I don't think there is any support for running in this mode in TV Headend.

(I think in Windows there are drivers and custom software to support this?)

Quote from heinzgruber

hi,

using Libreelec 10.0.1 on Raspberry Pi 4 with my LG OLED C9 and 4K/HDR looks fantastic! No problems so far.

I wonder what this means

• 10/12-bit video output isn’t implemented yet, 10-bit video is displayed in 8 bits

My movies come with HDR10. So Libreelec plays thos files with 8 bits?

Thanks

Yes - in this case the video is output as 8-bit (usually RGB), but accompanied with an HDMI flag to tell your TV that the video isn't to be displayed in SDR but is instead in a PQ HDR dynamic range (which is what HDR10 content uses), and that triggers your TV into an HDR mode. You may see banding that you wouldn't see with a full 10-bit path.

More recent nightly LE 11 builds will ensure the full 10-bit source is preserved and output, and remove the 8-bit bottleneck.

Quote from marantz

is there a way to alter the brightness of subtitles only when watching HDR? in a dark room its almost impossible to have subtitles enabled.

thanks for any help

I think this is tied into the lack of support for SDR-in-HDR rendering. Same reason the GUI overlays are very bright when playing HDR content.

I guess the issue is that with SDR content you might have subtitles set for something like peak-white (level 240 in 8-bit decimal) but in HDR10 PQ this would be massively into the HDR range, close to 1000nits - whereas SDR peak white is just 100nits).

A stop-gap would be to have two or three different subtitle 'colours' for SDR, HDR10 and HLG content - or a real interim would be to chose a much darker grey for subtitles (though this would make them more difficult to read on SDR content I guess)?

Quote from onlyrock

It appears that most if not all of my HDR10 videos get sent to my receiver using 12bit color. I think the builds prior to 2021.12.18 would send them as 8bit, as I detailed above.

I thought HDR10 used 10bit color. Is that correct? If so, is there a reason LE outputs them as 12bit?

UHD HDR10 content is encoded as 2160p (aka 4K) 4:2:0 YCbCr 10-bit with Rec 2020 colour gamut and using the h.265 codec typically.

When HDR support first arrived on the Pi 4B in LibreElec, HDR10 content was replayed with the 10-bits truncated to 8-bit (losing the lowest 2 LSBs), and output in RGB. This meant that the two lowest bits were truncated which would mean a lower quality picture was being delivered.

(I think some dither noise may have been added to reduce the visibility of the banding this would introduce on 10-bit capable displays - or those that simulate 10-bits with 8bit panels + FRC)

This truncation was obviously not ideal, but HDMI 2.0 doesn't support 10-bit RGB in 2160p (aka 4K) at all frame rates - so just increasing the bit-depth and staying RGB wasn't really an option (it would mean no 2160p50 or above support).

For higher frame rate UHD HDR with at least 10-bits, HDMI 2.0a supports either 4:2:0 YCbCr at 10-bit, or 4:2:2 YCbCr at 12-bit. The Pi 4B won't support 4:2:0 (as it requires both horizontal and vertical subsampling/scaling of chroma which the Pi GPU doesn't handle?), but the Pi 4B does support the horizontal-only scaling/subsampling for 4:2:2 YCbCr at 12-bit, which is now being used instead.

HDMI 2.0a doesn't include any bit depths for 4:2:2 YCbCr other than 12-bit at UHD resolutions, so YCbCr output at UHD is always 12-bit. 10-bit content is just padded with zeroes in the two LSBs to pad the 10-bit content to 12-bit.

Most of my UHD replay devices (UHD BD player, Apple TV 4K etc.) are set-up for 12-bit 4:2:2 output just as the Pi outputs, as is my AVR. (My Sky Q is 4:2:0 I think - haven't checked recently)

Quote from Nekromantik

Hello

Happy New Year all!

Does LE 10 support Dolby Atmos decoding? Or do you have to passthrough?

Does passthrough need certain NUCs to work or will NUC6 work?

Thanks

As far as I know there is no open source decoder / renderer for the Dolby Atmos Extensions used with Dolby Digital Plus or Dolby True HD - nor is there a majorly standardised route to sending them as PCM to an AVR.

As a result Passthrough/Bitstream of DD+ with Atmos or True HD with Atmos to an Atmos compatible sound system is the route to getting Atmos decoding and height speaker playback.

You can decode the DD+ and Dolby True HD stream to regular 5.1 / 7.1 PCM no problem though (as the streams are backwards compatible with non-Atmos decoders, which ignore the Atmos extensions)