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. 


View All Comments

  • heymrdj - Monday, January 14, 2013 - link

    Can't wait to see HB support this! Reply
  • 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 ( and of course the whole thing is free as in beer :). Reply
  • JohnMayer - Tuesday, January 15, 2013 - link

    Love my job, since I've been bringing in $5600… I sit at home, music playing while I work in front of my new iMac that I got now that I'm making it online(Click on menu Home)

    Happy New Year!
  • StevoLincolnite - Tuesday, January 15, 2013 - link

    We don't care about a measly $5600 for sitting on your ass. Go to a website where you can fool people with your scams. Reply
  • babgvant - Wednesday, January 16, 2013 - link

    We really need a way to flag comment spam as spam here. Reply
  • tipoo - Wednesday, January 16, 2013 - link

    But it's John Mayer! We have to believe him, this seems legit. Reply
  • Kamus - Wednesday, January 23, 2013 - link

    You are replying to what is most likely a bot. Reply
  • 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! Reply
  • dmytty - Friday, January 18, 2013 - link

    Is it possible to get the motion compensation data from Intel Quick Sync while encoding? Reply
  • 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.

Log in

Don't have an account? Sign up now