Anything better than a Pi4 currently?

    Cheapest way would be getting an android device that is licensed, or getting some cheapish device that could do tonemapping like Banana Pi M5 with CoreELEC. LE will not do it.

    Thanks for the confirmation. These proprietary formats are just annoying, only reason I care is some movies seem to only be available in 1080p or DV, no regular HDR10. I remember when distributing "lame" to handle mp3's required users to read some license and the headache that caused working with it.

    Im kinda set on sticking with x86; it sucks that I may be locked out of watching some movies in HDR quality but I have a feeling there will eventually be a solution.

    Out of curiosity, how is CoreELEC on a Banana Pi properly handling DV? Did CoreELEC pay for some licensing to handle DV files in software?

    Sorry for the double post. My posts need to be manually approved, so I can't edit the last one (#23).

    From reading a bit on the CE forum, it seems like the key to CE with specific hardware decoding DV is a proprietary driver blob. They are reusing the same blob that Dolby provided to android manufacturers for that specific SoC.

    So I understand why DV doesn't work except in very specific hardware chains. I'm guessing that some hardware could do handle the decoding, but without the necessary drivers from Dolby it won't be possible. I know on some specific windows laptops, with specific video players, DV does work, but again that is because of Dolby's blessing.

    I wonder if any of this could be hacked in the future, to create the necessary drivers. Or hopefully we just move past DV, and get an open implementation that doesn't cause this mess.

    I think mpv player already does DV 'decoding' by dynamically tonemapping the HDR10 compatibility layer using open source ffmpeg libplacebo library and converting to SDR (or HDR10). I don't know how does LE tonemap HDR10 to SDR (static or dynamic), i just know by default it passes-through HDR10 and DV to the display.

    I own a Samsung S95B Oled tv and it doesn't decode DV, however I have played DV-L1 processed content into HDR10 and native HDR10 on a split-screen clip and it looks the same. Only DV-L2 trim has a colorist tweak to lift dark scene shadows a bit (dynamic metadata), but the player could do it as mpv does. Dolby Vision L1 basically tonemaps the content to the tv luminance range. My HDR10 tv does this on its own. It statically tonemaps out-of-range mastering luminance to its capacity, i.e: 10,000 nits to approx. native 1000 tv nits without clipping using a curve. In theory, as I've been told, a 'normal' HDR10 tv doesn't do it when it's out of its range, for this you'd need DV or HDR10+ , but my tv does it already.

    Dolby Vision is a locked platform. But a player, in this case LE could dynamically tonemap HDR10 content to its target display range. This is what mpv does. Mpv in Windows has access to the system's output display format. I don't know if LE can access the display HDR characteristics by HDMI/EDID.

    Mpv uses two algorithms, bt.2446a for HDR10->SDR, and st2094-40 for dynamic HDR10+ metadata (available or not). Then the gamma and colorspace conversion is done for the display output (P3, BT.1886...).

    Does RPI4 has the computational power for this? popcornmix says for 4k probably not.

    Edited once, last by wyup (December 25, 2023 at 11:46 AM).

    Quote from josh4trunks

    I wonder if any of this could be hacked in the future, to create the necessary drivers. Or hopefully we just move past DV, and get an open implementation that doesn't cause this mess.

    It has to be conform to Dolby licensing conditions. If you find a legal hack, let us know.

    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.

    Edited once, last by noggin (December 28, 2023 at 12:46 PM).

    Quote from noggin

    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.

    Ok, that makes alot of sense. I thought all DV files were unplayable (in regular colors), but now I see that some files labeled DV seem to play with at least HDR10 working!

    Quote from Da Flex

    It has to be conform to Dolby licensing conditions. If you find a legal hack, let us know.

    I don't think I would be very helpful, but I'll keep an eye out where I can help, lol. I do remember when I first started using in Linux in 2009 I had to use a Windows wireless driver using "ndiswrapper" to get WiFi working. So maybe that could be the state of things one day. If Dolby gets a little too loose with their driver signing and makes something that works on all Intel/AMD GPUs, we could get to a similar point. Though, that might still require users to provide their own input cause I doubt LE would/could include these blobs in their builds. But ideally, I just hope for more open standards to gain acceptance over closed ones.

    Quote from Da Flex

    It has to be conform to Dolby licensing conditions. If you find a legal hack, let us know.

    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?

    wyup Only Dolby can say what's legal - ask them. My take is: If a device can decode DV, it has to have a license. It doesn't matter where the decoding algorithm comes from. So I guess it's a license-per-device thing.

    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.

    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)

    To be fair, the difference between SDR content and 'base' HDR10 content is so massive that it makes me wonder if DV or HDR10+ is actually worth caring about at all.

    The reason I started this thread is because I recently bought a £3K Sony 77" Bravia OLED TV and wanted to know if I am missing out on 'experience'.

    Ive been a long time happy user of LE/Kodi on a Pi4 8GB. The audio/video support is second to NONE. The buffering/cache options are great for smoothing out the experience for non local content and it just works.

    I started my journey with LE, with a USB HDD connected to the Pi4. I then changed to an FTP/S backend with a server (in a datacenter), but still with local library. Today I run a Jellyfin server on 13th Gen intel hardware with a massive drive array etc... in a datacenter and use the Jellyfin Kodi plugin to sync the libraries.

    LE on a Pi4 in my experience DESTROYS everything else I have tried, including the Nvidia Shield TV Pro (which people rave on about)... Yes it does DV, but the hardware is dated, its underpowered and doesn't have enough RAM for high bitrate content.

    I am awaiting delivery of a Pi 5 8GB which I plan to make my main media center system and retire the Pi4 to the bedroom.

    In short.... There doesn't appear to be one single perfect device out there which supports everything.... But the best around in my opinion is certainly LibreElec on the Pi 4 (and hopefully 5).

    No Dolby Vision or HDR10+? Meh.... I don't think im missing out on much at this point.

    Edited once, last by tomstephens89 (December 29, 2023 at 12:16 PM).