Hey All, First Time, Long Time and all that…
I’ve been using Plex for years on older PCs and/or Mac, but I went out and picked up a Mini PC with an N100 and I was pretty excited to get it going and I just installed the latest Ubuntu Server w/o looking into it, not realizing it’s only been out 7 days!
How long do these things typically take with Intel? Should I bite the bullet and reinstall on an older Ubuntu release, or are we talking about weeks and not months for an update?
Can I ask what the issue is precisely. I haven’t tested extensively but on my Proxmox 8.2 LXC install with Intel iGPU passthru, h/w transcoding appears to work for resolution changes eg 4k to 720p. Is it limited to HDR to SDR tone mapping or HDR content in general or have I not tested enough?
From my testing, HW transcoding will work fine as long as you don’t have tone mapping enabled. As soon as you enable it, Plex falls back to software transcoding.
To be specific about the failings of 6.8 –
The transcoding stack, when using HW is:
The 6.8 kernel issue prevents HW OpenCL from functioning.
Therefore, it must fallback to SW OpenCL which is CPU expensive.
For those of you with 6.8 Linux kernels and failed HW transcoding, May I please have DEBUG log files which show the following:
I am requesting this to add to the support ticket.
Hi Chuck,
I’ve just made quite a troubling discovery.
Let me explain, I have the same issue as everyone else - no hardware when I activate tonemapping, but I don’t have any failures either; the CPU manages to take over without suffering too much.
But here’s something quite funny: when I activate PGS subtitles, the hardware transcode with tonemapping works perfectly.
However, I can’t send the zip file here; it contains personal data such as email and public IP. Could I send it to you privately?
FWIW, it does appear that QSV/VAAPI-based HW tonemapping works with ffmpeg on Kernal 6.8 in ffmpeg. I tested this while doing some manual transcoding with ffmpeg. This is the filter_complex I used:
-init_hw_device vaapi=vaapi:/dev/dri/renderD128 \
-filter_hw_device vaapi \
-hwaccel vaapi \
-hwaccel_output_format vaapi \
-filter_complex \
"[0:s]scale=flags=fast_bilinear,format=bgra,hwupload=derive_device=vaapi[0];\
[0:v]setparams=color_primaries=bt2020:color_trc=smpte2084:colorspace=bt2020nc,tonemap_vaapi=format=nv12:p=bt709:t=bt709:m=bt709,procamp_vaapi=b=0:c=1.2[1];\
[1][0]overlay_vaapi=eof_action=endall:shortest=1:repeatlast=0:w=3840:h=2160"\
(this transcode job also HW accelerated burning in PGS subtitles)
I recognize that this is not how Plex Transcoding works currently, but perhaps this example would useful for the Transcoding engineers as they research how to address the issue.
I stumbled on this forum after trying to figure out why my plex server stopped hardware transcoding. It seems like a bug that’s reared its head in the past.
This is quite strange, I concur with Cousclou findings. When activating PGS subtitles, hardware transcode with tone mapping does work. Not sure if this makes a difference, but I’m on Debian 12 and ProxMox VE 8.2.2.
Also, I don’t really see much difference when disabling HDR tone mapping on the server end. In the past, video was mostly grey. Now, even disabled doesn’t seem so bad. I will keep it disabled for now and hopefully the issue will get resolved.
I believe that enabling PGS subs disables hardware tonemap in Plex today. PGS sub burn-in is done in software, so tonemapping must also be done in software in that scenario.
PGS (or any image-based) subtitle burning must currently be done with software.
This disables HW completely which will be evident in the “FFMPEG” start line of the logs.
I’m chatting with the Engineer and shared your post.
It was confirmed that your solution works however the caveat is it only works for the newer Intel devices. (You’re using VAAPI tonemapping vs OpenCL tonemapping).
The issue comes for those older Intel devices which are not supported for vaapi tonemapping.
There is a solution and confirming it works for ALL supported CPUs is where the adjustments are being made.
Yeah, it works amazing well on my DG2-based GPU (> 100fps with PGS subtitle burn), and it does run (slower, but still 2x - 3x realtime) on my 8809G-based Hades Canyon Skull NUC (which is from 2018), but I have no idea how many active intel CPUs that currently work with the OpenGL solution don’t work with the VAAPI solution.
Even if they solve the OpenGL issue, I sure wish they would support this approach for CPUs that support it, as PGS hardware transcoding is really nice. 
To be specific – while GeminiLake has always been the problematic step-child, ApolloLake should be valid because of its KabyLake base. JasperLake shouldn’t have any problems yet it does.
I will try to get some free time and see what I can recreate of your work again on the newer kernels.
Since it sounds like this could require both a kernel and Plex update, is there an upstream kernel bug or discussion we can track to see progress on the kernel being fixed?
There isn’t a kernel bug per se. For the Kernel to break this functionality by accident and not catch said failure seems like a deliberate change.
That said, there is an upstream report and open issue with the Intel NEO drivers not being detected in the 6.8 kernel.
It’s unknown if this is an Intel problem or indeed a kernel problem.
We are monitoring the progress to see what happens.
There are options but most of those options are unacceptable for users.
If we’re understanding what’s happening correctly.
As you can see, there is a considerable lack of information as to both current status, short term and long term plans.
We’re trying to learn as quickly as possible.
@ChuckPa Any updates from the engineering team on the latest Intel driver fix, and do you need any more log examples? (I’m assuming not at this point.)
We are working on it now.
Thanks for the offer of logs.
The next thing we’ll need is Alpha Testers (Forum Preview)
to help us confirm everything indeed works for ALL the platforms.
(This is a big update for Intel-based platforms)
Thanks @ChuckPa, I appreciate the updates
Does this also include the fixes for Nvidia and other GPU’s for 4K subtitle burnin issues that have been worked on for months? I can’t recall those ever being released. The burnin issue still plagues my PMS beta instance, and I’m on the latest beta. Unless I missed something, which I’d love to know.
We are working on the entire suite.
Remember where burning occurs in the stack.
In the past, after all transcoding was done, the CPU was then tasked to burn into the resultant image.
We’re changing this entire process.
You can almost think of it as an entirely new transcoder.
