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
Wolfpup - Tuesday, January 15, 2013 - link
Yeah, even still I don't think this makes sense and don't see how it really gets supported by the programs we all actually use.If I were on one of these teams, I'd be looking at whether OpenCL can do anything for me, given it's...open, and will probably be supported better than anything else, etc.
I continue to be pissed that Intel is blowing all these transistors on video and encoding. I do not want it. I want more cores, bigger cores, etc. Not some proprietary fixed function video encoder...
Arbee - Tuesday, January 15, 2013 - link
Yeah, as I understand it this doesn't actually fix x264's problem at all.And it wasn't just x264 that was unimpressed with QuickSync's image quality; recall that Apple refused to enable it Sandy Bridge on the grounds that the output looked like crap. I assume that's why Intel concentrated more on quality for IVB. It now meets Apple's specs, but you still wouldn't want to use it for non-realtime transcoding (e.g. DVD ripping with Handbrake or whatever).
Also, I must protest being an a$$hole as "playing Torvalds". Linux's success is due in equal parts to Linus' pragmatism and his generally well-founded stubbornness. I'm genuinely afraid of what'll happen if he gets hit by the proverbial bus and the FSF faction takes over the kernel. Google would probably have to fork to continue Android, among other things.
frenchy_2001 - Tuesday, January 15, 2013 - link
FSF has 0 say in the kernel and would not be able to change anything: the kernel is licensed under GPL v2 PERIOD. No "or later" or anything like that, so it is stuck to it (it would be *impossible* to get consent from the hundreds if not thousand of contributors to re-license it, as each contributor has kept their copyright).If anyone wants a kernel under a different license, they are welcome to write their own.
Gigaplex - Wednesday, January 16, 2013 - link
So what if it's GPL v2? The FSF could take over as the maintainers/stewards of the mainline kernel, leave it at GPL v2, and still accept patches into mainline that Linus would otherwise reject and/or reject patches that Linus would otherwise accept.Goty - Tuesday, January 15, 2013 - link
Oh boy, now we can all have horrendously transcoded video no matter our platform of choice! Joy!Spoelie - Tuesday, January 15, 2013 - link
Once I read this comparison (and saw the comparison shots):http://www.behardware.com/articles/828-1/h-264-enc...
I simply ignored quicksync - however that was with HD3000, has the quality situation improved?
etamin - Tuesday, January 15, 2013 - link
when will GPU acceleration finally come to handbrake??Senti - Thursday, January 17, 2013 - link
Quick Sync PR again? All people who really care about video encoding know that Quick Sync was pure marketing buzz from the beginning and has zero practical usage.First you show the x264-level application benefiting from it – only then I'll believe you. Oh, and I want Hi10P h264 btw.
Marburg U - Friday, January 18, 2013 - link
Without basic features like high profile and multipass it's totally useless.It's not even worth for nand-based portable devices where you are limited by the amount of storage: double the file size for WAY too low video quality.
This asic\simd based features may be worth something for 480p phones....
vegemeister - Thursday, March 21, 2013 - link
Multi pass is a huge waste of space, unless you're doing something silly like trying to burn movies to 700MB CD-Rs. Believe it or not, x264 knows better than you how many bits it needs to achieve a particular quality level with a particular video.