JasperLake hevc hw transcoding failing

Server Version#: 1.43.1.10611
Player Version#: 1.112.0.359-0d79a49f

I reported this issue when HEVC was new in plex, but was told that it was experimental and to disable it. So thought that I would give it another go now that HEVC has been unmarked as experimental.

I have a JasperLake igpu. Every time I enable HEVC hw encoding it pauses for a while, then flips back to Direct Play. If I disable tone mapping it has no effect. It looks like the HW transcoding fails and then falls back to Direct Play.

If I disable HVAC HW transcoding, the x264 transcoding works as expected. That is it transcodes the file with HW transcoding to the bitrate one specifies. It does so without pausing, delivering quick transcoding when requested.

So there are 2 issues here.

The first issue is: that HW transcoding is failing when H265 is enabled.

The second issue is: The failed HW transcoding is not handled well. Instead of falling back to h264, it moves to Driect Play. This is of course an issue because this dramatically effects the bitrate. It also changes the codec, etc. Those are things that cause failures when they are required. So the fallback is set to something that will almost certainly cause a failure, instead of falling back to HW x264, → Software x264, → Direct Play.

Plex Media Server Logs_2026-05-20_12-02-07.zip (64.9 KB)

Do you have a sample file you can share? I’ve got a JasperLake-based system on which I can test (Celeron N5105) on Linux. I’ve not seen similar issues. However, I’m running the current beta, 1.43.2.10687.

Do you mean sample Video File? On my system it happens with every single file. It happens consistently. No exceptions.

Then perhaps try the beta version of the server I mentioned, as that works here with no issues on JasperLake with the files I have available for testing.

Here’s an example of one I’m testing:

I will give it a shot when it comes out of beta. I do keep Plex relatively up to date. I am not super convinced that updating will the answer, as this issue has persisted over so many updates. I actually had this issue with a second server of mine, or something very similar to it. But I was using NVIDIA. I had a Pascal card in there before and when I switched to a more modern Turning architecture the problem resolved its self. x265 just worked from then on. I am not sure if it was just putting another card in there that make it work, or if it was the architecture its self, but it did. With this other server, its running off a little NAS. I cant change the graphics card out. But in both cases hardware encoding on x264 worked well. So its not a problem with the card being found etc.

Thanks for that, I completely missed that it was out of beta.

I am on TrueNAS. I have to wait a little bit before this update becomes available to my update button. It will happen shortly, but as of now, I am on the latest version available to me.

The latest version became available on TrueNAS last night, so I updated it and tested today. Unfortunately it is still broken. No luck :frowning:

Unfortunately, I’m unable to test on TrueNAS on my JasperLake-based system. It’s running a bare-metal Linux install that I can’t break.

At this point it would probably be best to provide server logs with debug logging enabled (but not verbose).

I did post my server logs with the original post.

After asking Grok about it and digging into the issue I was able to fix it. I enabled a kernal parameter i915.enable_guc=3. This did it.

I asked grok who this bug report should be sumitted to. Grock said, VA-API, is flaky on JasperLake, and Plex could improve support by using QuickSync, but its a niche combo. I also think that error reporting within plex could also be improved.

But I will also submit a bug report to TrueNAS, so they might be able to change their default settings.

Yeah, sorry, I should have been more specific to ask for current server logs. Obviously not necessary now.

I’m glad you found your solution though. This is actually something I’ve posted about a few times and where I was eventually going in this case.

Glad you found the solution on your own. (Maybe I actually contributed something to Grok’s answer! Probably not.)