Server Version#: 1.15.2.793-782228f99
Player Version#: iOS 5.12.1
I’m trying to get Plex working with hardware transcoding (Intel IGP) in an Ubuntu 18.04.2 LTS VM running on Proxmox… I’ve managed to passthrough the IGP to the VM and it seemingly does hardware transcode (see image below from Plex Web Dashboard), but every time I play something, I get the following output to the log immediately on play:
Mar 29, 2019 17:41:11.134 [0x7f24657fa700] WARN - Failed to find encoder ‘h264_qsv’
Can i just assume this is plex somehow getting confused about the CPU / IGP in the VM and can ignore this warning or does this point to it not hardware transcoding?
@ninja888plex,
I have a lot of trouble with my VM Plex under Proxmox, I solved a lot of these problems by switching to a LXC container.
There is especially a real gain of performance because the I/O are based on the host kernel.
Technically transcoding requires a good CPU rather than a good GPU.
LXC on Proxmox is not really an option for me at present given that the Proxmox (Debian Stretch) intel vaapi drivers are very old and don’t support the later Gemini Lake/Coffee Lake IGPs. Hence, no hardware transcoding under Proxmox LXC for me…
Hopefully this will be solved once Proxmox 6 is released and uses Debian Buster.
Having said that, what Intel IGP are you using under Proxmox LXC currently? Did you have to do anything with the Proxmox host kernel / drivers to get them working under LXC hardware transcoding?
I more interested in the Plex Devs opinion on whether I can just ignore the warning in the log if it does actually “seem” to be hardware transcoding. It’s just strange it provides that warning then hardware transcodes so maybe a bug?
Thanks @ChuckPa but that relates to LXC rather than a VM… I’d be interested to see what is the condition for showing the warning in the Plex Media Server.log “WARN - Failed to find encoder ‘h264_qsv’” when plex does seemingly then perform the hardware transcoding?
Just as it states… The H264 QSV codec. They are shared object libraries (.so) .
This is why having exec privilege on the drive where the container resides is important.
The root is mounted with exec (so files in /bin can execute)
If the drive you have (e.g /home) isn’t mounted with the exec option specified in /etc/fstab, you probably won’t have permission to execute.
If all the other codecs work properly, then it’s not the exec flag.
There’s no containers involved in this, it’s an Ubuntu 18.04.2 LTS Server KVM VM that is hosted on Proxmox with the VM’s virtual disk actually on a Synology NAS (NFS)… The VM disk is, as far as the VM is concerned, local to the VM.
(1) Followed above to recreate (empty) Codecs dir
(2) Played a Direct Play file (H264 / AAC), at original quality, no issue
(3) Set reduced the quality in the player to 720P
(4) File plays as expected at lower quality (Plex.tv Web indicates same as image above - that is it hardware decoding/encoding)
(5) The following three lines are output to the log:
Mar 30, 2019 15:34:24.487 [0x7fd045ffb700] WARN - Failed to find encoder 'h264_qsv'
Mar 30, 2019 15:34:26.016 [0x7fd0457fa700] INFO - CodecManager: obtaining decoder 'h264'
Mar 30, 2019 15:34:27.313 [0x7fd0457fa700] INFO - CodecManager: obtaining decoder 'aac'
The following files are now present in “Codecs” (datetime stamps indicate they were successfully downloaded at the same time as the “CodecManager” log entries above)… So the question I guess is, if libaac_decoder.so and libh264_decoder.so have been downloaded from plex.tv, why not ‘h264_qsv’?
$ ls -laR
.:
total 16
drwxr-xr-x 3 plex plex 4096 Mar 30 15:30 .
drwxr-xr-x 16 plex plex 4096 Mar 30 15:30 ..
drwxr-xr-x 2 plex plex 4096 Mar 30 15:34 a22632d-2132-linux-x86_64
-rw------- 1 plex plex 36 Mar 30 15:30 .device-id
./a22632d-2132-linux-x86_64:
total 2136
drwxr-xr-x 2 plex plex 4096 Mar 30 15:34 .
drwxr-xr-x 3 plex plex 4096 Mar 30 15:30 ..
-rw-r--r-- 1 plex plex 300528 Mar 30 15:34 libaac_decoder.so
-rw-r--r-- 1 plex plex 1874880 Mar 30 15:34 libh264_decoder.so
Then there is no codec available for download at that version.
I don’t know why, plus the weekend and nobody to ask, and , unfortnately, 3:30am (need sleep)
