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
Guspaz - Tuesday, January 15, 2013 - link
Last time I tried to enable both the iGPU and discrete GPU in the BIOS, my system decided to stop sending video signals to any output (on either the iGPU or discrete card), requiring a CMOS reset to get the thing booting again.Ryan Smith - Monday, January 14, 2013 - link
Most desktop motherboards come with Lucid Virtu MVP these days, so desktop users with discrete cards can access QuickSync through d-Mode. However that's only for self-built systems; I can't recall ever seeing Virtu with an OEM system, which is what most customers are buying.Guspaz - Tuesday, January 15, 2013 - link
My Z77 mobo didn't come with a Virtu license.danjw - Monday, January 14, 2013 - link
Well Intel should have done this when Sandy Bridge was released, but I am glad that they are doing it now. Makes me happier that I just upgraded to Ivy Bridge!edlee - Monday, January 14, 2013 - link
I love quicksync, I use it all the time to make smaller size video file for my android tablet when I am traveling .I upgraded to ivy bridge from sandy bridge to get the speed boost for transcoding. Nothing comes close right now.
Spoelie - Tuesday, January 15, 2013 - link
But already a year ago tablets have reached a point where they can decode 1080p in hardware.In addition, the model I have has 32GB built in, a micro SD card slot supporting 32GB cards and I also have a 64GB USB stick that I can put in its dock.
Transcoding for mobile hardware is a fad that will go away soon enough - I never bothered with it.
Well if you're in android world, apple isn't there yet.
Guspaz - Tuesday, January 15, 2013 - link
My 1080p movie files tend to be 10-15 gigabytes a pop. It's pretty easy to fill up your tablet's memory at that rate; 64GB of storage won't even get you through a flight from Toronto to Tokyo.edlee - Tuesday, January 15, 2013 - link
Most of my movies start at 4GB, I transcode them to less than a gig so I can fit about 25 films when I travel two weeks at a time. Also decoding a 1080p for a tablet uses more battery than 480p. I dont think transcoding is going away anytime soon.I use transcoding on the fly with servio and ps3ms in my house for all my dlna devices, but hopefully those apps with start to take advantage of Quicksync as well
Death666Angel - Thursday, January 17, 2013 - link
I hadn't bothered with it when I had my SGS2 with 16GB NAND and a 32GB mSDHC card. But when I switched to a Galaxy Nexus, space became a premium commodity. Now I reencode my 1080p stuff to 720p (reducing the size to ~1/3 or 1/4 of the original), so that I can cramp more stuff onto the phone.Though I wouldn't look at upgrading to a new setup (from my i7 860) just for QS.
vps - Tuesday, January 15, 2013 - link
AFAIR, the problem between Quick Sync and x264 were not because mediating library was closed source, but because main encoding process was closed and x264 had no way of affecting the quality. If I remember correctly (and I'm sure the messages can still be found in x264 forums):*) x264 folks were interested in accelerating the encoding, if x264 has access to all key steps and can affect the quality of the output (I have forgot the actual terms used).
*) Quick Sync works as a fast black box: you feed some data and get back final results without being able to affect anything.
*) Quick Sync produced quick results, but the quality wasn't good enough and offered no way to change that.
*) Intel guys offered x264 folks to use Quick Sync, but because of above mentioned reasons it was rejected.
*) Some x264 devs tried to play Torvalds and be an a$$hole. But they had actually very little reason to do so and in addition they overdid it. But it's not every day you get to opportunity to say "f**k off" to Intel from high horse, must have been very tempting, I'm sure.
The main argument of x264 against using Quick Sync was: it doesn't matter if it is fast, if it produces inferior results and doesn't provide any means to improve quality. In that sense Quick Sync doesn't differ from other fast libraries, for example Cyberlink. And x264 is not interested in being merely a caller of inferior external black boxes, no matter fast these are.
Many encoders trade quality for speed. x264 offers ability to trade speed to higher quality and x264 is not interested giving it up, even if some fast library is hardware accelerated and has "Intel inside" on it.