When we found the root problem with iHD_drv_video.so not loading, it explained many of the errors everyone was reporting.
Now, with iHD_drv_video being compiled correctly, we can hopefully figure out the remainder of its problems.
Because it’s not needed for Synology or QNAP systems, I’m hoping Engineering allows PMS for Synology and QNAP to not include it. I see no need to install the file if a) Not needed and b) causes problems.
There is a known problem with vaapi / ffmpeg upstream. I am still trying to understand if it is because of ApolloLake or the changes made for CoffeeLake (-9xxx) CPUs.
In my case, on 918+ using the client-info below. No artifacts, pixelation.
Movie starts rather quick after selection. I’m running 1.18.3.2175 now and removed the iHD-driver from my NAS.
Test is using 4G connection so not local LAN test.
Your observations mirror what I have been observing:
On Synology and QNAP systems, iHD_drv_video.so is not needed.
It is known, when extreme high bit rates are used (80+ Mbps) there will be problems with the i965 because it was created long before such bit rates were ever thought possible.
I just SSH and renamed the /volume1/@appstore/Plex Media Server/lib/dri/iHD_drv_video.so (I just appended a .disabled) and I can confirm that the encoding works for me after the rename.
@ChuckPa
Did test the latest 1.18.3.2175 Version on my DS918+
.
iHD Driver: Transcoding MKV with Codecs - Mpeg2video, h264, h265 (with AC3 or AAC Stereo Sound) - and internal Subtitels, setting burned in (SRT, VobSub) it doesn’t work, just sound.
Removing the iHD Driver: Same Testsamples as before - Transcoding works but Pixelation 30-90 sec before picture is normal - not watchable!
Thank you very much! That solved my problem i could not watch transcoded videos anymore (they did not work from one day to the other --> Seems to occur because of a new plex version)
I am running on ASRock J5005-ITX MB Intel Gemini Lake with Ubuntu 18.04.3 LTS (GNU/Linux 5.0.0-37-generic x86_64) / Plex Version 1.18.3.2156
Therefore i am waiting for the Plex Version 1.18.3. 2175 on the public channel to get this fixed permanently.
I have the same problem with 1.18.4.2171 on a DS218+, but with all hardware transcoding from MPEG2 (DVR) to h264. Video won’t play. Switching to software transcode works, but pins the CPU. Regressing to 1.16.5.1552 has temporarily resolved the issue.
start playback of a file which demonstrates the problem
play for 10 seconds
stop playback
wait 20 sec for buffers to flush to disk
Settings - Server - Troubleshooting - Download Logs
attach the ZIP file here
Subtitles must be done by the CPU.
Most of the Synology processors are not strong enough to do burn in* subtitle processing in real-time when substantive video content is being transcoded.
So are you saying even with hw transcoding enabled, SRT text based subtitles is not achievable when hw transcoding 4k content without substantial buffering and this is not a bug that can be fixed?
On the client side, I’ve set it to burn subtitles for only image formats.
I’m at work right now, I’ll get those logs for you when I get home, but from what you are saying, this is working as intended and not really a bug.
I will also install plex server on my windows box that has a more powerful cpu/gpu combination. I’m assuming this should be able to do hw transcoding while being able to do SRT subtitle burn in real time without buffering.
My assumption was that Plex server is feeding the hw transcoded video and the SRT subtitles separately to the player. Is that not the case?
HEVC is the most difficult codec to work with. That’s why we need HW acceleration to deal with it.
Attempting to do the work on a 2500 Passmark CPU just won’t cut it.
If subtitle burning is required (although every plex player handles SRT subtitle overlays) then yes, moving to a machine with more power is appropriate.
