Anything better than a Pi4 currently?

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)

I just setup my Pi 5 with a pineberry HatDrive! and a tiny NVME drive. It runs like a champ and loads all of my thumbs pretty much instantly. Running LE11 - 4kHDR and HD audio work perfectly. After futzing around with x86 for the past couple years, this is by far the best, easiest solution I’ve found.

The only problem is my flirc case doesn’t fit with the HatDrive! on top.

Quote from noggin

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.

Is there an easy way (e.g. using mediainfo, what is the relevant string to look for) to see which case a video is in?

Do you believe the first case here can be decoded and displayed correctly, purely by outputting the untouched YCbCr data from decoder and the appropriate metadata? I believe the second case requires per-pixel processing which is likely infeasible at 4k without dedicated hardware or a very high performance gpu.

Quote from chewitt

IIRC RPi 4/5 only support Vulkan under Wayland, and we do not run Kodi under Wayland because Wayland does not support refresh rate changing for optimal media playback. So yes FFMpeg added some support for DV but the devil is in the details and this is not a usable solution for our use-case. I'd also argue that using shaders is not "true" DV support; it's simply a way to get DV encumbered media to display with an acceptable (but not exact) on-screen appearance. True support requires knowledge of the proprietary stuff or a clean-room implementation. The former won't happen because it torpedo's Dolby's commercial model and the latter is rather unlikely since it will require a massive effort and the Linux community generally prefers to make a minimum acceptable effort when the target "standard" is vendor proprietary crap. I'll update/reword the wiki article a little to prevent further 2+2=5 conclusions.

Okay, but nobody says it has to be a 'true' implementation of DV, if there is a good enough one that does Profile 5 conversion to HDR/PQ or SDR and reads side data, it is functional and compatible enough, it is interesting at least to discuss. We're not expecting a 'clean implementation' anywhere near. If the linux community has put an effort in developing this library, obviously they don't consider DV 'propietry crap'. We're talking that most HDR content is in DV, and there are platforms and displays that don't support (or license) it, be TVs (old and new), the most popular RPI or even Windows (Does Windows include free/licensed DV software decoding yet?). If LE is open source, based on ffmpeg and it might include this powerful library (not just for DV decoding, but GPU offloading, jinc upscaling), I think it is worth mentioning. I don't know how LE plays HDR, I read it does by V4L, DRM framebuffer, or KMS on low level programming (I'm not an expert and do not know exactly) and a tight ffmpeg integration.

If you say RPI4/5 only support Vulkan under Wayland, okay I get it, although it doesn't mention this on building documentation: it only requires support for either opengl, vulkan or d3d11. I'm not sure DV decoding requires Vulkan.

But talking about Wayland: RPi has got full working support of it on their official desktop distro. RPI has a Vulkan and OpenGL driver GPU. Open source Mpv player, manages HDR and SDR in Windows and Linux. Is there any talks to move from low level DRM processing to a standard Wayland protocol and display server/compositor without requiring a full desktop environment/window manager?

You say "we do not run Kodi under Wayland because Wayland does not support refresh rate changing for optimal media playback", does it mean it is feasible? How many real content has refresh rate changing? I think some cell phones record video in minimal variable framerate, I don't know if this apply.

Does Wayland expect support for HDR soon to begin with? (passing HDR metadata)

I hope my rant is interesting for someone. It's meant for learning and discussing direction. Thanks for the support.

I'm just really looking forward to picking up an RPi5, in many ways it's looking like a refined RPi4 but with the performance that genuinely means it'll be able to brute force almost all video playback scenarios in software.

Don't sleep on the uplift the VideoCore VII will provide also, it's 4-5x over the VC6 and will be another useful tool for compute tasks.

Yeah, RPi5 is the brute force solution of video decoding . It misses the low-power A55 cores of Rockchip RK3588, and also hardware acceleration for common video codecs.

wyup refresh rate switching is essential if you want (micro-)stutter-free, smooth video playback. Cinema stuff/Blu-Rays are usually at 23.97/24 Hz, TV broadcasts at 50 or 59.94 Hz, PC videos often at 60Hz - if your video output mode doesn't match the video's framerate it'll look juddery.

Regarding DV: UHD Blu-Rays have a mandatory HDR10 base layer, so DV on these disc is an additional layer on top and RPi4/5 will output the HDR10 layer just fine - tested that here with 4k (DV) Blu-Ray rips I did on my own with makemkv.

Streaming services with "pure DV content" (without the HDR10 base layer) is another thing, and RPi4/5 certainly wouldn't have the grunt to process that - direct-to-plane rendering works fine for 4kp60 but GL/EGL rendering doesn't - it's too slow, even without shaders having to do tonemapping (RPi's graphics "chip" isn't anywhere near an Nvidia RTX).

so long,

Hias

Quote from popcornmix

Is there an easy way (e.g. using mediainfo, what is the relevant string to look for) to see which case a video is in?

Do you believe the first case here can be decoded and displayed correctly, purely by outputting the untouched YCbCr data from decoder and the appropriate metadata? I believe the second case requires per-pixel processing which is likely infeasible at 4k without dedicated hardware or a very high performance gpu.

It looks as if anything with dvhe.05 in its profile will be IPTPQc2 colour space rather than YCbCr. The dvhe.07 and dvhe.08 are based on Dolby Metadata with YCbCr Rec 2020 PQ HDR10 video (plus an optional enhancement layer for added Dolby-ness). However I think this is what happens aleady in LE? The dvhe.05 stuff plays as purple and green. This may be because it's been ripped or mastered incorrectly.

The UHD BD ripped and remuxed stuff usually contains something like dvhe.08.06, BL+RPU or dvhe.07.06, BL+EL+RPU and HDR10 compatible in the HDR format field for the HDR10 YCbCr HEVC Rec 2020 PQ base layer + DV BPU metadata. (Profile 7 is designed for a base encode (backwards compatible with other formats) plus accompanying Enhancement Layer (which can deliver greater bit depth AIUI) and RPU Metadata, Profile 8 just for a backwards compatible encode and RPU Metadata (with no DV enhancement data for increased bit depth)

The stuff that is ICtCp-ish (IPTPQc2 technically) usually contains something like dvhe.05.03, BL+RPU and no reference to HDR10 and no HDR10 metadata as it's not HDR10 backwards compatible, and has an ICtCp PQ encoding (in HEVC usually, though I think AV1 is also an option?) with DV BPUs. (Media Info still reports YUV as the color space - though I don't know if this is an assumption or a flagging thing)

AIUI libplacebo will decode IPTPQc2 encoded video but I don't know how fully - some discussions about Dolby-specifics such as NLW and MMR.

Quote from HiassofT

refresh rate switching is essential if you want (micro-)stutter-free, smooth video playback

Sorry, I had confused chewitt answer "refresh rate changing for optimal media playback" with kodi 'optimal' setting for variable refresh rate changing within a media file. Now I get it.

Quote from HiassofT

Regarding DV: UHD Blu-Rays have a mandatory HDR10 base layer, so DV on these disc is an additional layer on top and RPi4/5 will output the HDR10 layer just fine - tested that here with 4k (DV) Blu-Ray rips I did on my own with makemkv.

Regarding HDR10 mandatory compatibility layer on DV rip sources, yes it is there but on HDR displays with lower brightness than content's mastered luminance you need DV (or some kind of) tonemapping, otherwise highlights are blown-out, because HDR10 displays don't tonemap higher nits to their range, only DV does. However, my Samsung S95B tv is non DV and 1,000 nits capable and it can 'map' 10,000 HDR10 content correctly. But a Sony DV-enabled tv clips with 1,000 nits HDR10-only content, only DV content is shown correctly. So sending HDR10 compatibility layer is going to clip highlights on many tvs and monitors, since most of these won't reach content brightness.

Quote from HiassofT

RPi4/5 certainly wouldn't have the grunt to process that - direct-to-plane rendering works fine for 4kp60 but GL/EGL rendering doesn't - it's too slow, even without shaders having to do tonemapping

I understand a RPI4/5 may not have enough power for vulkan or opengl shader tonemapping, no question. Certainly HDR is not working on linux yet, and LE has the lead here. RPI OS Kodi package appears to use FullKMS open source driver and it has full 4k/HEVC acceleration. Maybe it's the same thing LE uses.

I've read Wayland can live over KMS. Probably it's an additional layer to direct KMS and slow things up as you say.

I just built my 8GB Pi 5 with this case: https://argon40.com/en-gb/products…-raspberry-pi-5

Running like a dream at the moment, it's quite impressive how powerful this thing feels compared to the Pi 4 in general.

I have a few raspi lying around, and while the 4/5's do work kind of nicely with Libreelec, they ´weren't designed to be living room material. And the pi foundation does everything to keep it that way:

• no power management,
• no soft on/off
• flimsy connectors (micro hdmi is mechanically highly unstable)
• no decent case
• connector all around the board
• no remote and while it has CEC, the latter cannot switch on the device

People keep saying keep it on, it doesn't suck that much power when idle,,, hmm, well, yes, but it keeps wol-ing other servers that could actually sleep. If you disable wol, then again you need to run around and physically switch on other stuff..

Again usabilty for non Nerds is a pretty low. Also, the PQ has improved, it isn't that great.

Which brings me back to intel nucs. Why is it that it they have been abandoned? Money? Is it possible to bribe someone to bring back functionality that was already there in LE10 and got broken in 11/12?

Some clarification - Intel NUC is used heavily and extensively in testing of all LE releases - specifically a NUC12WSKi7, and previously NUC6,10,11. There are known “issues” with audio on NUC11 that I have personally experienced, but are not occurring on a NUC12WSKi7. So not sure what issues are being referenced. There are LSPCON issues in some NUC devices that have caused issue.

Note: when using “new” (not yet upstreamed hardware) e.g. the AX100 wireless, some of the N100 chips … there will be 12-18 months of pain for the purchaser (note - I run bleeding edge software (and release candidate / patches) - to allow testing and running on these newer generations of hardware.) so LE is pretty much up to date as much as possible for support of newer hardware. But if the hardware being purchased is not fully supported by Kernel 6.6.y for Intel equipment (I can only vouch for the NUC mentioned) then you will have issues as this is the release that we are going with for LE12.

Next thing is unfortunately Intel has left the NUC business, and as an avid NUC users, have not decided on my next Intel direction. But after LE12 is released - I will probably be focussed on using the AMD Beelink SER7 - but this will bring its own challenges.

yamcenutzer It has a soft on / off, you just have to connect a button to GPIO. I agree with the tiny connectors. A real developer board would have sturdy, full-size connectors. I'm using two RPi, one as a NAS, and one as a streaming box on a non-smart TV (LE). Both run very stable.

RPi5 has a power on/off button and the Flirc case (shipping soon) will be decent (and there are others). For sure it's not the perfect hardware for everyone's taste, but it has the best software support by noticeable margin and that's the most critical factor for daily-driver usage with LE/Kodi. NUC's started out as a solid piece of kit and their reputation is built on that, but in the last few years as Intel bred chipsets faster than people wrote drivers for them it's been less smooth sailing and the current experience does not live up to past reputation. I think some of the cheaper mini-PC devices devices that ship these days have promise, but I think software support needs to improve in multiple places before you'll see project staff singing their praises.

Quote from heitbaum

Some clarification - Intel NUC is used heavily and extensively in testing of all LE releases - specifically a NUC12WSKi7, and previously NUC6,10,11. There are known “issues” with audio on NUC11 that I have personally experienced, but are not occurring on a NUC12WSKi7. So not sure what issues are being referenced. There are LSPCON issues in some NUC devices that have caused issue.

Note: when using “new” (not yet upstreamed hardware) e.g. the AX100 wireless, some of the N100 chips … there will be 12-18 months of pain for the purchaser (note - I run bleeding edge software (and release candidate / patches) - to allow testing and running on these newer generations of hardware.) so LE is pretty much up to date as much as possible for support of newer hardware. But if the hardware being purchased is not fully supported by Kernel 6.6.y for Intel equipment (I can only vouch for the NUC mentioned) then you will have issues as this is the release that we are going with for LE12.

Next thing is unfortunately Intel has left the NUC business, and as an avid NUC users, have not decided on my next Intel direction. But after LE12 is released - I will probably be focussed on using the AMD Beelink SER7 - but this will bring its own challenges.

Thanks for the info. I am glad to hear that Nucs are still extensively used for testing. I am however sorry to learn, that especially the 11gen have issues. The reason I got myself a nuc11 after years of happy using a nuc5 was that the nuc11 are the last ones with CIR. Also the nuc12 seemed even more overkill. I guess I'll now have to wait for the ASUS p42 with a n100 to start working, although I'd rather prefer my Nuc11. It's the smallest i3 (the pentiums don't have CIR). Any chance the nuc11 issues (what are they one you know about?) get resolved. I have issues with Audio coming and going and passthrouh not working as mentioned above near the starting posts of this thread.
The other issue has to do with the tv.hts client not playing uhd streams with VAAPI, which, I guess, is not really related to the chip.

Quote from yamcenutzer

Thanks for the info. I am glad to hear that Nucs are still extensively used for testing. I am however sorry to learn, that especially the 11gen have issues. The reason I got myself a nuc11 after years of happy using a nuc5 was that the nuc11 are the last ones with CIR. Also the nuc12 seemed even more overkill. I guess I'll now have to wait for the ASUS p42 with a n100 to start working, although I'd rather prefer my Nuc11. It's the smallest i3 (the pentiums don't have CIR). Any chance the nuc11 issues (what are they one you know about?) get resolved. I have issues with Audio coming and going and passthrouh not working as mentioned above near the starting posts of this thread.
The other issue has to do with the tv.hts client not playing uhd streams with VAAPI, which, I guess, is not really related to the chip.

I haven’t tested nuc11 for ages but the pass through “issue” I was able to reproduce on the NUC11PAHi7 regularly. The coming and going audio I have not experienced. The issue I experienced was “audio goes” and a reboot was required.

Quote from heitbaum

I haven’t tested nuc11 for ages but the pass through “issue” I was able to reproduce on the NUC11PAHi7 regularly. The coming and going audio I have not experienced. The issue I experienced was “audio goes” and a reboot was required.

Ah, yes, exactly the issue I have on an 11PAHi3. Any chance this could be fixed?

Also there is something interesting going on here...Intel Alder Lake 2160p @ 23.976 Hz passthrough HD Audio dropouts (i7-1270p/N100) - Page 2 - Hardware - LibreELEC Forum 
although that is also 12gen

Quote from yamcenutzer

I have a few raspi lying around, and while the 4/5's do work kind of nicely with Libreelec, they ´weren't designed to be living room material. And the pi foundation does everything to keep it that way:

• no power management,
• no soft on/off
• flimsy connectors (micro hdmi is mechanically highly unstable)
• no decent case
• connector all around the board
• no remote and while it has CEC, the latter cannot switch on the device

People keep saying keep it on, it doesn't suck that much power when idle,,, hmm, well, yes, but it keeps wol-ing other servers that could actually sleep. If you disable wol, then again you need to run around and physically switch on other stuff..

Again usabilty for non Nerds is a pretty low. Also, the PQ has improved, it isn't that great.

Which brings me back to intel nucs. Why is it that it they have been abandoned? Money? Is it possible to bribe someone to bring back functionality that was already there in LE10 and got broken in 11/12?

The best case for pi4 is the argon one V1/V2, on/off power management, and for the remote i use for year rii mini keyboard, far better than a simple remote control