This is only the packaging. It does not provide any information to PMS.
I have written it this way to help you (the admin) be aware of:
a. Any local configuration issues (the base Debian package)
b. HDR Tone mapping dependencies for sub-9xxx CPUs which need them (Beignet)
c. HDR Tone mapping dependencies for 9xxx and above.
Given:
a. Processors -7xxx (KabyLake) and -8xxx (CoffeeLake) rely on Beignet for tone mapping.
b. Processors -9xxx and above rely on Intel Compute Runtime for their tonemapping.
My goal with this packaging update is to take as much “guesswork” as possible out of installing extra packages to support HDR tone mapping for those who don’t necessarily understand the intricacies of why one is needed over another.
When PMS starts, specifically the transcoder, knowing the video it has to transcode, it checks to see which runtime libraries are present. If the right ones are installed, HDR tone mapping will occur. ( at least that’s the plan )
Regarding the reports of Tonemapping failing when enabled but working when disabled, I am working with the transcoding team to get that all sorted out. I relay the information to them.
What will be of most help is creating discrete DEBUG (not VERBOSE) log file ZIP sets.
HDR disabled but working
-followed by-
HDR enabled, transcoding the same file, but failing.
This applies to all processors , KabyLake and above.
If we can do that, while I finish this packaging (which is about to be put into a formal build for testing here), then we’ll be ready to go by addressing both facets concurrently (packaging and runtime)
Any form of pass/fail matrix we can create would be outstanding.
It’ll paint the landscape and hopefully make focusing in on the fault easier.
A note for those who just want HW transcoding of HDR content working… I’ve tried a few different builds, including the latest GA (general availability, public build), as well as the one linked in this thread. And neither actually gives me HW transcoding of HDR content. However, there is a build that does work. It’s this one:
plexmediaserver_1.21.1.3830-6c22540d5_amd64.deb
Note that the build that actually works, does NOT mention the newer Intel libs during install… Instead, it mentions the older beignet one, and the opencl library. But if you install the latest Intel libs from Releases · intel/compute-runtime · GitHub , then the above plex media server build may work for you.
I’m using the intel i5-10400 cpu, with no graphics card, and HW transcoding of 4k HDR content totally works, but ONLY using the build linked in this post.
@ChuckPa , the build you linked above, seemed to do quite well regarding identifying which libraries I need, and telling me whether they were already installed.
I’m about ready to spin a new one.
There shouldn’t be any changes other than those inherent to PMS
If nothing fails from the packaging perspective – meaning I identify everything correctly – then I’ll send this over for final QA and release to everyone.
There is a release of PMS making its way through testing now which fixes one significant problem where HW transcoding cuts out / is inconsistent. I’ll know more when it comes to me to rattle
I’m running the same chip (on a z490 board) and Version 1.22.0.4163 works perfectly for me. After that is where the drama begins for me. Sounds like things are happening though so hopefully not too much longer now. I only recently got the 10400 as I was giving it plenty of time to be confirmed working, which it was. Damn new chips really toppled things over…
Beignet installation requirement regardless of ICR status
“Flip-Flop” of HW transcoding when HDR enabled
I’d like to finalize packaging and make certain this is production ready
I cannot address functional issues with CometLake or RocketLake CPUs.
I’m only verifying the installer is capable of properly detecting the CPU and capabilities.
It should still detect:
Native, Docker, LXC, or VM
systemd, init, or custom
Intel i915 visibility (required for va-api)
Nvidia GPU visibility
All local site customizations from /etc/default/plexmediaserver or override.conf
All previous packaging capability / reporting should be as always.
Should be able to update from within a container.
I would appreciate help one last time with this to make sure it is where it needs to be.
I only have a 9th gen (Hades Canyon NUC8) to work with here at this time.
I double checked it. I even purged plexmediaserver, same was what emb531 did. I even downloaded it twice as part of my double-checking. Downloaded twice, installed twice. Same issue both times.
I have no idea why passing the CPU “string” doesn’t work.
There is no logical reason for it when the same exact text can be pasted to the shell command line (sh or bash) and it works flawlessly.
)
Downloaded twice, installed twice. Same issue both times.
