FFmpeg GPU transcoding for your video library, without tying up the processor

What changes when the card does the encoding?

Your processor stops being the bottleneck. An NVIDIA graphics card has dedicated video hardware: NVDEC reads the source and NVENC writes the new file, and FFmpeg's wiki says hardware encoders do not use much CPU.

What you give up is efficiency. The FFmpeg wiki says hardware encoders typically give significantly lower quality than x264 or another good software encoder when both get the same bitrate, so you either accept that or spend more bitrate. For a streaming catalogue where every title needs four or five sizes, that is normally a good deal. For a master copy you plan to keep for a decade, use the software encoder and take the time.

Will your card have an encoder, and how many jobs at once?

Check NVIDIA's encode/decode support matrix before you choose. These are the figures it gave on 22 October 2026 for the cards we fit; the right-hand column is NVIDIA's own figure for the most encodes a card will run at the same moment.

The A100 and H100 are built for AI and have no NVENC at all: h264_nvenc will not run on them, so every encode would have to be done in software on the processor. Leave them to model work.

Two numbers matter. The number of encoders decides how quickly each file finishes. The session figure decides how many outputs can be open together, and every resolution you write counts as one. Twelve is plenty for a queue of a few files at a time, each in two or three sizes. If you plan to write dozens of outputs at once, the P5000, Tesla P4 and T4, L4 and L40S have no such ceiling.

Getting the first file through the card

1. Install your Linux release and the NVIDIA driver. Your own system talks to the card directly, so you decide the driver version and keep it as long as you like.
2. Ask FFmpeg what it was built with. If h264_nvenc is not in the list, your distribution's package lacks it, and NVIDIA's guide shows how to build FFmpeg from source with nv-codec-headers.
3. Make sure your driver is at least the one the Video Codec SDK in your FFmpeg build asks for; NVIDIA's guide tells you to check this first.
4. Convert one real file and watch it play before you automate anything.

ffmpeg -hide_banner -hwaccels           # should list cuda
ffmpeg -hide_banner -encoders | grep nvenc

# HEVC at constant quality, everything on the card, original audio kept
ffmpeg -n -hwaccel cuda -hwaccel_output_format cuda -i film.mkv -sn \
  -c:v hevc_nvenc -preset p7 -tune hq -rc vbr -cq 26 -b:v 0 \
  -spatial-aq 1 -rc-lookahead 20 -c:a copy film-hevc.mkv

# 720p copy, resized on the card
ffmpeg -n -hwaccel cuda -hwaccel_output_format cuda -i film.mkv \
  -sn -vf scale_cuda=1280:720:format=yuv420p -c:v h264_nvenc -preset p5 -b:v 3M -c:a copy film-720.mp4

-cq asks NVENC for a steady quality instead of a fixed bitrate, which suits files people download or stream later; FFmpeg documents 0 to 51 for H.264 and HEVC. p7 is the slowest, best-looking preset and p1 the fastest. -n means FFmpeg never overwrites something already there. -sn drops subtitle tracks, since picture-based subtitles cannot go into an MP4, and format=yuv420p turns a 10-bit source into the 8-bit pictures h264_nvenc needs.

No graphics card? Intel Quick Sync can do it

Some Intel processors carry their own video encoder in the graphics on the chip. On our side that is the Xeon E-2286M, Xeon E3-1585L v5, Xeon E3-1284L v4 and Xeon E3-1284L v3, and no other processor on our Intel servers page. They do not all write the same formats. The machines that take a graphics card are a different family, so pick the route first and the server second.

On our side that means the E3-1585L v5 (Skylake, 8-bit HEVC) and the E-2286M (Coffee Lake, 8- and 10-bit HEVC) can write HEVC, while the E3-1284L v3 and v4 encode H.264 only. For the v4, v5 and E-2286M, install Intel's media driver as the full-feature package in the code below; Intel's table shows some older chips can only encode with that one. The E3-1284L v3 has Haswell graphics, which Intel's iHD driver does not cover; there you install the older i965 driver, package i965-va-driver, and stay with VAAPI and H.264.

sudo apt install intel-media-va-driver-non-free   # on the E3-1284L v3: i965-va-driver

# H.264 at a constant quality through Quick Sync (source must be H.264 here)
ffmpeg -n -hwaccel qsv -c:v h264_qsv -i lesson.mp4 \
  -c:v h264_qsv -global_quality 23 -look_ahead 1 -c:a copy lesson-qsv.mp4

# the same chip through VAAPI, at a set bitrate
ffmpeg -n -vaapi_device /dev/dri/renderD128 -i lesson.mp4 \
  -sn -vf 'format=nv12,hwupload' -c:v h264_vaapi -b:v 4M -c:a copy lesson-vaapi.mp4

The wiki warns that lookahead is not supported on some Quick Sync platforms; if the first command complains, drop -look_ahead 1. The VAAPI route has no lookahead, and its quality modes (CQP, ICQ, QVBR via -rc_mode) depend on the driver and chip, so the simplest portable choice is a bitrate.

Turning a folder into a queue

One FFmpeg at a time leaves the encoder half idle. NVIDIA's guide explains that each process spends time starting up, and that running several in parallel hides that cost; its example measures four. This script works through a folder three files at a time and can be stopped and started again safely.

#!/usr/bin/env bash
# convert every .mkv in ~/library/in to 720p H.264, three at a time
set -u
convert() {
  src="${1}"; dst="$HOME/library/out/$(basename "${src%.*}").mp4"
  [ -e "$dst" ] && return 0
  ffmpeg -nostdin -loglevel error -y -hwaccel cuda -hwaccel_output_format cuda \
    -i "$src" -sn -vf scale_cuda=1280:720:format=yuv420p -c:v h264_nvenc -preset p5 -b:v 3M \
    -c:a aac -b:a 128k "$dst.tmp.mp4" && mv "$dst.tmp.mp4" "$dst"
}
export -f convert
find "$HOME/library/in" -maxdepth 1 -name '*.mkv' -print0 | xargs -0 -n 1 -P 3 bash -c 'convert "${1}"' _

• A finished file only gets its real name once FFmpeg exits cleanly, so a reboot halfway through never leaves a broken file that the next run would skip.
• Three jobs with one output each is three sessions; stay at twelve or fewer on a GeForce card.
• Schedule it with cron or a systemd timer for new arrivals, wrapped in a lock so two runs never overlap: flock -n /tmp/convert.lock ./convert.sh. -nostdin keeps FFmpeg from waiting on a keyboard that is not there.

The server that fits

A long conversion run needs three things from a server: the encoder to itself, room for the files, and a network connection that does not charge by the gigabyte. Our GPU servers give you the whole card in a physical machine rented to you alone. There is no slice of a card, no time-sharing, and no other customer's job slowing yours down at four in the afternoon. You get all of the processor, memory and storage, root access, plus the iLO or iDRAC console built into the server, so if a driver update takes the network down you can still see the screen.

Nothing meters the port, so bringing a library in and pushing renditions out to a CDN never shows up on the invoice. The card is a separate line from the machine, so switching the GeForce for an L4 changes a single line. If a machine already carries the card you want, you are up in about 30 minutes once your order is approved; fitting a card we hold takes 4 to 24 hours, one we have to buy in takes 5 to 10 working days, and a current-generation accelerator on allocation 10 to 15 working days. No contract: one month is the default term.

When another route serves you better

• Converting live channels as they air is a different job, handled on our live video transcoding servers with a streaming engine.
• Watching your own films at home? Jellyfin converts on the fly when someone presses play.
• Teaching with video? Course video hosting may not need a graphics card at all.
• Sending a live show from OBS to your site starts with an nginx RTMP server, not a file queue.

Questions people ask

Why is my FFmpeg still using the CPU?

Usually because only half the job moved. You need a hardware decoder option such as -hwaccel cuda and a hardware encoder such as -c:v h264_nvenc; with only one of them, the other half still runs on the processor. Ordinary filters cannot work on pictures held on the card either, so resize with scale_cuda rather than scale.

Will viewers notice the quality drop?

That depends on the bitrate you give it. At the same bitrate as a careful x264 encode, FFmpeg's wiki says a hardware encoder typically gives significantly lower quality, so plan on more bitrate. NVENC's slow presets, lookahead and adaptive quantisation narrow the gap. Encode a test clip both ways and compare before you convert everything.

Do I need a data-centre card, or will a GeForce do?

For a queue working through a few files at a time, a GeForce card is fine: NVIDIA lists 12 concurrent sessions for the ones in our table. You need a P5000, Tesla, L4 or L40S when you want many outputs open at once, since NVIDIA lists those as Unrestricted (the A100 and H100 cannot encode at all). AV1 output also narrows the choice to the newer cards.

Can one server use Quick Sync and a graphics card together?

Not with our machines. The Intel processors with Quick Sync and the servers that take a graphics card are separate lines. Choose Quick Sync for a modest H.264 queue without a card (or HEVC on the E3-1585L v5 or E-2286M), and a GPU server when throughput or AV1 matters.