Somewhere in almost every video workflow there is a moment where someone says “just add -c:v h264_nvenc, it’s ten times faster.” They are usually right about the speed. Hardware video encoding is one of the largest single-flag speedups available in FFmpeg, and for live streaming it isn’t a convenience — it’s the only way the job finishes on time. But the flag does not conjure performance out of nowhere. It buys speed and power efficiency with a currency the tutorials rarely name: compression efficiency. At a matched bitrate, a well-tuned software encoder generally produces a better-looking picture. At a matched quality target, the hardware encode is a bigger file. Neither is “better.” They answer different questions, and knowing which question you’re asking is the whole skill.
This is a Create-pillar walkthrough of the trade: what the silicon is actually doing differently, why decode and encode are two separate switches that people constantly conflate, why the naive setup quietly throws away most of the speedup at a memory boundary, how much your specific GPU generation matters (a lot — more than which vendor you bought), and where the honest dividing line sits between “hardware is obviously right here” and “hardware is obviously wrong here.” Commands and behavior described here were checked against FFmpeg 8.1 “Hoare,” released 2026-03-16 (verified against ffmpeg.org on 2026-08-18).0.1 is the current point release as of 2026-08-12, from a branch cut from master on 2026-06-26, per FFmpeg’s own download page — and against the current vendor documentation, checked 2026-08-14. This area of the stack ages faster than any other part of FFmpeg; every vendor claim below carries the date it was verified for exactly that reason.
What the Silicon Is Actually Doing Differently
A video encoder’s job is a search problem. For every block of every frame it can choose among many possible predictions — look at a neighbouring block in the same frame, look at a block from a previous frame, look at a block from a future frame, try sixteen different motion vectors, try several different block partitionings — and each choice produces a different combination of “how many bits does this cost” and “how far off is the reconstruction.” A software encoder like x264 or x265 spends CPU time walking that search space, and its presets are the dial controlling how much of it to explore. (Worth stating precisely, because it’s the most common misreading: presets are a speed-versus-compression-efficiency dial, not a quality dial. At the same quality target a slower preset gives you a smaller file, not a prettier picture.)
A fixed-function hardware encoder is a dedicated block of silicon on the GPU die — physically separate from the shader cores that run games and machine-learning workloads — built to run a bounded, pipelined version of that search at a fixed cost per frame. It has a silicon budget, a clock, and a latency target, and it was designed to hit throughput and power numbers rather than to exhaustively explore rate-distortion space. That’s not a defect. It’s the design goal. A block of hardware that finishes a 4K frame in a predictable, tiny number of milliseconds while drawing a couple of watts is doing something a CPU fundamentally cannot, and it’s why your phone can record 4K video without becoming too hot to hold.
The consequence falls out directly: the hardware encoder is not searching as hard, so it needs more bits to reach the same perceptual result. That is the entire trade, and it’s worth being blunt about the number nobody should quote you: there is no single “hardware is X% worse” figure. How large the gap is depends on the encoder generation, the preset and tuning on both sides, the bitrate region you’re comparing in, the content itself (a static screen-capture behaves nothing like handheld sports footage), and which metric you asked. Anyone who hands you one percentage without those conditions attached is repeating marketing, not measurement. The defensible way to compare two encoders is a BD-rate curve — the average bitrate difference at equal quality across a range of operating points, not a single-point score — and any perceptual metric quoted alongside it has to say which model and which model version produced it. That’s a whole topic of its own, and this series treats it separately in a Measure-pillar piece on rate control and video-quality metrics.
| Software encoder (x264 / x265 / SVT-AV1) | Fixed-function hardware encoder (NVENC / QSV / VAAPI / AMF / VideoToolbox) | |
|---|---|---|
| Speed | Bounded by CPU cores and preset; slow presets can run well below real time | Typically many times faster; often many times real time even on modest hardware |
| Compression efficiency | Generally better at a matched bitrate, and the gap grows with slower presets | Generally needs more bits for the same perceptual result |
| File size at a matched quality target | Smaller | Larger |
| Power draw | High — pegs cores, heats laptops, throttles under sustained load | Low — a dedicated block sipping a few watts |
| CPU availability during the job | Consumed; the machine is busy | Largely free; the CPU can do other work |
| Concurrency | Limited by cores; each stream competes for the same pool | Limited by the encoder block and, on consumer cards, a vendor-imposed session cap |
| Tuning surface | Very large — dozens of meaningful knobs, deterministic output | Smaller and vendor-shaped; output can differ across driver versions |
| Reproducibility | Same build, same flags, same bits | Depends on GPU model, driver, and firmware |
Read that table as two columns of strengths, not a scoreboard. The first column wins on bits-per-pixel. The second wins on wall-clock time, watts, and how many streams you can run at once. Almost every real-world argument about hardware video encoding is two people optimizing different columns and assuming the other person is wrong.
Decode and Encode Are Two Separate Switches (and Two Separate Blocks of Silicon)
This is the single most common misconfiguration in the whole subject, and it’s worth slowing down for. On a modern GPU there is a hardware decoder block and a hardware encoder block. They are different silicon, they have different capability matrices, and in FFmpeg they are selected by two completely different mechanisms that do not imply each other.
Decode is selected with -hwaccel, and it is an input option. FFmpeg’s own documentation defines it exactly that plainly: -hwaccel[:stream_specifier] hwaccel (input,per-stream) — “Use hardware acceleration to decode the matching stream(s).” The accepted values include none, auto, vdpau, dxva2, d3d11va, vaapi, qsv, and videotoolbox, with NVIDIA’s CUDA path selected as -hwaccel cuda. Because it’s an input option it must appear before the -i it applies to. And FFmpeg attaches a caveat that deserves more attention than it gets: “Note that most acceleration methods are intended for playback and will not be faster than software decoding on modern CPUs.”
Encode is selected by naming a hardware encoder, which is an output option and looks like -c:v <codec>_<vendor>: h264_nvenc, hevc_nvenc, av1_nvenc, h264_qsv, hevc_qsv, av1_qsv, h264_vaapi, hevc_vaapi, h264_amf, hevc_amf, av1_amf, h264_videotoolbox, hevc_videotoolbox.
The two are freely mixable, and every one of these four combinations is a legitimate, supported configuration:
# Software decode → software encode (the CPU-only baseline)ffmpeg -i in.mp4 -c:v libx264 -preset slow -crf 20 out.mp4 # Hardware decode → software encode (underrated: cheap decode, best compression)ffmpeg -hwaccel cuda -i in.mp4 -c:v libx264 -preset slow -crf 20 out.mp4 # Software decode → hardware encode (common when the source codec has no hw decoder)ffmpeg -i in.mkv -c:v h264_nvenc -preset p6 -tune hq out.mp4 # Hardware decode → hardware encode, frames never leaving the GPU (the full-speed path)ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i in.mp4 -c:v h264_nvenc -preset p6 out.mp4The mistake to watch for runs in both directions. Someone adds -hwaccel cuda, sees the GPU light up in a monitoring tool, and believes they are hardware-encoding — they aren’t; the encode is still on the CPU and the job is still CPU-bound. Or someone sets -c:v h264_nvenc on a 4K HEVC source and wonders why the transcode is still slow — the encode is on the GPU, but every frame is being decoded in software first, and that is now the bottleneck. Diagnosing which half is actually limiting you is the difference between a fix and a superstition, and it’s the same profiling discipline that applies whenever a machine feels slower than its specifications suggest.
One naming point that matters and gets collapsed constantly: NVENC, Quick Sync, VAAPI, AMF, and VideoToolbox are not codecs. H.264, HEVC, and AV1 are standards; x264, x265, SVT-AV1, and libaom are software encoders that implement them; NVENC, QSV, VAAPI, AMF, and VideoToolbox are hardware paths that implement them. h264_nvenc and libx264 both emit legal H.264 that any H.264 decoder on earth will play. They just arrive at it by different amounts of searching.
GPU Residency: Where the Speedup Quietly Leaks Away
Here is the part that separates a real speedup from a disappointing one. -hwaccel cuda on its own decodes on the GPU — and then hands you frames in system memory, because that’s what the rest of a default FFmpeg pipeline expects. If your next step is a hardware encoder, those frames now have to be uploaded back across the PCIe bus to the GPU. You have paid a full round trip, per frame, for the privilege of using hardware on both ends.
The flag that fixes it is -hwaccel_output_format, and NVIDIA’s own FFmpeg documentation states its purpose in one sentence: “To automatically detect NV-accelerated video codec and keep video frames in GPU memory for transcoding, the ffmpeg cli option -hwaccel cuda -hwaccel_output_format cuda is used.” That second flag is what tells FFmpeg to leave decoded frames in device memory as hardware frame references instead of downloading them.
Keeping them there through the middle of the pipeline is the other half of the job, and it’s why NVIDIA’s documented example uses a GPU-resident scaler rather than the ordinary one:
ffmpeg -y -vsync 0 -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 \ -vf scale_cuda=1280:720 -c:a copy -c:v h264_nvenc -b:v 5M output.mp4scale_cuda (and its sibling scale_npp) resizes in hardware, on frames that never leave the device. Swap in the plain scale filter and FFmpeg has to insert a download, scale on the CPU, and upload again — the decode was still hardware, the encode was still hardware, and you have inserted two bus transfers and a CPU-bound stage into the middle. On an otherwise idle machine you may still come out ahead of a full software pipeline. On a machine running four of these at once, you will not.
The generalizable lesson here is bigger than FFmpeg, and it’s the reason this section is worth reading even if you never type an ffmpeg command: an accelerator’s speedup is only ever as good as its worst memory boundary. The same failure mode shows up in machine-learning inference pipelines that tokenize on the CPU between GPU stages, in physics simulations that read back intermediate state each step, and in every rendering pipeline that samples the framebuffer mid-frame. Profile the transfers, not just the compute. It’s also the practical reason GPU time is such a valuable, contended resource in the first place — the thing that makes markets for idle GPU capacity worth building at all.
Filters Are Where the Layers Collide
The residency problem has a sharp, specific edge case that catches people building anything more elaborate than a straight transcode: most FFmpeg filters are software filters, and a software filter cannot operate on a frame sitting in GPU memory. When you put one into a GPU-resident pipeline, FFmpeg does the only thing it can — it downloads the frame, runs the filter on the CPU, and uploads the result. Explicitly, that’s hwdownload and hwupload; implicitly, FFmpeg will often insert the equivalent for you and the pipeline will simply be slower than you expected with no error to explain it.
There are hardware filters, and they’re worth knowing by name because they’re the escape hatch: scale_cuda and scale_npp on the NVIDIA path, scale_vaapi, deinterlace_vaapi, tonemap_vaapi, procamp_vaapi on VAAPI, scale_qsv and vpp_qsv on Quick Sync, overlay_cuda for compositing without leaving the device. But they are a genuinely small subset of libavfilter’s several hundred filters, and each is vendor-specific — a filtergraph built around scale_cuda does not run on an Intel iGPU without being rewritten around scale_qsv.
This is a concrete instance of a motif that runs through this whole series: almost every confusion in the media stack is a layer being collapsed. Container versus codec. Library versus binary. Encoder versus standard. Here it’s memory domain versus filter graph — two layers people mentally merge, right up until a drawtext overlay silently halves their throughput. If you need a complex filtergraph, the honest planning assumption is that you are doing significant CPU work regardless of what the encoder says, and you should design the pipeline around which stages genuinely have a hardware equivalent rather than assuming the whole graph inherits the accelerator.
The Vendor Landscape: Five Stacks and One Abstraction
There are five hardware paths that matter in FFmpeg, and one of them is not a vendor at all — a distinction that causes real confusion because “VAAPI” gets discussed as though it were a competitor to NVENC rather than an interface that can sit in front of several vendors’ silicon.
| Stack | Whose | FFmpeg encoder names | Platform | Where it fits |
|---|---|---|---|---|
| NVENC / NVDEC | NVIDIA | h264_nvenc, hevc_nvenc, av1_nvenc | Windows, Linux (proprietary driver) | Discrete GPUs; the most documented path and the one with the clearest published capability matrix |
| Quick Sync (QSV) | Intel | h264_qsv, hevc_qsv, av1_qsv | Windows, Linux | Integrated graphics on Intel CPUs and Arc discrete cards; the reason a low-power NAS box can transcode several streams at once |
| AMF | AMD | h264_amf, hevc_amf, av1_amf | Windows and Linux | AMD Radeon GPUs and APUs |
| VAAPI | Not a vendor — an open API specification with per-vendor backend drivers | h264_vaapi, hevc_vaapi, av1_vaapi | Linux (and other Unix-likes) | The vendor-neutral route; one filtergraph and one command can target Intel or AMD silicon through different backend drivers |
| VideoToolbox | Apple | h264_videotoolbox, hevc_videotoolbox | macOS, iOS | The only hardware path on Apple platforms; the media engine on Apple Silicon |
VAAPI deserves the clarification. Its reference implementation, libva, describes itself as “an open-source library and API specification, which provides access to graphics hardware acceleration capabilities for video processing,” built as a main library plus driver-specific acceleration backends for each supported hardware vendor. That architecture is the point: on Linux, a VAAPI command targeting an Intel iGPU and the same command targeting an AMD GPU differ in the backend driver loaded, not in your invocation. That portability is real and valuable, and it comes at the usual abstraction cost — vendor-specific tuning knobs are more accessible through the vendor’s own path than through the generic one. On Linux with an NVIDIA card you will generally reach for NVENC directly rather than through VAAPI.
Intel’s runtime layer has moved, which matters if you’re reading older guides. Quick Sync is now reached through Intel VPL (libvpl), which supersedes the older Intel Media SDK and provides, in Intel’s own words, “access to hardware accelerated video decode, encode, and processing capabilities on Intel GPUs.” Its dispatcher documentation, checked 2026-08-14, names the supported families: Tiger Lake, Iris Xe MAX (DG1), the Alder Lake series, Arc A-Series (DG2), Data Center GPU Flex, the Raptor Lake series, Meteor Lake, the Arrow Lake series, and Lunar Lake. If a tutorial tells you to install Intel Media SDK, it is describing the previous generation of that stack.
AMD’s AMF documents its FFmpeg integration through AMD’s GPUOpen wiki, which as of 2026-08-14 covers h264_amf, hevc_amf, and av1_amf on both Windows and Linux, with usage profiles named transcoding, ultralowlatency, lowlatency, webcam, and high_quality, plus three quality levels: speed, balanced, and quality. That naming is itself instructive — the vendor is telling you outright that this is a dial, and that “high quality” and “ultra low latency” are opposite ends of it.
Generation Matters More Than Vendor
If you take one practical thing from this article, take this: which GPU generation you have matters more than which logo is on it. Vendors version their media engines separately from the graphics architecture, and capability changes across those versions are dramatic — not marginal.
NVIDIA publishes this directly. The table below is drawn from NVIDIA’s own Video Encode and Decode GPU Support Matrix, checked 2026-08-14 — and note that it labels the NVENC generation as a distinct number from the GPU architecture name, which is exactly why “I have a newer card” is not the same claim as “I have a newer encoder.”
| GPU architecture | NVENC generation (NVIDIA’s own label) | H.264 | HEVC | AV1 |
|---|---|---|---|---|
| Blackwell | 9th Gen | Yes, including 4:2:2 and 4:4:4 | Yes — 8K, 10-bit, 4:4:4 | Yes |
| Ada Lovelace | 8th Gen | Yes (4:2:0, 4:4:4); no 4:2:2 | Yes — 8K, 10-bit, 4:4:4 | Yes |
| Ampere | 7th Gen | Yes (4:2:0, 4:4:4); no 4:2:2 | Yes — 8K, 10-bit, 4:4:4 | No |
| Turing | 6th–7th Gen (varies by model) | Yes | Yes, 10-bit; 8K on 7th Gen only | No |
| Volta | 6th Gen | Yes | Yes, 8K; no 10-bit | No |
| Pascal | 6th Gen | Yes | Yes; no 8K, no 10-bit | No |
| Maxwell | 4th–5th Gen | Yes | No HEVC encode at all | No |
Read down that AV1 column. Hardware AV1 encode on NVIDIA begins at Ada Lovelace. On an Ampere card — a perfectly capable modern GPU — av1_nvenc does not exist, and no driver update will create it, because the silicon isn’t there. Read the HEVC column and the same story repeats a generation earlier: Maxwell cannot hardware-encode HEVC at all. Note too that Turing spans two NVENC generations depending on the specific model, which is the clearest possible demonstration that architecture name and encoder generation are not interchangeable.
The same principle holds on the other stacks even where the published matrices are less granular: whether av1_qsv or av1_amf will actually run is a property of the specific media engine in your specific chip, not of the encoder name existing in FFmpeg’s build. The honest instruction is the boring one — look up your exact model in the vendor’s current support matrix, and treat any capability claim in a blog post (including a claim about which generation added what) as needing a date attached.
Quality, as distinct from capability, has also moved across these generations — and that’s precisely the claim that needs test conditions rather than a headline. “NVENC looks as good as x264 now” is not a statement anyone can evaluate without knowing which NVENC generation, which preset and tune on both sides, which bitrate region, what content, and which metric. Treat every such claim as a question, not an answer.
Session Limits: A Product Line Drawn in Software
Consumer GPUs carry a cap on how many simultaneous encode sessions the driver will grant, and it is a segmentation decision rather than a physical limit of the encoder block. NVIDIA’s support matrix, checked 2026-08-14, lists a maximum of 12 concurrent NVENC sessions on consumer GeForce cards, against “Unrestricted” on the professional and data-center parts (with some professional SKUs listed at 8).
Two things follow. First, this cap has been raised over time through driver changes, and it is exactly the kind of number that has been repeated wrongly in forum threads for years after the fact — if you read a much lower figure somewhere, check the current matrix before you plan around it. Second, if you’re sizing a home media server, the session limit is a real design input alongside raw throughput: a card that can encode ten 1080p streams in real time is only useful for ten streams if the driver will hand you ten sessions. For a Plex or Jellyfin box serving a household this is a non-issue at current caps. For anything approaching commercial density, it’s the line that pushes you toward the professional parts — which is the intent.
It’s also worth noting that the number of physical encoder blocks varies within a generation: NVIDIA’s matrix lists between one and three NVENC chips depending on the model. Two encoder blocks is a throughput fact; twelve sessions is a licensing fact. They are separate constraints and they bind at different points.
Rate Control Works Differently Over Here
A practical trap on the way in: the rate-control vocabulary you know from x264 does not transfer cleanly to hardware encoders. -crf 20 is meaningful to libx264. Hand it to h264_nvenc and it isn’t the same control at all — the NVENC path uses its own constant-quality parameter (-cq), constant-QP mode, and VBR/CBR modes, and the numbers on those scales are not interchangeable with x264’s CRF scale. This is a specific instance of a broader rule this series treats separately: CRF values do not transfer across encoders, and the equivalence tables floating around online are approximate, version-dependent rules of thumb rather than conversion formulas.
What vendors offer instead is a set of intent-shaped profiles, and NVIDIA’s documentation splits them along exactly the axis this article is about. Its latency-tolerant, quality-first configuration enables “B-frames, look-ahead, reference B frames, variable bitrate (VBR) and higher VBV buffer sizes,” in a form like -preset p6 -tune hq. Its low-latency configuration disables B-frames, uses constant-bitrate mode, and sets a very small VBV buffer, in a form like -preset p6 -tune ll -bufsize 167K. AMD’s AMF exposes the same idea under different names, with its high_quality and ultralowlatency usage profiles at opposite ends and webcam explicitly described as the balance point.
The reason those two configurations look so different is worth understanding rather than memorizing. B-frames reference future frames, so encoding one means holding frames back before you can emit anything — excellent for compression, fatal for a low-latency stream. A large VBV buffer lets the encoder spend bits unevenly across a scene, which is how you get good quality on a hard shot — and it also means the decoder has to buffer more before playback can start. Every knob in the low-latency profile is trading compression efficiency for the ability to emit a frame now. If you’re streaming, that trade is correct and you should make it deliberately; latency is a budget you spend across capture, encode, network, and playback, in the same way ping and jitter shape everything else interactive on a connection.
When Hardware Is Clearly Right, and When It’s Clearly Wrong
Strip away the argument and the decision is usually easy, because the two columns of that first table map cleanly onto real jobs.
| Job | Use | Why |
|---|---|---|
| Live streaming to Twitch/YouTube | Hardware | The encode must keep pace with real time and leave the CPU free for the game or the app being captured. This is what NVENC in OBS exists for. |
| Screen recording and screencasts | Hardware | Same deadline, plus you want the machine responsive while recording — the case for hardware in any desktop capture workflow. |
| Video calls and real-time collaboration | Hardware | Latency dominates everything; the compression gap is irrelevant at conversational bitrates. |
| A home media server transcoding on the fly | Hardware | Several streams at once on a low-power box is precisely the concurrency-and-watts case, and nobody is archiving the transcode. |
| Bulk transcode of a large library where wall-clock time is the constraint | Hardware | Throughput is the objective; a somewhat larger file is an acceptable cost. |
| Encoding on battery or in a thermally constrained chassis | Hardware | Watts are the binding constraint, and sustained software encoding will thermal-throttle. |
| Archival masters and anything you’ll re-encode from later | Software | This is a one-time cost paid once and inherited forever. Spend the CPU time. |
| A distribution encode served to many viewers | Software | The encode happens once; the bitrate is paid for on every single view. Efficiency compounds. |
| Hitting a hard file-size or bandwidth ceiling at the best possible quality | Software | This is exactly the axis hardware trades away. |
| Reproducible output across machines | Software | Same build and flags gives you the same bits; hardware output can vary with GPU model, driver, and firmware. |
Two patterns underneath that table are worth naming. Encode-once, view-many is the software case. If bits get paid for repeatedly — by every viewer, forever — spending an hour of CPU to make the file smaller is trivially good economics, and the whole logic of bandwidth as a recurring cost applies directly. Encode-once, view-once-or-never is the hardware case. A live stream, an ephemeral transcode, a recording someone watches and deletes — bits spent there are spent once, and the deadline is the only thing that matters.
And the underrated middle option deserves its own line: hardware decode plus software encode. Decoding is the cheap, low-risk half to accelerate — it’s the source-side bottleneck on 4K HEVC material, and it has none of the quality controversy that surrounds the encode side, because a conforming decoder produces the specified output. Pairing -hwaccel with libx264 or libx265 frees CPU cores that were being spent on decode and hands them to the encoder’s rate-distortion search. For a large batch of high-resolution sources being encoded for archive, that configuration is frequently the actual best answer, and it’s the one that gets skipped because it doesn’t fit the “hardware versus software” framing the question is usually asked in.
❓ Frequently Asked Questions
Is hardware video encoding always faster than software encoding? Almost always for encode, yes — often by a very large margin, and with far lower power draw. Decode is a different story: FFmpeg’s own documentation notes that “most acceleration methods are intended for playback and will not be faster than software decoding on modern CPUs.” The speedup is also not automatic in a full pipeline; if frames bounce between GPU and system memory, or a software filter sits in the middle of the graph, much of the advantage is consumed by transfers and CPU work.
Does -hwaccel cuda mean I’m hardware-encoding? No. -hwaccel is an input option that selects a hardware decoder; FFmpeg documents it as “Use hardware acceleration to decode the matching stream(s).” Hardware encoding is selected separately, on the output side, by naming a hardware encoder such as h264_nvenc, hevc_qsv, or h264_vaapi. They are separate blocks of silicon and separate switches, and all four combinations of hardware/software decode and encode are valid configurations.
Why is my hardware transcode barely faster than the CPU one? The usual cause is that frames are leaving GPU memory. -hwaccel cuda alone hands you frames in system RAM; pairing it with -hwaccel_output_format cuda is what keeps them resident, and NVIDIA’s documentation states that combination is specifically what “keep[s] video frames in GPU memory for transcoding.” The other common cause is a software filter in the graph forcing a download-and-upload per frame — use the hardware equivalents (scale_cuda, scale_vaapi, scale_qsv) where they exist.
How much worse does hardware encoding look? There is no single honest number, and you should be suspicious of anyone who gives you one. The gap depends on the encoder generation, the presets and tuning on both sides, the bitrate region, the content, and which quality metric was used — and a proper comparison is a BD-rate curve across multiple operating points rather than a single score, with the metric and its model version stated. The reliable qualitative statement is the one this article opened with: at a matched bitrate the software encode generally looks better; at a matched quality target the hardware file is bigger.
Can my GPU encode AV1? Only if its media engine supports it, which is a generation question rather than a vendor question. On NVIDIA, per its own support matrix checked 2026-08-14, hardware AV1 encode appears at Ada Lovelace and continues on Blackwell; Ampere and Turing do not have it and cannot gain it through a driver update. Intel and AMD have their own cutoffs tied to specific media-engine versions. Look your exact model up in the current vendor matrix rather than assuming the encoder name existing in FFmpeg means your hardware can run it.
Should I use VAAPI or the vendor-specific path? On Linux, VAAPI’s value is portability — libva describes itself as a library and API specification with driver-specific backends per hardware vendor, so one command can target Intel or AMD silicon by loading a different backend. The cost is the usual abstraction tax: vendor-specific tuning is more accessible through the vendor’s own path. With an NVIDIA card on Linux, NVENC directly is generally the better-documented route; on mixed or Intel/AMD Linux fleets, VAAPI is often worth the trade.
How many streams can one consumer GPU encode at once? NVIDIA’s support matrix, checked 2026-08-14, lists a maximum of 12 concurrent NVENC sessions on consumer GeForce cards, versus “Unrestricted” on professional and data-center parts. That cap is a driver-enforced product-segmentation line, not a physical property of the encoder block, and it has been raised over time — so check the current matrix rather than an older forum figure. Separately, the number of physical encoder chips varies from one to three by model, which bounds actual throughput independently of the session count.
📚 Further Reading
- Understanding Internet Bandwidth for Engineers and Architects — why a smaller file is worth real CPU time when the bits are paid for on every view, and how to think about the bandwidth side of the encode decision.
- Ping, Jitter, and Packet Loss — the latency budget that low-latency encoder profiles are spending against, and what else in the chain competes for it.
- Screenshots, Screencasts, and Recording your Desktop — the everyday capture workflow where hardware encoding is straightforwardly the right call.
- Why Is My Computer So Slow? Diagnosing and Fixing Common Issues — the profiling habit behind figuring out whether decode, encode, filtering, or a bus transfer is actually your bottleneck.
- What Is the Render Network? Idle GPUs, Explained — GPU time as a scarce, contended resource, and why keeping a pipeline resident on the device is worth engineering for.
- FFmpeg —
ffmpegcommand-line documentation — the primary source for-hwaccel,-hwaccel_device, and the input/output option split this article leans on. - NVIDIA — Using FFmpeg with NVIDIA GPU Hardware Acceleration — the vendor’s own GPU-residency guidance,
scale_cuda/scale_nppexamples, and the latency-tolerant versus low-latency preset split. - NVIDIA — Video Encode and Decode GPU Support Matrix — the authoritative, per-model capability and session-limit table; check your exact card here before planning anything.
- Intel VPL (
libvpl) — the current Quick Sync runtime that supersedes Intel Media SDK, with the supported-hardware dispatcher table. - libva — the VA-API reference implementation — the open API specification and its per-vendor backend-driver architecture.
- AMD GPUOpen — AMF Encoder Settings and Tuning in FFmpeg — AMD’s own usage profiles and quality levels for
h264_amf,hevc_amf, andav1_amf. - Apple — Video Toolbox framework — the hardware encode/decode path on macOS and iOS, exposed in FFmpeg as
-hwaccel videotoolboxand the_videotoolboxencoders.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Start with the free material, and for this topic especially. Hardware encoding is the fastest-ageing corner of the media stack: capability matrices change every silicon generation, runtimes get superseded, session caps move with driver releases. No book tracks that, and none of the ones below try. The current material is free and published by the people who build the hardware.
- NVIDIA — Video Encode and Decode GPU Support Matrix — the single most useful page in this subject: per-model NVENC and NVDEC generation, codec and chroma-format support, encoder-chip counts, and concurrent-session limits. Look your exact card up here before planning anything.
- NVIDIA — Using FFmpeg with NVIDIA GPU Hardware Acceleration — the vendor’s own guidance on keeping frames resident, the
scale_cudaandscale_npphardware scalers, and the split between latency-tolerant and low-latency configurations. The GPU-residency section above leans directly on it. - FFmpeg’s own documentation —
ffmpeg-all— every option, encoder, and filter in one nightly-regenerated page, including each hardware encoder’s private options. When a tutorial and this page disagree, this page is right. - Intel VPL (
libvpl) and libva — the current Quick Sync runtime that supersedes Intel Media SDK, and the VAAPI reference implementation. On Intel or a mixed Linux fleet, these are the ground truth. - AMD GPUOpen — AMF Encoder Settings and Tuning in FFmpeg — AMD’s own usage profiles and quality levels, maintained alongside the driver rather than reverse-engineered from it.
- Digital Video Introduction — Leandro Moreira’s free, illustrated walkthrough of frame types, GOP structure, motion compensation, and rate control: the machinery a fixed-function encoder runs a bounded version of. Actively maintained, and it treats AV1 as a first-class citizen.
The books below cover the durable half — coding theory, signal and colour groundwork, and the block-based pipeline both kinds of encoder implement. None will tell you what your specific GPU supports.
Video Demystified: A Handbook for the Digital Engineer
Keith Jack · 5th edition, Newnes, 2007 · Paperback, 944 pp
The closest thing on the shelf to a book written from inside the world this article describes — video from the hardware engineer’s side of the table, where a codec is something you build a block for rather than something you call from a command line. Interfaces, timing, colour spaces, sampling, and the realities of moving video through silicon. Read it for how that mindset differs from a software encoder’s, which is the whole reason fixed-function encoders behave the way they do. The honest caveat is its age: the 5th edition dates from 2007, so it predates HEVC and AV1 entirely and every hardware-generation specific in it is long superseded. Fundamentals and engineering culture here; capability facts from the vendor matrices above.
Coding Video: A Practical Guide to HEVC and Beyond
Iain E. Richardson · Wiley, 2024 · Hardcover, 448 pp
The most current codec text available, from the author of the standard H.264 books. It walks the modern block-based pipeline — prediction modes, motion estimation, partitioning, transform, quantization, entropy coding — in the detail this article’s “what the silicon is actually doing differently” section can only gesture at. That matters here specifically: once you can see the size of the search space an encoder chooses from, the reason a fixed-function block needs more bits stops being a claim you take on trust. One caveat: the publisher’s own description does not promise substantive AV1 or VVC coverage, so read “and Beyond” as an HEVC-centred book with a forward glance.
Introduction to Data Compression
Khalid Sayood · 5th edition, Morgan Kaufmann, 2017 · Paperback, 790 pp
The theory underneath the trade this whole article is about. Sayood builds from information theory through entropy coding, quantization, transform coding, and — most relevantly — rate-distortion theory, the formal name for the “how many bits does this cost versus how far off is the reconstruction” question every encoder decision answers. General compression theory rather than a video-specific text, and better for it: once rate-distortion is a curve in your head rather than a slogan, BD-rate comparisons and the emptiness of any single “hardware is X% worse” number both become obvious.
Digital Video and HD: Algorithms and Interfaces
Charles Poynton · 2nd edition, Morgan Kaufmann, 2012 · Hardcover, 752 pp
The reference on the signal and colour side — gamma, colour spaces, chroma subsampling, bit depth. Worth open beside a vendor capability matrix, because the entries in those matrices are mostly colour-and-sampling facts: 4:2:0 versus 4:2:2 versus 4:4:4, 8-bit versus 10-bit. This is what makes those columns mean something rather than read as codes. Know what it is not: a colour and signals book with roughly one part of six on compression, and no HEVC or AV1 coverage. Buy it to understand pixels, not codecs.
For AV1 and VVC there is no mature book to recommend — the literature genuinely does not exist yet. The specifications are the material: the AV1 Bitstream & Decoding Process Specification is free to read online, as is the ITU-T H.266 Recommendation. Pair either with the matrix for your own hardware and you have a more current picture than anything on the shelf.