It would be really awesome if the transcoder could offload to CUDA (nVidia GPUs) for transcoding, seeing how I have a 570 GTX that does nothing while I'm not playing Battlefield.
The GTX's have also gotten cheap enough that this would enable people to DRASTICALLY improve their transcoding for cheaper than a new CPU in many cases.
As much as I agree, plex has no control over this, as they use FFMPEG to do transcoding, so it's FFMPEG that would need to support this, I think they have a forum as well that you could post in and request this.
CUDA in FFMPEG is unlikely to happen any time soon.
There is limited opencl support in x264, and as a result in newer builds of FFMPEG, so that may trickle down to Plex's FFMPEG at some point, but because of the way Plex uses FFMPEG/x264, it probably won't improve transcode speeds that much, and in some cases, will actually decrease transcode performance.
This was proposed for ffmpeg's participation in Google's Summer of Code (http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2014#HardwareAcceleratedVideoEncodingwithVA-API). Not sure if anyone's been working on it, but that at least outlines what they would like to do and some of the challenges involved.
Doesn't the OpenCL spec also support the nVidia GPUs, negating any need to run 'pure CUDA' and shut out the other GPUs?
Doesn't the OpenCL spec also support the nVidia GPUs, negating any need to run 'pure CUDA' and shut out the other GPUs?
Yes. But x264 only uses OpenCL for one (but important) part of the encoding process, Rate Control lookahead. Plex currently uses a relatively small RC lookahead value, so if it was to use an FFMPEG build with OpenCL, it could increase that value for systems that support it, increasing quality.
The problem is that, for GPUs that don't have unified memory (the majority in use today), there's a fair amount of overhead in moving data to and from GPU memory. For Plex's relatively small RC lookahead, you'd likely see a decrease in performance on many systems when enabling OpenCL. The gain of offloading rc lookahead to the GPU may not be enough to offset the overhead of moving data to the GPU. However, after that initial hit, the rc lookahead value could be increased for "free". Increased rc-lookahead would allow the encoder to better allocate bits, increasing quality of the transcode, but not necessarily increasing speed over what we have today. (Well, the speed would be improved over a non OpenCL encode with the same increased rc lookahead value, but I think you get my point.)
Don't get me wrong. I'm not saying that an OpenCL build of ffmpeg should be avoided. I'd certainly like to see OpenCL in Plex's FFmpeg. Just trying to point out that it's not the panacea some may think it is.
I most definitely concur GPU-transcoding would not be the panacea some think. The amount of CPU required to deal with the non-unified memory is substantial. (I build real-time full fidelity flight simulators) I think there is a misconception of how GPUs are used with video generation and how they are used in the gaming world. My comment was only attempting to point out that a pure-CUDA solution would most likely not be the ideal way to benefit everyone. I definitely can see the benefit when Plex is performing a transcode prior to Syncing, just as HandBrake would use it as well but agree, the overhead and demand on the memory bus is considerably more than most realize.
CUDA would it be a problem with FFMPEG license agreement? It would be a non-free external library.
i dont support CUDA anything. I'd love to get openCL support though, even though i know the SDKs for it are messy compared to CUDA. The problem is that so many systems that are great for an HTPC don't have a dedicated graphics card. Intel quicksync and openCL are both supported on the intel core series of chips, with HD graphics... So i can't like this post since it specifically says CUDA... :-(
Should I summarize the thread by saying…
An OpenCL supporting implementation would be of benefit and without imposing any proprietary / licensing restrictions
