Posts by noggin

I've found my Pi 4 and Pi 5s both confuse my Denon AVR-X2400H + Sony TV 49XF900? combo (haven't tried with my new LG OLED yet) does something similar. When the Pi boots you see the LibreElec splash screen and then get corrupt video (sometimes no signal on the TV, often digital shash).

I found disconnecting the Pi's HDMI output and reconnecting (Hot plug force?) re-establishes a video display that's robust from then on as frame rates and resolutions change (I'm using a Pi Foundation Micro HDMI to HDMI short cable and then an Amazon HDMI 2.0b Premium Certified cable to the AVR, so break the connection at the in-line HDMI junction between the two cables)

I think I've seen something similar with this combo when I change screen resolution and/or frame rate settings in Raspberry Pi OS - so suspect it's something to do with underlying HDMI handling that the Pi and Denon don't agree on.

DV and HDR10+ dynamic metadata makes tonemapping content that is potentially outside your display's capabilities better (as HDR10 does to a lesser degree). However some manufacturers ignore the metadata (for HDR10 at least - treating it as PQ10) and use their own algorithms instead of using metadata information. (*)

Ironically DV and HDR10/10+ are based on PQ and a direct 1:1 link between video level and pixel nit light output - HLG isn't (it doesn't mandate a 1:1 mapping between video level and light output - it's relative instead), and HLG has built-in support for ambient light level compensation. Dolby have had to accept that PQ doesn't work for some viewing scenarios and use DV IQ to do something similar to what HLG can do.

Personally if DV and HDR10+ can improve my TV's peformance I'm happy to take it - but I'm not going to spend LOTS of money chasing after support for them. That said not having DV did partially influence me not to buy a Samsung Quantum Dot OLED - I've gone for an LG C3 (65").

(*) Some DV profiles use ICtCp colour space instead of YCbCr/YUV which can in theory improve picture quality as it better maps the high and low bandwidth channels to match the eye/brain perception - and also comes closer to constant luminance (I think) - which has always been an issue with YCbCr/YUV vs RGB gamma processing (I think). Other DV implementations use YCbCr/YUV HDR10/10+ base layers and add an enhancement layer to get nearer 12-bit representation rather than 10-bit - which can also help (You don't need a 12-bit capable display for the benefit as you'll get some benefits with tonemapped 12-bit content mapped to a reduced range 10-bit display I think)

Quote from wyup

Libplacebo open source library, which is "provided by ffmpeg as a Vulkan-based video filter, does native support for Dolby Vision HDR, including Profile 5 conversion to HDR/PQ or SDR, reading DV side data, and reshaping. (BL only, currently"). RPi4 has Vulkan 1.2 and GL 3.0 compatibility.

LE Wiki says:

Kodi supports Dolby Vision under Android (if the device is licensed for it) but not Linux. Dolby requires manufacturers to license their Intellectual Property and use integration libraries to decode the HDR metadata. Until FFMpeg comes up with a "clean room" reverse engineered open-source implementation, Kodi will not support it.

I guess this is an open source implementation that LE could use to decode Dolby Vision to HDR10.

Who could implement it, Kodi or LibreElec?

NB the CoreElec implementation for DV implemented on DV Licensed platforms requires that CoreElec Linux runs alongside an existing Android (including DV Support) installation and hooks into the DV decoder stuff in the Android file system and uses it within CoreElec. It's a neat solution that's VERY bespoke to specific installations - and only works on licensed systems (though is potentially pushing at the edges of legality - though I'm not a lawyer)

Quote from wyup

Well, at least decode DV to HDR10 with libplacebo open source library, provided as a vulkan-based video filter in FFmpeg?

Is this ICtCp to YCbCr/YUV conversion for native DV HEVC stuff that uses the ICtCp style representation? (Used for the DV profiles commonly used by Netflix, Prime, Apple TV+ etc.) rather than just using the DV RPUs to generate new metadata for HDR10 YCbCr/YUV encodes? (Ignoring FEL - Full Enhancement Layer - DV streams that expand the HDR10 stuff to >10-bit?)

Beware using 'DolbyVision' as a catch-all. There are lots of different variants of DV...

Some are based around YCbCr (aka YUV) PQ HDR10 or HLG 10-bit HEVC/h.265 and then Dolby Vision RPU metadata (and in some cases also an expansion layer to get from 10-bit to 12-bit depth). These can usually be replayed with no Dolby Vision licensing requirement for the HDR10/HLG stuff. Examples of this type of DV sources are Dolby Vision UHD Blu-rays and DV video shot on iPhones.

Other DV stuff is encoded purely in a DolbyVision video format using ICtCp representation and PQ instead of YCbCr/YUV - though still encoded in 10-bit HEVC/h.265. When these are replayed by non-Dolby Vision licensed devices they replay with magenta/green colours instead of normal colours, because they are interpreted as YCbCr when they aren't. This format is widely used for streaming platforms - where the streaming player can request a specific encode that it can play (rather than a single encode needing to be playable by multiple devices). The CoreElec DV implementation can play these OK, few other devices can.

Quote from wolfgang61

Pi 5 goes to Yamaha RX-V685 goes to a 4K TV.

Replacing the cable from Pi 5 to the Yamaha fixed the problem. I have no idea if this cable is 2.0 or whatever, but it looks more expensive.

Could it be that the Pi 5 produces a higher HDMI data rate than the Pi 4? Why is that so with the same video material? DVB-S2, HD. If so, that might be worth mentioning in future upgrade instructions. Or reduce the HDMI data rate to what is really needed for the actual video.

Different HDMI output resolutions, frame rates and bit depths require different bandwidth HDMI cables. I think both the Pi 4B and Pi 5 can output the higher bandwidth 18Gbs modes in 2160p60 4:2:2 12-bit (there isn't a 4:2:2 10-bit option in HDMI 2.0). Someone please correct me if I'm wrong.

However it could be that your previous set-up with a Pi 4B didn't try to use 18Gbs modes and your Pi 5 set-up is?

Quote from twilightened

I am still using the "9.2.8" version on a RPI3B. It is amazing how it can decode 10bit 1080p x265 videos with ease. If i install the new version, even 720p videos suffer. This goes to show that when optimized, software can do amazing things, even on low end hardware. We don't really need all that power.

To be fair - AIUI it's using GPU compute (i.e. offloading some computation to the GPU) to lighten the load on the CPU - so it's using more processing power than the CPU alone used for pure software decode can provide.

Quote from liverty

Agree that DTS-HD is a high-bitrate audio format that requires a more powerful processor than the Raspberry Pi 4. This may result in lags and interruptions in the audio.

Not sure I follow - the bitrate of DTS-HD Master Audio is no different to Dolby True HD or something like 192kHz 5.1 PCM? The Pi 4B can handle all of them OK in my experience. (It can also decode DTS HD MA to PCM with no major issue). Audio's not hugely processor-hungry (particularly if you aren't decoding it and just moving it from A to B).

The usual stuttering stuff is caused by work-in-progress buffer code, or a non-complete understanding of some of the specs, as this is all being partially implemented by enthusiasts trying to solve a problem, rather than people being paid to commercialise a product.

There was a long-standing issue relating to high-bitrate Dolby True HD on multiple platforms (including Intel ISTR) that took a while to get to the bottom of.

Quote from brunis

I am only getting Stereo output (as in, front speakers, no center) when setting E-AC3/Atmos to passthrough. It seems the speaker config also matters a lot, eg. E-AC3 only appears on the passthrough list if my speaker config is 2.0 .. but why would LE care about my TV speaker config, when I'm bypassing it with Passthrough? .. make it make sense?

You don't have enable transcoding to AC3 enabled do you?

That option only appears if you have 2.0 speaker config selected. The other passthrough options should appear for all speaker configurations.

Quote from chewitt

It's not an obvious configuration and sadly does catch a few people out. I'm not sure what we could really do to improve though.

Is the setting actually serving two use cases ?

1. Displays that can't accept p25 modes and only p50 (though EDID and/or whitelisting may catch this anyway?)

2. Chosing to deinterlace i25 to p50 rather than p25

The two don't fully overlap - but currently one setting covers both use cases?

Personally I'd argue that defaulting to on rather than off would be the better default?

Quote from itisljar

I'm sorry to intrude, but is this specific to Raspberry or is it for all architectures?

I'm into buying N100 based motherboard, and I'd like to have HW accelerated decoding of h264, h265 and AV1, which is supported by that iGPU. Should I postpone it?

I believe this discussion is specific to the Pi2/3 HEVC implementation. That platform doesn't have VPU (video processing unit) support for hardware acceleration of HEVC/h.265 but instead uses a combination of CPU and GPU compute (not the same as dedicated VPU support) to allow HEVC content to be played on a platform that otherwise wouldn't be able to.

The Pi 4 and Pi 5 both have hardware HEVC/h.265 VPU blocks to allow for hardware acceleration - which is supported in newer versions of LE.

Other platforms like x86 which have 'GPU hardware decode' (which is more like VPU decode on ARM platforms) of HEVC are a different matter and depend on the driver support for that platform. I'd expect recent Intel CPUs to work fine once driver support for newer processors has made its way into the code base.

Quote from chewitt

Kodi always outputs progressive so you need to enable adjust-refresh and rate doubling, and set the mode whitelist to NOT include 1080p @ 30/29.97/25 modes. Kodi will then switch to 1080@50 with each interlaced half-frame rendered in a single frame. Normal PAL content will be output at 1080@50 too (each frame is rendered twice).

Ah - I hadn't realised that frame doubling was used as the term to signify i25->p50 deinterlacing vs i25->p25 deinterlacing in settings (for some reason I thought this was a way of implementing 2:2 pulldown for replay of p25/p30 stuff in 50/60Hz output modes as it talks about enabling it for compatibility reasons).

I'd assumed denterlacing was always at field rate by default (why would anyone do it at frame rate other than if their CPU/GPU couldn't keep up?) I suspect I've always enabled that setting without thinking about it in the past. (I only ever enable 23.976/24/50/59.94/60Hz refresh modes in my Whitelist.)

*** EDIT - should add that this was, indeed, the issue. h.264 1080i25 native 50Hz interlaced stuff is now replaying fine with full 50Hz motion deinterlaced to 1080p50. BWDIF is the deinterlacer used it seems - which is a good choice. None of my CPU cores were >40% loaded in playback - most were less than this by quite a lot. The Active Cooler PWM fan didn't kick in for the few minutes I tested. ***

Have just got a Pi 5 - trialling h264 1080i25 file replay in the latest nightly (20231031) - and the only software deinterlace option I have is 'deinterlace' which deinterlaces native i25 to p25 rather than p50 - so halving the temporal resolution. Thought I'd report it.

(Apologies if this is already known about).

Quote from Stefan M.

Hello,

I have used the combination *elec and Raspbis for quite some time to up-smarten the TVs of various Friends and Family Members. For myself I have always used my Windows Desktop with an NVIDIA graphics card, which I could use to play back Dolby Atmos & Co. The windows desktop has been finally replaced by a Linux desktop, the pc with the NVIDIA card is - ATM - only switched on to play games and view videos. I would like to reduce that to "to play games" and someday to "not at all".

I have read that the new Raspberry Pi 5 supports HDR. That sounds like a good excuse before the treasury committee of my mind to buy a new Raspi (I have enough old ones).

Can the Pi 5 with Libreelec and KODI play back HDR and Dolby Atmos in its full glory? Is this combination fast enough to decode h264-4k-Content, which is unfortunately not supported in hardware any more? (Stupid decision, can't really believe that a little bit of downwards compatibility would have changed the prince more than a few cents)

Yours sincerely

Stefan

Display More

Raspberry Pi 4B plays 2160p HDR (HDR10 and HLG) HEVC content with HD Audio passthrough (DTS HD MA, Dolby True HD, including Atmos extensions etc.) - such as UHD BDs. Would expect the Pi 5 to have the same functionality.

The hardware h.264 decoder in the Pi4B and earlier topped out at 1080p (it's never supported 4K h.264 hardware decoding - so it's not a case of 'not supported in hardware any more' as it never was). The SoC functionality that supported h.264 decoding on earlier Pis was largely unchanged since the first Pi was released AIUI.

AIUI there are reports that h.264 2160p content encoded at the kind of bitrates used for web-based content are decoding in software - at least at 2160p24 level. 1080p h.264/VC-1/AV1 all software decodes OK too I believe.

Quote from rupat

in ordered the digibit twin, but it seems i cant get any channels, tvheadend finds the 2 devices.

I think my landlord installed the system and they have more satelites over one cable, is the twin not capable of that?

Is there a howto for using tvheadend and the digibit twin?

There are different ways that multiple satellites can be sent over a single cable - you need to know which one your landlord is using so you can configure your receiver and/or software correctly :

e.d. Diseqc switching a Universal LNB feed, Unicable, Unicable II etc.

Quote from davidsilva

I'm seeing some expensive number for satip boxes. I paid for £15 for mine

I used an old Linux sat-s2 receiver, Zgemma star s2 and installed satip software onto it. Edited the startup script to boot satip at boot and that's it. Facebook market place is flooded with old sat boxes which can be turned into satip boxes.

Here's the link for github with all the information

https://github.com/catalinii/minisatip

I've been using this method for years without a single problem. Tvheadend picked up the tuners straight away.

I nearly suggested this route - it's a perfectly sensible approach - and you can now get low-ish cost FBC Enigma boxes that will give you more than 4 tuners.

Quote from rupat

would I have any advantages using the R1 with the alternative firmware?

there are some on ebay atm.

If you have a need to receive MPLS/Multistream stuff from 5W I think that is only possible with the Sat Axe firmware. Also that gives you a lot more flexibility in config terms (Unicable stuff, tuner vs LNB allocation etc.)

I paid far less than the current going rate for my Digibit (something like £100?) - if you are spending £300 then the Kathrein Exip 418 is worth a look. 8 tuners... I have one of these fed from a Unicable II Global Invacom GTU fed over the fibre distribution system I have access too (we aren't allowed satellite dishes or TV aerials on our estate as it's in a conservation area so get 28.2 and Freeview via an RF-over-fibre feed)

There are two aspects to this issue :

How do you get the four tuners to work independently. You can do this with a Quad or Quattro LNB (with 4 cables to the R1), or a Unicable/Unicable II LNB or Multiswitch (with one cable) - though that latter may require you to use third party firmware like SatAxe and to understand how to configure Unicable/Unicable II. This will allow you to tune to a maximum of 4 satellite transponders.

How many channels that you want to provide to your network does each transponder have? You can use one tuner and LNB feed/Unicable UB slot to tune more than one channel if it's on the same transponder (though you may not be able to stream ALL of the channels on a transponder). When you tune to a transponder, the R1 will get a data stream with all the channels in that transponder, and will filter out the ones you want. You can usually filter out a number of channels from the same transponder before you hit a processing limit (it depends how hard the R1 is working I think)

If you want to offer specific channels to your network - you can look at which channels are on which transponder and come up with a plan to use your 4 tuners to decide which 4 transponders make the most sense. Or you can just decide to limit each user to one tuner/transponder and limit it to 4 users. They are two sensible approaches for different reasons.

Quote from kaibenn

noggin Thank you for explaining the possibilities.

I need DVB-S/S2. So the PI TV Hat is not sufficient.

There are a lot of options, but I think I understand them.

For straightforward DVB-S/S2 from a single LNB or simple Diseqc then a SAT>IP server makes a lot of sense, or you may find you can run SAT>IP server software on an Enigma 2-based DVB-S/S2 set top box (ignoring its primary role). These days with FBC tuners giving 8 separate tuners in a single box - it can make a powerful set-up.