ALL;
Continuing on our fixes to transcoding, We have an engineering build for JasperLake (N5xxxx and J5xxx)
Is there anyone who would be willing to test this for us in their machine and confirm operation ?
@ChuckPa I’d be happy to try it in my JasperLake environment.
Though I will note that I’m currently running the latest Plex Pass beta and HW accelerated transcoding appears to be fine. What issues does the engineering build address so that I know what to test?
Thanks as always for your efforts!
thanks for volunteering.
SOME of the JasperLake CPUs work ok while others fail when specific bitrate is set.
This happens because of NRC (No Rate Control) by default in the kernel for those processors ( EHL, JSL, DG2, ATS, and MTL )
It’s easy to tweak desktop platforms but NAS platforms are problematic. Some are lucky in that the Kernel and BIOS already enable Rate Control.
When a machine has this problem, the error reported looks like this:
h264_vaapi @ 0x7f3743735b00] Driver does not support any RC mode compatible with selected options (supported modes: CQP)
This is the condition we want to solve for with this build.
The result is: Quality mode versus Bitrate mode where the output bitrate will fluctuate at or below the selected level instead of holding steady
If you’ve ever played with FFMPEG directly, the CRF value is what we’re utillizing for those CPU/systems which need it.
I’m waiting for the Engineer to give me the link to the packages.
Which will you need ?
1 Like
Oh, sorry! Ubuntu/Debian Intel 64-bit. Thanks!
JasperLake-specific transcoder change ( CQP problem )
When testing, please confirm you still have control over output bit rate.
You should just as before.
Thanks @ChuckPa, I’ll test and let you know. If you’d like logs, please send me a PM and I’ll reply with them.
I’ll send the logs to you shortly, But, in summary, there were no issues with either 1.32.7.7571 (latest Plex Pass beta) or 1.32.8.7613 (engineering build).
I tested using the LG Colors of Journey HRK UHD 4K demo. For each test, I stepped down through 1080P 20 Mb, 1080P 10 Mb, 720P 4 Mb, and 480P 1.5 Mb; there were suitable reductions in quality for each step down (though my old eyes didn’t really perceive much, if any difference, between 1080P 20 Mb and 1080P 10 Mb).
For what it’s worth, my server doesn’t report the CQP message above with either version. On the contrary, it reports:
Oct 20, 2023 18:40:30.045 [140263446457144] DEBUG - [Req#4e/Transcode] [FFMPEG] - Driver supports RC modes CQP, CBR, VBR, QVBR.
At any rate, I’ll send you full logs shortly.
Edit:
If it matters, I use the following i915.conf.
cat /etc/modprobe.d/i915.conf
options i915 enable_guc=3
This enabled GuC submission and HuC firmware loading. (Though GuC submission isn’t actually supported on JasperLake; so enable_guc=2 is all that’s required.)
ALL
For JasperLake CPUs, specifically now hoping to test on J5xxx and N50xx CPUs.
N51xx has been confirmed functional.
So I’ve read through this thread and the last one and it seems like my current setup ( which is obviously far from supported ) is proxmox running unraid ( kernel 6.1.63 ) in a VM with the raptor lake iGPU which works fine with the docker binhex/arch-plexpass:1.32.4.7195-1-01 but crashes the unraid vm with latest.
I’d like to choose the best VM to create for running Plex and the best way of doing it.
So far my reading is that the closest I’d get to Plex’s comfort zone would be:
Ubuntu server.
Native rather than docker.
Is that correct?
Plex likes it simple. The simpler the better.
That having been said,
- Ubuntu server VM
- Pass the QSV / Nvidia GPU through to the VM
- Install the native DEB file
- Enable the repository. (automatic updates)
Every layer you add is another chance for failure.
- Unraid expects to own the machine – you have it in a VM with the dongle passthrough
- PMS will work in a container on the host OS but then you must manage updates
K.I.S.S. principle applies here. Avoid doing things just because you can and you’ll be better off — AKA. AVOID TEMPTATION!!! LOL 
the voice of a man with experience… coming from another… 
Hello,
I have version 1.32.8.7639 installed on my J5005 Gemini Lake NAS.
Apparently this fix applied to this version according to the relase notes:
(Transcoder) HW transcoding failed on GeminiLake CPUs when running on linux (#14465)
When I transcode a 4K SDR stream to 1080p it works fine using hw decoding. But when playing a 4K HDR stream to 1080p it still doesn’t work.
To further test this, if I disable “Enable HDR tone mapping”, then it converts a 4K HDR stream to 1080p fine as hw conversion.
So definitley still an issue with HDR.
Should this be fixed in the release that I’m running?
1 Like
What you’re saying here is confusing to me but I do understand you have JSL (JasperLake) which, until now, has not exhibited any problems but we can try a few things.
I will attempt to restate. Please tell me which one(s) work and don’t work.
- Transcode 4K HDR to 1080p without tonemapping
- Transcode 4K HDR to 1080p with tonemapping (HW)
- Transcode 4K SDR to 1080p no tonemapping of SDR
What we changed fixed GLK. ( #14465)
What we have since learned
-
Unraid 6.12.4 → 6.12.6 (current release as I write this) – FAILS on GLK
– I’m working with the Unraid folks now to figure out why
– 1. Hardware detected as PMS starts
– 2. PMS cannot talk to the QSV via the i965 driver -
I have a J4125 GLK here
Hi @ChuckPa
Transcode 4K HDR to 1080p without tonemapping
*This works OK.
Transcode 4K HDR to 1080p with tonemapping (HW)
*This does not work.
Transcode 4K SDR to 1080p no tonemapping of SDR
*This works OK.
I am running this in docker running on Debian 11.
It used to work OK. I’m about to purchase a 1080p TV for my daughter, so I thought I would check it and noticed that it doesn’t work.
Thanks
1 Like
Can you capture the DEBUG server logs ZIP file of this not working so I can see the failure?
( Restart the server, wait a minute, then perform the playback, lastly grab the logs)
Also, please let me know if you have a specific VaapiDriver= callout in your Preferences.xml and what value you have.
With that info, I might be able to figure out what’s happening and, if it’s what I think it is, give you a workaround until my team member and i can discuss it
Thank you for the logs.
I was incorrect about JasperLake. This is indeed GeminiLake.
The problem you’re having is based on the Kernel itself.
You’re using the 6.1 kernel which is known to have i915 problems and OpenCL failures.
There is a Backport wiki document which shows folks how to upgrade to 6.1 kernel.
Is this what you did to upgrade from the 5.x default kernel ??
If so, this is what caused the problem
(I’ve replicated this condition on my GeminiLake machine a few weeks ago)
You can try changing VaapiDriver="ihd" and attempting to use the Intel Media Driver.
If this is successful for you then great. Normal (J4xxx GeminiLake CPUs cannot use this alternative). This has a low probability of success given this is a kernel issue.
Otherwise –
Please let me know what you did & how you got the kernel into this state so we can figure out how to move forward.
The alternative is to hold, run without tonemapping, while we work here to make OpenCL compatible with the newer 6.1 / i915 drivers
– You could downgrade PMS temporarily but I would make a backup of your databases (just in case) before doing so. This also has a low probability of success as the problem is the Kernel - OpenCL interaction.
My only issue with these “Wiki” documents is they almost never document / test interaction / fallout of upgrading the kernel with hardware-accessing systems such as PMS. (“Backports” are often dangerous)
Hello @ChuckPa
Thanks for the info.
I’m running OpenMediaVault with Plex in a docker container. By default this appears to be running the 6.x Kernel (6.1.0-0.deb11.13-amd64). I’ve never really taken any notice of it. Maybe that happened when I upgraded from OpenMediaVault 5 to 6 recently and has broken Plex.
I just tried to boot with the 5.19.17-2-pve Promox kernel instead and the problem still persists. The option to boot from another kernel is available in OpenMediaVault. As it didn’t work, I’ve gone back to the default 6.x kernel.
Hope this all makes sense. I wouldn’t change anything with the Kernel. It must have been the default with the latest OpenMediaVault (I think).
Could I ask what you would suggest in this situation?
I’ll try changing the default driver first and see how that goes. I’ll send an update! 
Tried changing the driver manually to ihd and that didn’t help at all. So I’ve gone back to i965 and turned off HDR tonemapping. All is good again!
So if it’s OK, I will wait for the work to make OpenCL compatible with the newer 6.1 / i915 drivers? Hopefully all what I have said here is still compatible with this option!?
Thank you.
