@rajil_s, at this point I think the issue is beyond what I can help with. I’m not familiar with LXD on Arch. To compound the issue, the 1030 card is unique in that it supports NVDEC and not NVENC. There could be more complication here than just simply getting everything set right on the LXD profile.
Plex with hardware acceleration on containers is very much a no man’s land right now. LXC on Proxmox seems the most common deployment here, but outside of that it’s going to be very hard to validate. I can say I’m doing LXC with passthrough ok a Debian container with Proxmox, but your mileage may vary a lot with such an infrastructure
Wow! This made a much bigger difference than I thought it would! I went from around 80-85% CPU usage on a H.264 1080p transcode to around 15-20%!
I mean, ok I might have a 9 year old processor but it was high-end when I bought it (plus I overclocked it) so I figured software decoding of 1080p content was not a big deal and it was all about the encoding (i’ve had NVENC working for a while). I guess I was wrong! Great work.
A lot of my friends had started to use my server, so I was even thinking of buying a new computer to handle the transcoding load (two people couldn’t transcode 1080p at once). Now I don’t have to! I just need my old GFX card and a 9 year old CPU. This is great, really, absolutely great. Thanks so much. This really makes Plex practical on hand-me-down gaming rigs repurposed as servers. I was literally pricing out something on newegg this week.
Awesome script, works great for me currently with my p2000. I had 6 4k streams going and GPU was sitting on 35-40% gpu. CPU was like 10%. This is going to be great once finally officially supported.
Is this script no longer working with the latest Plexpass version of PMS? I’m running the script (as a User script in Unraid), it says “already applied” yet it doesn’t appear to be working as you can see here.
I’ve just checked and all is working here, but I’m running fedora. Had to re-apply the script as latest version did update the transcoder, but all seems to be working according to netdata.
Nvmd, I realized I was running a different script that is more optimized for Unraid. I didn’t realize they weren’t one in the same. Sorry guys. I had to pull a new version of that script and now it’s working.
Has there been any updates regarding TrueHD 7.1 multi-threaded decoding?
I’m upgrading CPUs in my server but the new server has slightly worse single-thread performance (but incredibly higher multi-thread/cpu performance) and I’m a bit concerned about this?
thanks for the wrapper, i am using it on an intel xeon 1240v2 esxi system with passed through P400. While everything seems to work pretty smooth now, i am not seeing as much decrease in cpu usage with nvdec compared to using quicksync for decoding. With a intel graphics 620 on a nuc i can reach like 5% CPU usage on transcoding h264/h265 content while the nvdec solution seems to use around 30% CPU on the xeon. Of course this is still a very nice solution for retro fitting so i merely want to share my personal testing experience compared to current quicksync.
This is unlikely to happen. All audio transcodes with FFMPEG are single threaded. It sounds like there’s significant technical hurdles to multithread the workload without causing quality or audio loss
Running this patch with the latest Plex Media Server version (1.15.5.994) in the official Docker container (plexinc/pms-docker:plexpass) doesn’t seem to work.
I keep getting a bunch of these errors whenever I try to transcode anything:
[FFMPEG] - libva: va_getDriverName() failed with unknown libva error,driver_name=(null)
[FFMPEG] - Failed to initialise VAAPI connection: -1 (unknown libva error).
gsrcrxsi, this is due to converting 10 bit HDR to SDR (8 bit). It looks like it is more pronounced with NVDEC than by software, but color information is just dropped as opposed to resampled.
Leyaena, that log message is pretty standard if you do not have support for QSV. Was there any other log message?
I’m not sure 10bit HDR is solely the cause. I have several other 10bit HDR titles that do not do this. Why wouldn’t they exhibit the same problem?
Also. If that is the problem, where does the fix lie? In Plex, in the patch, or in the NVDEC hardware itself? Hardware Decode support is what takes most of the muscle to process.
I also see the artifacts on some of my HDR content but not others, but it is very much due to the handling of the color space. Even the software renderer doesn’t do the resample required, so all colors are washed out if compared to an SDR content source
