Any news on GPU transcoding, especially Intel Quick Sync?

Don't know where a few people are getting the idea that Quicksync is only a small difference.  On my Haswell i7 it is insane!!

Handbrake transcoding 720p TV shows from H.264 5.1 profile to a 4.1 profile so they can be played on the XBOX 360s takes ~3-4 minutes per episode, with the Optimise Video slider set to "Best Quality" rather than balanced or best speed, and the CQP slider set to 20.  That is better than 5x realtime.  Using the fastest settings, I can actually transcode at 14x realtime!  With an x264 "Fast" preset, it takes 6-7 minutes on the same machine.

It was even much better than this for awhile, but either handbrake or Intel video drivers have screwed something up in the past year.

Also, as far as quality goes, there have been improvements there with each CPU generation.   In fact, at bitrates below 4Mbps, Haswell Quicksync beats x264 in quality: http://www.tetrachromesoftware.com/q264Test1Analysis/q264test_1.html

Actually I have always thought in makes sense with a i5 or i7. The problem is when someone wants to use QS on let’s say a Haswell based atom. There is some belief that QS will make such hardware server capable.


Though QS does significantly speed those platforms, it is generally just about real time. Far from sufficient for much transcoding. An i7 certainly isn’t part of that and comparison.


Sent from my SAMSUNG-SM-N900A using Tapatalk

Putting the video quality debate aside for a moment, I don't think you would find many people in-the-know suggesting that QS is anything other than a huge win for power efficiency and performance.  You're trading off general purpose transistors for special purpose / dedicated video transcoding transistors.  Of course you're going to need fewer transistors and watts to transcode a frame of video.

I just wish Plex would have a representative comment on their roadmap regarding this feature, and if they're taking a pass I'm curious why they don't feel it's worth the effort.  Maybe the effort to implement is significantly more for them than projects like Handbreak, maybe they've run into some technical hurdles.  Who knows.  I just wish they would comment on it.

Oech

What applications are you using to convert your BL Ray collection, I am trying to do the same thing with my huge BL Ray library.

Thank you,

No, it is definitely not flawed. I am using DVD Fab and there is an option for copying the video source or converting it. 

The video was transcoded, not remuxed. The 50% load are 2 cores with full load and 2 cores idle. (1 core will be for transcoding audio, the other core for assisting Intel QS)
With software transcoding all 4 cores have full load.
The enormous 700% gain is also owed to the low computing power of the J1900. It only has a passmark score of 1943. And Quick sync does not depend on the CPU that much as it is the same encoding chip in all Intel HDs.

There are also reviews showing that Intel Quick Sync is far better and faster then Nvidia and AMD.

http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/9

and

http://www.tomshardware.com/reviews/sandy-bridge-core-i7-2600k-core-i5-2500k,2833-5.html

Actually I have always thought in makes sense with a i5 or i7. The problem is when someone wants to use QS on let's say a Haswell based atom. There is some belief that QS will make such hardware server capable.

Though QS does significantly speed those platforms, it is generally just about real time. Far from sufficient for much transcoding. An i7 certainly isn't part of that and comparison.

Sent from my SAMSUNG-SM-N900A using Tapatalk

I haven't tested QuickSync on the Atom but I have used Handbrake nightly with a Pentium G3240 Haswell (test build and spare HTPC) to convert Blu-ray (Game of Thrones) to 720p H.264/stereo AAC. Iirc, it took just 5-10 minutes to convert a 1-hour episode with burnt-in subs. That's 6-10x real-time on a $50 CPU. Quite likely sufficient for at least 2 live streams, probably more. QuickSync actually makes far more sense on low-end CPUs that would struggle with software-based transcoding than it does on a fairly capable quad-core, hyperthreaded, top of the line Core i7.

That said, I do understand why the Plex team is reluctant to add QuickSync support while it's not yet part of the official ffmpeg release.

I too was wondering about quicksync support as I was building a new system

(I don’t think my 2GHz Atom 330 is up to snuff for transcoding DVD’s on the fly.)

@leschan said:
mavrrick wrote on May 17 2015, 10:16 PM: »

Actually I have always thought in makes sense with a i5 or i7. The problem is when someone wants to use QS on let’s say a Haswell based atom. There is some belief that QS will make such hardware server capable.

Though QS does significantly speed those platforms, it is generally just about real time. Far from sufficient for much transcoding. An i7 certainly isn’t part of that and comparison.

Sent from my SAMSUNG-SM-N900A using Tapatalk

I haven’t tested QuickSync on the Atom but I have used Handbrake nightly with a Pentium G3240 Haswell (test build and spare HTPC) to convert Blu-ray (Game of Thrones) to 720p H.264/stereo AAC. Iirc, it took just 5-10 minutes to convert a 1-hour episode with burnt-in subs. That’s 6-10x real-time on a $50 CPU. Quite likely sufficient for at least 2 live streams, probably more. QuickSync actually makes far more sense on low-end CPUs that would struggle with software-based transcoding than it does on a fairly capable quad-core, hyperthreaded, top of the line Core i7.

That said, I do understand why the Plex team is reluctant to add QuickSync support while it’s not yet part of the official ffmpeg release.

Actually I don’t think that is exactly true. QS on a Atom isn’t as fast as QS on a i5 or i7. You can’t look at the performance gain on a i7 to justify QS on a low powered CPU. That is why I tested it on my dell tablet. I also looked at the CPU you mentioned. It has a postmark score of 3200. That should be certainly enough to transcode 720p video. Possibly 2 streams.

Oha, have not been on the forum a while.

@iZgrooms1010 : I’m using DVDFab. Works very well with the Intel QS and it is possible to simply copy the surround sound or even generate an own Dolby Digital 5.1 track.

@mavrrick : An Silvermont Atom based Celeron using QS achieves much more than “just about real time”. As I have posted before the J1900 using QS transcodes 1080p material with 70-90 FPS. That’s enough for 2-3 1080p streams where it can’t handle a single 1080p using software transcoding (10-15 FPS).

Being able to use Intel’s QS would make these chips the perfect home server. It’s cheap, has enough CPU power for homeuse tasks (apart from 1080p real time transcoding) an it’s really power efficient (10w tdp for CPU+mainboard).
So yeah, still hoping to get Intel QS support. :smiley:

I’m very interested in this as well. It doesnt’ seem like it should be that large of a task to include…is there somewhere they announce what they’re currently working on within plex?

It wouldnt be in plex exaclty though. This would have to implemented in FFMpeg, the transcoding product that plex uses.

Hi,

I have a version of ffmpeg that provides HW acceleration (this one uses NVENC in particular). Is there a way to have Plex use this “custom” ffmpeg, instead of the version included with the server? In other words, replace the Plex Transcoder by ffmpeg (temporarily, for testing)?

Thanks!

I’d give a shot at just renaming PlexNewTranscoder.exe to PlexNewTranscoder.exe.orig, and naming yours to PlexNewTranscoder.exe and dropping it in the PlexMediaServer folder…

But… I dunno :slight_smile:

@jeradc said:
I’d give a shot at just renaming PlexNewTranscoder.exe to PlexNewTranscoder.exe.orig, and naming yours to PlexNewTranscoder.exe and dropping it in the PlexMediaServer folder…

But… I dunno :slight_smile:

The PlexNewTranscoder.exe is only used for Transcoding tasks on the PMS machine. I assume you guys are looking to try a new ffmpeg on the client machine by replacing the ffmpeg version in the client software.
I have never tried it, but I assume that you need to do a branch of the PHT repo, and update ffmpeg in there and use some new flags for it to actually work.

Well, that and probably a 100 other small things that I have no idea about.

@atrus said:
Well, that and probably a 100 other small things that I have no idea about.

but… clients dont transcode, only servers do :slight_smile:

PHT is the 1 Plex client that does decode on the client end. The project is open source, so you can find how to build FFMPEG in the repo. This might be more consistant with what PMS uses. PMS is closed source so you can’t see what was done to build the FFMPEG that PMS uses.

I was a bit too tired yesterday when I wrote that. I for some reason was really sure them guys wanted to accelerate their PHT experience. Which is still a valid request, but totally not what they wanted :slight_smile:

Another entire year has gone by and, despite all the interest and solid arguments for supporting Quick Sync, Plex still can’t be bothered to support a technology that’s now several years old and offers massive benefits to their core business and customers. What’s more, as I explained earlier in this thread, it could also save millions of dollars in electricity bills and save massive amounts of energy and, literally, significantly benefit the planet. All if just one person spent perhaps a week or two incorporating existing published code into Plex. How is that not worth it?

It’s hard to believe, after years of people asking, Plex management is unaware of this issue. Despite, no doubt, being aware of the benefits, I don’t think Plex has ever publicly even acknowledged this issue let alone offered a reason why they haven’t supported it or any promise of when they might in the future. It’s really sad something with such huge potential continues be ignored year after year by Plex.

Plex seems to be yet another greedy and largely marketing driven company largely out of touch with what their users really want and even what make sense. I dropped my Plex pass a long time ago and I’d encourage others not to give a dime to Plex until they can be bothered to spend a trivial amount of resources to finally support Intel Quick Sync.

@MurphyBed said:
Another entire year has gone by and, despite all the interest and solid arguments for supporting Quick Sync, Plex still can’t be bothered to support a technology that’s now several years old and offers massive benefits to their core business and customers. What’s more, as I explained earlier in this thread, it could also save millions of dollars in electricity bills and save massive amounts of energy and, literally, significantly benefit the planet. All if just one person spent perhaps a week or two incorporating existing published code into Plex. How is that not worth it?

It’s hard to believe, after years of people asking, Plex management is unaware of this issue. Despite, no doubt, being aware of the benefits, I don’t think Plex has ever publicly even acknowledged this issue let alone offered a reason why they haven’t supported it or any promise of when they might in the future. It’s really sad something with such huge potential continues be ignored year after year by Plex.

Plex seems to be yet another greedy and largely marketing driven company largely out of touch with what their users really want and even what make sense. I dropped my Plex pass a long time ago and I’d encourage others not to give a dime to Plex until they can be bothered to spend a trivial amount of resources to finally support Intel Quick Sync.

The issue is that since Plex uses ffmpeg to transcode, they want those guys to implement it upstream of them. This is an issue because it is open source software, so waiting could literally take forever.

If they pay a developer to add it to ffmpeg, then their competitors will get it also. If they fork ffmpeg and make that part closed source (which might not even be possible) then they will lose all the good ffmpeg updates that come out. They would have to patch every version they chose to release with their code.

Obviously they should suck it up and help the ffmpeg guys get it done, even if the competitor’s will get it also. The business case would be;

  1. Release to Plex Pass first, lots of NAS users would want this feature ASAP.
  2. PR the saved green house gases/electricity saved by Plex users. Plex is helping save the planet, etc. People really do support companies over this.

If the development is that expensive (which I don’t see how it could be more expensive then SSL) then keep it a Plex pass only feature. Obviously people could hack it in, but most people don’t want to do any of that, or even know what ffmpeg is for that matter. Most people would much rather just buy Plex Pass then build a new PC, if they can get away with it.

I have a feeling it is harder then it is expensive.

@mavrrick said:
Actually I have always thought in makes sense with a i5 or i7. The problem is when someone wants to use QS on let’s say a Haswell based atom. There is some belief that QS will make such hardware server capable.

Though QS does significantly speed those platforms, it is generally just about real time. Far from sufficient for much transcoding. An i7 certainly isn’t part of that and comparison.

Sent from my SAMSUNG-SM-N900A using Tapatalk

http://emby.media/community/index.php?/topic/10723-gpu-transcoding-intel-quicksync-and-nvidia-nvenc/?p=158523

The user that started implementing Intel QuickSync in mediabrowser was doing it on a J1900 Quad Core Intel Atom CPU @ 2 GHz.

He was able to transcode;
1 x 1080P stream(s) @ 70 FPS
3 x 1080P stream(s) @ 75 FPS total (25 FPS each).

This CPU scores a 1885 on the Passmark benchmark, which means that it probably can’t transcode 1 x 1080P stream without QuickSync.

So if a PC transcodes w/ Intel QuickSync at 250FPS (which is possible) they could transcode 8 x 1080P streams @ 30FPS.

It would take a comparable CPU score of 16,000 on Passmark to do the same. Which would require a $1000+ CPU alone.

Those are actual ffmpeg #'s he got, not some benchmark or other guess work.

@bjd223 said:
Those are actual ffmpeg #'s he got, not some benchmark or other guess work.

I am hoping for Intel Quicksync just like the next guy. But those numbers (added above) do not say much. A 1080P file can have a bitrate from 2 Mbps to 120 Mbps (well anything over 70 is mainly test files though. I do have a 120 test file at home :slight_smile: ).Transcoding a 1080P movie on a CPU with a passmark score of 1885 is not a problem at all, as long as the bitrate isn’t going all crazy. My guess is that it will work on everything that is re-encoded. When it is a bluray remux (40 Mbps is quite common) it will be very close to not being able to pump out a transcode speed over 1.0.

I would be very glad if QS will tripple the transcoding power, but that sounds extreme in my ears.