Server Version#: 1.13.9.5456
Player Version#: Web Client ( 3.69.1) or AppleTV (latest)
Hi folks,
I run both Emby and Plex under Docker on Linux, using nvidia-docker to provide GPU capabilities to the container.
With Emby (which uses ffmpeg as a transcoder), I can use hardware acceleration for both encoding and decoding (h264_cuvid), and it works a treat. I use 1-2 CPU threads to stream a 4K movie.
Under Plex, I read that hardware decoding is not supported with nVidia GPU, but only with Intel Quicksync (which, sadly, my CPU doesn’t support).
Since it’s obviously technically possible to use cuvid decoding, and (AFAIK) the Plex transcoder uses ffmpeg, is there a reason why we can’t use nVidia GPUs for decoding?
I’ve been asking for it for over a year. They just never added the enable parameter for cuvid to their ffmpeg builder. It literally takes 2 seconds for whoever manages their jenkins to do that.
They did say they were going to add nvdec, the new implementation that is supported in ffmpeg v4, but they haven’t updated their ffmpeg build to v4 yet. Pretty ridiculous in my opinion
The Plex Transcoder, while having FFMPEG roots, is a lot more than just FFMPEG.
It is not as easy as “Compile FFMPEG; rename the file; include in the PMS distribution package”
It is not as easy as “Compile FFMPEG; rename the file; include in the PMS distribution package”
That is exactly what the plex transcoder is. It is literally stock ffmpeg (confirmed by another plex team member), compiled with some local linked libraries including the intel driver (common practice when building ffmpeg; one can even build a completely static build that needs no dependencies from the host like zeranoe’s builds), then renamed to Plex Transcoder and included in the PMS build.
Yup, that’s just ffmpeg. Judging by the build option locations, it is likely built on jenkins, probably multi-arch and multi-platform. If so, it would take adding a single parameter to the config options to enable cuvid, and rebuilding. And no, it wouldn’t require any changes to the build environment either, since nvenc is already included.
?? Honestly, what are you talking about?
What does any of what we discussed have anything to do with legal contracts?
I feel like we are not on the same page. Could you please ping someone else on the team who has more experience with the ffmpeg builds?
Perhaps @Ridley can provide more insight into the matter.
I remember he said a while back that there were plans to add nvdec when they switch to ffmpeg v4. Until then, can cuvid be added since it is supported in the ffmpeg version used by plex? It shouldn’t require any other changes than adding the enable flag. Cuvid had been the official cuda decode method in ffmpeg for a long time: https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNVDEC
I highly doubt that (although I could be wrong). The last time ChuckPA started talking about legal contracts and Company Confidential info, he ended up locking a thread and called for a cease and desist, only for another employee to come in and do damage control:
It is literally stock ffmpeg (confirmed by another plex team member)
Sorry if there’s been a miscommunication here, but this is inaccurate. Plex Transcoder contains a number of changes from upstream ffmpeg to handle our particular use-cases. We send a lot of patches upstream, but some features are either specific to Plex, or wouldn’t work generally enough with the current infrastructure (so they have to be implemented in more specific ways that won’t be accepted upstream until the infrastructure is expanded). You can download the source of the version used in a particular PMS version, with all our changes at a URL listed in the LICENSE file in the Resources directory.
We’ll be updating our ffmpeg to a newer version that includes NVDEC soon. Can’t promise any exact release timeframe, but we’ve already started on the process and I’m optimistic that we should be able to get it through testing soon.
It’s true that we could enable CUVID for decoding with the current version, but it’s more than just adding the build-time configuration flag. It’s actually fairly complex to automatically configure the ffmpeg filter graphs for a new hardware acceleration API, especially given all the different hardware configurations and media types that need to work reliably (e.g. zero-copy conversion can be done in some cases, but isn’t compatible with all filter configurations yet). We’ll be doing that when ffmpeg’s been updated, along with testing in a variety of cases. Testing to make sure we don’t break things for existing users is the biggest reason why changes that might seem simple don’t always get pushed through quickly.
Hope that shines some light on the reasoning here!
Can confirm, cuvid is a nightmare to work with. Some things can be transcoded using zero-copy, other things need to be copied to system ram temporarily. Also, Plex has to support many different generations of geforce cards which have different capabilities – ex:
1070/1080s support VP8 decoding but the 1080 ti and titan x/titan xp do not.
960 supports h265 decoding but the 980 does not.
(there are many other examples, including 8/10/12 bit color, along with numerous problems involving pixel formats)
There are also certain nvidia drivers (can’t remember which, this was a year or 2 ago) where mpeg4 decoding is completely broken, and some drivers where the decoder outputs empty frames without warnings/errors… Plex would need to make sure to turn off decoding for those drivers.
Add on top of that that cuvid doesn’t fall back to cpu decoding if a command fails (DXVA2 decoding supports cpu fallback), and it’s kind of a pain to include in production software that end users expect to just work.
I’m pretty sure plex is using dxva2 decoder for windows, which isn’t supported on Linux. Linux would have to use the cuvid/nvdec decoder, which is a pain in the ass to use compared to dxva2.
While I respect that it is difficult, Emby has been doing this for a while now. And its not like they have hundreds of developers.they have maybe 3-4 developers at most.
