Intel's Quick Sync: Coming Soon to Your Favorite Open Source Transcoding Applications
by Anand Lal Shimpi on January 14, 2013 4:01 PM EST- Posted in
- CPUs
- Intel
- Sandy Bridge
- Ivy Bridge
- Haswell
- Quick Sync
Intel's hardware accelerated video transcode engine, Quick Sync, was introduced two years ago with Sandy Bridge. When it was introduced, I was immediately sold. With proper software support you could transcode content at frame rates that were multiple times faster than even the best GPU based solutions. And you could do so without taxing the CPU cores.
While Quick Sync wasn't meant for high quality video encoding for professional production, it produced output that was more than good enough for use on a smartphone or tablet. Given the incredible rise in popularity of those devices over recent history and given that an increasing number of consumers moved to notebooks as primary PCs, a fast way of transcoding content without needing tons of CPU cores was exactly what the market needed.
There was just one problem with Quick Sync: it had zero support in the open source community. The open source x264 codec didn't support Quick Sync, and by extension applications like Handbrake didn't either. You had to rely on Cyberlink's Media Espresso or ArcSoft's Media Converter. Last week, Intel put the ball in motion to change all of this.
With the release of the Intel Media SDK 2013, Intel open sourced its dispatcher code. The dispatcher simply detects what driver is loaded on the machine and returns whether or not the platform supports hardware or software based transcoding. The dispatcher is the final step before handing off a video stream to the graphics driver for transcoding, but previously it was a proprietary, closed source piece of code. For open source applications whose license requires that all components contained within the package are open source as well, the Media SDK 2013 should finally enable Quick Sync support. I believe that this was the last step in enabling Quick Sync support in applications like Handbrake.
I'm not happy with how long it took Intel to make this move, but I hope to see the results of it very soon.
Facebook
Twitter
RSS
45 Comments
View All Comments
heymrdj - Monday, January 14, 2013 - link
Can't wait to see HB support this!babgvant - Monday, January 14, 2013 - link
DVRMSToolbox has had QS support for a long time (since SNB). I don't OSS the filters, but the surrounding DirectShow code is FOSS (http://babgvant.svn.sourceforge.net/viewvc/babgvan... and of course the whole thing is free as in beer :).tommo123 - Tuesday, January 15, 2013 - link
they didn't support it in x264 iirc as intel didn't give access to any low level stuff. made it pointless for the devs in that case as they had no control. if that's been fixed now then sweet!dmytty - Friday, January 18, 2013 - link
Is it possible to get the motion compensation data from Intel Quick Sync while encoding?icrf - Monday, January 14, 2013 - link
Most of my transcoding is disc to archive, so quality is more important than speed. It would have been nice if there was more granularity to the fixed function encoder so the parts that matched x264 could have been utilized by it. The x264 people have generally said they can match QuickSync / GPU speed if you drop the quality down to comparable levels.When I upgrade to Haswell, I'll still use the software encoder, especially if x264 makes as good as use of AVX2 as it sounds.
TerdFerguson - Monday, January 14, 2013 - link
The x264 clowns are full of it. They went out of their way to hamper bringing Quicksync to the masses, and they did it for petty reasons of personal politics. I've read the forum posts where Intel came to them and said, "hey, this is what we're working on, what do you think?" They acted like jerks, and their performance claims are hogwash. Quicksync is fast. Seriously fast.raulizahi - Monday, January 14, 2013 - link
There is no way that x264 can compare to QuickSync in raw performance (not in quality) as, with full 4X 1080i59.94 HD Transcoding, Sandy Bridge Mobile CPUs only use 10%-25% of the CPU to feed the QuickSync engine while x264 would need more of the CPU to execute the same video transcoding task not leaving CPU performance for Audio Transcoding.mavere - Monday, January 14, 2013 - link
"There is no way that x264 can compare to QuickSync in raw performance"Let's fine-tune that statement. The folks at Compression.ru do a yearly compression study and release free + paid reports. The appendix from their 2012 study, which includes IVB QS2 results, found that on performance desktop IVB, x264 is both faster AND provides a higher qual:perf ratio.
Here's a shot of the graph summarizing the results on desktop IVB: http://i.imgur.com/0ccUC.png
On mobile hardware, with a mid-end quad core IVB, QS takes the lead in performance and quality per performance.
I don't expect anyone with high end or overclocked CPUs to benefit from Quicksync, unless they're planning on doing some strenuous multitasking during the encode period.
heffeque - Tuesday, January 15, 2013 - link
Nice to see an informed comment. They aren't easy to find here on the intarwebz.Soulwager - Tuesday, January 22, 2013 - link
There are a huge number of people that stream their gaming live. Quicksync could allow people with 2 core CPUs to stream without impacting game performance, and would allow people with 4 core CPUs to stream at a much higher quality.