@ChuckPa What does this mean? HW transcoding is working as expected?
I tested again today, Jellyfish 400 mbps 4K is literally unplayable on both the browser and my iPhone. But maybe 400mbps is something so big that’s not out there in the real world? Even though the file was only 1.5 GB I thought it should go smoothly, it just doesn’t play at all. I’m not 100% sure what the 400mbps is supposed to represent though. I know my internet connection is about 100mbps, but that’s internet speed - unrelated to video size.
On browser: it just buffers for 20 sec then crashes
On iPhone, I got once “connection to server is not fast enough”
and another time: “The server is not powerful enough to convert this video for smooth Playback.”
Those errors don’t appear in the browser app though (but I guess that’s another issue entirely)
I did see the CPU spike until 100% with that jellyfish video.
Ok, so I tried another Jelly fish, this time I tried a much smaller file that said 80mpbs.
“4.2 Mbps” is because of how it scans. Don’t worry about it. The initial scan picks specific frames. At that bitrate, and resolution, the specific frame it selected for initial analysis often shows as less. The i965 chip has “throttling” issues at rates above 100 Mbps. That’s why intel added a new interface in the GeminiLake platforms. Those GeminiLake CPUs should be using the iHD (which is currently not working). If the iHD_video_drv.so (driver) were working, the rate would be accurately shown.
“Transcoding is working” – Meaning that you are accessing the QSV ASIC through the i915/i965 asic pair (both in the CPU). QSV is detected, 2160p HDR decode works.
Caveat The i965 is not rated for sustained bitrates > 80 Mbps. That’s why this is a “workaround”.
The bug with the iHD is simple but not easy to fix. It is required for all Intel Core -9xxx CPUs (CoffeeLake / IceLake). It works for them.
I’m not worried at all about an inital 100% CPU spike. PMS is reading and filling the buffer as fast as it can. Once the output (playback) buffer is full, you see the CPU drop. That’s all 100% expected and perfectly normal because it’s reaching steady state.
Trying to play to a LAN or remote not capable of handling more than 100 Mbps — you get the crazy results. Go back to the Remote Access settings. set your upload limit. Remote devices will have their streams transcoded down to fit within that limit.
Internet speed * 0.8 = total bitrate available (best case). This must include the bitrate of Video , Audio and subtitle track(s) being sent.
So your iPhone was correct. It can’t play at the speed you requested. Notice showed you the maximum of 79.9 ? There’s your hint. 83.3 is perfect / theoretical. Plex is being a bit conservative to account for propagation delays.
Last thing. IGNORE the CPU… 99.999% of the work is being done in the QSV ASIC. The CPU’s job is to read the file, then send out the converted stream when done.
IF it ever does hit 100%, then hardware isn’t working. You’ll know it. HEVC will chew up the entire CPU in a heartbeat
So yesterday I signed-up to Plex Pass and got PMS running on my QNAP NAS TS-653D. So far i’ve been really impressed and but like others I’m experiencing issues when transcoding. All videos I’ve tried so far work perfectly when direct play/keeping original quality, but the minute I change the quality to auto or anything other than keep original the video either it doesn’t play (via the web, black screen orange rotating circle) or when on my iPhone I get a frozen image and the audio continues to play.
I’m guessing my QNAP (Intel Celeron J4125 quad-core 2.0 GHz) CPU doesn’t have the power to do the transcoding and the hardware acceleration (the Intel HD Graphics 600 GPU) isn’t being used, which is odd because looking in the Dashboard under the ‘Now Playing’ section the video file shows transcode with “(HW)” which one would assume indicates hardware acceleration is being used?
Reading the above I’m assuming the fix here is to modify the Preferences.xml file adding the following text… > VaapiDriver=“i965”
It sounds like a relatively simple fix and workaround, although I’m surprised there’s not a built-in setting option for this as I get a bit nervous editing system xml files.
Before I go ahead and break something can someone please advise/confirm my methods? Thanks in advance.
Thanks Chuck, it’s working a charm now. Many thanks!
Will this require any future maintenance - i.e. when updating Plex or when Intel release a driver fix?
When Intel releases the formal update and Engineering completes updating the transcoder (check the Release Notes from Plex), you can remove the string using the same procedure.
Hi @ChuckPa,
I’m still have the VaapiDriver=“i965” code in my Preferences.xml file. I’ve noticed that Q29: How to bypass iHD driver appears to have been removed from your QNAP FAQ page and your last post in this topic states:
It’s good. No bypass needed with 1.21.0 +
Just for absolute clarity, has this issue with the Intel Celeron J4125 CPU (used in the QNAP TS-x53D) been resolved now and therefore is the work around no longer required?
Assuming this code is no longer required, am I to remove it before or after updating PMS. I’m guessing it doesn’t matter either way but wanted to double check as I’m just about to update PMS from Version 1.20.5.3600 to Version 1.21.1.3830.
That’s correct, you no longer need the work-around to force the i965’s driver to be used.
If you have some really exotic older videos, it might produce better quality in hardware but in general application the iHD is better and is also what Intel now supports.
