excellent explanation. That makes so much more sense now. Thank you!
On most nix variants the process is re-parented to init, and is called an orphaned process. The opposite, a child process exiting without its parent reaping it, is a zombie process.
Sorry for off-topicness. Still waiting for official hardware decode support. Switching to alpha channel is getting more and more tempting, but don’t want to break anything 
This has been an amazing thread for tinkering around, and like all of us here, I am very hopeful for what hardware decoding will bring to the table. I’m testing on Ubuntu 18.04, and a patched GTX1050 ti. I’ve gotten 9 simultaneous hvec 1080p transcodes running on the card in one test, and have pushed 3 4k files in another, and it’s been purring along very happily for the most part. I see a bit of a cpu hit with audio decoding, but from what i’m seeing in the thread thus far that’s to be expected.
I have however come across an issue decoding older avi mpeg4’s. I imagine that a lot of us who have been doing this for a while have more than a couple of these floating around our collection. Whenever one of those files would attempt to play, the transcoder would choke and timeout, and the client side player would be stuck at 33% trying to load, which of course it doesnt. Eventually resulting in the player timing out as well (tested with repeatable behavior on iOS, Roku, and Android).
My first question is, has anyone else come across this? Second, if so, has anyone found any workarounds?
Since I couldn’t get the transcoder to play nice with the older mpeg4’s, regardless of nvidia driver or cuda version, I wrote a filter in the transcoder wrapper that was posted above (thank you @levi9292, @binarymelon, @Alexis_Evo, and AnnonymousRetard for your explanations and work putting that together.) to filter out the mpeg4’s as they are sent to the transcoder, and this seems to have solved the issue for me for now. Now the wrapper will pass along the plain ffmpeg option string to the transcoder without the nvdec option injected, if it detects the mpeg4 type, and will hardware decode everything else. I’ve posted an updated bash script for the above workaround below. Please forgive my bash scripting, I know there’ s probably a cleaner way of doing this, but its been a while since I’ve actually written anything.
#!/bin/bash
marap=$(cut -c 10-14 <<<"$@")
if [ $marap == "mpeg4" ]; then
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 "$@"
else
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 -hwaccel nvdec "$@"
fi
My last question is, with the nvdec option injected into the ffmpeg command, PMS becomes almost unusable if the ‘enable hardware acceleration’ option is turned on, and the transcoder crashes on most files. Because of this i’m not seeing any encoding on my card, only decoding. Does anybody have any insight as to why? i feel that i’m stuck here, and i’m missing something obvious and simple, but cant figure out what.
[SOLVED] I answered my own third question. I had to disable the Intel Graphics Adapter in BIOS for Plex to send encodes to the GTX 1050 ti, as it was defaulting to using the Intel QSV for hardware acceleration.
2 Likes
I haven’t had any issues with leaving the plex enable HA option on and encoding.
might come down to nvidia driver version differences
I have been running patched NVIDIA-Linux-x86_64-418.30
I just decided to give this a test myself: I’ve got a 4K HEVC Main 10 HDR - source with DTS-HD MA 5.1 - audio, transcoding on-the-fly to 1080p AAC, on a 4-core/8-thread Xeon E3-1230V3 under Linux.
With no H/W-accel enabled at all and with 1.14.0 PMS, I was seeing 380%+ CPU-utilization.
With H/W-encoding enabled and with 1.14.0 PMS, I was seeing ~240% CPU-utilization.
With H/W-encoding and decoding with the latest 1.15.1-beta, I am seeing 101% CPU-utilization.
That’s frickin’ swell, to be honest.
It’s great there are some solutions but is this something the Plex team are still working on?
Will there be an out of the box solution that does not need the wrapper?
yes. this whole thread is about that progress, and that people are ‘cheating’ to enable something that is not finished, by using the wrapper
We don’t really know that the feature is being actively developed though. All we know is that the ffmpeg update required has been completed.
They obviously don’t publish road maps or time lines, but I think it is obvious from not only this thread, but many other threads and comments from the dev’s themselves that this is something they are working towards.
At this risk of assuming, I believe that linux based servers represents a large number of servers (if not the majority), so getting a top line feature working equally (or at least similarly) across both primary server platforms (ie windows & linux) is to their best interest and bottom line.
Anyway, just like the rules of fight club, they generally just don’t talk about it, but that doesn’t make it not happening.
Check out their latest blog post. They raised the premiere device limit to 25. Non premiere connections of course don’t count against that limit.
1 Like
I hope you guys don’t mind me asking this in this thread. But can’t really seem to find a definitive answer.
I am thinking of buying a P2000 or either a GTX1060 (and hopefully unlock the encoding limit) ans us this for HW transcoding, I am now running Proxmox VE 5.3 on my server with Plex running in its own LXC container. Can you forward an entire PCI-E device to a LXC container? in my case, the nvidia gpu. Or will I have to do some trickery to partially hand it over to the LXC? The system I’m running is a Dell T420.
Thanks for any insight you guys can give me
GTX1050 would be a better choice, see the nvidia matrix. Unlocking is no problem.
Not sure about Proxmox/LXC but it’s working on docker.
#!/bin/bash
marap=$(cut -c 10-14 <<<"$@")
if [ $marap == "mpeg4" ]; then
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 "$@"
else
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 -hwaccel nvdec "$@"
fi
Wouldn’t it be better to invert that if statement and only use -hwaccel nvdec for the supported codecs?
MPEG-2, VC-1, H.264 (AVCHD), H.265 (HEVC), VP8, VP9
Tijmenvn, I have my Plex running in a LXC passing through a M2000. I’m not at my system right now, but I can post the config to do the passthrough.
You need the Nvidia driver loaded on both the proxmox host as well as the container to work. You can verify this is you see the card’s status when running nvidia-smi
Would be nice to see the guide/config you used.
For difference between GTX1050/GTX1060. Both have indeed the same type of transcoder. But since I want my system to ‘be able’ to handle up to 16 transcodes at a same time. A 1060 would be able to handle more streams/hold more transcodes in memory.
Do you guys discourage using the hack and opting for Quadro P series cards (that have unlim encodes ofc). Or is the hacked solution just as stable?
Incorrect, GTX1050/Ti supports more codecs than GTX1060. VP8/9 might not be interesting though.
GTX1050 can do 16 h264 transcodes.
Interesting, do you have a source for this? I have not seen anyone mentioning the GTX1050 having superior encoder. Also, I should’ve specified this ‘16 transcodes’ a bit more. I want to be able to do these transcodes from a mix of 4K/1080p H265 -> 1080p H264. Which a single 1050/1060 might not handle. But divided accress GPU/CPU encoding they might
EDIT: I see that with some GTX1050 models (gp107 models), you get VP9-10/12 bit support. Codec’s not used in our usecase. Therefor, 1060 would still be better in the sense that it would be able to simply handle more transcodes
I used the LXC GPU guide from ChuckPA. PMS installation guide when using a Proxmox 5.1 LXC container
This guide is specifically for using the Intel GPU, but can work just fine if you target the NVIDIA devices and use the Nvidia drivers
As a note, I specifically used a Debian LXC container as well in order to keep the hardware presentation and drivers in sync between the host and container
Here’s the passthrough config I have working on my LXC config:
lxc.cgroup.devices.allow: c 195:* rwm
lxc.cgroup.devices.allow: c 242:* rwm
lxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind,optional,create=file
lxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm-tools dev/nvidia-uvm-tools none bind,optional,create=file
EDIT: I will also add that the official Debian driver repo for Nvidia is extremely outdated and didn’t work for me. I would recommend downloading the latest from Nvidia directly and installing that
1 Like
Yep, if it would be limited by ram, I haven’t really seen that behavior myself.
Edit: Now saw that you mention 4k… a mix of 4K and 1080p is gonna need some serious power…
@NiclasU, This reads the codec type, and sends -hwacel nvdec to everything that isn’t mpeg4. Thus far mpeg4 is the only type I’ve found that I’ve had issue with, so it made sense to filter it out specifically. If there are other formats that don’t want to play nice, I’d write filters to weed them out too. Have you found any?
When reversing the logic check, which would look like this:
#!/bin/bash
marap=$(cut -c 10-14 <<<"$@")
if [ $marap <> "mpeg4" ]; then
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 -hwaccel nvdec "$@"
else
exec /usr/lib/plexmediaserver/Plex\ Transcoder2 "$@"
fi
The end result is the same, and saves no CPU time, which is minuscule anyway. The other option, which would be to write if/then conditionals for each codec (MPEG-2, VC-1, H.264 (AVCHD), H.265 (HEVC), VP8, VP9), and would be a slightly more intensive flow, is unnecessary for this use case thus far.
The only additional conditional that I would think could be needed, would be for weeding out Music types (MP3, WAV, FLAC, etc.), since there’s no need to send them to the hardware decoder, and they wouldn’t get processed there anyway. Still, I haven’t had any issues with playback of those with this wrapper in place yet. YMMV, let me know if you decide to try it. I’m curious about the results.
