@trudge said:
boboki wrote on April 30 2015, 2:17 PM: »
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.
Yeah, I used to use desktop CPUs to do server work too and it was always high CPU usage then I switched to actual server hardware and CPU’s and now I can easily have several transcodes going and it barley breaks 0-1%. : )
As much as I like to see hardware transcoding. Now if it is too much of a hassle or man power how about them add hardware transcoding to the optimize conversion portion. I have tried Plex version and reminds alot like handbrake takes about 20mns or more. So I got Wondershare that uses hardware encoding and was able to encode a 1080p movie in like 5 mins. I do have a 4930k cpu, 500 gig ssd (Plex), and 2-4 tb hardrives (500 movies and shows) . So I ended up re-encoding all my media before I added to plex and now I can stream remotely to 8 clients and my cpu has only hit about 70% when they are all on.
As much as I like to see hardware transcoding. Now if it is too much of a hassle or man power how about them add hardware transcoding to the optimize conversion portion. I have tried Plex version and reminds alot like handbrake takes about 20mns or more. So I got Wondershare that uses hardware encoding and was able to encode a 1080p movie in like 5 mins. I do have a 4930k cpu, 500 gig ssd (Plex), and 2-4 tb hardrives (500 movies and shows) . So I ended up re-encoding all my media before I added to plex and now I can stream remotely to 8 clients and my cpu has only hit about 70% when they are all on.
Which version of wondershare did you buy, and do you know if they have a gpu compatibility list?
Once you by wondershare it stays updated. As far as compatibility most new AMD and Nvidia is supported. I have a gtx 980 and isn’t on their list but still works. On their forums they mentioned how they stop listing gpu’s because of how many their are. So as long as its modern like past 5 years or so. But their best feature like other programs that do hw encoding is they have a device support list that includes phones,tv’s and consoles.
Given that Plex Transcoder is lightly patched ffmpeg, and ffmpeg has support for NVENC in mainline since at least v2.6.x (i.e. a while), I don’t imagine this would be hard to add.
In fact, you could rename Plex Transcoder out of the way and replace it with a shell script that rewrites the options to replace x264 parameters with nvenc ones. It’s a bit of a bodge but I’m 99% certain it would just work.
Intel Quick Sync is very nice. I’m currently using it via Handbrake to re-encode some larger files. It takes only 8 minutes to do so. Plex takes at least 3 times that long on the same hardware, with the same quality.
@Alitchy said:
Intel Quick Sync is very nice. I’m currently using it via Handbrake to re-encode some larger files. It takes only 8 minutes to do so. Plex takes at least 3 times that long on the same hardware, with the same quality.
I honestly think most people wouldn’t notice, in a world where most people are perfectly happy with Netflix’s compression, but most tech reviews I’ve read about hardware accelerated transcoders say that QuickSync doesn’t show the same quality as a good software transcode.
That said, in Plex’s context where you just want files transcoded as fast as possible for your remote friends and family, hardware transcoding is long overdue.
QuickSync and NVENC don’t offer anywhere near the same quality as libx264 software codec for any given output bit rate limit.
IMO the key benefit of hardware acceleration is for cases where you want to keep raw DVD or BR rips, and want them transcoded in realtime to a lower bit rate or different codec (e.g. from raw BR 30Mbit to 10Mbit for Chromecast, or from raw DVD MPEG2 to H.264) but in a much smaller power envelope than libx264. NVENC hardware power budget is something like 5W, a tiny fraction of what libx264 running on a CPU would burn through.
This is mainly an issue on systems that are very CPU or power budget constrained.
For all cases other than raw rips or temporary bit rate constraints (e.g. mobile) you would be far better off in terms of both bit rate and quality by statically transcoding everything into a universally compatible format using x264, fdk_aac and mp4 containers.
I used to be that guy who obsessed over every minute detail in my home theater. Then I had a kid and my entertainment time turned into the 2 hours after her bed time.
I’m at a point in my life where I’m no longer obsessed with eeking out every last bit of picture quality, especially for TV shows. On my 9 foot wide cinema scope screen, the difference between the 1080p file and the handbrake 720p HQ 70p preset using quicksync is not noticeable enough to make a difference - for my viewing purposes. Also mentioned by KarlDog - it really isn’t noticeable for my mom who is streaming remotely from a ROKU built into her TV.
The QuickSync copy is not identical to the original file. I am fine reclaiming half my storage and the ability to do so in less than a third of the time Plex transcodes would take.
What is your media source, though? Does leaving the static transcoding going on in the background (before you even add it to the Plex library) really matter? I’m still not convinced that hardware transcoding acceleration is useful for anything other than realtime transcoding. That is what it is optimized for, and it’s not just about squeezing every last bit of visual quality, the compression ratios with hardware transcoders is also relatively poor because they are optimized toward constant bit rate streaming (e.g. for game streaming).
Don’t get me wrong, it would be great to have hardware codec support, but the point I’m making is that this seems mainly useful for realtime transcoding, not static transcoding.
I agree real time transcoding would be great. I could be wrong but, I would assume that any switch to using hardware transcoding could be applied in a real time and static environments. I doubt Plex is using a different transcoding process for the two.
Real time is not my biggest “like to have” currently. I have a quad core i7 in my plex server. It doesn’t break a sweat when transcoding to the max number of devices in my environment - 5. Static transcoding gives me a reduction in storage, and puts the media in a format more likely to be direct played by those devices (which can help avoid transcoding.)
It would be great if I could leverage the optimize feature in plex as new media comes in to do this, as you can already setup filters to automate the process for newly added media.
Indeed, but if it is for static transcoding you might as well do it manually with 5 lines of bash and a custom compiled build of ffmpeg. That way you don’t need the Plex’ transcoder at all, unless you need to reduce the bit rate at playback time. And it also means you don’t need to keep an additional version of the file on top of the original one, which needlessly wastes space in many cases.
Agree with you gordan79. I think we all dream the day where Plex can hardware transcode a movie while its format is also x265, without having any trouble at the client side.
Almost, but not quite. Any transcoding involves some data loss, but it is always a compromise against the CPU resources consumed.
For optimal storage quality the ideal situation would be to store the input media raw without transcoding (e.g. DVD or BR extract). and then transcode at playback time, but the reality of the situation is also that realtime transcoding has to cut corners that static offline transcoding does not.
Pros:
Original is preserved.
Cons:
Consumption time CPU cost (everything has to be transcoded at playback time at every playback)
Less than optimal visual quality
High storage requirements (raw extracts are 2-4x bigger than transcoded media)
Suitability for GPU acceleration: High
For optimal viewing quality, the best approach is to statically transcode into the format that can be DirectPlayed by most devices (H.264/AAC/MP4).
Pros:
Low consumption time CPU uage (everything DirectPlays)
Best consumption time visual quality
Low storage cost
Cons:
Original is not preserved
High background CPU cost
Suitability for GPU acceleration: Low (lower quality and higher bit rate than libx264)
So while GPU acceleration definitely has a place, there are two distinct cases:
Low background CPU + High storage + GPU
High background CPU + Low storage
So if your storage space is charged at flat rate (e.g. all you can eat Amazon Cloud Drive for a flat annual fee), option 1 may well be preferable despite the 2-4x increase in storage requirements. For those who want their data locally and pay for their own disks, option 2 will most likely be preferable.
There is also a compromise between the two, because GPU transcoded H.264 will still be smaller than raw media, and won’t burn huge amounts of CPU in the process (NVENC will consume a tiny fraction of the KWh that the CPU will to transcode the same media).
For the PMS transcoder, IMO option 1) is the main use case, as everything that doesn’t require realtime transcoding might as well be done statically before the media is even added to the library.
