I don’t know exactly when HandBrake added the capability of using the GPU for encoding, but it was somewhere between 1.3.1 (current version in the Ubuntu repositories) and 1.3.3 (current version on PPA). Regardless, this option offers dramatic speed improvements, particularly when working with 4K videos. In this post, I’ll show how to use this feature in Handbrake and show some comparisons to illustrate the benefits and tradeoffs that result.

HandBrake 1.3.1 is the current option in the Ubuntu 20.04 repositories.
Version of HandBrake available from the PPA that has NVENC/GPU encoding capabilities.

How to Use NVENC GPU Encoding

First, make sure you have the latest version of Handbrake installed (as of 6/26/2020 that is version 1.3.3). Also, to use Nvenc encoding, you’ll need the Nvidia Graphics Driver 418.81 or later and an Nvidia GeForce GTX 1050+ series GPU or better per HandBrake’s documentation. I’m using a GTX 1060 and have Driver version 440.100 installed. My CPU is an AMD Ryzen 5 3600 6-Core, 12-Thread processor.

My GPU (GeForce GTX 1060) and my driver version: 440.100.

The video I’m using to illustrate how to use GPU encoding is a Blu-Ray rip of Pan’s Labyrinth. I’m making a backup copy of the video to store on my file server. I used MakeMKV to pull the video off the BluRay disc, resulting in a 31.7GB file. I’m going to convert that to a 1080p H265 video file that is substantially smaller in size.

Open up HandBrake and load your file you want to convert by clicking on “Open Source.” Find the file you want to convert and select “Open.”

HandBrake will run through the file, gathering information about the codec, subtitles, audio tracks, etc. Once it’s done, you’ll need to select what format you want to convert it to. For this tutorial, I’m just going to use a General Preset, but I want to illustrate the difference in encoding speed, so I’m going to select Super HQ 1080p30 Surround rather than Fast 1080p30.

My mouse is on Super HQ 480p 30 in the image, but I selected Super HQ 1080p.

To change from CPU encoding to GPU encoding, click on the Video tab:

In the middle of the screen, you’ll see a drop-down menu labeled “Video Encoder.” Click on that drop-down menu and you should see two NVENC options: H.264 (NVenc) and H.265 (NVenc). Those are the two options for using your GPU for the encoding versus using your CPU. The H.265 codec is newer and has somewhat better compression algorithms, but I’m not going to opine as to which of these you should choose. That choice should really be driven by what device you’re going to be playing your videos on. Regardless of which you choose, those two will push the encoding to your GPU instead of your CPU.

Again, my mouse is on the wrong option here. The two options you want are: H.264 (NVenc) or H.265 (NVenc).

Make sure you’ve adjusted your Audio, Subtitles, and Tags to your preferences, then click “Start.” That’s all there is to it – you now have GPU encoding.

Benchmarks: Encoding Speed

Using the H.265 (NVenc) encoder, it took about 17 minutes to convert the 31.7GB MKV file into a 8.4GB m4v file.

My mouse is next to the estimated time for encoding the video: 16m50s.

You can also see that even using the H.265 (NVenc) encoder, much of the processing is passed to the CPU, as shown in this screenshot that shows my GPU is working, but it’s certainly not being stressed:

GPU load is on the left. CPU load is top right.

Using all the same options but CPU encoding instead, HandBrake took 1 hour and 15 minutes to encode the file, so about 5 times as long.

When I grabbed this screenshot, HandBrake was estimating 1h07m, but it ended up taking about 1h15m for the entire encode.

Here’s the same resource utilization illustration showing that HandBrake is drawing exclusively on the CPU and not the GPU:

GPU utilization is on the left; CPU utilization is upper right.

Other tests I ran encoding 4K video illustrated that this difference increases with 4K video. I converted one 4K movie that was about 1 hour, 40 minutes using H.265 (NVenc) and it took about 1 hour. Using the CPU alone, HandBrake estimated it would take 18 hours (I didn’t wait to see if that was accurate). Thus, there is a dramatic difference in encoding speed with higher resolution and larger video files.

Benchmarks: Video Size and Quality

What about file size and video quality? I’m probably not going to do justice the differences because I don’t have the most discerning eye for pixellation and resolution differences, but I will try to use some objective measures. The video encoded with the GPU was 8.39GB in size. The video encoded with the CPU was 3.55GB. I’m not exactly sure why the file sizes are so different given that I chose the same setting for both encodes, but this next screenshot illustrates that the NVENC encode resulted in a higher bitrate (9,419 kb/s) versus the CPU encode with a lower bitrate (3,453 kb/s). Strange.

On the left are the specs for the NVENC encoded video; the CPU encoded video specs are on the right.

I also wanted to see if I could tell if there was a noticeable difference in quality between the two videos. I navigated to the same scene in both videos and used VLC to take a screenshot. First, the NVENC encoded screenshot:

Click for full resolution. This is the NVENC encoded video.
Click for full resolution. This is the CPU encoded video.

My 43-year-old eyes don’t see much of a difference at all.


If you’ve got the hardware and want to save time, using GPU encoding with Handbrake is a nice option. The end result is a much faster encode, particularly with higher resolution videos. Some of the forums where I was reading about this option suggested there are problems with using GPU encoding. I certainly won’t challenge those assertions, but I can’t tell the difference.

 80,552 total views,  42 views today

11 Replies to “HandBrake – Convert Files with GPU/Nvenc Rather than CPU”

  1. Thanks man. Great post. No I’m not a bot, but algorithms sent me this link. I love how a gaming computer is what you now need to edit video. Personal computers have never been so versatile.

    Im glad Nvidia saw the bigger picture unlike AMD who is still targeting gaming only (mostly)

  2. Thanks for the write-up. I’m running Ubuntu and getting similar results to your own with a GTX 1650 Super (Turing). I was surprised to see the CPU is working at 80% while the GPU doesn’t appear to register much of any stress.

    Also, I noted the disparity between GPU and Video Engine usage displayed on the Nvidia panel. On the nvidia panel, GPU registers 7-10% utilization whereas the Video Engine is pegged. I haven’t found anything to support this, but I suspect the Video Engine represents the hardware Encode/Decode capabilities whereas GPU would be a measure of everything else (eg live gaming rendering).

    Handbrake also has different presets between the CPU (x265) and GPU (NVENC H.265) encoders. From this perspective, you can’t, really, make an apples to apples comparison for the quality to file size comparison. When I use average bitrate of 4000 rather than Constant Quality at RF 20, I get similar size and quality to CPU (x265) encoding. Of course, quality is a subjective term, but I believe this is where the Turing chipset shines over previous generations In terms of effectiveness (my current hypothesis at least).

  3. I’m running an AMD Ryzen 9 3560x (16-core CPU) and a Nvidia GeForce RTX 3080 Founder’s Edition, and my results are about the same (in terms of speed and file sizes with those options).

    I was hoping the 3080 GPU would compress better, but alas, the CPU does a much better job, albeit about 4 times longer in duration.

    Interestingly, there’s not a noticeable difference in compressed file size between NVENC h.264 and NVENC h.265. In fact, h.265 NVENC is usually slightly larger (i.e., ~505,000mb vs 515,000mb).

    When dealing with h.264, the NVENC compressed the files slightly smaller, but nothing to get excited about. Duration for transcoding was about the same. Since I have a beefy CPU, I may just let the CPU handle those in the future.

  4. I stumbled upon this post Today and quickly tried the settings recommended.
    I had several MKVs made with MakeMKV from Blurays. As an example I used the James Bond Casino Royale as a test file.
    The original MKV (straight from the Blyray) with English DTS-HD and French AC3 (5.1) has a size of 33Gb.

    Passed through the High Quality (custom preset based on https://www.thewebernets.com/2019/01/29/easiest-best-optimal-settings-for-handbrake-1080p-blu-ray-video-conversion-on-mac-windows-and-linux-new-january-2019/) i ended up with a file size of 10.3Gb in 3 hours and 15 minutes using my i7-8700 CPU @ 3.20Ghz. .

    Using my Nvidia GTX 1060 and the H.265 NVEnc (that pretty much the only thing I changed in my aforementioned setting) I ended up with a 10.4Gb file in 22 minutes.

    I put the two files on my Plex server and went to chapter 9 on my Toshiba Blyray reader and on my Amazon Fire Stick and switched the HDMI input on my Sharp Aquos (42 inch) and could not see the difference. I compared the CPU and GPU Encoded files against the Bluray disk and could not see any difference either.

    By the way I am also 43 years old 😉

  5. Yeah I tried this too and it’s really great if you want to save time, it halved the time for a bluray 1080 rip to mkv using the nvidia nvenc h265 with quality at 20, slow encode, ac3 passthrough audio, match source framerate, cq. When I watch on a 40″ 720p screen I can’t tell much difference from cpu h264 version with about the same file size. One small difference that I did notice is that in some high motion shots it does have some slight stutter when changing camera angles but this could be the older laptops old cpu/old amd gpu that I’m outputting from, I’ve heard that h265 is more cpu intensive. On newer equipment I didn’t notice this. Oh and same age too lol

  6. As mentioned above – you were looking at the load on CUDA cores (equivalent of Stream cores with AMD), but that’s not what does the job.

    NVIDIA and AMD GPUs contain one or more hardware-based decoder and encoder(s) (separate from the CUDA/Stream cores) which provides fully-accelerated hardware-based video decoding and encoding. It is not the big computational part of the GPU you looked at, but it is an ASIC part on the GPU designated only for de/en-coding. (You can see load on these eg. in the Task Manager)

    That is why even integrated GPU in AMD CPUs (when used h.264/265 AMD VCE) has almost the same encoding time as dedicated GPUs from AMD – it is virtually the same ASIC part of the chip. Btw., I haven’t done quality comparison, but encoding times with the same bitrates are very similar for AMD and NVidia, but I prefer AMD as it offers many more options for the output quality/way of encoding.

    About the preset – you cannot compare CPU to NVidia NVENC (or AMD VCE) the way you did as they have different quality settings (and scaling). If you want to compare, you should compare quality of outputs with the same bitrate.

  7. Hi – just read your article.
    Thank you for your efforts.
    Currently I’m in the same situation.

    Just as a hint: you are using nvtop to check GPU utilization. Go into config (F2) and configure it to display GPU encode. This is the graph you were looking for.


Leave a Reply to Chris Cancel reply

Your email address will not be published.