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

  • 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. Reply
  • 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.
  • 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', 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. Reply
  • Goty - Tuesday, January 15, 2013 - link

    Oh boy, now we can all have horrendously transcoded video no matter our platform of choice! Joy! Reply

Log in

Don't have an account? Sign up now