I am wondering if I get a better graphics card could it speed up h264 encoding on my machine using handbrake?

If so how can I tell what graphics card will support this?

I am aware that the GPU can do hardware decoding of h264, but am not sure about encoding.

  • Related: Accelerated Video Compression – in any way, you want to have an NVIDIA card for this and be willing to spend money. – slhck Oct 3 '11 at 21:01
  • Another related blog post: Encode Your Videos Using Your GPU – slhck Oct 3 '11 at 21:18
  • For h.264 encoding, handbrake uses software encoder x264 (videolan). Some answers below imply handbrake uses ffmpeg, which can use x264 or hw (GPU) implementations. Although this old (but still relevant) question probably is not asking "how to make handbrake faster", but rather "how to make h.264 encoding faster". Answers will have a shelf-life (some are already expired); but for now, if doing ML and/or batch processing you may have to match an implementation to your hardware – michael Jan 4 '18 at 4:49
  • fwiw, I found this comment from ffmeg interesting: "Hardware encoders typically generate output of significantly lower quality than good software encoders like x264, but are generally faster and do not use much CPU resource. (That is, they require a higher bitrate to make output with the same perceptual quality, or they make output with a lower perceptual quality at the same bitrate.) " – michael Jan 4 '18 at 4:53

Using Handbrake the answer would be no. Handbrake is a CPU-only h.264 encoder, though it now is able to use OpenCL for video scaling and has some support for DXVA for video decoding.

The question linked by slhck mentions MediaCoder, but it requires either an Nvidia graphics card or an Intel CPU with a 2nd generation graphics core.

There are a couple of older products that have been obsoleted, specifically Badaboom and the ATi Avivo software.

Badaboom which could use Nvidia and Intel graphics processors to speed up the encoding process but it is now end-of-life and does not support newer graphics cards.

ATi had their own video encoder that used to be called "Avivo" before being merged into the AMD Codec Package which included the AMD Video Converter though it is no longer available.

  • So I am using an AMD CPU at the moment, does that mean this is a waste of time for me? Can it be any NVIDIA card - oh so it has to support CUDA? – peter Oct 3 '11 at 21:09
  • I found this link, en.wikipedia.org/wiki/CUDA which suggests that quite a lot of NVIDIA cards support CUDA. – peter Oct 3 '11 at 21:12
  • I've updated my answer with a link to the AMD software package that may help you use the GPU to encode video, but it requires a HD2000 series card or better. If you have a particularly powerful CPU but a budget graphics card then Handbrake may still be faster. – Mokubai Oct 3 '11 at 21:50
  • Badaboom is being end-of-lifed as of 4/18/2012. – Hans Van Slooten Jun 16 '12 at 12:06
  • 2
    The answer above is not/no-longer correct. – totaam Sep 4 '13 at 10:04

x264 now supports OpenCL encoding acceleration. How much acceleration you get will depend on your graphics card's performance, on my GTS 450 I get none and with slower cards it actually slows down encoding. Better cards may help. All you need to do is add --opencl to the x264 command line. I believe handbrake makes use of the same x264 libraries and does offer the same OpenCL acceleration in newer builds.

  • How should I use OpenCL encoding acceleration? – Dr.jacky Dec 9 '15 at 11:36


FFmpeg provides a subsystem for hardware acceleration.

Hardware acceleration allows to use specific devices (usually graphical card > or other specific devices) to perform multimedia processing. This allows to use dedicated hardware to perform demanding computation while freeing the CPU from such computations. Typically hardware acceleration enables specific hardware devices (usually the GPU) to perform operations related to decoding and encoding video streams, or filtering video.

When using FFmpeg the tool, HW-assisted decoding is enabled using through the -hwaccel option, which enables a specific decoder. Each decoder may have specific limitations (for example an H.264 decoder may only support baseline profile). HW-assisted encoding is enabled through the use of a specific encoder (for example nvenc_h264). Filtering HW-assisted processing is only supported in a few filters, and in that case you enable the OpenCL code through a filter option.

There are several hardware acceleration standards API, some of which are supported to some extent by FFmpeg.

"-hwaccel auto" option allows you to select the hardware-based accelerated decoding to use for the encode session. You can add this param with "auto" before input (if your x264 is compiled with OpenCL support you can try to add -x264opts param), for example:

ffmpeg -hwaccel auto -i input -vcodec libx264 -x264opts opencl output

Sorry, but I can't remember how to list all available options for "-hwaccel".

Also you can try this: https://wiki.archlinux.org/index.php/Hardware_video_acceleration

  • It doesn't appear this specifically answers the question, though it appears useful. How about you add some details that show how ffmpeg and it's arguments can help the OP. – music2myear Nov 20 '16 at 4:31
  • This answer implies using ffmpeg instead of handbrake for h.264 encoding, which is probably fine, as the question is probably just asking for the fastest way to encode -- and presumes GPU would enable this. Note that not all GPUs are equally powerful (eg integrated GPUs vs dedicated), and CPUs also have optimizations that libraries may utilize if the library is compiled to support it. So "hardware acceleration" is the right path to go down, whether it be via CPU or GPU. – michael Jan 4 '18 at 3:01

At the present, Handbrake supports the following hardware-accelerated encoders for H.264/AVC:

  1. Intel QuickSync (on Windows and on Linux). This is compatible with at least Intel-based Sandybridge (2nd generation Core) - series processor lines with integrated graphics enabled and exposed to the operating system. Recommended hardware for acceptable encoding quality: Haswell (4th generation Core-series) and beyond, which introduced the concept of fine-grained target levels (TUs), lookahead functions (such as LA-BRC and ICQ encoding modes) with significantly better performance. See usage guide from handbrake documentation here.

  2. NVIDIA's NVENC: This requires at least NVIDIA's Kepler (GK+) series GPUs and above from the high performance consumer SKUs (GTX-series) and the professional lineups (Quadro and Tesla GPUs based on Kepler and beyond). This is available on both Windows and Linux.

Of note is that with NVENC, you'll be artificially limited to at most two simultaneous encode sessions on the consumer SKUs, whereas the professional lineup remains unaffected by this. For your reference on specific encoder capabilities, refer to the GPU matrix. For best encoder performance and quality, stick to the latest iteration of Pascal and Volta GPUs.


  1. AMD AMF's encoding support is also available in the current nightly builds for Windows ONLY. A special note about AMD's AMF (that taps into the VCE encoder built into the hardware in all GCN+ SKUs) is that on newer hardware, such as Polaris (RX 400+ series) and Vega, some advanced encoder tunings for H.264/AVC were deprecated as they introduced HEVC encoding support. What AMD dropped was B-frame encoding, with no support for adaptive quantization (AQ), a feature that the aforementioned hardware-based encoders (QuickSync and NVENC) have implemented for generations with no regressions. Also, see this on notes concerning throughput metrics on what to expect.

As far as Apple's support is concerned, this is at best, tentative. The VideoToolBox API, where implemented beyond the scope of Handbrake, also seems to have a very limited set of controls. Even if Handbrake adopts it upstream, don't expect miracles in terms of quality retention and throughput.

Note that you may require to use the latest nightly build to use the latest encoder features on your platform, as at the present. This will definitely change in the future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.