Tesla P4 for Plex and Jellyfin - configuration and how many 4K streams it really handles

The short answer: the Tesla P4 is one of the most sensible cards for a home Plex/Jellyfin server: 75 W, a single slot, power from the PCIe slot alone (no extra plugs) and a Pascal-generation hardware NVENC/NVDEC encoder/decoder. It handles H.264 and HEVC (including HEVC 10-bit, both decoding and encoding), it does NOT handle AV1, and, as a data-centre card, it does NOT have the fixed limit on the number of concurrent NVENC sessions that NVIDIA still applies to consumer GeForce cards. How many 4K streams can it handle? That depends on exactly what you are doing, and I will not give you a figure plucked out of thin air. Instead, I will give you a step-by-step configuration, our measurement with a transparent methodology, and show you how to work it out yourself.

I write this as someone who sells these cards, but I am allergic to posts along the lines of "the P4 will do 20 4K streams at once". Because the answer is: it can do a lot or it can do little, depending on whether you transcode the picture alone or add HDR tone mapping, what bitrate you choose, whether you change the resolution and what the source codec is. Throwing out a single figure is marketing, not engineering. Below, I explain what is certain and clearly identify what you need to measure yourself.

Why the P4 in particular for transcoding

Hardware transcoding in Plex/Jellyfin does not use the CUDA cores in the sense of "GPU compute power": it uses a separate, dedicated block of silicon: NVENC (the encoder) and NVDEC (the decoder). This is important, because it means you do not need a powerful or expensive card. You need a card with a good NVENC/NVDEC block that does not guzzle power.

One caveat straight away, because it comes back below: NVENC/NVDEC does not mean that the whole transcoding chain runs on the GPU. Scaling, HDR tone mapping, subtitle burn-in and other filters can, depending on the configuration, use other mechanisms (including the CPU). The encoder/decoder alone is not the same as the whole pipeline. The P4 fits the role of an inexpensive transcoder perfectly:

• 75 W total board power (the most common SKU; NVIDIA's catalogue also lists a 50 W variant): powered entirely from the PCIe slot, with no extra cables. For a compact, economical server this is a big advantage.
• Single-slot, low profile: it fits where larger cards will not.
• Pascal NVENC/NVDEC: hardware encoding and decoding of H.264 and HEVC (H.265).
• No fixed NVENC session limit: more on this below, because it is one of the most important and least known advantages of a Tesla over a GeForce.
• 8 GB of VRAM: plenty of headroom for typical video transcoding; in most scenarios VRAM does not limit the number of sessions.

To be honest about the drawbacks, so there are no surprises: the P4 neither encodes nor decodes AV1. If you are building a library for AV1, the P4 will not provide it: look at the NVIDIA A2 16GB (Ampere, decodes AV1; it does not encode AV1). The T4 does not handle AV1 either; its advantage over the P4 is HEVC quality at a given bitrate, not AV1. The second point: this is a passive card: it has no fan of its own and relies on the airflow in a server chassis. In an ordinary desktop case without adequate airflow it can overheat and throttle. I have described how to solve this separately: cooling a passive server card in a desktop. Treat it as required reading, not an extra.

Step-by-step configuration

1. Driver

Install the NVIDIA Data Center driver (formerly the "Tesla driver") from the 580 branch: R580 is the last branch that supports Pascal, so newer branches will not drive the P4 (pin it, e.g. nvidia-driver-pinning-580 on Ubuntu, so an update does not move you past it). On Linux, add the NVIDIA Container Toolkit package if you are going to run in Docker (and you most likely will). Check that nvidia-smi sees the card and shows its UUID: you will need that UUID shortly.

2. Plex Pass or Jellyfin

Hardware transcoding in Plex requires an active Plex Pass subscription: without it Plex will not use NVENC and will grind away on the CPU. This is not a limitation of the card, but of Plex's licence. Jellyfin is free, and you enable NVENC hardware transcoding at no cost: for many people that is an argument in itself.

3. Docker: variables that have to be right

The most common source of problems along the lines of "the card is there, but it still transcodes on the CPU" is incorrectly set container environment variables. In a configuration based on environment variables, check these three elements:

• GPU access: the container must be started with access to the card, e.g. --gpus all or the NVIDIA Container Runtime configuration (runtime: nvidia / --runtime=nvidia). Without this it does not see the GPU.
• NVIDIA_VISIBLE_DEVICES: point to the card. Instead of all, I recommend giving the card's UUID (GPU-xxxxxxxx-... from nvidia-smi -L). This works with runtime: nvidia; if you use --gpus, give the UUID there instead (--gpus device=GPU-xxxxxxxx-..., or device_ids in Compose), because --gpus all sets NVIDIA_VISIBLE_DEVICES=all and overrides your value. The UUID is immune to a change in PCI order after a restart or after adding a second card: index 0 can shift, the UUID does not.
• NVIDIA_DRIVER_CAPABILITIES: must include at least video (for NVENC/NVDEC). A very common mistake: people set just compute,utility, so the container sees the card for compute but does not get access to the video block, and hardware transcoding does not work. Set all or explicitly compute,video,utility. Note: compute is not decoration here: Jellyfin uses CUDA for hardware HDR tone mapping, so if you plan to use tone mapping, compute must be included.

4. Enabling hardware transcoding in the application

• Plex: Settings → Transcoder → tick "Use hardware acceleration when available" and "Use hardware-accelerated video encoding".
• Jellyfin: Dashboard → Playback → Transcoding → select NVENC as the hardware accelerator and tick the codecs it should decode/encode in hardware (H.264, HEVC). Leave AV1 disabled: the P4 does not support it.

Checking that it really works: during playback that forces a transcode, check the encoder/decoder utilisation (nvidia-smi dmon or the Enc/Dec columns in nvidia-smi) and the session status in Plex/Jellyfin (both applications show whether a session is running in hardware: Plex marks it "(hw)"). Do not base the diagnosis solely on the GPU process list: an empty list can be misleading, and certainty comes only from comparing the Enc/Dec engine utilisation with the session information in the log/application. If the encoder sits at zero and the application shows a CPU transcode, go back to the section on variables above.

How many 4K / 1080p streams in practice

Any figure given without its conditions is misleading. So I will give you our measurement together with the conditions under which it was obtained.

A distinction at the outset: this is a benchmark of an NVENC encoding path: synthetic testsrc2, a pure transcode, with decoding deliberately done in software (on the CPU). The intention was to isolate the encoder, but the 4K result may also be limited by CPU decoding and pixel-format conversion. It is not a guaranteed number of concurrent Plex/Jellyfin sessions. A real player adds hardware decoding (NVDEC), scaling, tone mapping, subtitle burn-in, audio and I/O: some of these stages load other blocks and the CPU, and pull the result down. Treat the figures below as the result of this controlled test, not as a fixed property of the card or a promise.

The methodology of our measurement:

Parameter	Value
GPU	Tesla P4 8 GB, PCIe Gen3, full power limit (in the test peak ~64 W, temp ~59 °C: no thermal throttling)
Driver	580.173.02
CUDA Toolkit	12.0 (build/test environment only: irrelevant to NVENC itself)
Tool	ffmpeg 6.1.1, NVENC hardware encoder (h264_nvenc / hevc_nvenc)
Decoding	software (CPU): intended to isolate the encoder, although CPU decoding and pixel-format conversion may contribute to the 4K limit; in Plex, with hardware acceleration enabled and a supported input format, NVDEC can take over decoding and relieve the CPU
Preset	p4
Input material	testsrc2 (synthetic): 1080p H.264 High ~8 Mbps, 30 fps, 60 s and 4K HEVC Main 10 (10-bit), CRF 28, 30 fps, 30 s
Output	the same resolution, -b:v 2000k, no scaling, no tone mapping, no subtitles, no audio, -f null
"Realtime" criterion	every parallel stream ≥ 30 fps for the whole clip
Range of N	1080p loaded until below 30 fps (realtime N: 12 H.264 / 14 HEVC); 4K up to 4 sessions; H.264 and HEVC separately

The exact commands (to reproduce on your own system):

# Source material
ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30:duration=60 -c:v libx264 -b:v 8000k in_1080p.mp4
ffmpeg -f lavfi -i testsrc2=size=3840x2160:rate=30:duration=30 -c:v libx265 -pix_fmt yuv420p10le -crf 28 in_4k_hevc.mkv

# A single session (one of the three measured paths):
ffmpeg -i in_1080p.mp4   -c:v h264_nvenc -preset p4 -b:v 2000k -f null -   # 1080p H.264
ffmpeg -i in_1080p.mp4   -c:v hevc_nvenc -preset p4 -b:v 2000k -f null -   # 1080p HEVC
ffmpeg -i in_4k_hevc.mkv -c:v hevc_nvenc -preset p4 -b:v 2000k -f null -   # 4K HEVC Main 10, no tone mapping

# N sessions in parallel (example: 10× 1080p HEVC). We start N identical processes at once
# and look for the largest N at which EVERY process holds ≥30 fps for the whole clip:
seq 10 | xargs -P10 -I{} ffmpeg -i in_1080p.mp4 -c:v hevc_nvenc -preset p4 -b:v 2000k -f null -

Two things are worth saying plainly here. testsrc2 is synthetic material: it lets you control the parameters and repeat the test frame for frame, but it does not reproduce all the loads of a real film (grain, changing scenes, subtitles). And -b:v 2000k is a fixed parameter adopted for repeatability, not a recommended bitrate for a real 4K transcode: on your own system, set a bitrate close to that of your files.

How to read the xargs -P10 command: it is an example for N=10. In the measurement we increased N by one and checked whether each process held ≥30 fps: the result is the largest N at which this still succeeds (12 for H.264, 14 for HEVC).

Results:

• 1080p: as we loaded the encoder with additional sessions until they fell below 30 fps, the P4 maintained 12 H.264 streams and 14 HEVC streams in real time: these figures were measured directly, not extrapolated (H.264 hits the encoder's ceiling slightly earlier than HEVC). The total throughput of the path stops at ~440 fps (with enc_util saturated at 100%). Do not treat the ~440 fps itself as a fixed P4 specification: it is the result of this particular test (the preset, codec, material and clocks make a difference).
• 4K HEVC: 3 realtime streams measured directly (30 fps each); with a 4th session the result dropped to ~23 fps, that is, below realtime. In this test, 3 4K streams were the limit for maintaining realtime. Unlike at 1080p, encoder utilisation is not reported here, and this path also decodes 4K HEVC 10-bit and converts the pixel format on the CPU, so part of the limit may come from the CPU rather than NVENC. In Plex Media Server 1.43.1.10611, HEVC encoding lost its experimental label and became enabled by default; its use still depends on client and hardware support and transcoding settings. A transcode may also change the resolution, for example from 4K to 1080p. Neither 4K → H.264 nor 4K → 1080p was part of the test described here.

The results come from a single tested P4 unit and this particular hardware/driver configuration: it is not a test of a population of cards, so another unit may give slightly different results.

These are results for the tested encoding paths; the 4K limit may also reflect CPU decoding and pixel-format conversion. In real Plex, with HDR tone mapping, scaling and a higher bitrate, it will be lower. Your result depends on:

• Whether you transcode the picture or only repackage the container (remux). A remux puts almost no load on NVENC.
• The target resolution: 4K→4K, 4K→1080p and 1080p→720p are completely different costs.
• The bitrate, codec and preset: the relative cost of H.264 and HEVC depends on the GPU generation and preset; on this Pascal card at preset p4, HEVC actually held more streams than H.264 (14 against 12).
• HDR tone mapping (see below): it can be the single largest load in the chain.

What really limits the number of streams depends on the scenario, not on a single figure:

Scenario	Main limitation
Direct Play (the client supports the file)	practically not NVENC: the GPU does not transcode the video
Remux (repackaging the container)	I/O / network
1080p → 1080p	NVENC
4K → 1080p	NVDEC + scaling + NVENC
4K HDR → SDR	tone mapping + scaling + NVENC
Subtitle burn-in	filter + encoder

The key conclusion: if the client supports the format, bitrate and other requirements of the file, Plex/Jellyfin can use Direct Play: the GPU then does not transcode the video at all, and the number of such concurrent playbacks is not limited by NVENC. Transcoding starts only when the client cannot play the file directly.

A good tool for an initial estimate is the elpamsoft calculator (Plex/Jellyfin Hardware Transcoding): it lets you enter the card model and scenarios, and gives approximate ranges. Treat it as a starting point, not as gospel. The most reliable result for your case is the one you measure on your own hardware, with your own files: start streams one after another and watch nvidia-smi until the encoder utilisation approaches its ceiling or buffering appears. It takes a quarter of an hour and gives a figure worth more than any blog post (including this one).

Pitfalls nobody talks about

HDR → SDR tone mapping is a heavy load. If you have 4K HDR material and the client's player does not support HDR, the server has to perform tone mapping (converting the wide tonal range to SDR). This is often one of the most expensive operations in the whole chain and can reduce the number of parallel streams more than the transcode itself. In Jellyfin, enable tone mapping only deliberately and test with it, not without it. If you want to avoid the problem at source, keep SDR versions of the most frequently watched titles.

Subtitle burn-in. If the client forces subtitles to be burned into the picture (especially graphical ones, PGS), an additional layer is overlaid on the picture, which can significantly raise the cost of the whole transcode. This is another reason why the result of a synthetic NVENC benchmark is not the same as a guaranteed number of Plex/Jellyfin sessions.

Cooling a passive card. I repeat it because it is the most common cause of "the P4 slows down after a few minutes": without forced airflow the card throttles thermally. I have described the solutions here.

Slow I/O. With a large number of parallel transcodes, the disk can also become a bottleneck: temporary transcoding segments landing on a slow HDD can choke the whole server faster than the GPU itself. Keep the transcoding directory on an SSD (or a RAM disk) if you run many parallel sessions.

NVIDIA_DRIVER_CAPABILITIES without video. A classic. The card is visible, nvidia-smi works, and the transcode still runs on the CPU. Check this variable first.

When the P4, and when a newer card

Card	Generation	NVENC (encoder)	AV1 decoding	AV1 encoding	Power / form factor	Best for
Tesla P4 8GB	Pascal	H.264, HEVC	NO	NO	75 W, single-slot	A very good price/capability ratio for Plex/Jellyfin, if you do not need AV1
T4	Turing	H.264, HEVC: a newer NVENC block, more scope for optimising HEVC compression than Pascal	NO	NO	70 W, single-slot	When you want better HEVC quality at a given bitrate than Pascal (one NVENC engine against the P4's two, so not necessarily more parallel sessions)
NVIDIA A2 16GB	Ampere	H.264, HEVC	YES	NO	about 40–60 W, single-slot	When AV1 decoding and the lowest power draw matter to you

To sum up plainly: if your library is mainly H.264/HEVC and you want an inexpensive, fanless, economical transcoder (with adequate airflow provided), I would take the P4. If you know you are heading for AV1, I would skip the P4 and consider the A2 (it decodes AV1; no card in this table encodes it). If you want better HEVC quality at the same bitrate, consider the T4 or A2, but do not expect more parallel sessions: both have one NVENC engine, the P4 has two. Do not buy the P4 "because it is cheap" if in six months you will regret the lack of AV1: that is one of the main scenarios in which you may regret choosing the P4 (alongside very demanding tone mapping and a lack of airflow).

---

An honest disclaimer: we sell used cards from the data-centre market. The stream counts in this post are our measurement of the NVENC path with a transparent methodology, not a guarantee for your library, because the real result depends on your files and settings. Measure it on your own system. Before dispatch we put every card through a burn-in (a load test and verification of the NVENC/NVDEC block), but the realities of a home server are always best checked yourself. Do you have an unusual scenario, or are you not sure whether the P4 will be enough for your library? Write to us and we will help you choose.

Sources

• NVIDIA Video Encode and Decode GPU Support Matrix: the official NVENC/NVDEC matrix per generation (Pascal: H.264/HEVC, no AV1).
• NVIDIA Container Toolkit: GPU access and capabilities (video, NVIDIA_VISIBLE_DEVICES): documentation of the container environment variables.
• Plex: Using Hardware-Accelerated Streaming (requires Plex Pass): official confirmation of the Plex Pass requirement and configuration.
• Jellyfin: NVIDIA hardware acceleration: NVENC configuration, the transcoding pipeline and tone mapping in Jellyfin.
• Agile Store's own benchmark (methodology and commands in the text): ffmpeg 6.1.1, NVENC encoder + software decoding, preset p4, testsrc2, driver 580.173.02, full power limit.