Tesla P4 do Plex i Jellyfin - konfiguracja i ile strumieni 4K realnie uciągnie

Krótka odpowiedź: Tesla P4 to jedna z najsensowniejszych kart do domowego serwera Plex/Jellyfin — 75 W, jeden slot, zasilanie z samego PCIe (bez dodatkowych wtyczek) i sprzętowy enkoder/dekoder NVENC/NVDEC z generacji Pascal. Obsłuży H.264 i HEVC (w tym HEVC 10-bit do dekodowania), NIE obsłuży AV1, a jako karta datacenter NIE ma stałego limitu licencyjnego liczby równoległych sesji NVENC, który dławił karty konsumenckie. Ile strumieni 4K uciągnie? To zależy od tego, co konkretnie robisz — i tutaj nie podam Ci wyssanej z palca liczby. Dam za to konfigurację krok po kroku, nasz pomiar z jawną metodologią i pokażę, jak samemu to policzyć.

Piszę to jako ktoś, kto te karty sprzedaje, ale mam alergię na wpisy typu „P4 zrobi 20 strumieni 4K jednocześnie". Bo odpowiedź brzmi: może zrobić dużo, może zrobić mało — w zależności od tego, czy transkodujesz sam obraz, czy dokładasz mapowanie tonów HDR, jaki bitrate wybierasz, czy zmieniasz rozdzielczość i jaki kodek jest źródłowy. Rzucanie jedną liczbą to marketing, nie inżynieria. Poniżej masz to, co pewne, i wyraźnie oznaczone to, co musisz zmierzyć u siebie.

Dlaczego akurat P4 do transkodowania

Transkodowanie sprzętowe w Plex/Jellyfin nie zajmuje rdzeni CUDA w sensie „mocy obliczeniowej GPU" — używa osobnego, dedykowanego bloku krzemu: NVENC (enkoder) i NVDEC (dekoder). To ważne, bo znaczy, że nie potrzebujesz mocnej ani drogiej karty. Potrzebujesz karty, która ma dobry blok NVENC/NVDEC i nie żre prądu.

Jedno zastrzeżenie od razu, bo wraca niżej: NVENC/NVDEC nie oznacza, że cały łańcuch transkodowania jedzie na GPU. Skalowanie, mapowanie tonów HDR, wypalanie napisów i inne filtry mogą — zależnie od konfiguracji — korzystać z innych mechanizmów (w tym CPU). Sam enkoder/dekoder to nie to samo co cały pipeline. P4 trafia w rolę taniego transkodera idealnie:

• 75 W total board power (najczęstszy SKU; NVIDIA katalogowo podaje też wariant 50 W) — zasilanie w całości ze slotu PCIe, zero dodatkowych kabli. Do cichego, oszczędnego serwera to duża zaleta.
• Single-slot, niski profil — wchodzi tam, gdzie większe karty się nie mieszczą.
• Pascal NVENC/NVDEC — sprzętowe kodowanie i dekodowanie H.264 oraz HEVC (H.265).
• Brak stałego limitu sesji NVENC — o tym niżej, bo to jedna z najważniejszych i najsłabiej znanych zalet Tesli względem GeForce.
• 8 GB VRAM — do typowego transkodowania wideo to duży zapas; w większości scenariuszy liczby sesji nie ogranicza VRAM.

Szczerze o wadach, żeby nie było niespodzianek: P4 nie enkoduje ani nie dekoduje AV1. Jeśli budujesz bibliotekę pod AV1 albo zależy Ci na najlepszej kompresji przyszłościowo, P4 tego nie da — wtedy patrz w stronę NVIDIA A2 16GB (Ampere, dekoduje AV1) albo T4. Druga rzecz: to karta pasywna — nie ma własnego wentylatora, liczy na przepływ powietrza w obudowie serwerowej. W zwykłej obudowie desktop bez odpowiedniego przepływu powietrza może się przegrzewać i throttlować. Jak to rozwiązać, opisałem osobno: chłodzenie pasywnej karty serwerowej w desktopie. Potraktuj to jako obowiązkową lekturę, nie dodatek.

Konfiguracja krok po kroku

1. Sterownik

Zainstaluj sterownik NVIDIA Data Center (dawniej „Tesla driver") przeznaczony dla kart Data Center/Tesla, a nie zwykły GeForce Game Ready. Na Linuksie dołóż pakiet NVIDIA Container Toolkit, jeśli będziesz jechać w Dockerze (a najpewniej będziesz). Sprawdź, że nvidia-smi widzi kartę i pokazuje jej UUID — ten UUID zaraz Ci się przyda.

2. Plex Pass albo Jellyfin

Sprzętowe transkodowanie w Plex wymaga aktywnej subskrypcji Plex Pass — bez niej Plex nie użyje NVENC i będzie mielił na CPU. To nie jest ograniczenie karty, tylko licencji Plexa. Jellyfin jest darmowy i sprzętowe transkodowanie NVENC włączasz bez żadnej opłaty — dla wielu osób to argument sam w sobie.

3. Docker — zmienne, które muszą się zgadzać

Najczęstsze źródło problemów „karta jest, a i tak transkoduje na CPU" to źle podane zmienne środowiskowe kontenera. W konfiguracji opartej na zmiennych środowiskowych sprawdź te trzy elementy:

• Dostęp do GPU — kontener musi być uruchomiony z dostępem do karty, np. --gpus all albo konfiguracją NVIDIA Container Runtime (runtime: nvidia / --runtime=nvidia). Bez tego nie widzi GPU.
• NVIDIA_VISIBLE_DEVICES — wskaż kartę. Zamiast all polecam podać UUID karty (GPU-xxxxxxxx-... z nvidia-smi -L). UUID jest odporny na zmianę kolejności PCI po restarcie czy dołożeniu drugiej karty — indeks 0 potrafi się przesunąć, UUID nie.
• NVIDIA_DRIVER_CAPABILITIES — musi zawierać co najmniej video (dla NVENC/NVDEC). Bardzo częsty błąd: ludzie dają samo compute,utility, przez co kontener widzi kartę do obliczeń, ale nie dostaje dostępu do bloku wideo i transkodowanie sprzętowe nie działa. Ustaw all albo jawnie compute,video,utility. Uwaga: compute nie jest tu ozdobnikiem — Jellyfin do sprzętowego mapowania tonów HDR używa CUDA, więc jeśli planujesz tone mapping, compute musi być.

4. Włączenie sprzętowego transkodowania w aplikacji

• Plex: Ustawienia → Transkoder → zaznacz „Use hardware acceleration when available" oraz „Use hardware-accelerated video encoding".
• Jellyfin: Panel → Playback → Transcoding → wybierz NVENC jako akcelerator sprzętowy i zaznacz kodeki, które ma dekodować/enkodować sprzętowo (H.264, HEVC). AV1 zostaw wyłączony — P4 tego nie ma.

Weryfikacja, czy naprawdę działa: podczas odtwarzania wymuszającego transkod sprawdź wykorzystanie enkodera/dekodera (nvidia-smi dmon albo kolumny Enc/Dec w nvidia-smi) oraz status sesji w Plex/Jellyfin (obie aplikacje pokazują, czy sesja leci sprzętowo — Plex oznacza „(hw)"). Nie opieraj diagnozy wyłącznie na liście procesów GPU: jej pusty stan bywa mylący, a pewność daje dopiero zestawienie zajętości silnika Enc/Dec z informacją o sesji w logu/aplikacji. Jeśli enkoder stoi na zerze, a aplikacja pokazuje transkod na CPU — wróć do sekcji o zmiennych wyżej.

Ile strumieni 4K / 1080p realnie

Każda liczba bez podania warunków jest myląca. Podam Ci więc nasz pomiar razem z warunkami, w jakich powstał.

Rozróżnienie na starcie: to jest benchmark samego enkodera NVENC — syntetyk testsrc2, czysty transkod, dekodowanie celowo programowe (na CPU), żeby izolować sam enkoder. To nie jest gwarantowana liczba jednoczesnych sesji w Plex/Jellyfin. Realny odtwarzacz dokłada sprzętowy dekod (NVDEC), skalowanie, mapowanie tonów, wypalanie napisów, audio i I/O — część tych etapów obciąża inne bloki i CPU, i obcina wynik w dół. Traktuj poniższe liczby jako wynik tego kontrolowanego testu, a nie stałą właściwość karty ani obietnicę.

Metodologia naszego pomiaru:

Parametr	Wartość
GPU	Tesla P4 8 GB, PCIe Gen3, pełny power limit (w teście peak ~64 W, temp ~59 °C — bez thermal throttlingu)
Sterownik	580.173.02
CUDA Toolkit	12.0 (tylko środowisko build/test — do samego NVENC nieistotny)
Narzędzie	ffmpeg 6.1.1, enkoder sprzętowy NVENC (h264_nvenc / hevc_nvenc)
Dekodowanie	programowe (CPU) — celowo, żeby izolować sam enkoder; w realnym Plexie dekod przejmie NVDEC i odciąży CPU
Preset	p4
Materiał wejściowy	testsrc2 (syntetyk): 1080p H.264 High ~8 Mbps, 30 fps, 60 s oraz 4K HEVC Main 10 (10-bit), CRF 28, 30 fps, 30 s
Wyjście	ta sama rozdzielczość, -b:v 2000k, bez skalowania, bez tone mappingu, bez napisów, bez audio, -f null
Kryterium „realtime"	każdy równoległy strumień ≥ 30 fps przez cały klip
Zakres N	1080p dociążane aż poniżej 30 fps (realtime-N: 12 H.264 / 14 HEVC); 4K do 4 sesji; H.264 i HEVC osobno

Dokładne komendy (do odtworzenia u siebie):

# Materiał źródłowy
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

# Pojedyncza sesja (jedna z trzech mierzonych ścieżek):
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, bez tone mappingu

# N sesji równolegle (przykład: 10× 1080p HEVC). Odpalamy N identycznych procesów naraz
# i szukamy największego N, przy którym KAŻDY proces trzyma ≥30 fps przez cały klip:
seq 10 | xargs -P10 -I{} ffmpeg -i in_1080p.mp4 -c:v hevc_nvenc -preset p4 -b:v 2000k -f null -

Dwie rzeczy warto tu powiedzieć wprost. testsrc2 to materiał syntetyczny — pozwala kontrolować parametry i powtórzyć test co do klatki, ale nie odwzorowuje wszystkich obciążeń prawdziwego filmu (ziarno, zmienne sceny, napisy). A -b:v 2000k to stały parametr przyjęty dla powtarzalności, nie rekomendowany bitrate realnego transkodu 4K — u siebie ustaw bitrate zbliżony do swoich plików.

Jak czytać komendę xargs -P10: to przykład dla N=10. W pomiarze podnosiliśmy N o jeden i sprawdzali, czy każdy proces trzyma ≥30 fps — wynik to największe N, przy którym jeszcze się to udaje (12 dla H.264, 14 dla HEVC).

Wyniki:

• 1080p: dociążając enkoder kolejnymi sesjami aż spadały poniżej 30 fps, P4 utrzymał w realtime 12 strumieni H.264 i 14 strumieni HEVC — to liczby zmierzone wprost, nie ekstrapolacja (H.264 dobija do ściany enkodera nieco wcześniej niż HEVC). Łączna przepustowość toru zatrzymuje się na ~440 fps (przy nasyceniu enc_util = 100%). Nie traktuj samego ~440 fps jak stałej specyfikacji P4 — to wynik tego konkretnego testu (preset, kodek, materiał, zegary robią różnicę).
• 4K HEVC: 3 strumienie realtime zmierzone wprost (po 30 fps); przy 4. sesji wynik spadał do ~23 fps, czyli poniżej realtime. W tym teście 3 strumienie 4K były granicą utrzymania realtime.

Wyniki pochodzą z jednego testowanego egzemplarza P4 i tej konkretnej konfiguracji sprzętowo-sterownikowej — to nie jest test populacji kart, więc u innego egzemplarza mogą się nieznacznie różnić.

To wynik samego toru enkodera. W realnym Plexie z mapowaniem tonów HDR, skalowaniem i wyższym bitrate będzie mniej. Twój wynik zależy od:

• Czy transkodujesz obraz, czy tylko przepakowujesz kontener (remux). Remux prawie nie obciąża NVENC.
• Rozdzielczość docelowa — 4K→4K, 4K→1080p, 1080p→720p to zupełnie różne koszty.
• Bitrate i kodek — HEVC potrafi kosztować więcej zasobów niż H.264, zwłaszcza przy enkodowaniu.
• Mapowanie tonów HDR (patrz niżej) — potrafi być największym pojedynczym obciążeniem w łańcuchu.

Co realnie ogranicza liczbę strumieni — zależy od scenariusza, nie od jednej liczby:

Scenariusz	Główne ograniczenie
Direct Play (klient obsługuje plik)	praktycznie nie NVENC — GPU nie transkoduje wideo
Remux (przepakowanie kontenera)	I/O / sieć
1080p → 1080p	NVENC
4K → 1080p	NVDEC + skalowanie + NVENC
4K HDR → SDR	mapowanie tonów + skalowanie + NVENC
Wypalanie napisów (burn-in)	filtr + enkoder

Kluczowy wniosek: jeśli klient obsługuje format, bitrate i pozostałe wymagania pliku, Plex/Jellyfin może użyć Direct Play — wtedy GPU w ogóle nie transkoduje wideo, a liczba takich jednoczesnych odtworzeń nie jest ograniczana przez NVENC. Transkod włącza się dopiero, gdy klient nie umie odtworzyć pliku wprost.

Dobrym narzędziem do wstępnego oszacowania jest kalkulator elpamsoft (Plex/Jellyfin Hardware Transcoding) — pozwala wpisać model karty i scenariusze, i daje orientacyjne widełki. Traktuj go jako punkt startowy, a nie wyrocznię. Najbardziej wiarygodny wynik dla Twojego przypadku to ten, który zmierzysz na własnym sprzęcie, na własnych plikach: uruchamiaj kolejne strumienie i patrz w nvidia-smi, aż wykorzystanie enkodera zbliża się do sufitu albo pojawia się buforowanie. To zajmuje kwadrans i daje liczbę wartą więcej niż każdy wpis na blogu (w tym ten).

Pułapki, o których się nie mówi

Mapowanie tonów HDR → SDR mocno obciąża. Jeśli masz materiał 4K HDR, a odtwarzacz klienta nie obsługuje HDR, serwer musi zrobić tone mapping (przełożyć szeroki zakres tonalny na SDR). To często jedna z najbardziej kosztownych operacji w całym łańcuchu i potrafi zredukować liczbę równoległych strumieni bardziej niż samo przekodowanie. W Jellyfin włącz tone mapping tylko świadomie i testuj z nim, a nie bez niego. Jeśli chcesz uniknąć problemu u źródła — trzymaj wersje SDR najczęściej oglądanych tytułów.

Wypalanie napisów (subtitle burn-in). Jeśli klient wymusza wypalenie napisów w obraz — szczególnie graficznych (PGS) — na obraz nakładana jest dodatkowa warstwa, co potrafi mocno podnieść koszt całego transkodu. To kolejny powód, dla którego wynik syntetycznego benchmarku NVENC nie jest tym samym co gwarantowana liczba sesji Plex/Jellyfin.

Chłodzenie pasywnej karty. Powtarzam, bo to najczęstsza przyczyna „P4 zwalnia po kilku minutach": bez wymuszonego przepływu powietrza karta się dławi termicznie. Rozwiązania opisałem tutaj.

Wolne I/O. Przy dużej liczbie równoległych transkodów wąskim gardłem może stać się także dysk — tymczasowe segmenty transkodowania lądujące na wolnym HDD potrafią zdławić cały serwer szybciej niż sam GPU. Trzymaj katalog transkodowania na SSD (albo w RAM-dysku), jeśli robisz dużo równoległych sesji.

NVIDIA_DRIVER_CAPABILITIES bez video. Klasyk. Karta widoczna, nvidia-smi działa, a transkod i tak leci na CPU. Sprawdź tę zmienną w pierwszej kolejności.

Kiedy P4, a kiedy nowsza karta

Karta	Generacja	NVENC (enkoder)	AV1 dekod	AV1 enkod	Pobór / format	Do czego
Tesla P4 8GB	Pascal	H.264, HEVC	NIE	NIE	75 W, single-slot	Bardzo dobry stosunek ceny do możliwości do Plex/Jellyfin, jeśli nie potrzebujesz AV1
T4	Turing	H.264, HEVC — nowszy blok NVENC, większe możliwości optymalizacji kompresji HEVC niż Pascal	NIE	NIE	70 W, single-slot	Gdy chcesz lepszą jakość/wydajność HEVC niż Pascal
NVIDIA A2 16GB	Ampere	H.264, HEVC	TAK	NIE	ok. 40–60 W, single-slot	Gdy zależy Ci na dekodowaniu AV1 i najniższym poborze

Podsumowując bez owijania: jeśli Twoja biblioteka to głównie H.264/HEVC i chcesz taniego, bezwentylatorowego, oszczędnego transkodera (przy zapewnionym przepływie powietrza) — brałbym P4. Jeśli wiesz, że idziesz w AV1 albo chcesz maksymalną wydajność HEVC na przyszłość — P4 bym odpuścił i rozważył T4 lub A2, zależnie od aktualnej ceny używek. Nie kupuj P4 „bo tanie", jeśli za pół roku będziesz żałować braku AV1 — to jeden z głównych scenariuszy, w których możesz żałować wyboru P4 (obok bardzo wymagającego tone mappingu i braku airflow).

---

Uczciwe zastrzeżenie: sprzedajemy karty używane, z rynku datacenter. Liczby strumieni w tym wpisie to nasz pomiar toru NVENC z jawną metodologią — a nie gwarancja dla Twojej biblioteki, bo realny wynik zależy od Twoich plików i ustawień. Zmierz go u siebie. Każdą kartę przed wysyłką przepuszczamy przez burn-in (test obciążeniowy i weryfikację bloku NVENC/NVDEC), ale realia domowego serwera zawsze najlepiej sprawdzić samemu. Masz nietypowy scenariusz albo nie wiesz, czy P4 wystarczy do Twojej biblioteki — napisz do nas, pomożemy dobrać.

Źródła

• NVIDIA Video Encode and Decode GPU Support Matrix — oficjalna matryca NVENC/NVDEC per generacja (Pascal: H.264/HEVC, brak AV1).
• NVIDIA Container Toolkit — GPU access i capabilities (video, NVIDIA_VISIBLE_DEVICES) — dokumentacja zmiennych środowiskowych kontenera.
• Plex — Using Hardware-Accelerated Streaming (wymaga Plex Pass) — oficjalne potwierdzenie wymogu Plex Pass i konfiguracji.
• Jellyfin — NVIDIA hardware acceleration — konfiguracja NVENC, pipeline transkodowania i tone mapping w Jellyfin.
• Benchmark własny Agile Store (metodologia i komendy w tekście): ffmpeg 6.1.1, enkoder NVENC + dekod programowy, preset p4, testsrc2, sterownik 580.173.02, pełny power limit.