I would LOVE (in all caps) to see some GPU (nvidia as the dominate force but I will be happy to BUY radeon) processing added into the transcoder. if this already exists, I would love to know how to make it work, but if not man that would make things SCREAM! I notice I only see 32 bit transcoders in my 64bit system, also kind of curious why there is no 64bit ver yet?
If it's possible to also utilize the built in HD3000/4000 in the Intel processors that would be great, but I dont know if this even is possible.
I notice I only see 32 bit transcoders in my 64bit system, also kind of curious why there is no 64bit ver yet?
not a lot of point doing a heap of work just to allow the transcoder to access more memory when it uses very little memory in the first place.
I believe FFMPEG already has hardware decoding on windows, so I wouldn't think it too tough to implement if Plex is still using FFMPEG. x264 is working on OpenCL acceleration for its rc lookahead (should allow for better quality and/or faster encodes), but it's currently waiting on Intel and AMD to work out compatibility issues in their drivers.
If Plex Transcoder is still based off FFMPEG (I think it is, right?), Plex would need to wait until FFMPEG gains more GPU support. here's one thread from about a year ago discussing just that. Not sure what progress has been made on any of it.
One issues I've run into with hardware decoding/opencl on intel HD4000 is that it doesn't seem to work well/at all on headless systems. A current limitation of the driver that may not ever change.
Durring setup I thought this would be a good idea as well, and was surprised it wasnt already in use. In practive, though, I run PMS on an old, crappy quad with 4GB of DDR2 800mhz, Ubuntu and 10TB raid6. It really is a dumpy little computer I put together with odds and ends and rejects from boxes in my garage, and has a quater pound of duct tape on it. Works FLAWLESSLY. I cant imagine desiring better transcoding performance, or the ability to turn a crappier server into a viable one with an expensive graphics card. I honestly dont see the point here, they've done a spectacular job using cpu/ram as is.
Any feedback on this yet? still would love to see it implemented.
not a lot of point doing a heap of work just to allow the transcoder to access more memory when it uses very little memory in the first place.
Actually, memory use isn't the only reason to choose 64bit for x264. x264 x64 is known to be ~5-10% faster than x264 x86.
Old bump. Has Plex looked at this or came to any conclusion? Due to the forced transcode on the Xbone I have started to look at some other options to handle multiple streams smoothly. Right now my xbone stutters when playing 11gb 1080p files and my i7 3770 chip is maxed out all the time. Would be nice to use me GPU cores to load balance a bit...especially because I am waiting to upgrade to x99 for a while.
Old bump. Has Plex looked at this or came to any conclusion? Due to the forced transcode on the Xbone I have started to look at some other options to handle multiple streams smoothly. Right now my xbone stutters when playing 11gb 1080p files and my i7 3770 chip is maxed out all the time. Would be nice to use me GPU cores to load balance a bit...especially because I am waiting to upgrade to x99 for a while.
I'm running 6-7 simulationous streams (4-5 of them beeing video transcoded) and that flys just well, I would think your issue is not the CPU, bur rather an network (bandwith) issue
I'm running 6-7 simulationous streams (4-5 of them beeing video transcoded) and that flys just well, I would think your issue is not the CPU, bur rather an network (bandwith) issue
This^
The i7 3770 scores 9391 CPU Passmarks plex requires ROUGHLY 1500-2000 marks per transcode so your CPU should be able to pump out 4-5 streams before you experience any significant buffering. This also refers to FULL transcodes not container changes or remuxing which require significantly less CPU capacity.
I'm running 6-7 simulationous streams (4-5 of them beeing video transcoded) and that flys just well, I would think your issue is not the CPU, bur rather an network (bandwith) issue
This^
The i7 3770 scores 9391 CPU Passmarks plex requires ROUGHLY 1500-2000 marks per transcode so your CPU should be able to pump out 4-5 streams before you experience any significant buffering. This also refers to FULL transcodes not container changes or remuxing which require significantly less CPU capacity.
This was my first thought too. But here is why I think it is lagging at my computer...
My xbone is connected to the same switch as my Fire TV is. The fire tv can play any 1080p with no stuttering at all. My first action was to use the old Fire TV cable on the Xbone, just in case the X cable was bad for some reason, but that had no effect. So to test my network further, I used the Xbone network cable to connect my laptop. At first I launched theater and played a "Complete" rip (30gb file) and it played flawlessly. This really is no surprise because I built my network to be full 1gb speed. So, I did a file copy test. This test hit ~120ish MB per second (SSDs on both computers to limit bottlenecks). As far as an internal network speed, I have confirmed I have almost full 1gb capability.
As far as my Internet speeds, I have the highest package that gives me 150Mb down and 25Mb up. However, speed test on my Xbone only hits ~66Mb down :( on average. This sucks because using the same cable I can hit 165Mb on my laptop (cox offers a speed boost gimmick).
hmmm this does not seem right, I have a i7-2600k and a single 1080p transcode can take up to 75-90% cpu with transcoder set to automatic. Setting lower does not seem to make ANY difference whatsoever.
hmmm this does not seem right, I have a i7-2600k and a single 1080p transcode can take up to 75-90% cpu with transcoder set to automatic. Setting lower does not seem to make ANY difference whatsoever.
yes, but it doesnt need to take all that CPU, it is just taking it to get the job done faster.
rough example, the same 1 hour 1080p file
CPU1, 2000 passmarks, transcode takes 100% cpu for 1 hour
CPU2, 12000 passmarks, transcode takes 100% cpu for 10 minutes, spends 50 mins doing nothing.
CPU1 has to run at 100% to keep the stream real time
CPU2 just runs at 100% cause it can.
I really would like to see GPU Transcoding support with QuickSync, NVenc and whatever AMD has .=)
July 2016… and still no hardware transcoding in Plex, while this has been added a while ago by many NAS vendors.
Synology added a hardware transcoder in DS415+ and RS815+ (which I have). Plex is NOT able to use this feature. Synology’s own media server product is able to leverage the hardware transcoder.
Result: Plex cannot transcode h265/1080p videos while Synology Video Station can, on the same system. This is a shame.
Please note that Synology provide a specialized version of ffmpeg that leverages the hardware transcoder. So Plex would only need to use this version of ffmpeg in their Synology build.
Please please, Plex Team, thank you!
Please add GPU support, if I like to use 4k transcoding, I run in issues if I have to do the transcodning over the CPU. Specially if I have 2-3 simultaneously 4k (transcodning) streams, probably most CPU’s can’t handel that load.
@tenki said:
Please add GPU support, if I like to use 4k transcoding, I run in issues if I have to do the transcodning over the CPU. Specially if I have 2-3 simultaneously 4k (transcodning) streams, probably most CPU’s can’t handel that load.
That’s a completely unrealistic scenario with the current CPU market. GPU might help but I doubt 3 4k transcodes are even possible with a high end chip right now.
Any news on this topic?
Plex devs, please consider to support GPU acceleration.
thanks.
hi plex. it could be nice, that if hardware transcoding of hevc will, get to pms for the graphic card, there handle hevc. i use for now my shield tv as pms. but it’s not as staple like pms on a desktop. or to nas
@jkiel said:
Trudge wrote on April 5 2013, 3:59 PM: »not a lot of point doing a heap of work just to allow the transcoder to access more memory when it uses very little memory in the first place.
Actually, memory use isn’t the only reason to choose 64bit for x264. x264 x64 is known to be ~5-10% faster than x264 x86.
It’s also time to stop running 32-bit processes on 64-bit systems in general so we can move forward into the future and drop 32-bit support completely. The only time anyone should be running anything 32-bit at this point is if there is no 64-bit option.
