Handbrake/Intel Quick Sync

[hogger129]

Does anybody know how to configure Handbrake 0.9.9.1 (the latest version) to use Intel Quick Sync? I have an Intel i5 which supports Quick Sync, and I like Handbrake more than DVDFab because Handbrake produces better quality encodes. But DVDFab is so much faster because of Quick Sync. Anybody know how to configure this on Handbrake? I'm trying to do CQ18 with Quick Sync, using Medium for my H.264 setting, but it's estimating to take about 4 hours to encode. Would be nice to have Quick Sync so it does it in about 3 hours instead.

Thanks.

[Selur]

No clue, don't use Handbrake, but the quality will probably be the same independent if you use Handbrake or DVDFab if the QuickSync encoder is used.

[hello_hello]

Handbrake uses the x264 encoder which is CPU only. I don't think there's a way to get Handbrake to use Quicksync for decoding.

Does DVDFab use QuickSync just for decoding or for encoding too? I couldn't find any definitive info. This is a couple of years old so I don't know if it's accurate. http://www.prnewswire.com/news-releases/dvdfab-products-use-intel-quick-sync-to-be-fas...123094188.html
It sounds like you need to manually enable QuickSync encoding, which is probably a good thing. The general consensus is it's not as good as the x264 encoder even if it is faster. QuickSync just decoding shouldn't effect quality, I assume.

[hogger129]

Handbrake uses the x264 encoder which is CPU only. I don't think there's a way to get Handbrake to use Quicksync for decoding.

Does DVDFab use QuickSync just for decoding or for encoding too? I couldn't find any definitive info. This is a couple of years old so I don't know if it's accurate. http://www.prnewswire.com/news-releases/dvdfab-products-use-intel-quick-sync-to-be-fas...123094188.html
It sounds like you need to manually enable QuickSync encoding, which is probably a good thing. The general consensus is it's not as good as the x264 encoder even if it is faster. QuickSync just decoding shouldn't effect quality, I assume.

I'm pretty sure it supports encoding and decoding with Quick Sync in DVDFab. I was just curious though, as I hate having to wait 6 hours or so to do an encode. I'd speed up my x264 setting, but then the file size is larger. Ehh I'll play around with it and see if there's a better configuration for my needs. Thanks.

[jagabo]

There is a special QS beta build of Handbrake. The cropping feature is borked though. And QS encoding quality isn't as good as x264. x264 at veryfast delivers better quality and isn't too much slower.



Looking at the changelog it appears QSV is now in the regular builds:

https://trac.handbrake.fr/timeline

So maybe they've fixed the cropping bug.

[hello_hello]

Interesting...... not that I can run it. Aside from a lack of QuickSync, Handbrake doesn't run on XP any more.

Is it possible to decode via Quicksync but encode using the x264 encoder?

[jagabo]

I don't really use Handbrake so I don't know exactly what it's capable of. But it's theoretically possible to decode with QS and encode with x264. From what I've seen, Handbrake is often limited by decoding speed if you're using the faster x264 presets.

[Bazzie]

Interesting...... not that I can run it. Aside from a lack of QuickSync, Handbrake doesn't run on XP any more.

Is it possible to decode via Quicksync but encode using the x264 encoder?

No - Quicksync uses its own encoder. I've been using the nightly builds (Beta - all QS capable Handbrake's are here) for the last year or so with very good results. Previously, I did many many blu-rays using BD Rebuilder (X264) with also great results.
To be honest, if you use a QS with a QP setting of 22 or so, the results, to my eyes, are comparably to two-pass BD Rebuilder. Very few artifacts (in fact I can't see them). The big big difference is TIME. With my Inspiron 17R SE with i7-3630QM it typically takes about 15 minutes (after dumping movie as ISO file on hard drive) to do a movie in QS which looks great on my big LCD. Much much faster than a couple of hours or more using BD Rebuilder.

I came across an article comparing the newer versions of QuicSync to X264 and itself at various bit rates. I was stunned how well QS did. Differences were very small, especially considering the huge time savings. Read it here:

http://www.missingremote.com/review/intel-quick-sync-examining-haswell-performance

My own informal tests at home tend to agree with these findings. In fact, I haven't used BD Rebuilder for over six months as I find the visual quality with QS to be virtually indistinguishable with casual viewing.

I haven't had any problem with auto cropping the last couple of builds but you can set it manually as well, or even leave the top and bottom black borders.

I should mention that I did play around with QuickSync a couple of years ago when it was only supported by a couple of software programs (Splash Pro and another one), and found the results very poor with lots of artifacts. Things may have improved with these programs since then and, to be fair, I was using the original i7-2600K processor. Still, it was a delightful eye opener with my very first results using Handbrake QS. I hope it soon gets out of Beta.

[racer-x]

Aaaah, now I know what "QSV" means. I noticed it in Aviutl as an export plugin. I tried it, but I don't think my old Q9300 supports it. It looks like it used the software version instead. Maybe If I upgrade to new PC, I'll test it out:

------------------------------------------------------------------------------------------------------------------------------
[C:\Users\Racer X\Desktop\junk\QSV.mp4]
------------------------------------------------------------------------------------------------------------------------------
auo [info]: converting YUY2 -> NV12p, using SSE2
qsv [info]: QSVEnc 1.21 (x86), based on Intel(R) Media SDK Encoding Sample 5,0,337,0
qsv [info]: CPU Info Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (4C/4T)
qsv [info]: Media SDK impl software encoder, API v1.8
qsv [info]: Input Frame Info auo: yuy2->nv12, 488x90, 30/1 fps
qsv [info]: Output Video H.264/AVC High @ Level 4
qsv [info]: 488x90p 1:1 30.000fps (30/1fps)
qsv [info]: Encode Mode Constant QP (CQP)
qsv [info]: CQP Value I:24 P:26 B:27
qsv [info]: Target usage 4 - balanced
qsv [info]: Trellis Auto
qsv [info]: Ext. Bitrate Control disabled
qsv [info]: CABAC on
qsv [info]: RDO off
qsv [info]: mv search precision: Q-pel, window size:8x8
qsv [info]: min pred block size inter: Auto intra: 4x4
qsv [info]: Ref frames 3 frames
qsv [info]: Bframe Settings 3 frames
qsv [info]: Max GOP Length 300 frames
qsv [info]: Scene Change Detection off
qsv [info]: B pyramid off
qsv [info]: GOP Structure fixed
qsv [info]: Slices Auto
qsv [info]: Memory type system
qsv [info]: Input Buffer Size 3 frames
qsv [info]:
qsv [info]: encoded 900 frames, 549.45 fps, 109.12 kbps, 0.39 MB
qsv [info]: encode time 0:00:02

qsv [info]: frame type IDR 3
qsv [info]: frame type I 3, total size 0.02 MB
qsv [info]: frame type P 225, total size 0.12 MB
qsv [info]: frame type B 672, total size 0.26 MB
auo [info]: IntelMediaSDK Encode : 0hr 0min 1.7sec
auo [info]: Muxing with L-SMASH muxer. Video: on, Audioff, tcff, chapff, Extended Mode:None
auo [info]: Muxing with L-SMASH remuxer. Video: on, Audioff, tcff, chapff, Extended Mode:None
auo [info]: Total Encode Time: : 0hr 0min 3.8sec

Co52plePe7 on 2014-6-7- 16:52
-------------------------------------------------------------------------------------

[hello_hello]

I came across an article comparing the newer versions of QuicSync to X264 and itself at various bit rates. I was stunned how well QS did. Differences were very small, especially considering the huge time savings. Read it here:

http://www.missingremote.com/review/intel-quick-sync-examining-haswell-performance

It doesn't really. It compares x264 CRF 10/16 with QuickSync QP 10/16. No mention of the resulting bitrates, unless I'm missing the obvious.
Plus if the reviewer was only going to use SSIM to compare quality, he probably should have enabled --tune simm for x264. If memory serves me correctly, all that does it disable x264's psychovisual enhancements, and the general consensus seems to be they improve the perceived quality, but they have a negative effect on SSIM results. Although whether it'd make much difference when using low CRF values, I'm not sure.

Anyway.... if Quicksync encoding quality is improving, I guess that's a good thing.

[Selur]

btw. did anyonw play aroudn with the Quicksync sample_multi_transcode tool ?

[Bazzie]

I came across an article comparing the newer versions of QuicSync to X264 and itself at various bit rates. I was stunned how well QS did. Differences were very small, especially considering the huge time savings. Read it here:

http://www.missingremote.com/review/intel-quick-sync-examining-haswell-performance

It doesn't really. It compares x264 CRF 10/16 with QuickSync QP 10/16. No mention of the resulting bitrates, unless I'm missing the obvious.
Plus if the reviewer was only going to use SSIM to compare quality, he probably should have enabled --tune simm for x264. If memory serves me correctly, all that does it disable x264's psychovisual enhancements, and the general consensus seems to be they improve the perceived quality, but they have a negative effect on SSIM results. Although whether it'd make much difference when using low CRF values, I'm not sure.

Anyway.... if Quicksync encoding quality is improving, I guess that's a good thing.

Regardless, the final chart clearly shows that QS does a very good job of recoding compared to X264 (of which I am a big fan, by the way).
The CRF/QP settings of 10-16 are quite a bit lower than I would use. I try to keep finished files in the 4 to 5 GB range. At that, I am more than pleased with the quality. The original source - generally 24 FPS film is so full of studdery motion and blurring that it usually hides any encoding flaws (except maybe for the macroblocking and mosquito noise that popped up with regularity in the old days using Nero Recode and Mpeg2).
The other charts comparing only QS with itself at different bit rates shows remarkable faithfulness to the original unless - typically well under 1% variation from the original.
I don't know about everyone else, but the vast majority of my recoding is backing up my Blu-Rays to a hard drive and I find that almost all of the discs are AVC encoded. At that, Quick Sync does a very good job of maintaining quality at bit rates as low as 3Mb/sec. Most of my files average around 5 Mb/sec and at that rate the faithfulness demonstrated in the article shows about .997 to 1.
Occasionally I compare original Blu-rays to recoded versions using my twin 24" Dell monitors. Unless I use a ridiculously low bit rate - like CRF25+ I find it very difficult to find any visual variation or flaws in my recoded versions. This is both using BD Rebuilder - 2 pass and Handbrake QSV with similar size recoded files.
Not trying to start an argument here but I was truly shocked at how well Handbrake QS recodes compared to previous software programs I had tried - Splash Pro and Media Espresso.

[hello_hello]

No argument required here..... I was just offering my take on the article. It didn't seem to provide all the relevant information to me. I'd be more than happy to use a faster encoder if it matched x264 for quality at similar bitrates. When I upgrade this PC (very soon) I'll definitely give QuickSync a test drive.

Although even assuming Quicksync is particularly clever, I find mostly when I encode video I apply some sort of filtering, even if it's just a little noise removal, and that's always via an Avisynth script, which would probably put a bit of a dent in my QuickSync usage..... but I will give it a spin.

[Bazzie]

No argument required here..... I was just offering my take on the article. It didn't seem to provide all the relevant information to me. I'd be more than happy to use a faster encoder if it matched x264 for quality at similar bitrates. When I upgrade this PC (very soon) I'll definitely give QuickSync a test drive.

Although even assuming Quicksync is particularly clever, I find mostly when I encode video I apply some sort of filtering, even if it's just a little noise removal, and that's always via an Avisynth script, which would probably put a bit of a dent in my QuickSync usage..... but I will give it a spin.

Yes, Noise and film grain does play havoc with efficient recoding. I'm frequently amazed at the small finished file size of digital animation features I've recoded, no doubt due to the absence of noise/film grain.
Haven't played with any pre-processing filters yet but maybe I should give it a try.