HandBrake to Get QuickSync Support
by Anand Lal Shimpi on March 27, 2013 9:01 PM EST- Posted in
- GPUs
- CPUs
- Intel
- Haswell
- Quick Sync
The latest version of Intel's Media SDK open sourced a key component of the QuickSync pipeline that would allow the open source community to begin to integrate QuickSync into their applications (if you're not familiar with QS, it's Intel's hardware accelerated video transcode engine included in most modern Core processors). I mentioned this open source victory back at CES this year, and today the HandBrake team is officially announcing support for QuickSync.
The support has been in testing for a while, but the HandBrake folks say that they expect to get comparable speedups to other QuickSync enabled applications.
No word on exactly when we'll see an official build of HandBrake with QuickSync support, although I fully expect Intel to want to have something neat to showcase QuickSync performance on Haswell in June. I should add that this won't apply to OS X versions of HandBrake unfortunately, enabling that will require some assistance from Apple and Intel - there's no Media SDK available for OS X at this point, and I don't know that OS X exposes the necessary hooks to get access to QuickSync.
Source: Intel PR
Facebook
Twitter
RSS
32 Comments
View All Comments
mevans336 - Friday, March 29, 2013 - link
You are in the vast minority. I watch 1080p movies about 6' from my 47" LED LCD and I don't notice a single difference in 10Mbps x264 MKV or 10Mbps (QS) MP4 that have both been transcoded from the same source. I don't really notice a difference in QS or x264 until I hit 15Mbps ... and even then it's ridiculously minor. Definitely not worth the performance hit.mediaconvert - Friday, March 29, 2013 - link
At 10Mbps a 1 hour file would be 10Mpbs *3600s/8 ( 8 bit per byte)= 4500MB ( 4.5 GB ) per hour. Thats only 7 hours of hd footage on your average 32gb phone/tablet.Besides any encoder can look okay at those bit rates. If you know the Handbrake settings can get great HD results at sub 4Mbps bit rates with X264. At LOW and really low bit rates ( and hence smaller file sizes) quicksync just looks an aweful mess but X264 still looks really good. IMO quicksync is only good if you need to get something on you phone quickly. If I'm keeping the file I use X264 and handbrake to preserve the quality.
Wolfpup - Thursday, March 28, 2013 - link
So would this support Sandy Bridge (and Ivy) or only Haswell?If I were the Handbrake guys, personally Quicksync support is the LAST thing I'd work on. I'd much sooner support OpenCL since it's...open, works on multiple platforms, mulitple CPUs, multiple GPUs, etc. Quicksync is IMO a really terrible idea Media on here is saying it can't actually compete with CPU transcoding, it's limited to just some CPUs from one company, it keeps changing with every CPU, and there's no guarantee it'll stick around. And IMO it shouldn't exist to begin with-the transistors used on Intel's video should be spent towards more CPU, let alone the transistors spent on hard wired transcoding...
Novulux - Thursday, March 28, 2013 - link
Their nightly builds split into two branches, one of which is OpenCl supported. You can check it out yourselfJarredWalton - Friday, March 29, 2013 - link
Considering Quick Sync is several times faster than the best alternative encoding method (even using GPU resources), I have to disagree. Not to mention NVIDIA (NVENC) and AMD (Video Codec Engine) have both tried to do the same thing, though neither has yet attained the speed and quality of Quick Sync. If you're just trying to get something ready for a YouTube upload, or transcoding for use on a smartphone or tablet (where max quality on such a small screen really doesn't matter), Quick Sync is awesome.ericore - Thursday, March 28, 2013 - link
Unfortunately, quality will be reduced with quicksync. Haswell should suffer less from this, but really until broadwell hits quicksync won't be x86 quality. Really, you'd be much better off with an AMD 8 core (whatever the next one is called); it improves performance quite a bit, and handbrake will thrive on this CPU. Or get at 6 core Intel CPU 599$ with plenty of smiles, or wait until they perfect OpenCL, another year away. On Budjet, i3 and i5 just aren't worth it. Better off going with (next gen AMD 8 core 200$, Penitum 45-70$ or Xeon 240$ )mevans336 - Friday, March 29, 2013 - link
The AMD 8-core doesn't even beat the i7-3770k. You have no idea what you're talking about.JarredWalton - Friday, March 29, 2013 - link
Not to mention Quick Sync performance is largely tied to the CPU architecture and whether you have dual-core or quad-core matters very little. Case in point, a ULV IVB Core i5 with Quick Sync is about 80% of the speed of the fastest desktop i7-3770K at transcoding. (Of course, if you use other features of Media Espresso or Media Converter that hit the CPU more, you'll see a bigger difference.)piroroadkill - Sunday, March 31, 2013 - link
Guess it can be a pain when your videos are >4GiB and you only have FAT32 support on your phone, maybe.loadwick - Thursday, April 4, 2013 - link
Are we over the days of QuickSync not working in you have another GPU on your PC? Back in the Sandy Bridge days QuickSync only worked when you had a monitor attached to one of its outputs, is this still the case?I will be buying a Haswell set up when it's out but will also be using a dedicated GPU, will the GPU on the CPU still function? Will software like Handbrake still have access to QuickSync?
Also there is often concerns over quality from GPU assisted encoding, is this still the case with Open CL? What would be a better option (mainly quality but also speed) new upper mid-range AMD or nVidia card or sticking with QuickSync or disabling all GPU acceleration and purely using x86?