HandBrake GPU Not Used During Encode: How to Fix It

You start an encode in HandBrake expecting GPU acceleration, but Task Manager shows little GPU activity while CPU usage climbs. In some cases, the selected hardware encoder is unavailable, HandBrake falls back to a software encoder, or the monitoring tool displays the wrong GPU engine. In others, hardware encoding is working correctly while decoding, filters, audio processing, or subtitle rendering continue to use the CPU.

The key distinction is that GPU encoding, hardware-assisted decoding, and video filtering are separate operations. HandBrake is not a general-purpose GPU renderer that automatically moves the entire conversion pipeline onto a graphics card. This guide shows how to confirm what is actually happening, select the correct encoder, interpret GPU monitoring tools, and use HandBrake's Activity Log to identify the specific cause.

1. Confirm the Symptom With a Small Test Encode

Before changing drivers or reinstalling HandBrake, reproduce the problem with a short, controlled test. A small test is faster, reduces variables, and makes it easier to compare a hardware encoder against a software encoder.

1.1 Create a short test

Open a source that HandBrake can scan normally, such as a phone video, camera clip, screen recording, or unprotected disc source you have the right to convert. Use the Range controls to encode approximately 30 to 60 seconds rather than the entire video.

Select a simple preset close to the source resolution. Avoid resizing, denoising, sharpening, deinterlacing, burned subtitles, and other optional processing during this first test. Choose one audio track and, if possible, use a straightforward audio configuration.

Run the test and record three observations:

• The exact video encoder selected on HandBrake's Video tab
• The encoding speed shown in frames per second
• The encoder information reported in the Activity Log

Repeat the same short range with x264 selected. The purpose is not to prove that hardware encoding always wins. It is to determine whether HandBrake can initialize and use the hardware encoder and whether its performance differs from software encoding on the same source.

1.2 Understand what successful GPU use looks like

A successful hardware encode generally has all of the following characteristics:

• A hardware encoder such as NVENC, Intel Quick Sync, AMD VCN, or Apple VideoToolbox is explicitly selected
• The Activity Log identifies that hardware encoder rather than x264 or x265
• The operating system reports activity on a video encode engine when that metric is available
• The output file finishes successfully and plays correctly

GPU utilization does not need to reach 100 percent. A video encoder is a specialized fixed-function block, and it may complete its work without heavily loading the GPU's 3D cores. CPU usage also does not need to fall to zero because HandBrake still performs demuxing, audio work, synchronization, filters, subtitle handling, and other tasks.

If the Activity Log confirms the requested hardware encoder and the output is correct, stop changing settings merely to make an overall GPU percentage increase. The encoder log is stronger evidence than a single utilization number.

2. Check the HandBrake Settings Directly Related to This Problem

2.1 Choose a hardware video encoder explicitly

Selecting a preset does not always mean that a hardware encoder is active. Open the Video tab and inspect the Video Encoder menu. Depending on the operating system, graphics hardware, drivers, source, and output format, the available choices may include encoders labeled with terms such as NVENC, QSV, VCN, or VideoToolbox.

By contrast, x264 and x265 are software encoders and primarily use the CPU. If x264 is selected, high CPU usage and little video encode activity on the GPU are expected. This is not a HandBrake failure.

Choose an encoder whose name clearly identifies the supported hardware path on your computer. Start with H.264 hardware encoding if you are unsure because it is widely supported by playback devices. HEVC, 10-bit, AV1, and advanced profile combinations require more specific hardware support.

Success means the hardware encoder remains selected, the encode starts without an initialization error, and the Activity Log names the expected encoder. If that happens, do not keep switching codecs unless you have a compatibility or quality reason.

2.2 Do not confuse presets with encoder selection

A preset is a collection of settings. Some presets use software encoders, while hardware-oriented presets are designed around a supported hardware encoder. Loading a hardware preset is a useful test because it replaces combinations that may be incompatible or unnecessarily demanding.

For troubleshooting, load an appropriate hardware preset, select a short range, and avoid modifying its video options. If the preset works but your custom configuration fails, the GPU and driver are probably functional. Compare the Video, Dimensions, Filters, Audio, and Subtitles tabs to find the setting that introduced the problem.

2.3 Verify the container and codec combination

The output container, such as MP4, MKV, or WebM, must support the selected codec and the features you enabled. HandBrake usually limits incompatible choices in its interface, but imported presets and unusual combinations can still complicate testing.

Use a standard MP4 or MKV output with H.264 hardware encoding for the initial test. Once that succeeds, add HEVC, higher bit depth, additional tracks, or other features one at a time. Stop when the required final configuration works reliably.

2.4 Check quality and frame-rate settings

Hardware encoders expose different quality controls from x264 and x265. Do not assume that the same numeric quality value produces equivalent results across different encoder families. Begin with the hardware preset's default quality setting rather than copying a software encoder value.

Use the same frame rate as the source during diagnosis and avoid unnecessary frame-rate conversion. A conversion that duplicates, drops, or blends frames can add CPU-side processing and obscure whether encoding itself is the bottleneck.

3. Check the Factors Around the Encoder

3.1 Read the correct Windows Task Manager graph

Windows Task Manager can display separate GPU engines, including 3D, Copy, Video Decode, and Video Encode. The default graph may show 3D activity even while a fixed-function video encoder is busy.

Open Task Manager, select Performance, choose the relevant GPU, and change one graph to Video Encode. If the source is being decoded in hardware, another graph may show Video Decode activity. Integrated and discrete GPUs can also appear as different numbered devices, so inspect each installed GPU.

Low 3D usage is not evidence that HandBrake is ignoring the GPU. Success is activity on the correct Video Encode graph combined with confirmation in the Activity Log. Some drivers and operating-system combinations may report engine activity imperfectly, so the log remains important.

3.2 Separate encoding from decoding

Hardware encoding compresses processed frames into the output video. Hardware decoding reads compressed frames from the source. These are independent capabilities. A GPU may support encoding the output codec while being unable to decode the source codec, profile, bit depth, chroma format, or resolution in hardware.

For example, a supported H.264 hardware encoder does not guarantee hardware decoding for every HEVC, AV1, 10-bit, 4:2:2, or camera-specific source. In that situation, CPU usage can remain substantial because the CPU is decoding frames before sending them to the hardware encoder.

This can still be a successful hardware encode. If the Activity Log names the hardware encoder and the encode completes normally, high CPU usage may reflect software decoding rather than an encoder failure.

3.3 Disable CPU-heavy filters for the test

Filters can become the slowest stage in the pipeline. Denoising, deinterlacing, decomb, sharpening, color processing, cropping, scaling, and frame-rate conversion may require CPU work depending on the filter and platform. Burned subtitles also require frames to be composited before encoding.

Open the Filters tab and turn optional filters off for a temporary test. Use the source resolution, avoid upscaling, and set subtitles to none. If performance improves while the hardware encoder remains the same, the encoder was not the original bottleneck.

Re-enable only the processing the video needs. Interlaced material may genuinely require deinterlacing, and noisy footage may benefit from denoising. The goal is not to eliminate necessary processing but to recognize that hardware encoding cannot make every earlier stage run on the GPU.

3.4 Verify driver and hardware support

The hardware encoder must exist on the processor or graphics card, be exposed by a compatible driver, and support the requested codec configuration. Update the graphics driver from Intel, NVIDIA, AMD, Apple, your Linux distribution, or the computer manufacturer as appropriate.

On laptops with switchable graphics, the integrated GPU may contain a usable media engine even when a discrete GPU handles display or 3D applications. Conversely, forcing HandBrake onto the high-performance GPU does not guarantee that a particular encoding path becomes available.

After a driver update, restart the computer and reopen HandBrake. Check whether the expected hardware encoder appears in the Video Encoder menu. Success means it appears, initializes during a short test, and is identified in the log. If it never appears, verify the GPU model's official encode support rather than repeatedly changing HandBrake presets.

3.5 Account for source, audio, subtitle, and storage limits

A difficult source can prevent the encoder from receiving frames quickly enough. Damaged timestamps, variable frame rate, unusual color formats, high-resolution camera media, or complex disc structures can increase processing time. Test a known-good local video to distinguish a source-specific problem from a system-wide problem.

Audio encoding also uses CPU resources. Multiple audio tracks, high-quality audio conversion, channel remixing, and sample-rate conversion add work. Keep one audio track during the clean test. If suitable for the output container and your playback devices, audio passthrough can remove audio re-encoding from the test, but it should only be used when compatibility is understood.

Subtitle scanning and burning can delay or limit processing. Disable subtitles temporarily. Later, prefer a selectable subtitle track when the source, container, and playback device support it. Burned subtitles are rendered into every video frame and therefore become part of the video-processing pipeline.

Slow network storage, external drives, nearly full disks, antivirus scanning, and insufficient temporary space can also limit throughput. Encode from a local source to a local destination for diagnosis. Success means storage activity is stable and the short test completes without pauses or write errors.

4. Use the Activity Log to Separate Guesswork From Evidence

The Activity Log is the most useful HandBrake troubleshooting tool because it records the scan, selected settings, encoder initialization, filters, tracks, warnings, and completion status. Open it immediately after running the short test and save the complete log before starting another job.

4.1 Find the encoder information

Search the log for the video encoder name and the final job configuration. If you intended to use NVIDIA hardware encoding, look for NVENC-related encoder information. For Intel hardware encoding, look for Quick Sync or QSV references. AMD and Apple hardware paths should likewise be identified by their corresponding encoder names.

If the log identifies x264 or x265, HandBrake performed software encoding. Return to the Video tab, choose the intended hardware encoder, and start a new test. If the requested hardware encoder is selected but fails to initialize, inspect the nearby error lines for an unsupported profile, level, bit depth, resolution, driver, or device problem.

Do not focus on one isolated line. Read the job settings and the surrounding messages because a log can contain capability checks that are not the same as the encoder ultimately used for the output.

4.2 Look for filters and fallback explanations

The log can show whether scaling, cropping, deinterlacing, subtitle rendering, or other filters were added to the pipeline. It also reports source properties such as codec, frame size, frame rate, and track layout. These details explain why CPU activity may remain high even when hardware encoding is active.

When seeking help, share the complete log after removing personal file paths if necessary. A screenshot of Task Manager without the log rarely reveals which encoder HandBrake selected or why initialization failed.

4.3 Know when the evidence is sufficient

Stop troubleshooting GPU usage when the log confirms the intended hardware encoder, the test finishes without relevant errors, the output plays on the target device, and performance is acceptable. A low overall GPU percentage or high CPU percentage does not override those results.

5. Run a Clean Temporary Encode With Minimal Settings

If the cause is still unclear, create a clean job designed to isolate the video encoder. This is more reliable than changing several options in an existing custom preset.

1. Restart HandBrake and open a known-good local video file
2. Load a standard hardware preset appropriate for the available GPU
3. Choose H.264 in the corresponding hardware encoder family
4. Set a 30 to 60 second range
5. Keep the source resolution and frame rate
6. Disable optional filters and subtitles
7. Include one simple audio track
8. Save the output to a local drive
9. Start the encode and inspect the Activity Log
10. Repeat with x264 while keeping other settings as similar as practical

If the hardware test succeeds and the log names the expected encoder, add your required settings back one at a time. Test after enabling resizing, filters, subtitles, extra audio tracks, HEVC, 10-bit output, or a different container. The first change that causes failure or a large slowdown identifies the area to investigate.

If the hardware encoder fails even with the clean test, check hardware support and reinstall or update the graphics driver. If it remains absent after confirming that the GPU model supports the desired codec, consult HandBrake's platform documentation and provide the complete Activity Log when requesting support.

6. Quick Fix Checklist

• Select NVENC, QSV, VCN, or VideoToolbox instead of x264 or x265
• Use a hardware preset for the first controlled test
• Monitor the Video Encode engine, not only the 3D graph
• Check every GPU listed in Task Manager on multi-GPU systems
• Confirm the actual encoder in HandBrake's Activity Log
• Test H.264 before more demanding codecs and bit depths
• Disable denoising, deinterlacing, scaling, and sharpening temporarily
• Remove burned subtitles during diagnosis
• Use one audio track and a known-good local source
• Encode to a local drive with sufficient free space
• Install an appropriate current graphics driver and restart
• Verify official codec support for the exact GPU model

Once the log confirms hardware encoding and the output meets your speed, quality, and compatibility requirements, stop adjusting settings. Higher utilization is not automatically better, and an encode can be correctly accelerated without saturating the entire GPU.

7. Frequently Asked Questions

7.1 Why is HandBrake using 100 percent CPU and almost no GPU?

The most common reason is that x264 or x265 software encoding is selected. Another possibility is that hardware encoding is active but decoding, filtering, subtitle burning, scaling, or audio processing is keeping the CPU busy. Check the selected video encoder and confirm it in the Activity Log.

7.2 Why does Task Manager show zero percent on the 3D graph?

Video encoding generally uses a specialized media engine rather than the 3D engine. Change a Task Manager graph to Video Encode and inspect the correct GPU. The 3D graph can remain nearly idle during a valid hardware encode.

7.3 Does hardware encoding mean the entire HandBrake job runs on the GPU?

No. Hardware encoding only accelerates the compression stage supported by that encoder. Source decoding may use the CPU, and many filters, subtitle operations, audio encoders, and container tasks can remain CPU-based. Hardware decoding is a separate capability and has its own codec, profile, and bit-depth limitations.

7.4 Why is hardware encoding not faster than x264 on my file?

The encode may be limited by software decoding, filters, subtitle rendering, storage, or another stage that cannot supply frames fast enough. Very short clips also include startup overhead that can distort comparisons. Run a clean test without filters and compare the logs as well as the average encoding speed.

7.5 Is GPU encoding always better than software encoding?

No. Hardware encoding is often attractive for speed, responsiveness, batch conversion, and live workflows. Software encoders such as x264 and x265 can provide better compression efficiency or more detailed tuning at a given file size, although results depend on the content and settings.

If maximum quality per bit or the smallest practical file is the priority, test a software encode. If speed is the priority and the hardware output looks good on the intended display, hardware encoding may be the better choice. Compare short samples at realistic settings rather than assuming one encoder is universally superior.

7.6 What should I do if the hardware encoder is missing from the menu?

Confirm that the exact GPU or processor supports hardware encoding for the desired codec. Then install the appropriate graphics driver, restart the system, and check again. On Linux, ensure the required driver and device permissions are present. On macOS, available VideoToolbox options depend on the Mac hardware and operating system.

If the encoder remains missing, save an Activity Log from a scan or software test and compare the detected hardware with official support information. Reinstalling HandBrake repeatedly will not add an encoding engine that the hardware or driver does not expose.