Hello,
there are new products from Qnap and Synology on the market. They are using the Intel Celeron J4125 processor with Intel UHD 600 Graphics.
I was wondering why this new Intel Processor can’t decode h.265 10 bit codec? The very old Intel J3455 from previous Qnap / Synology models can decode this codec.
What does that mean for Plex media (direct local) playback?
Can we help with this, e.g., doing beta testing etc? I have a TS653-D arriving tomorrow.
Thanks,
James
If I may augment here?
I am evaluating the QNAP HS435DX in our lab at this time.
Part of what I believe I’m seeing is the Intel IHD driver is not 100% compatible with the J4xxx CPU ASICs.
I welcome additional help from the community.
The J4xxx should be able to run using the default i965 ASIC interface mode which is enabled by placing VaapiDriver="i965" in `Preferences.xml when Plex is stopped.
Testing both IHD and i965 modes, in a variety of codecs and bit rates (low to extremely high) is VERY welcomed.
I can do lots of this, hopefully. How can I report it back? Is there a useful log?
What I’m interested in seeing is:
H.264 as pass 1 then HEVC as pass 2.
Pass 3 - 2160p HEVC
FIles I use, which are considered standard,
I have a “Jellyfish” (other videos) library section.
If you do these 15 tests, List resolution & bit rate + result.
When it fails, capture the logs at that point (DEBUG only - VERBOSE OFF)
and annotate. If you see screen image breakup and can capture that (screenshot) it would be superb. Codecs and drivers give hints by the way they fail.
There seems to be a way to disable the PLEX default 265 drivers so that it can seamlessly play 265 10bit files. If playing 265 video files via media Station app on the latest release of QNAP NAS with this chip, no issues playing the file, so it proves the chip can handle it but PLEX needs to rollout out new drivers or stop default codex booting up when this type of file selected to play if this cpu is detected on the hardware.
NASCOMPARES on youtube talks about this and will be uploading a video soon on how you manually workaround the driver issue in PLEX.
To setup yourself:
Preferences.xml with a Linux text editor (Syno text editor / QNAP text editor in File Station)VaapiDriver="i965" before the closing /> at the end . (it will look like this: VaapiDriver="i965" />
This will allow the J4xxx CPUs to be used until Intel updates their IHD driver.
Any update on the status of the IHD driver? Where does one check if there has been a driver update? Will this be included in the Plex updates? Or do I need to check the NAS software updates?
They released a fix to the iHD driver that should resolve this issue.
Issue documented:
Here’s the fix:
Thank you for reporting.
I’ve forwarded everything you provided here directly to the transcoder team.
Awesome! To be clear, I haven’t tested this fix yet, I just saw it was released.
You can’t try their fix as they’ve released it.
Plex has to compile it and integrate it with the transcoder drivers (downloaded on demand).
What you can do is add VaapiDriver="i965" in Preferences.xml using the Synology text editor (no Windows text editors) in front of the closing /> with PMS shut down.
When you start PMS, transcodes will use the i965 driver instead of the currently-failing Intel iHD driver.
Woohoo - having only recently moved my Plex to a new QNAP setup I got hit by this recently and look forward to seeing this fix in the server, without having to rm/mv the iHD driver away again!
Just to be sure, there hasn’t been a Plex release with the fix in place, right? Looked through the recent releases and didn’t see the iHD driver or Gemini lake mentioned. But perhaps it’s labeled differently.
There hasn’t been a release from Intel.
That’s the holdup
Intel provides quarterly updates, and the Q2 update was released on July 10. I think we can expect the Q3 release (with the fix) in the next couple weeks or so… I personally have my fingers crossed 
@ChuckPa Looks like Intel has released a new driver with the fix! Hope the Plex team can get this fix in for us soon!
Thanks very much for being on top of it.
I suspect they already know but I forwarded the link anyway 
Seems like that PR was not a fix for the driver issues. 
Someone verified in the issue that the problem still exists, but I haven’t tried it myself though. See [Issue] KO hardware decode/encode with Gemini lake family · Issue #930 · intel/media-driver · GitHub
Thanks for keeping me up to date. That’s one less thing I need to run down.
I’ll be checking in with the transcoder guys today/monday so will close that loop.
