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. 
Comments Locked


View All Comments

  • icrf - Tuesday, January 15, 2013 - link

    The big thing is no one uses x264 on superfast presets because people using x264 usually care about quality. The result is few people are aware of how fast it can be in raw fps numbers once it backs off the quality benchmark it is known for.

    I will grant you that while x264 veryfast may be around Quicksync speeds, it will definitely be using more CPU power to do it.
  • hornetfig - Monday, January 14, 2013 - link

    I've read that discussion in the past (first in early 2011 - when deciding whether to buy into P65 or wait for Z77). That's not really a correct interpretation of what the state of affairs were:

    Firstly, the x264 dev's overriding interest is in maintaining the quality of the encode. If QuickSync was fast, that was irrelevant if it couldn't be used to replicate the quality of x264's CPU h.264 encode. We hhad all seen nVidia's efforts in this area to that time and they were pretty awful. So of course there was skepticism.

    Then there was a problem with what information was actually forthcoming from Intel. The information provided seem to come from one engineer's private outreach. All the claims were vague (maybe he wasn't a native English speaker?). Requests for further information took a long time and still weren't sufficient.

    Effectively, there seemed to be cross purposes. The x264 project would have been more than willing look at using specific elements of QuickSync, to the extent it was possible. The Intel engineer was thinking x264 should be just a QuickSync frontend (obviously not going to happen). Intel itself had no official involvement in the discussion at all.

    So here we are two years down the track at approximately where we should have been a tad over 2 years ago!
  • icrf - Tuesday, January 15, 2013 - link

    Yeah, I had read that thread, too, and I think that sums it up nicely.

    For anyone else interested in the details, this is the original discussion from October 2010:
  • iwod - Monday, January 14, 2013 - link

    Well, you should reread the discussions again. Love QuickSync and all the juicy part Anand told you about? They are not available unless you paid for an application. The decoder to OS software player didn't came long time later. And Intel couldn't be bother to work with the community as far as i could tell. ( Although not necessarily the engineers fault. )

    So we basically have a piece of Hardware in our CPU that is being greatly advertised but cant be used at all.
  • frenchy_2001 - Tuesday, January 15, 2013 - link

    It is actually not quite true. You DO have free (as in beer) software taping QuickSync since early/mid 2012, when Intel made it available in their dev kit.
    Mediacoder is one of them and works quite well (on my SB 2500k).

    QS is a black box with very limited options though, so in the end I used x264 for flexibility (still with MediaCoder btw).

    So, it is usable, but intel is lifting the veil one corner at a time...
  • tdtran1025 - Thursday, January 17, 2013 - link

    This may have been true in the past because they found (collectively) AMD and NVidia solutions did not offer substantial gains in transcoding time. Now QS is the game changer and so reflect the attitudes of said "clowns".
  • Montago - Thursday, March 7, 2013 - link

    I read about that too... the Handbrake people are jerks... Maybe because they are French ?...

    I've read tons of forums and articles about people wanting GPU power to HandBrake - and everytime the HandBrake/x264 people shoot it down (with good reasons sometimes)

    I'm pretty sure that nothing will happen, that Handbrake and x264 will continue to be CPU only.
  • MonkeyPaw - Monday, January 14, 2013 - link

    I do enjoy QuickSync, as I specifically wanted the HD 3000 i3 for this very task. I was disappointed I could not use QS on Ubuntu and that Intel offered no support. My guess is that Intel wants full exposure of QS so that their SDP chips have the most market penetration possible. QS on Android perhaps?
  • Guspaz - Monday, January 14, 2013 - link

    If QuickSync is still not available to anybody using a discrete graphics card, few desktop users will be able to access it.

    I'll wind up in the bizarre situation where my IvyBridge MacBook Air will be able to transcode video much faster than my desktop i7 3770k system with a GeForce GTX 670.
  • babgvant - Monday, January 14, 2013 - link

    DX11 supporting GPUs don't need a connected display to enumerate, so it will work headless (or disconnected).

Log in

Don't have an account? Sign up now