HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

HandBrake for Windows support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
bbz_Ghost
Posts: 18
Joined: Fri Aug 21, 2009 10:29 pm

HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

Post by bbz_Ghost » Wed Mar 13, 2019 3:26 pm

Description of problem or question:

A very long time ago when I had a first generation Sandy Bridge CPU in an older Dell Latitude laptop, I remember reading about Quick Sync and thinking "Wow, it's about time we had hardware acceleration for encoding h.264, now I wonder how bad the quality will be." And when it first became available with HandBrake I actually did some encodes, and yes they suffered in quality because x264 was and still is capable of producing far better looking content and the Quick Sync encoder - while being crazy fast - could not match the visual quality even with the highest (but extremely limited) quality settings that encoder was capable of.

Nowadays, machines have newer CPUs, and my current machine - an HP EliteBook Folio 9470m with an Ivy Bridge i5-3247u processor - is supposed to be able to do Quick Sync and yet, no matter what I do, I cannot get it to actually work in terms of the GPU being involved in the encoding process at all. I've used Windows 7 Professional 64-bit (the OS the laptop shipped with originally), and now I'm currently testing out Windows 10 Professional 64-bit (build 1809) fully updated. On both platforms I've had the latest Intel video drivers, HandBrake tells me Intel Quick Sync is enabled in the activity log (below); the Intel Quick Sync checkbox is selected in the Preferences, and so on. I've done everything I can think of - except for maybe installing the latest Intel SDK if needed - but save for that one time for a few test encodes years ago, I've never been able to get Quick Sync working again on any of 3 dozen laptops I've owned over the years, all pure Intel hardware across the board.

Now, when I say Quick Sync worked long ago during that testing I mean when I watched HandBrake's fps for the encode (using the Avatar 1080p m2ts file as the source material) it jumped to over 350 fps so I was like "Wow, that's fast." When I monitored my actual CPU usage it was barely cracking 15-20%, but when I looked at GPU-Z to monitor the GPU activity, it was pegged at 100% as expected since Quick Sync uses the GPU for that - makes sense, right? Never has that happened again on any of the 3 dozen or more laptops I've owned and attempted to make use of Quick Sync on.

So this post... I'd really like to attempt to finally figure out either a) why it's never working even when all the hardware is Intel across the board or b) what I'm missing to get it functional. I'm aware of the quality issues, I am, and I know it's not great, but if it can speed up some encodes for mobile device purposes on the go so I don't have to copy massive huge video files to my device, I'm perfectly OK with this.

If anyone can help me figure this baffling situation out after all these years I'd be grateful for any assistance even if it turns out I'll never get it to work properly at all.

Steps to reproduce the problem (If Applicable):

Not sure what to put here, perhaps the rest of the info I provide might be more relevant.

tl;dr I would like to get Quick Sync actually working with HandBrake, it's that simple.

HandBrake version (e.g., 1.0.0):

1.2.2 (2019022300) 64-bit

Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):

Windows 10 Professional 64-bit build 1809, fully updated as of this morning (March 3, 2019)
Intel video drivers for the Intel HD 4000 integrated GPU version: 10.18.10.5059 dated August 16, 2018 (the latest available)

The machine runs about as cleanly and smoothly as possible, with no issues, using a Samsung 860 EVO SSD as the primary drive, with 12GB of DDR3 1600 RAM working in proper dual channel mode.

HandBrake Activity Log ***required*** (see How-to get an activity log)

I loaded the hd_other_avatar_trailer.m2ts file into HandBrake, all default settings (meaning it defaults to the Fast 1080p30 preset) except for changing it to H.264 (Intel QSV) for the Video Codec encoder, then hit Start and when it was done this was the activity log. During the encode I used GPU-Z to monitor for any potential GPU activity aka Quick Sync performance hit, nothing was noted, zero activity.

https://pastebin.com/yf1Jvk2q

I'm just baffled by this, I really am. Everything I've read in doing hours of research into this, pouring over hundreds if not thousands of posts all over the place and at the Intel support forums about how Quick Sync is enabled, detected, but never actually called into action on so many machines, all with straight Intel hardware, with various versions of Windows on them, updated, etc. Sure would be nice to get this one thing working even if I don't use it all that much - it's just one of those irritating things where it should work but it doesn't so I have to figure out why, it's a moral imperative at this point. 8)

Thanks again for any assistance, and thanks to the developers of HandBrake over the years, your efforts in creating this awesome and very useful tool are greatly appreciated by myself and many many others. :)

EDIT:
Not that it might help, who knows, but here's the MediaInfo information (as provided by MPC-HC) for the encoded output file, just in case it's useful:

https://pastebin.com/0cDbm8fj

User avatar
JohnAStebbins
HandBrake Team
Posts: 5386
Joined: Sat Feb 09, 2008 7:21 pm

Re: HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

Post by JohnAStebbins » Wed Mar 13, 2019 4:19 pm

QSV is enabled and working according to your log. But you also have some filters enabled that are not hardware accelerated. This is most likely the reason it is not as fast as you expect. You're source isn't interlaced, so you can safely disable comb detect and decomb filters.

bbz_Ghost
Posts: 18
Joined: Fri Aug 21, 2009 10:29 pm

Re: HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

Post by bbz_Ghost » Wed Mar 13, 2019 4:48 pm

Well, I never put that together at all that such processing could have a negative effect on the overall speed, thanks for pointing that out. I disabled all the filters (no sense in using them really for such purposes, I'm not looking to create cinema-quality encodes obviously) and got this for encoding speed in the log:

Code: Select all

[11:32:47] work: average encoding speed for job is 65.731812 fps
so a definite improvement in encoding speed. But again, the GPU is never being called into action as I watched both Task Manager's GPU columns and also GPU-Z and saw nothing, and it should: that's the entire point of GPU-accelerated hardware encoding, right? Or am I missing something there too? If the 1st gen Sandy Bridge CPU could kick out 350+ fps with that GPU in the encoding path, I just can't figure out why I'm never able to get newer CPUs (Ivy Bridge in this laptop, and I've owned a Haswell-based machine in the recent past and even a Kaby Lake-based laptop within the past few months and neither of those would show any activity on the GPU either) to do this properly. I mean, this Ivy Bridge CPU is obviously superior to that older Sandy Bridge one but I can't ever get HandBrake - or any other encoder software of any kind that supports Intel QSV - to actually put the GPU to use.

I apologize since I know this isn't technically a HandBrake issue directly; the logs are clearly showing HandBrake is seeing QSV supported but I just don't see any visual proof in terms of the encoding framerates nor any measurable activity on the GPU during an encode, not with Task Manager in Windows 10 (which can show the GPU engine in use and how much it's being used) nor GPU-Z or any other GPU monitoring tool.

I'm grateful for the tips, it'll help with the encoding speed, but it's still very very far from what's possible I suppose. Maybe someday it'll just start working out of the blue, who knows. : :?

rollin_eng
Veteran User
Posts: 3087
Joined: Wed May 04, 2011 11:06 pm

Re: HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

Post by rollin_eng » Wed Mar 13, 2019 4:57 pm

Could you please post your new HB logs.

User avatar
Rodeo
HandBrake Team
Posts: 12102
Joined: Tue Mar 03, 2009 8:55 pm

Re: HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

Post by Rodeo » Wed Mar 13, 2019 5:07 pm

bbz_Ghost wrote:
Wed Mar 13, 2019 4:48 pm
I watched both Task Manager's GPU columns and also GPU-Z and saw nothing, and it should: that's the entire point of GPU-accelerated hardware encoding, right? Or am I missing something there too?
It's hardware-accelerated encoding on dedicated hardware; the fact that it happens to be located on the GPU is mostly irrelevant. Most of the GPU isn't used at all by the QSV encoder.

User avatar
Rodeo
HandBrake Team
Posts: 12102
Joined: Tue Mar 03, 2009 8:55 pm

Re: HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

Post by Rodeo » Wed Mar 13, 2019 5:10 pm

65fps seems about right for a full HD encoder on such a slow CPU… the video decoder (CPU-based) is most likely the bottleneck here. Your original test may have been done on a DVD source, or something otherwise faster to decode (MPEG-2 Video)?

bbz_Ghost
Posts: 18
Joined: Fri Aug 21, 2009 10:29 pm

Re: HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

Post by bbz_Ghost » Wed Mar 13, 2019 5:22 pm

OK, so I rebooted my laptop (just 'cause) and then opened HandBrake, loaded the hd_other_avatar_trailer.m2ts file, went to the Filters tab and set everything to "Off," then the Videos tab and changed it to H.264 (Intel QSV) then selected the target file by clicking Browse at the bottom and then overwriting the previous encode on the Desktop, then hit Start and it went a bit faster this time - the previous encode was done with just HandBrake running so these tests aren't being done with most anything else running in the background, for the record.

https://pastebin.com/VLXHui1r

Now I can't say why it's suddenly a bit faster, that's about 30-33% so a nice boost over what it did earlier, who knows, maybe the reboot cleared something out. I suspect I'm just being weird about all this but it just seems like it's not as fast as I think it should be based on my past experience years ago. Is it faster than a pure CPU encode? Well, I suppose so, and since I wondered about it I just did a pure CPU encode with just the H.264 encoder with the same source file loaded in the same instance of HandBrake and got this a moment ago (again, this is a different encode log with the native H.264 encoder, not QSV, using the same file/etc):

https://pastebin.com/09xkLSZ0

So yes, obviously it's much much faster when I choose the H.264 (Intel QSV) encoder since I hadn't even done a test encode with the pure H.264 native encoder up to this point (I just got this laptop a few days ago and finally worked on setting it up properly this morning). I'm still not sure why I was seeing such crazy frame rates years ago on the Sandy Bridge machine and the GPU taking on all the work unlike it's doing now.

Perhaps there's something that's changed with the more current CPUs so that when the GPU is used for Quick Sync purposes the GPU data counters aren't reporting it as GPU usage and instead just reflecting the increased resource usage as CPU time, I don't know, but it's a bit odd even so.

Again, thanks for the responses.
Rodeo wrote:
Wed Mar 13, 2019 5:10 pm
65fps seems about right for a full HD encoder on such a slow CPU… the video decoder (CPU-based) is most likely the bottleneck here. Your original test may have been done on a DVD source, or something otherwise faster to decode (MPEG-2 Video)?
I thought about that earlier but remembered that my "go-to-test-clip" for encoding testing purposes has always been that hd_other_avatar_trailer.m2ts test file because it exhibits a pretty high bitrate at one point in the clip. I've never used DVD-based MPEG2 content for encoding with HandBrake, actually, at least in the past 10 full years which is just before Core processors and Quick Sync ever existed (meaning the original Core tech which came out in early 2010 with the Clarkdale hardware, QSV was introduced with Sandy Bridge a year later in 2011).

Anyway, for now it's faster and I'll just be happy with it. :)

Next week I'm getting a fully maxed out ThinkPad W540 workstation laptop (i7-4930mx CPU + 32GB of DDR3 RAM + SSD + IPS display + a built-in Pantone colorimeter, etc, all the bells and whistles) so it should be interesting to see if it can do a bit better for these encoding jobs now and again (the 4930mx is Haswell based). Something to look forward too, definitely.

EDIT:
Just in case anyone was wondering, that Avatar trailer clip has the following MediaInfo:

https://pastebin.com/WF25sA4w

and if anyone wants it for whatever reason (I like it because it just has a good look to it, very sharp and clear, great color spectrum, and it's just been my go-to clip for this stuff for a long time now) I'd be happy to drop it on a site like Mega or someplace, thanks again.

User avatar
Rodeo
HandBrake Team
Posts: 12102
Joined: Tue Mar 03, 2009 8:55 pm

Re: HandBrake and Intel Quick Sync - it worked, once, and I mean literally just once :(

Post by Rodeo » Wed Mar 13, 2019 5:40 pm

We did use to have a full zerocopy path in older versions of HandBrake (where decoding, crop/scale and encoding all happened on the GPU), but that's no longer the case (we needed to make changes to the encoding path and the zercopy path was too hard to maintain given our limited resources), which may also explain some of the performance difference.

Post Reply