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
Kamus - Wednesday, January 23, 2013 - link
People that argue that people using x264 only care about quality have very little imagination.There's a lot of uses i can think off where you need speed for x264.
It's the codec that xsplit uses, and it's also used by plex and other applications like it.
on both xsplit and plex i'd much rather have the speed than the quality.
For xsplit the ability to stream with little to no performance hit would be very useful. Because assuming it doesn't slow your game down it would be just as good as having a dedicated encoding computer for streaming or a capture card that does hardware encoding.
This would allow people to use hardware they already have instead of having to shell out 300 dollars or more on a hardware solution.
Plex would also have huge benefits from this. My whole family uses plex trough roku boxes and iOS clients. For me that means that my entire library has to be transcoded. Having plex use quicksync would probably allow for multiple transcodes with out breaking a sweat. Something that isn't possible right now; since a few 1080p transcodes will choke my server more often than not.
I never understood why intel would invest so much on a piece of technology if they were going to make it so useless...
Well, at least they are trying to fix that now. But now we have to see if developers of desirable software jump on board.