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
Handbrake QSV uses 70% iGPU and 100% CPU
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.
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.
Re: Handbrake QSV uses 70% iGPU and 100% CPU
Nope.Unless I understand it wrong, the iGPU should do all the work.
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.
Re: Handbrake QSV uses 70% iGPU and 100% CPU
Thanks for a quick an thorough reply!
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).Your source is H.265 and your encoding to H.264. Your CPU doesn't have a H.265 Decoder
I didn't even notice Decomb is on (in every preset)...you have software filters enabled and running
So which mp4 audio codec wouldn't take a lot of CPU cycles?the audio encoding is not supported by QuickSync
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?you have the HandBrake engine keeping everything humming along
The 70% iGPU and 100% CPU combination threw me off completely.While you can achieve quite low CPU usage
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.
Re: Handbrake QSV uses 70% iGPU and 100% CPU
All input has to be decoded before re-encoding. You can see the map of support for decode vs encode in QuickSync here: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).
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.
Audio in General isn't overly CPU intensive. Filters and Decode are both fairly significant.So which mp4 audio codec wouldn't take a lot of CPU cycles?
HandBrake unlike many many apps out there, is not a Command Line front-end to other encodes.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?
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.
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.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.
Re: Handbrake QSV uses 70% iGPU and 100% CPU
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.
Re: Handbrake QSV uses 70% iGPU and 100% CPU
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.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
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.
Re: Handbrake QSV uses 70% iGPU and 100% CPU
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.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.