You are correct, but I was lazy and just told Plex to optimize the video instead. Test the ideal condition of both video and audio. After some tooling around, my bottleneck was the audio transcoding. Once audio is stepped down to a 5.1 AAC format, it streams just fine at a 3.2x rate with 4K HVEC source.
those numbers are horribly off and irrelevant for 4k movies and give the wrong idea @TeknoJunky bandwidth-wise for BD sources. the largest BD In my collection is a BD100 of Batman v Superman which is over 90GB. even at 100 GB. which is 800Gb… evenly spread for the sake of math over 1.5 hours is approx 148Mb/s. The highest bitrate ive seen is 220ish for an action movie.
you are talking about compressed x265
the raw uncompressed 4k data (ie what NVDEC is doing) is what that link is talking about, and is what the PCIE and GPU have to deal with.
think about the bandwidth for hdmi, which carry the uncompressed video/audio streams and other associated data.
https://www.google.com/search?q=hdmi+2+bandwidth
also @ https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_HDR10_video
i missed the earlier comment. thats my bad. as for the above… the p400 is not the bottleneck as it can handle 32GB/s at 3.0 x16… and plex is not sending raw 4k to the viewer… it SHOULD be decoding AND encoding. Its no different than 1080p. you will never get raw from a transcode, but a format suitable for the player
my response was in response to his earlier post
and
to wit, that the gpu does not have enough pcie bandwidth to decode the 4k (even if the gpu itself is capable).
this is not exactly true;
the source and the transcoded result are compressed.
the process of DECODING the source (ie uncompressing it) and then converting it to a different resolution and potentially different color space, and then compressing all take a great deal of internal processing bandwidth between the pcie/gpu/cpu/main memory/etc.
im never answering these on email again. i miss too much. thanks for the clarifications. ill see myself out.
Thanks this is very elucidating. I do have a question though, NVDEC and NVENC work just fine when handling high bitrate 4k encoded with H.264. I would think that if it can handle those over a 2x PCIE link, HEVC would work as well?
hmm yeah I would think so to, but perhaps it has more something to do with the conversion from x265 > x264, than just a resolution change 4k >1080
decoding x264 is not hard (even with 4k)
it is the x265 dec/enc that is hard. (not saying that plex encodes 265, it does not, just that x265 is just plain hard either way)
Ok thank you! So creating a backup of the original file and creating a new file with that code…got it
I had run nvidia-persistenced only as specified in manual, just running nividia-persistenced in terminal. And after running nvidia-smi I’d see persistence mode turned on.
Anyway, I’ve tried to use the script given from the github you’ve linked. I just haven’t got that to work either. It keeps failing to install the nvidia-persistenced service with the following:
Adding user ‘nvidia-persistenced’ to group ‘nvidia-persistenced’… done.
Killing nvidia-persistenced… done.
Backing up existing ‘/etc/systemd/system/nvidia-persistenced.service’… done.
Installing sample systemd service nvidia-persistenced.service… done.
Enabling nvidia-persistenced.service… done.
Starting nvidia-persistenced.service… failed.
in journalctl -xe I see the following line:
Mar 22 20:24:41 pve nvidia-persistenced[39127]: Failed to open PID file: Permission denied
I’ve tried to install the service manually, but with no succes so far. Tomorrow morning I am finally physically at my server location, to fix the blacklisting of nouveau drivers. My system still crashes on every reboot if I disable nouveau, I’ve read some posts about disabling nouveau already at the GRUB menu. so I will try to fix that tomorrow morning, hopefully that also fixes the problems I’m having with this persistenced module.
Really looks like after every little thing I fix about this problem, new problems arise xD. But I’ll keep trying untill it works. Thanks for the help so far, will update this post tomorrow morning after trying some more solutions
EDIT: got nvidia-persistenced to work, by locating the .pid file, its owner was root:root with 611. Changed this to 998:998, (user id and group id for nvidia-persistenced), after this. Install script works without any error, still no uvm/uvm-tools though. Maybe after reboot tomorrow
EDIT2: I’ve been doing a lot of troubleshooting this morning, but there is luckilly progress!
At first I tried to fix the “PCI express fatal error” my Dell server gives me after every reboot. Haven’t get that one fixed. Have found out it only does that with a reboot, shutdown → turn on does not give the error. So I don’t think the blacklisting has anything to do with it. Because the error is given before anything is booted.
I’ve tried many things to get uvm/uvm-tools to show up, the following udev rule fixed it for me at first: Bug #1760727 “/dev/nvidia-uvm-tools not created” : Bugs : nvidia-graphics-drivers-384 package : Ubuntu
I added the mount points to my config, started my lxc and immediatly got HW encoding working. So I shut my server down to see if it would still work after reboot, which it wouldn’t. After following every step I previously did, I couldn’t get uvm/uvm-tools to show up.
Eventually I found this guide: Install NVIDIA driver & CUDA inside an LXC container running Ubuntu 16.04 · GitHub
where I added the following line to /etc/modules-load.d/modules.conf
nvidia
nvidia_uvm
After updating kernel and a reboot the uvm/uvm-tools showed up! differently enough under a different cgroup as they did with the udev “solution”.
Some quirks I got after enabling decode as well, with the script given above: I did the patch on the host side to disable the 2 stream limit. fired the lxc back up, but limit wasn’t lifted. Stopped plex, applied the patch lxc side, and then the limit WAS lifted. Which is weird, since I shouldn’t be having to apply patch lxc side, right?
Hey folks, been trying to follow this thread for a little while. I had a freenas setup and snagged a P2000 from the recent slickdeals round, figuring I got a good deal and I’d wait around for gpu support for plex through freenas someday.
My freenas boot drive failed, so I’m facing a clean slate and considering making the switch to ubuntu to utulize the gpu immediately. My ZFS pool I’m pretty sure is in tact, so I could try mounting it with zpool in ubuntu.
I don’t have extensive experience with linux outside of freenas. Any advice before I give this a go?
Doesn’t seem too hard…
Step 1- install ubuntu to ssd
Step 2- mount/decrypt zfs pool
Step 3- install/restore plex
Step 4- install nvidia drivers
Step 5- …?
Step 6- something with wrappers
Step 7- profit.
edit: I see andy’s earlier comment for the wrapper. seems like the easiest part.
looks pretty much it to me.
i’d suggest making sure everything works as expected before complicating things with script wrapper, but otherwise yeah.
For my personal usecase, I’ve added a Nvidia gpu to do the heavy lifting for HEVC content only, My server has 2x E5 2470v2’s and never had problem with doing 15+ H264 transcodes. So I would want my RTX2060 to only kick in for the H265 content, would the following script work for that?
#!/bin/bash
marap=$(cut -c 10-14 <<<"$@")
if [ $marap == "mpeg4" ] | [ $marap == "h264" ]; then
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 "$@"
else
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 -hwaccel nvdec "$@"
fi
Or would you guys advise implementing it like this:
#!/bin/bash
marap=$(cut -c 10-14 <<<"$@")
if [ $marap == "hevc" ]; then
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 -hwaccel nvdec "$@"
else
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 "$@"
fi
Some quirks I got after enabling decode as well, with the script given above: I did the patch on the host side to disable the 2 stream limit. fired the lxc back up, but limit wasn’t lifted. Stopped plex, applied the patch lxc side, and then the limit WAS lifted. Which is weird, since I shouldn’t be having to apply patch lxc side, right?
I think if you installed the driver on both the host and the lxc then you’d need to patch both. I never install the driver on the lxc side so there’s nothing to ‘patch’ there for me.
After updating kernel and a reboot the uvm/uvm-tools showed up! differently enough under a different cgroup as they did with the udev “solution”.
This actually makes intuitive sense to me, and really, something you have to keep an eye out for anytime you install anything new on your server.
Glad you were able to get it to work! It certainly feels like this isn’t a ‘this always works this way’ solution unfortunately.
Yes, I will definetely be watching out for this if I’d decide to change out hardware.
There is indeed not a “guide to rule them all” yet. But I’ll also be keeping an eye out for people that need help in here. Thanks again for the help!
All I’ve put up a forum post on this in a more applicable area to act as a guide for patching Plex installs. The topic on this thread has been deviating pretty heavily to more about bugs or tweaks as opposed to being focused on the request for the devs to add native support.
If we can, we should use this thread to keep the request open to the Plex devs, but we can all work on finding the most stable working details in the other thread: Guide: NVDEC Hardware Acceleration Patch for Plex Media Server on Linux
Current state of NVDEC support on Linux:
- PMS 1.15.1.719 updated FFMPEG libraries to a level that NVDEC is now supported
- PMS 1.15.1.719 does NOT natively support calling NVDEC acceleration
- NVDEC does work when inserting ‘-hwaccel nvdec’ to the call to the Plex Transcoder to start a video transcode
- The Plex team has not yet commented on making this a native feature of Plex, but ChuckPA has been a generous help to this thread on getting the libraries updated to the working point they are now
4 Likes
I think that people are ending-up here because this is where google is leading them. That’s how I found this post. Trying to herd the conversation over there might be like trying to change the course of a stream, but I hear what you’re saying about good forum etiquette.
Hopefully the attention this issue has received shows Plex that there are many of us who are serious about the desire for this functionality to work. Kudos to the Plex Linux community for cobbling/hacking all of this together, as we always seem to do…
Indeed, well said. Really like how we all get together to get our own “experimental” setups working. Each and everyone doing it slightly different. We’re not gonna falter for Emby. We stick together and make it work xD. I figure you are in a similar situation as we are?
This is a great thread I have to say. I currently have a GTX 1080Ti setup for HW transcoding with both the nvidia driver patched (to remove the 2 stream limit) and a script to enable nvdec. It’s working great.
Quick question though that hopefully will not derail this thread.
Once HW transcoding is enabled, do the the transcoder settings such as “Transcoder Quality” and “Background transcoding x264 preset” still apply or are those only for CPU transcoding?
And has anyone compared the quality of HW transcoding with a Pascal card versus a Turing card? Wondering if there is any major difference in quality that would be worth the upgrade.
These are settings for software decoders, such as your CPU, these do not apply for HW encoders. HW encoders have only one setting.
Next link is some internal testing from Nvidia comparing it to libx264 medium setting. Not sure how reliable this is, and is not comparing to previous generation.
Here is LTT with the RTX2080 review: https://youtu.be/o1DoG6uTYBg?t=418
It compares to a GTX1080 and with x264 at “fast” preset (same “fast” preset as you can select with background transcoding)
1 Like
