@RedSocks157 said:
Why would GPU transcoding produce a lower quality result?
because of the algorithms used.
http://www.anandtech.com/show/5771/the-intel-ivy-bridge-core-i7-3770k-review/21
https://www.reddit.com/r/hardware/comments/2dsvoi/i_did_some_tests_with_handbrake_and_intel/
@starbetrayer Interesting. I wonder if this also goes for AMD’s equivalent media acceleration?
Interesting thread. What I learned is that Quick Sync != Quick Sync as generations of intel implementations have varied. Also leaned that Quick Sync will work on some OS combinations and not others. So while it sounds “good”, the feature could be very problematic. Even if implemented, there will be complaints.
@RedSocks157 said:
@starbetrayer Interesting. I wonder if this also goes for AMD’s equivalent media acceleration?
VCE has not really been used for video transcoding, except screen captures.
The only test I know about comparing all solutions is this one.
AMD’s AVC was slower, and quality not so good, so that can be thrown away.
AMD’s AVC is worthless (crap for an H.264 encoder, no better than the ASP encoders - it’d do better if more bitrate could be thrown at it)
The Result
Hardware encoders are not much faster and significantly worse in quality, efficiency and bitrate than x264. Quicksync probably uses less power, mind, but it’s usually cheaper to do a poorer job. There hence awaits a great opportunity to embed x264 at preset veryfast (a touch slower than superfast) and obliterate everything on the market while encoding only a touch slower than quicksync (it’d probably be about a fast as AMD’s AVC?).
I have run, and seen, benchmarks between AMD’s implementation, NVIDIA CUDA,
and Intel QSV. Quality is “good” though x264 can be much better.
However, in this case I’m really not interested in the “best” quality for
live transcoding at all. What I want is Intel QSV to be available for
transcoding since it is incredibly fast and uses far less power. It enables
a relatively low-end Plex server (e.g., Core i3 or Core i5) to live
transcode at ease.
QSV is 6-10x, or more, faster than NVIDIA QSV. If you want to see a great
example of how awesome it is, install Handbrake and run a comparison
transcode for x264 and Intel QSV, both selectable in the software’s
encodinug codec section.
QSV was so fast (especially input & output from & to an SSD) that I
literally didn’t think it was working, and verified the output video was
real. It feels like magic.
@yottabit said:
I have run, and seen, benchmarks between AMD’s implementation, NVIDIA CUDA,
and Intel QSV. Quality is “good” though x264 can be much better.However, in this case I’m really not interested in the “best” quality for
live transcoding at all. What I want is Intel QSV to be available for
transcoding since it is incredibly fast and uses far less power. It enables
a relatively low-end Plex server (e.g., Core i3 or Core i5) to live
transcode at ease.QSV is 6-10x, or more, faster than NVIDIA QSV. If you want to see a great
example of how awesome it is, install Handbrake and run a comparison
transcode for x264 and Intel QSV, both selectable in the software’s
encodinug codec section.QSV was so fast (especially input & output from & to an SSD) that I
literally didn’t think it was working, and verified the output video was
real. It feels like magic.
Unfortunately Handbrake only supports QSV for Windows, and will for Linux in the future. I am an OSX type of guy, and Intel hasn’t made the appropriate APIs available (Intel Media SDK) for OSX, and it doesn’t look like they will.
@rcombs said:
@darkfu2re said:
ffmpeg supports qsv encoding since 2.7 (august-september version, not sure). See changelog:
https://raw.githubusercontent.com/FFmpeg/FFmpeg/release/2.8/ChangelogThe support referenced there involves use of Intel’s proprietary MFX libraries, which are not compatible with the GPL. We’re investigating hardware encoding support, but it’ll take time, and will have to be implemented in a GPL-compatible manner.
How much time it can take? A few weeks, or months? Or maybe years?
imho, the concern that QSV produces poor quality results is oversimplified.
I’d like to call those interested to quickly skim through this white paper for some insights into the generational improvements that has been made and the distance intel goes to make sure the QSV is comparable ( at the very least) to a cpu based encode/decode.
I also think that we may sometime look at the trees before the forest. In the typical plex usage scenario, handheld devices like the iPad and iPhones are the most frequent devices to require transcoding.
Being able to stream to them at more than realtime speed with minimum cpu usage, with a small degree of loss in perceivable quality(if any) can be argued to be more valuable than a super high quality result for such a small form device.
If you however need transcoding on a serious viewing/large screen home theatre setup then perhaps you are just doing it wrong. That said, another undeniable reason for transcoding would be streaming from a remote library, for which I agree the loss of quality can be an issue, if it’s significant enough.
It is enlightening to learn that the team is indeed looking at this more seriously than we thought they would. Thank you for the updates @rcombs Hoping there’s more to follow!
@rcombs please make it happen!
The emby server now supports intel quick sync. A transcoding video dropped from 90% cpu to just 30%. That’s huge!
I use a QNAP TS-451 NAS, but would love to see support for this as well. Has anyone heard from the Plex dev team about this? I did see this: https://ffmpeg.org/general.html#Intel-QuickSync-Video
@Deithmos Emby is really shaping up pretty well. I hope that plex gets a bit more adventurous now that an aspirant appeared.
@maxengel said:
I use a QNAP TS-451 NAS, but would love to see support for this as well. Has anyone heard from the Plex dev team about this? I did see this: General Documentation
Not many days ago in this very thread 
https://forums.plex.tv/discussion/comment/1054393/#Comment_1054393
@atrus said:
@maxengel said:
I use a QNAP TS-451 NAS, but would love to see support for this as well. Has anyone heard from the Plex dev team about this? I did see this: General DocumentationNot many days ago in this very thread
Thanks!
@atrus said:
@Balthazar2k4 said:
Has GPU transcoding quality improved any? Last time I used it the output was pretty much garbage.Last I read up on it the consensus was that it degraded the quality yes. Have not read up on it the last year though, so things might have changed. Not that it matters to some I believe. They rather have worse quality than buy a device with more powerful CPU.
I have been testing QS using the emby server and it works great. CPU use dropped from to 25% compared to 80% when transcending and I didn’t see a difference in video quality.
@vincezz said:
@Deithmos Emby is really shaping up pretty well. I hope that plex gets a bit more adventurous now that an aspirant appeared.
Perhaps but don’t hold your breath. People have been asking quite loudly for Quick Sync support for nearly two years now and we’ve seen very little from Plex beyond either excuses or “we’re looking into it”. Emby is looking to be a much more viable option for all of us using modern low power NAS hardware. A fanless 6 watt TDP CPU like the Intel Braswell N3150, or earlier Bay Trail equivalents like the J1900 or N2930, can beautifully transcode anything I could throw at with Emby. That same hardware chokes badly on some things with Plex.
There’s a huge user base out there who doesn’t want to have a high powered PC running all the time just to stream video and/or mess around running Plex server on their PC. Increasingly many people don’t even have high-powered PCs. Fortunately that user base now has other options like Emby, offerings from the NAS manufactures, etc.
I also want to chime in and argue the quality debate in this thread really is a side issue and is largely off topic. Offering Quick Sync support opens up far more hardware options to transcode Plex and the vast majority of those users will never notice any quality differences. The video purists can still run high powered hardware and avoid Quick Sync if they don’t like it for some reason.
And even if Quick Sync doesn’t work for some users they’re still no worse off than they were without it. It’s a win-win for everyone yet Plex still hasn’t implemented it and, at this rate, perhaps never will.
@MurphyBed your absolutely right. I have been using Plex for years now, but emby is getting more attracive each day…
I concur regarding transcoding quality. One could solve this by adding it as an additional transcoder quality setting for QuickSync etc. I too only transcode for mobile now that the Client that I employ finally supports subtitles without transcoding. For mobile i do not care that much about transcoding quality.
Qnap offers transcoding support for it’s native media player and can play on more than once device at same time. So they figured this out. I thing for the most part transcoding will only happen for remote devices that will be playing at a lower resolution and bitrate anyway. So quality shouldn’t be a factor. I really hope Plex Server supports this soon, especially on Qnap, due to the fact that they seem to be pushing the all in one chips with GPU built on and support for on the fly multiple devices transcoding.
Count me among those who are seriously looking at migrating to Emby due to the support for Quick Sync.
