Handbrake QSV uses 70% iGPU and 100% CPU

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
2mg
Posts: 5
Joined: Fri Sep 22, 2017 7:06 pm

Handbrake QSV uses 70% iGPU and 100% CPU

Post by 2mg »

Please detail your question or problem in as much detail as possible:

Handbrake uses around 70% iGPU (Intel QSV) and 100% CPU with x265 QSV encoder. Unless I understand it wrong, the iGPU should do all the work.

Tell us about your environment. What version of HandBrake? What version of Windows are you running. etc.

Tried latest 1.7 release and latest 1.7 nightly as of this date, same results. Win7 x64, i5-3470 CPU with HD 2500 Graphics. Latest drivers and all that. Main GPU disabled and switched to iGPU during testing.

I have MSI AB + RTSS installed, but both AREN'T running during test. Also, iGPU usage is 100% when I use "benchmark" in settings for recording with those programs.

Please include the scan or encode log:

https://pastebin.com/bRm8Fc5Z
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Handbrake QSV uses 70% iGPU and 100% CPU

Post by s55 »

Unless I understand it wrong, the iGPU should do all the work.
Nope.

Your source is H.265 and your encoding to H.264. Your CPU doesn't have a H.265 Decoder (You need a skylake / kabylake CPU for this) in the QuickSync ASIC. So, that has to be done in software and thus on the CPU.

In addition, you have software filters enabled and running. QuickSync doesn't support these (in any generation).
I suspect your source isn't interlaced, so you could turn off the software combdetect and decomb filters for a modest speed bump and slightly less CPU usage.

Also, the audio encoding is not supported by QuickSync so the audio encoder is also running at the same time.

After all that, finally, you have the HandBrake engine keeping everything humming along keeping everything in sync.

While you can achieve quite low CPU usage, you have to turn off anything that runs on the CPU to get there. What your doing now gets you the best of both worlds.
2mg
Posts: 5
Joined: Fri Sep 22, 2017 7:06 pm

Re: Handbrake QSV uses 70% iGPU and 100% CPU

Post by 2mg »

s55 wrote: Fri Sep 22, 2017 8:31 pm While you can achieve quite low CPU usage, you have to turn off anything that runs on the CPU to get there. What your doing now gets you the best of both worlds.

Thanks for a quick an thorough reply!
Your source is H.265 and your encoding to H.264. Your CPU doesn't have a H.265 Decoder
It didn't even occur to me that a h265 as an input frame for transcoding has to be decoded by iGPU itself too before encoding (was thinking it's "raw" somehow).
you have software filters enabled and running
I didn't even notice Decomb is on (in every preset)...
the audio encoding is not supported by QuickSync
So which mp4 audio codec wouldn't take a lot of CPU cycles?
you have the HandBrake engine keeping everything humming along
Will the engine have to work after it sends commands to x264 QSV? AFAIK x264 (the regular "CPU" one) is a self-contained encoder, Handbrake just instructs it what to do?
While you can achieve quite low CPU usage
The 70% iGPU and 100% CPU combination threw me off completely.

PS: I tried transcoding an x264 in x264, same FPS, dimensions and no cropping, but these 3 are seen as filters in activity log, can they be bypassed since it's a pure format-to-format conversion to offload the CPU (pure iGPU transcode)? Regardless of that, I'm having Handbrake crash when I try OpenCL scaler, log is here: https://pastebin.com/kkZH0fCt I even tried disabling dedicated GPU in Device Manager to make sure OpenCL is handled by iGPU, since GTX is OpenCL CUDA, as per GPU-Z info. Both are 1.2 OpenCL.
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Handbrake QSV uses 70% iGPU and 100% CPU

Post by s55 »

It didn't even occur to me that a h265 as an input frame for transcoding has to be decoded by iGPU itself too before encoding (was thinking it's "raw" somehow).
All input has to be decoded before re-encoding. You can see the map of support for decode vs encode in QuickSync here:
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
Note that libav supports literally hundreds of formats. Quicksync only supports a few mainstream ones and then varies by CPU generation.

So which mp4 audio codec wouldn't take a lot of CPU cycles?
Audio in General isn't overly CPU intensive. Filters and Decode are both fairly significant.
Will the engine have to work after it sends commands to x264 QSV? AFAIK x264 (the regular "CPU" one) is a self-contained encoder, Handbrake just instructs it what to do?
HandBrake unlike many many apps out there, is not a Command Line front-end to other encodes.
We have our own library for managing the pipeline between decode, filter (including some of our own filters), audio/video encoding and audio / video sync management and corrections, memory management etc etc etc.
PS: I tried transcoding an x264 in x264, same FPS, dimensions and no cropping, but these 3 are seen as filters in activity log, can they be bypassed since it's a pure format-to-format conversion to offload the CPU (pure iGPU transcode)? Regardless of that, I'm having Handbrake crash when I try OpenCL scaler, log is here: https://pastebin.com/kkZH0fCt I even tried disabling dedicated GPU in Device Manager to make sure OpenCL is handled by iGPU, since GTX is OpenCL CUDA, as per GPU-Z info. Both are 1.2 OpenCL.
Don't use OpenCL scaler. We've binned it in the upcoming release as it's too problematic and actually slower in most instances that it actually works.
2mg
Posts: 5
Joined: Fri Sep 22, 2017 7:06 pm

Re: Handbrake QSV uses 70% iGPU and 100% CPU

Post by 2mg »

s55 wrote: Sat Sep 23, 2017 2:09 pm
Thanks. Gotta ask, since I'm experimenting and learning and I want to see how far I can push QSV to offload the system, I'm not sure why I'm seeing 30-50% CPU usage on a pure transcode, here: https://pastebin.com/ECiSLqF1

I see some filters are active, especially the FPS one, but I'm not using any, dimensions are same as source, FPS is same as source, no cropping.
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: Handbrake QSV uses 70% iGPU and 100% CPU

Post by s55 »

Thanks. Gotta ask, since I'm experimenting and learning and I want to see how far I can push QSV to offload the system, I'm not sure why I'm seeing 30-50% CPU usage on a pure transcode, here: https://pastebin.com/ECiSLqF1
There is still memory management, a/v Sync/ colour space conversions, managing the AAC passthru data (it's not 0% cpu) going on in the background, so what your seeing is about right.
The QuickSync implementation in HandBrake isn't designed to be a pure ASIC approach. It's designed to take advantage of the HandBrake pipeline and all it's features.

What your seeing is about right and not something you can do anything about by adjusting settings more.
2mg
Posts: 5
Joined: Fri Sep 22, 2017 7:06 pm

Re: Handbrake QSV uses 70% iGPU and 100% CPU

Post by 2mg »

s55 wrote: Sun Sep 24, 2017 9:37 am The QuickSync implementation in HandBrake isn't designed to be a pure ASIC approach. It's designed to take advantage of the HandBrake pipeline and all it's features.

What your seeing is about right and not something you can do anything about by adjusting settings more.
Thanks. Last question, and I'm seeing these on GitHub, it's "Error code -17, hb_qsv_wait_on_sync 602", transcode simply stops about midway in process. It's either my driver and/or broken MKV frame right? Same file went thru with software 264 encode. It's another file, not in any logs I linked here, but I have logs looking same as on GitHub for that problem.
Post Reply