NVENC and NVDEC in Teslas - which card encodes video, how many sessions and which codecs (matrix)

The short answer: most of the Teslas in our range encode video in hardware: the P4, P40, T4 and A2, as well as the V100 and P100, have an NVENC encoder. The difference lies not in "whether it encodes", but in "how well, and whether that is its job". For a media server you want the P4, P40, T4 or A2: better suited to video applications (and the P4/T4/A2 are also energy-efficient), with a newer or more suitable video block. The V100 and P100 will encode too, but they have an old encoder (no HEVC B-frames) and are expensive compute cards: buying them "for Plex" is a waste of money, not a lack of capability. None of these cards encodes AV1 (the A2 only decodes AV1). The only card in this world with no encoder at all is the A100, and for that reason we do not offer it for video. And the limit on concurrent NVENC sessions that guides warn about applies to consumer GeForce cards: Teslas do NOT have it. Below is the full matrix of who can do what.

I write this as a seller who would rather you bought the right card once than an expensive, wrong one and then regretted it. The most common mistake in this category is someone who saw "V100 32 GB HBM2, a powerful Tesla, cheap" and took it for a media server. The card will encode video, but it is like buying a combine harvester to mow the lawn: you overpay, get an old encoder and waste the silicon you paid for (compute). This post is meant to save you from that mistake, so it will be bluntly specific.

Encoder vs decoder: let us define the terms first

People confuse these two things, yet they are completely different hardware blocks:

• NVENC = encoder = ENCODING. It takes frames and writes them in a compressed format (H.264, HEVC…). You need it when the server transcodes a stream (changes the codec/resolution/bitrate on the fly) or when you record/stream video. Without NVENC, encoding usually falls to the CPU, which with many parallel streams greatly increases its load.
• NVDEC = decoder = READING/DECODING. It unpacks compressed video into frames. It is needed, for example, for playback or as the first step of a transcode (decode the source → encode it again).

The key point: full hardware transcoding can use both blocks: NVDEC to decode the source and NVENC to re-encode the result. NVDEC is not a requirement, however: you can decode on the CPU and feed the frames to NVENC (that is what we do in the "encode path" scenario below: it tests the encoding path, but with a weaker CPU the decode may limit the result; we measure the full transcode through hardware NVDEC separately). A card that has only compute and no encoder will not encode the result in hardware: in this whole family there is really only one such card, the A100. The rest (including the V100 and P100) have an encoder; the question is whether it is worth using it on that particular card.

The matrix: who can do what

The data on the presence of NVENC/NVDEC and the codecs comes directly from NVIDIA's official matrix (links at the end):

Card	Generation	NVENC (encoder)?	NVDEC (decoder)?	HEVC (H.265)	AV1	NVENC session limit
Tesla P4 8GB	Pascal	YES (H.264, HEVC)	YES	encode + decode	NO (neither encode nor decode)	Unrestricted*
Tesla P40 24GB	Pascal	YES (H.264, HEVC)	YES	encode + decode	NO (neither encode nor decode)	Unrestricted*
T4	Turing	YES (H.264, HEVC: better, with B-frames)	YES	encode + decode (better)	decode: NO · encode: NO	Unrestricted*
NVIDIA A2 16GB	Ampere	YES (H.264, HEVC: the same newer block as the T4, with B-frames)	YES	encode + decode (better)	decode: YES · encode: NO	Unrestricted*
V100 32GB	Volta	YES, but old (no HEVC B-frames)	YES	encode + decode	NO	Unrestricted*
P100 16GB	Pascal	YES, but old (no HEVC B-frames)	YES	encode + decode	NO	Unrestricted*
A100 (for contrast: not for video)	Ampere	NO: 0 encoders	YES (5×)	decode: YES · encode: none	NO (neither encode nor decode)	not applicable

An explanation of the columns, with honest markers:

• NVENC?: whether the card encodes video in hardware at all. Contrary to popular opinion, the V100 and P100 do have an encoder (NVIDIA's official matrix): simply an old one, from the Pascal/Volta generation. The only card in this family that truly has no encoder is the A100 (0 NVENC units): that is why it, and not the V100/P100, is called "compute-only, without video".
• "Old encoder" for the V100/P100: specifically, the Pascal/Volta-generation NVENC block does not support B-frames (or multiple reference frames) in HEVC, which lowers the efficiency of H.265 compression compared with Turing (T4). It will encode, but it has less scope for optimising compression than the newer Turing block. That is the real reason newer cards are chosen for video, not "no NVENC". Since Plex Media Server 1.43.1.10611, HEVC encoding is no longer labelled experimental and is enabled by default; actual use still depends on hardware, the client and settings. Missing HEVC B-frames matter when the transcode output is HEVC.
• HEVC: all the cards on this list (apart from the A100) support H.264 and HEVC. The T4 (Turing) and the A2 (Ampere) share the newer seventh-generation NVENC, with HEVC B-frames, which gives better HEVC quality at a given bitrate than Pascal/Volta.
• AV1: watch out for a common myth here: none of these cards ENCODES AV1. The A2 (Ampere) is the only one that decodes AV1, which is useful for playing AV1 material. The T4 (Turing) does NOT decode AV1: hardware AV1 decoding starts only with Ampere. For hardware AV1 encoding you need the Ada generation or newer.
• Session limit (Unrestricted*): see below, because this is the source of the most confusion. * means there is no artificial limit on the number of concurrent sessions on the driver side; the real ceiling is set by the available resources (NVENC throughput, memory, the rest of the system), not by a threshold imposed from above. For data-centre cards, the official matrix gives exactly "Unrestricted".

We measured on our own hardware the throughput values in streams (the "How many streams in practice" section below). Methodology: ffmpeg 6.1.1, -preset p4, a uniform -b:v 2000k, 1080p H.264 (8-bit) and 4K HEVC (10-bit) material from testsrc2; three scenarios: encoding (encode path: source decoded on the CPU → NVENC; it tests the encoding path, but the CPU may limit the result), decoding (NVDEC) and a full codec transcode (hardware NVDEC → NVENC: the core of the Plex/Jellyfin pipeline, without tone mapping, subtitles or other filters); "max. realtime streams" = the largest N at which each stream holds ≥ 30 fps; each card at its full power limit; driver 580.173.02, CUDA 12.0. testsrc2 is synthetic material, so we treat the results as a measurement of the throughput of the video blocks, not as a simulation of a particular film or Plex/Jellyfin library. A real server also adds scaling, subtitles, audio and I/O: allow for a margin. The capability matrix itself (who has NVENC, who decodes AV1) is certain and comes from NVIDIA's documentation.

How many streams in practice: we measured the whole family

The matrix says "who has NVENC". It does not say "how much it can handle". So we measured: not just the encoder, but three real scenarios: encoding (the encoder fed with frames), decoding (NVDEC, the "cameras/playback" path) and a full codec transcode (NVDEC → NVENC: the core of what Plex/Jellyfin does, without tone mapping, subtitles or other filters). Everything at a uniform -b:v 2000k, 1080p, realtime criterion = every stream ≥ 30 fps (speed ≥ 1.0×), full power limit. The figures are the max. N realtime streams on our units:

Scenario (1080p @30, 2000k)	P4	A2	P40	P100	V100-16
H.264 encoding (CPU→NVENC)	12	11	14	14	14
HEVC encoding (CPU→NVENC)	14	10	15	14	14
H.264 decoding (NVDEC)	14	44	20	17	18
H.264 → H.264 transcode	14	13	18	16	17
H.264 → HEVC transcode	14	11	19	17	17
4K → 1080p transcode	4	12	5	5	5
Card power cap	75 W	60 W	250 W	250 W	250 W

Three things follow from this:

• The P40 achieved the highest full-transcode throughput in our benchmark: 18–19 parallel transcodes and 20 decodes, 1–2 streams more than the P100 (16–17) and the V100 (17). All four Pascal/Volta cards have one third-generation NVDEC, and the P40 has fewer NVENC engines (2) than the P100/V100 (3). Its transcode lead coincides with its higher decode-test result (20 against 17–18), suggesting a limitation in the decoding path. Engine counts and these results alone do not establish the bottleneck; the decode test also includes copying frames to system memory. If the maximum number of transcodes is what matters and a 250 W power draw does not constrain you, this is the card; for a home, where the electricity bill matters, the P4 or A2 will more often win.
• The A2 achieved the highest H.264 decoding and 4K→1080p results in our benchmark: 44 decodes and 12 4K→1080p transcodes (the rest of the family manages 4–5 here). It has 2× NVDEC, which in this workload is a significant advantage over the older cards, although the result also reflects the generation of the block, the scaler and the whole pipeline, not just the decoder count. For monitoring (many cameras) and 4K downscaling → the A2. In encoding alone, the A2 (1× NVENC) matches the P4 in H.264 (11 vs 12) and scores lower in HEVC (10 vs 14), even though the P4 has 2× NVENC.
• More compute power ≠ more streams: CUDA core count and VRAM capacity do not explain these test results. The expensive V100 (17 transcodes) does not do significantly more than the inexpensive P4 (14), despite having many times more compute power. On the Pascal and Volta cards, each with one NVDEC, the full transcode ends almost exactly where the decode test ends (P4 14/14, P40 18–19/20, P100 16–17/17, V100 17/18), suggesting a limitation in the decoding path. However, that test also includes copying frames to system memory, so this does not prove saturation of NVDEC itself. The A2 has two NVDECs and reaches 44 streams in the decode test versus 11–13 in transcoding, suggesting a later limitation in the pipeline, probably encoding on its single NVENC. Confirmation requires utilisation measurements for the individual engines at the stream limit. In the encode path, CPU decoding may account for part of the limitation.

And most importantly for this post: the P100 and V100 really do encode and transcode: 14 encoding streams, 16–17 transcodes, confirmed by our measurement, not just the matrix. That settles the "P100 is compute-only" myth: the only card in this family without an encoder is the A100. (We carried out the measurements on a V100 PCIe 16 GB and a P100 16 GB. The NVENC/NVDEC block is a property of the chip (GV100 in the V100, GP100 in the P100), not of the amount of memory; in NVIDIA's matrix the V100 appears as a single entry, not per VRAM variant.)

Note, however, the power cap: the P40/P100/V100 are 250 W cards, the P4 is 75 W and the A2 60 W. During the tests we also measured the real power draw (a sidecar nvidia-smi power.draw, peak): the full video path on the P4 or A2 stayed within ~30–43 W, and on the P40 reached 60–68 W: this is a measured peak, not an estimate. Counting streams per watt, the small cards beat the 250 W P40: in basic 1080p transcoding the P4 and A2 results are similar at a much lower power draw, and the A2 adds a big advantage in decoding and 4K downscaling.

A methodological note. The table replaces our earlier, preliminary "encode-only" measurement (~16–18 for the P40) from working notes: those were sessions of the encoder alone with decoding on the CPU. The table above is real NVDEC→NVENC at a uniform bitrate, so it is more representative of "how many transcodes in Plex". Important for interpretation: the "encode path" (scenario A) means CPU decode → NVENC, so it is not a laboratory measurement of the maximum throughput of NVENC alone: the CPU can become the bottleneck. You can see this on the P4: the encoding path stopped at 12, while the full hardware H.264→H.264 transcode reached 14; hardware NVDEC removes software video decoding from the CPU, and the transcode matches the decode-test result (14 streams). That test also includes copying frames to system memory, so matching results alone do not prove saturation of the P4's single NVDEC.

Exactly how we measured (commands to reproduce yourself)

Since we claim to have "measured the whole family", we also show what we measured it with, so that you can repeat it on your own card rather than take our word for it. All the figures in the table above come from the same harness.

Test bench: a VM with the card in passthrough, one card per test, each at its full power.max_limit (P4 75 W, A2 60 W, P40/P100/V100 250 W). Driver 580.173.02, CUDA 12.0, ffmpeg 6.1.1 (Ubuntu, with NVENC/NVDEC/cuvid).

Input material (synthetic testsrc2, generated once and used for all cards):

• 1080p: testsrc2 1920×1080@30 → H.264 High, 4:2:0 8-bit, ~8 Mb/s (libx264), 60 s.
• 4K: testsrc2 3840×2160@30 → HEVC Main 10 (10-bit), yuv420p10le (libx265), 30 s.

Four scenarios (CUDA_VISIBLE_DEVICES pins the test to one card; -b:v 2000k throughout):

# A. Encoding (encode path): CPU decode → NVENC; tests the encoding path, the result may be limited by the CPU
ffmpeg -hide_banner -stream_loop -1 -t 15 -i in_1080p.mp4 \
  -c:v h264_nvenc -preset p4 -b:v 2000k -f null -        # HEVC: -c:v hevc_nvenc

# B. Decoding (decode-only): NVDEC → null (frames are copied back to system memory, so this is NVDEC plus that copy)
ffmpeg -hide_banner -hwaccel cuda -c:v h264_cuvid -stream_loop -1 -t 15 -i in_1080p.mp4 -f null -

# C. Full codec transcode: NVDEC → NVENC (no tone mapping, subtitles or filters)
ffmpeg -hide_banner -hwaccel cuda -hwaccel_output_format cuda -c:v h264_cuvid \
  -stream_loop -1 -t 15 -i in_1080p.mp4 \
  -c:v h264_nvenc -preset p4 -b:v 2000k -f null -        # h264→hevc: -c:v hevc_nvenc

# D. 4K→1080p: NVDEC (HEVC) → scaling on the GPU → NVENC
ffmpeg -hide_banner -hwaccel cuda -hwaccel_output_format cuda -c:v hevc_cuvid \
  -stream_loop -1 -t 15 -i in_4k.mp4 \
  -vf scale_cuda=1920:1080 -c:v h264_nvenc -preset p4 -b:v 2000k -f null -

We do the 4K→1080p scaling on the GPU with the scale_cuda filter (not the CPU-based scale), so that the whole path is in hardware: a different scaler would give different figures.

How many "realtime" streams: for each scenario we start N parallel copies of the command in the background on the same card (scanning N = 1…40) and after each N we look at the speed= of the slowest of the N streams. N_realtime = the largest N at which that slowest stream held ≥ 1.0× realtime (with a 30 fps source, that is exactly 30 fps per stream). Above that N, one of the streams drops below realtime, and that is the limit given in the table.

Monitoring and power draw: in parallel, a sampler collects nvidia-smi --query-gpu=power.draw,memory.used,temperature.gpu,utilization.encoder,utilization.decoder every 1 s. The reported ENC%/DEC%/W/°C are peaks over the whole run: hence "P4 ~27–30 W" or "P40 ~61–68 W" are the measured power.draw peaks, not estimates. That NVENC/NVDEC, and not the CPU, is doing the work can be seen from utilization.encoder/utilization.decoder > 0 in the given path.

What this does NOT measure: this is the throughput of the codec blocks on synthetic material. Real Plex/Jellyfin adds HDR→SDR tone mapping, subtitle burn-in, audio transcoding, reading from disk/network and session logic, so in production allow for a margin compared with these figures.

The "NVENC session limit" and the keylase patch: what it is about

The "keylase patch" (nvidia-patch) circulating on forums removes the limit on concurrent NVENC sessions, but that limit applied to non-qualified cards (consumer GeForce), where the driver restricted the number of simultaneous sessions to push professionals towards Quadro/Tesla. The Teslas listed here are qualified Data Center cards, for which NVIDIA's official matrix gives an "Unrestricted" policy: they encode as many sessions as the available resources allow (NVENC throughput, memory, the rest of the system), not up to a threshold imposed from above.

The practical conclusion: for a server with many parallel streams, a Tesla also beats a GeForce by not having this artificial session limit, and you simply do not need the patch from the GeForce world.

An anti-guide: what to buy "for video", and what not to

I will say it plainly, because this is the most common costly mistake in this category, except that the mistake is not "the card will not encode", but "I overpaid for the wrong one":

• Do not buy a V100 "for transcoding": not because it will not encode or because it is slow. Our measurement showed that it transcodes on a par with the family (17 streams, ~= P100, just below the P40). The problem is different: it is a 250 W card with an old encoder (no HEVC B-frames, weaker H.265 compression) and the price of a compute card: for video you overpay and waste the silicon you paid for (compute). The V100 32GB shines in AI/HPC: point it there.
• The same goes for the P100: also measured: 16–17 realtime transcodes, it works perfectly well. But the P100 16GB shines in FP16 (2:1 mode) and FP64; as a 250-watt transcoder for Plex it is a sledgehammer to crack a nut, when the P4 (75 W) and A2 (60 W) give a similar result in basic 1080p transcoding at a much lower power draw.
• If you need AV1 ENCODING, none of these cards will do it. The A2 only decodes AV1; for AV1 encoding you need a newer generation.
• If you want a purely compute card without an encoder (and that is what you are looking for), that is the A100, not the V100/P100. But the A100 makes no sense for video by definition.

And what to buy for video:

• On a budget, H.264/HEVC: the Tesla P4 8GB: 75 W, single-slot, no session limit; measured at 12–14 encoding streams and 14 full transcodes.
• The most transcodes in this group: the Tesla P40 24GB: the most transcodes in our measurement (18–19 streams, 1–2 more than the P100/V100; 20 decodes) plus 24 GB of VRAM; the price is a 250 W power draw.
• The champion of decoding and 4K downscaling, AV1 decoding, low power draw: the NVIDIA A2 16GB: 44 decodes and 12 4K→1080p transcodes (2× NVDEC), 60 W.
• A newer HEVC block than Pascal/Volta (with B-frames): the NVIDIA A2 16GB has it (measured above); the T4 (Turing) has the same block: we source it to order and did not have a unit to test, so we report its capabilities from the matrix rather than benchmark results.

I have shown how to put all this together into a working Plex/Jellyfin server step by step in a separate post: Tesla P4 for Plex and Jellyfin.

Why the card's generation changes so much

The NVENC/NVDEC block is a separate piece of silicon that NVIDIA develops with each generation, independently of the CUDA cores. That is why two cards with similar "compute power" can have completely different video encoding capabilities and efficiency: what matters is the generation of the block, not the number of teraflops.

• Pascal (P4, P40, P100): a solid NVENC for H.264 and HEVC, but without B-frames in HEVC. A sufficient, proven standard for home transcoding (P4/P40); in the P100 the same old encoder sits on an expensive compute card. No AV1 in any form.
• Volta (V100): an encoder is present, but still from the "no HEVC B-frames" family and without AV1: in terms of video it is closer to Pascal than to Turing, even though the compute architecture is newer. Our measurement is consistent with this: 14 encoding streams and 17 realtime transcodes, practically level with Pascal (P100) and below the P40 transcoder.
• Turing (T4): a newer HEVC block, with B-frame support and greater scope for optimising compression. Still without AV1 encoding and without decoding AV1.
• Ampere (A2): the same seventh-generation NVENC as the T4 (HEVC with B-frames), plus AV1 decoding, useful when your files are already in AV1. AV1 encoding is still missing. (The A100 is the other face of Ampere: a pure compute core, with no encoder at all.)

This shows that the generation number alone does not tell the whole story: you need to know whether a given card is designed primarily for compute (V100/P100/A100: a video block is present but secondary, and the A100 has no encoder at all, only decoders), or whether its video block is an essential part of its intended application (P4/P40/T4/A2).

How to check for yourself what a card supports

Before you believe anyone (including me), verify it on the specific unit:

• nvidia-smi dmon -s u shows the encoder (ENC column) and decoder (DEC) utilisation live: if ENC moves during transcoding, the card is really using NVENC. Plain nvidia-smi shows the card and the processes using it; nvidia-smi encodersessions (or nvidia-smi -q -d ENCODER_STATS) shows the active encoder sessions.
• The official "Video Encode and Decode GPU Support Matrix" is the source of truth about which cards have NVENC/NVDEC, how many units and which codecs: check your specific model there.
• In Jellyfin/Plex, once acceleration is enabled, you will see in the logs whether the session went through NVENC or fell back to the CPU.

---

An honest disclaimer: we sell used cards from the data-centre market. We based the NVENC/NVDEC capabilities in the matrix on NVIDIA's official documentation; we give the throughput figures in streams as measured on hardware, not "off the top of our heads". Before dispatch we put every card through a burn-in, including a check that the NVENC/NVDEC block really works where it should. Not sure which card suits your application (video vs AI)? Write to us and we will talk you out of a bad purchase before you make it.

Sources

• NVIDIA Video Encode and Decode GPU Support Matrix: https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
• NVIDIA Video Codec SDK: NVENC Application Note (encoder generations, B-frames/HEVC, session-count policy for qualified vs GeForce): https://docs.nvidia.com/video-technologies/video-codec-sdk/12.0/nvenc-application-note/index.html
• NVIDIA Tesla T4 datasheet: https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/tesla-t4/t4-tensor-core-datasheet-951643.pdf
• NVIDIA A2 datasheet: https://www.nvidia.com/content/dam/en-zz/solutions/data-center/a2/pdf/a2-datasheet.pdf
• NVIDIA Container Toolkit: the video capability for NVENC/NVDEC in containers: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html