Jellyfin NVIDIA hardware transcoding Docker konfiguracja

Co budujesz

Transkodowanie sprzętowe Jellyfin na karcie graficznej NVIDIA składa się z czterech kroków wykonywanych w określonej kolejności, przy czym tylko ostatni z nich odbywa się wewnątrz Jellyfin. Kontener nie wykryje karty graficznej, jeśli sterownik hosta nie został załadowany. Jellyfin nie może użyć karty, której kontener nie widzi. Pracuj zgodnie z tą kolejnością, aby każda awaria miała jedno, oczywiste miejsce do weryfikacji.

1. Zainstaluj sterownik NVIDIA na hoście, a następnie potwierdź jego działanie za pomocą nvidia-smi.
2. Zainstaluj NVIDIA Container Toolkit, aby Docker mógł przekazać kartę graficzną do kontenera.
3. Zarezerwuj kartę graficzną dla usługi Jellyfin w docker-compose.yml, a następnie potwierdź, że kontener ją widzi.
4. Włącz NVENC i NVDEC w ustawieniach odtwarzania Jellyfin, a następnie potwierdź, że rzeczywiste odtwarzanie z nich korzysta.

NVENC (koder NVIDIA) i NVDEC (dekoder NVIDIA) to bloki o stałej funkcji na karcie. Są to oddzielne układy krzemowe od rdzeni cieniujących, które wykonują obliczenia CUDA (compute unified device architecture). To właśnie to rozdzielenie sprawia, że warto wykonać tę konfigurację: strumień, który w trybie programowym zużywa kilka rdzeni procesora, obciąża jedynie niewielką część jednego rdzenia oraz dedykowany blok sprzętowy na karcie graficznej.

Odtwarzanie bezpośrednie (Direct Play) jest wydajniejsze niż transkodowanie, więc sprawdź to w pierwszej kolejności

Zanim przystąpisz do konfiguracji, ustal, czy transkodowanie jest konieczne, czy może wynika z przyczyny, którą można łatwo wyeliminować. Jellyfin transkoduje plik, gdy klient nie jest w stanie odtworzyć go w oryginalnej formie. Przyczyna zawsze znajduje się na krótkiej liście: kodek wideo, kodek audio, format kontenera, napisy oparte na obrazie lub limit przepływności (bitrate) narzucony przez klienta.

Otwórz Dashboard, przejdź do sekcji Playback i obserwuj aktywną sesję podczas odtwarzania. Sesja oznaczona jako Direct playing przesyła plik bez zmian i niemal nie obciąża procesora. Sesja oznaczona jako Transcoding wyświetla powód, dla którego Jellyfin podjął taką decyzję. Wyeliminowanie tej przyczyny sprawia, że GPU nie musi być w ogóle używane.

Dwie zmiany eliminują większość przypadków transkodowania. Ustaw jakość w aplikacji klienckiej na Auto lub na wartość maksymalną, ponieważ klient żądający 4 Mbps wymusza ponowne kodowanie pliku o przepływności 20 Mbps, niezależnie od użytego kodeka. Następnie użyj natywnej aplikacji klienckiej zamiast karty w przeglądarce, ponieważ przeglądarka jest najbardziej ograniczonym odtwarzaczem, podczas gdy natywna aplikacja na tym samym telewizorze często odtworzy ten sam plik w trybie Direct play.

Napisy oparte na obrazie są wyjątkiem, którego nie naprawi żadne ustawienie klienta. Napisy PGS z kopii Blu-ray oraz VOBSUB z kopii DVD to obrazy, więc muszą zostać nałożone bezpośrednio na wideo, co oznacza pełne ponowne kodowanie strumienia wideo. Napisy tekstowe w formacie SRT są przesyłane do klienta jako oddzielna ścieżka i nie generują obciążenia. Konwersja ścieżek napisów na format tekstowy, tam gdzie to możliwe, przynosi większe korzyści niż wydajne GPU. Pozostałe aspekty konfiguracji serwera zostały opisane w przewodniku uruchamiania serwera multimediów Jellyfin na VPS.

Większość planów VPS nie posiada GPU

Standardowe plany VPS nie obejmują jednostki GPU. Uruchom poniższe polecenie na serwerze, zanim zaplanujesz jakiekolwiek dalsze działania.

lspci -nn | grep -Ei "3d|display|vga"

Na typowym VPS typu KVM polecenie to wyświetli wirtualny adapter ekranu dostarczony przez hypervisor lub nie zwróci żadnych użytecznych informacji. Takie urządzenie nie posiada możliwości kodowania wideo. Rzeczywiste GPU pojawia się tylko wtedy, gdy dostawca przekaże fizyczną kartę do instancji (passthrough) lub udostępni jej część, co wiąże się z odpowiednio wyższą ceną planu. Które obciążenia faktycznie uzasadniają opłacanie VPS z GPU wyjaśnia, kto powinien, a kto nie powinien korzystać z tego rozwiązania.

Jeśli serwer nie posiada GPU, należy dążyć do bezpośredniego odtwarzania (direct play) i traktować transkodowanie programowe jako rzadki wyjątek. Pojedynczy transkod programowy wideo 1080p H.264 jest obciążający, ale możliwy do obsłużenia przez kilka rdzeni CPU. Transkodowanie programowe materiału 4K HDR wraz z mapowaniem tonów (tone mapping) nie zostanie wykonane w czasie rzeczywistym przez mały VPS, co spowoduje zacinanie się strumienia przy jednoczesnym obciążeniu CPU na poziomie 100 procent.

Instalacja sterownika NVIDIA na hoście

Jellyfin 10.11 wymaga sterownika NVIDIA w wersji co najmniej 520.56.06 w systemie Linux. Ubuntu udostępnia narzędzie pomocnicze, które automatycznie dobiera odpowiedni pakiet.

sudo ubuntu-drivers list --gpgpu
sudo ubuntu-drivers install --gpgpu
sudo reboot

--gpgpu wybiera wersję sterownika typu headless server, co jest pożądane w przypadku serwera multimediów, ponieważ na maszynie nie działa środowisko graficzne. Polecenie list wyświetla dostępne gałęzie, a wybraną można przypiąć według nazwy, na przykład sudo ubuntu-drivers install --gpgpu nvidia:570-server. Należy użyć gałęzi wyświetlonej na liście, a nie tej podanej w przykładzie.

Wersja serwerowa nie zawsze pobiera pakiet nvidia-smi. Należy zainstalować odpowiedni pakiet narzędzi dla wybranej gałęzi, na przykład sudo apt install nvidia-utils-570-server. Następnie należy sprawdzić sterownik.

nvidia-smi

Poprawny wynik wyświetla tabelę z wersją sterownika i wersją CUDA w nagłówku, nazwą karty oraz pustą listą procesów. Często występują dwa błędy. nvidia-smi: command not found oznacza brak pakietu narzędzi, a nie samego sterownika. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver oznacza, że moduł jądra nie został załadowany, co po świeżej instalacji niemal zawsze wynika z braku restartu lub blokady Secure Boot, która uniemożliwia załadowanie niepodpisanego modułu. Obecność modułu można potwierdzić za pomocą lsmod | grep nvidia.

Instalacja NVIDIA Container Toolkit

Sterownik umożliwia hostowi korzystanie z GPU. Docker nie przekaże go jednak do kontenera, ponieważ kontener nie posiada ani węzłów urządzeń, ani bibliotek sterownika. NVIDIA Container Toolkit to komponent, który wstrzykuje oba te elementy podczas uruchamiania kontenera. Poniżej znajdują się oficjalne polecenia instalacyjne NVIDIA dla systemów Debian i Ubuntu.

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

Sama instalacja pakietu jest niewystarczająca, ponieważ należy poinformować Dockera o istnieniu tego środowiska uruchomieniowego.

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

nvidia-ctk runtime configure zapisuje wpis środowiska uruchomieniowego nvidia w pliku /etc/docker/daemon.json. Restart jest krokiem, który często bywa pomijany, a jego pominięcie generuje najczęstszy błąd w całej tej konfiguracji. Przed przystąpieniem do konfiguracji Jellyfin należy przetestować poprawność połączeń.

sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

Polecenie to powinno wyświetlić tę samą tabelę, co na hoście. Jeśli zamiast tego pojawi się błąd informujący o niemożności wyboru sterownika urządzenia z możliwościami gpu, oznacza to, że Docker daemon nie rozpoznaje środowiska uruchomieniowego nvidia. W takim przypadku należy ponownie wykonać polecenie konfiguracji i zrestartować demona.

Udostępnianie GPU kontenerowi Jellyfin w Docker Compose

Jest to nowoczesna forma zapisu Compose, zgodna z przykładem publikowanym przez Jellyfin.

services:
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin
    user: 1000:1000
    network_mode: host
    restart: unless-stopped
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NVIDIA_DRIVER_CAPABILITIES=all
    volumes:
      - /srv/jellyfin/config:/config
      - /srv/jellyfin/cache:/cache
      - /srv/media:/media:ro
    runtime: nvidia
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

Uruchom usługę i odpytaj bezpośrednio kontener.

docker compose up -d
docker compose exec jellyfin nvidia-smi

Jeśli polecenie wyświetli tabelę sterowników z wnętrza kontenera, GPU zostało przekazane poprawnie, a wszelkie pozostałe problemy wynikają z konfiguracji Jellyfin.

Cztery linie w tym pliku wymagają wyjaśnienia. capabilities: [gpu] jest wymagane przez sam program Compose; pominięcie tego wpisu spowoduje, że Compose odrzuci usługę zamiast uruchomić ją bez GPU. NVIDIA_DRIVER_CAPABILITIES=all jest istotne, ponieważ zestaw narzędzi montuje biblioteki wideo w kontenerze tylko wtedy, gdy wymagana jest obsługa wideo, a dokumentacja Jellyfin wymienia tę zmienną jako wymaganą dla oficjalnego obrazu. Bez niej CUDA działa, ale NVDEC nie, a dziennik transkodowania zgłasza Cannot load libnvcuvid.so.1. network_mode: host to ustawienie używane w oficjalnym przykładzie Jellyfin, ponieważ automatyczne wykrywanie klientów na porcie UDP 7359 nie działa w sieci typu bridge.

user: 1000:1000 to ostatni parametr, który nie ma związku z GPU. Decyduje on, które pliki Jellyfin może odczytać w punkcie montowania multimediów; niezgodność w tym miejscu objawia się pustą biblioteką, a nie błędem uprawnień. Jak PUID i PGID mapują użytkownika kontenera na pliki na dysku wyjaśnia tę numerację; jest ona identyczna z tą, którą ustawiono w przypadku stosu Sonarr i Radarr w Docker Compose działającego obok.

Dlaczego większość poradników nadal stosuje runtime: nvidia

Starsza forma pojawia się w niemal każdym poradniku, co nie oznacza, że jest błędna. Jest to zaszłość historyczna. Oryginalny pakiet nvidia-docker2 rejestrował runtime OCI o nazwie nvidia, więc jedynym sposobem na przekazanie GPU do kontenera było użycie --runtime=nvidia oraz NVIDIA_VISIBLE_DEVICES. Wersja Docker 19.03 wprowadziła flagę --gpus oraz odpowiednie API dla żądań urządzeń. Narzędzie Compose potrzebowało więcej czasu na adaptację, a gdy to nastąpiło, żądanie urządzenia trafiło pod klucz deploy.resources.reservations.devices – parametr, który większość użytkowników ignorowała, ponieważ deploy kojarzyło się głównie z Docker Swarm.

W rezultacie obie formy działają obecnie, a opublikowany przykład dla Jellyfin zawiera obie jednocześnie. Pozostawienie runtime: nvidia nie generuje kosztów i zapewnia kompatybilność pliku ze starszymi wersjami Compose. Jeśli zachowasz tylko runtime: nvidia i usuniesz blok deploy, musisz pozostawić NVIDIA_VISIBLE_DEVICES=all, ponieważ ta starsza ścieżka odczytuje zmienną środowiskową w celu określenia, które urządzenia mają zostać wstrzyknięte, i nie posiada alternatywnego mechanizmu żądania urządzenia.

Włączanie sprzętowego transkodowania NVIDIA w Jellyfin

Do tej pory nie skonfigurowano Jellyfin do korzystania z karty graficznej. Przejdź do Dashboard, następnie Playback i wybierz Transcoding. Ustaw Hardware acceleration na Nvidia NVENC. Zaznacz Enable hardware encoding; w przeciwnym razie Jellyfin zdekoduje obraz na GPU, ale zakoduje go na CPU. Jest to nieefektywny stan pośredni, w którym GPU wykazuje aktywność, a procesor jest nadal mocno obciążony.

Opcja Enable enhanced NVDEC decoder przełącza między bieżącą ścieżką NVDEC a starszą CUVID. Pozostaw ją włączoną. Obsługa Dolby Vision wymaga jej aktywacji, aby w ogóle korzystać z NVDEC.

W sekcji Enable hardware decoding for zaznacz tylko te kodeki, które faktycznie są obsługiwane przez Twoją kartę. Jest to ustawienie, w którym często popełniane są błędy. Zaznaczenie AV1 na karcie bez dekodera AV1 nie generuje komunikatu o błędzie. Jellyfin wysyła żądanie sprzętowego dekodowania, nie otrzymuje go i przełącza się na dekodowanie programowe. W rezultacie zużycie CPU jest wysokie, a GPU pozostaje niemal bezczynne, co wygląda tak, jakby przekazywanie sprzętowe w ogóle nie działało.

Dodatkowe ograniczenie dotyczy całej strony: akceleracja sprzętowa działa tylko z dołączoną kompilacją jellyfin-ffmpeg. Jeśli wskażesz ścieżkę FFmpeg na systemowy FFmpeg, uzyskasz częściową akcelerację lub jej brak.

Które kodeki obsługuje Twoja generacja GPU w zakresie dekodowania i kodowania

Oto ograniczenia dokumentowane przez Jellyfin dla NVENC i NVDEC. Dekodowanie i kodowanie to odrębne możliwości; karta może obsługiwać jedną z nich bez drugiej.

• H.264 8-bit: każde GPU NVIDIA z NVENC i NVDEC obsługuje zarówno dekodowanie, jak i kodowanie.
• HEVC 8-bit: dekodowanie i kodowanie od architektury Maxwell drugiej generacji (GM206) wzwyż.
• HEVC 10-bit: dekodowanie od architektury Maxwell drugiej generacji wzwyż, ale kodowanie dopiero od architektury Pascal wzwyż.
• AV1: dekodowanie od architektury Ampere wzwyż, kodowanie od architektury Ada Lovelace wzwyż.

Podział w przypadku HEVC 10-bit jest tym, co w praktyce sprawia najwięcej problemów. Karta z epoki Maxwell zdekoduje plik 4K HDR na GPU, ale nie będzie w stanie zakodować wyjścia 10-bitowego, więc Jellyfin zakoduje materiał jako H.264 8-bit. Taki strumień nadal będzie odtwarzany i w większości przypadków jest to właściwy wybór dla klientów. Kodowanie AV1 rzadko jest pożądane w 2026 roku, niezależnie od posiadanej karty, ponieważ wsparcie dla dekodowania AV1 po stronie klienta jest nadal ograniczone, a transkodowanie wykonuje się w celu obsłużenia klienta, który już wcześniej miał problemy z odtwarzaniem.

Dlaczego mapowanie tonalne potajemnie wysyca GPU

Mapowanie tonalne z HDR (high dynamic range) do SDR (standard dynamic range) to ustawienie, które wyczerpuje budżet zasobów GPU, a powodem jest architektura. Dekodowanie odbywa się na NVDEC. Kodowanie odbywa się na NVENC. Mapowanie tonalne nie korzysta z żadnego z nich: jest to filtr CUDA wykonywany na rdzeniach cieniujących (shader cores), czyli tej samej części GPU ogólnego przeznaczenia, która obsługuje obliczenia. Strumień 4K HDR wymagający mapowania tonalnego wykorzystuje więc dekoder i koder, a dodatkowo obciąża shadery.

Jellyfin dokumentuje mapowanie tonalne CUDA jako dostępne na każdym GPU NVIDIA, które potrafi dekodować HEVC 10-bit. Oznacza to, że pole wyboru pojawia się i działa na kartach, które nie są w stanie obsłużyć tego w rozdzielczości 4K. Objawem jest strumień, który uruchamia się, buforuje i nigdy nie osiąga płynności, podczas gdy nvidia-smi wskazuje, że koder jest ledwo zajęty.

Dlatego warto oddzielnie monitorować obciążenie shaderów.

nvidia-smi dmon -s u

To polecenie wypisuje jedną linię na sekundę z oddzielnymi kolumnami dla sm, enc oraz dec. Niskie wartości enc i dec przy wysokiej liczbie sm oznaczają, że bloki stałofunkcyjne pracują z zapasem, a wąskim gardłem są shadery, więc to mapowanie tonalne, skalowanie lub wypalanie napisów generuje koszt. Ścieżka CUDA obsługuje również Dolby Vision profile 5 z użyciem zero copy, co ma znaczenie, ponieważ bez zero copy ramki przesyłane są do pamięci systemowej i z powrotem między krokami filtrowania, a ten cykl kosztuje przepustowość przy każdej pojedynczej ramce.

Co faktycznie ogranicza limit sesji NVENC w kartach konsumenckich

[
  {
    "label": "GeForce RTX 5090",
    "nvenc_engines": 3,
    "max_encode_sessions": 12
  },
  {
    "label": "GeForce RTX 4090",
    "nvenc_engines": 2,
    "max_encode_sessions": 12
  },
  {
    "label": "GeForce RTX 4060",
    "nvenc_engines": 1,
    "max_encode_sessions": 12
  }
]

Są to oficjalne dane z macierzy NVIDIA według stanu na sierpień 2026, a nie pomiary wykonane w tym miejscu. Karta GeForce posiada limit 12 jednoczesnych sesji kodowania, niezależnie od modelu. Ograniczenie to znajduje się w sterowniku, a nie w krzemie, a firma NVIDIA zwiększała je już wielokrotnie na przestrzeni lat, dlatego należy sprawdzać aktualną macierz zamiast starych wątków na forach. Liczba silników to parametr, który faktycznie zmienia się wraz z modelem karty: GeForce RTX 5090 posiada 3 silniki NVENC, podczas gdy GeForce RTX 4060 posiada 1. Większa liczba silników oznacza wyższą przepustowość kodowania równoległego, a nie wyższy limit sesji.

Limit dotyczy sesji kodowania, więc obejmuje wyłącznie strumienie transkodowane. Odtwarzanie bezpośrednie (direct play) oraz remuxing nie otwierają sesji kodowania. Karty klasy data center, takie jak L4, są w tej samej macierzy oznaczone jako nieograniczone, a karty tego typu są zazwyczaj oferowane w planach GPU VPS, dlatego limit ten dotyczy głównie serwerów domowych.

W przypadku osiągnięcia limitu transkodowanie kończy się niepowodzeniem, a dziennik FFmpeg zawiera OpenEncodeSessionEx failed: out of memory (10). Komunikat odnosi się do pamięci, jednak odmowa z powodu limitu sesji zgłasza ten sam kod, dlatego przed rozpoczęciem poszukiwań wycieku VRAM należy sprawdzić liczbę jednoczesnych strumieni. W praktyce większość użytkowników osiąga limit mapowania tonów (tone-mapping) lub przepustowości wysyłania znacznie wcześniej niż dwunastą sesję.

Weryfikacja transkodowania GPU bez polegania na konfiguracji

Zapisane ustawienie nie stanowi dowodu działania. Należy odtworzyć plik wymuszający transkodowanie, a następnie przeprowadzić trzy testy.

1. Otwórz Dashboard, a następnie Playback. Aktywna sesja powinna wskazywać Transcoding wraz z podaniem przyczyny. Jeśli widnieje komunikat Direct playing, transkodowanie nie zachodzi i testowany jest niewłaściwy plik.
2. Otwórz Dashboard, następnie Logs i otwórz najnowszy dziennik FFmpeg.Transcode. Transkodowanie sprzętowe objawia się obecnością -hwaccel cuda oraz -hwaccel_output_format cuda w wierszu poleceń, przy czym enkoderem jest h264_nvenc lub hevc_nvenc. Obecność libx264 oznacza transkodowanie programowe, niezależnie od ustawień widocznych w panelu konfiguracji.
3. Uruchom nvidia-smi na hoście podczas trwania odtwarzania. Powinien pojawić się proces z /usr/lib/jellyfin-ffmpeg/ffmpeg z przydzieloną pamięcią GPU, a nvidia-smi dmon -s u powinno wykazywać niezerowe wartości w kolumnach enc oraz dec.

Trzeci test należy wykonać na hoście, a nie wewnątrz kontenera. nvidia-smi uruchomione wewnątrz kontenera zazwyczaj pokazuje pustą listę procesów, ponieważ nie ma wglądu w identyfikatory procesów spoza własnej przestrzeni nazw, mimo że wskaźniki wykorzystania zasobów są odczytywane poprawnie. Pusta lista procesów wewnątrz kontenera nie jest błędem.

Gdy system przełącza się na przetwarzanie programowe bez powiadomienia

Jellyfin priorytetowo traktuje ciągłość odtwarzania. Gdy ścieżka sprzętowa jest niedostępna, system przełącza się na przetwarzanie programowe zamiast przerywać strumień. Wskaźnikiem problemu jest zatem obciążenie procesora oraz dziennik FFmpeg, a nie komunikat o błędzie.

Cannot load libnvcuvid.so.1 w dzienniku transkodowania oznacza, że biblioteka dekodera nie została zamontowana w kontenerze. Należy ustawić NVIDIA_DRIVER_CAPABILITIES=all i utworzyć kontener ponownie, ponieważ zmiana zmiennych środowiskowych wymaga docker compose up -d do przebudowania instancji, a zwykły restart zachowuje stare ustawienia.

No capable devices found z h264_nvenc oznacza, że FFmpeg uzyskał dostęp do biblioteki enkodera, ale nie wykrył sprawnej karty. Należy ponownie sprawdzić docker compose exec jellyfin nvidia-smi, ponieważ zazwyczaj oznacza to, że rezerwacja urządzenia została usunięta lub kontener został utworzony na podstawie nieaktualnego pliku.

Wysokie obciążenie procesora przy bezczynnym GPU oznacza, że dekodowanie kończy się niepowodzeniem bez zgłaszania błędu. Należy odznaczyć kodeki, których dana generacja sprzętu nie obsługuje, a następnie ponownie odtworzyć plik i sprawdzić w dzienniku FFmpeg, czy pojawia się -hwaccel cuda.

Transkodowanie, które uruchamia się, a następnie zawiesza przy materiale 4K HDR, podczas gdy 1080p działa poprawnie, wynika z ograniczeń mapowania tonów, a nie z błędnej instalacji. Należy potwierdzić to w kolumnie sm w nvidia-smi dmon -s u, a następnie obniżyć rozdzielczość żądaną przez klienta lub odtwarzać pliki 4K HDR wyłącznie na urządzeniach obsługujących direct play.

FAQ

Dlaczego Jellyfin nadal używa CPU po włączeniu NVENC?

Sprawdź najnowszy dziennik FFmpeg.Transcode w sekcji Dashboard, a następnie Logs. Jeśli zawiera on libx264, oznacza to, że ścieżka sprzętowa nie została użyta, co zazwyczaj wynika z braku dostępu kontenera do GPU; wykonaj docker compose exec jellyfin nvidia-smi, aby to potwierdzić. Jeśli dziennik zawiera h264_nvenc, a CPU jest nadal obciążone, dekodowanie odbywa się programowo. Dzieje się tak, gdy wybrano kodek nieobsługiwany przez kartę lub gdy opcja Enable hardware encoding pozostała wyłączona, przez co tylko część potoku została przeniesiona na GPU.

Czy nadal muszę używać linii runtime: nvidia w Docker Compose?

Nie, jeśli posiadasz blok deploy.resources.reservations.devices i aktualną wersję Docker Compose. Blok ten jest nowoczesną formą żądania urządzenia i wykonuje to samo zadanie. runtime: nvidia to starsza ścieżka z ery nvidia-docker2; nadal działa, a oficjalny przykład Jellyfin zawiera obie wersje. Pozostawienie obu jest bezpieczne. Użycie wyłącznie runtime: nvidia wymaga zachowania NVIDIA_VISIBLE_DEVICES=all, ponieważ ta ścieżka nie zawiera żądania urządzenia i pobiera listę urządzeń ze zmiennych środowiskowych.

Ile strumieni jednocześnie może transkodować jedna karta NVIDIA GPU?

Opublikowana przez NVIDIA macierz ogranicza karty GeForce do dwunastu jednoczesnych sesji kodowania (stan na sierpień 2026), natomiast karty klasy data center nie posiadają takich ograniczeń. Ten limit rzadko jest jednak główną przeszkodą. Mapowanie tonów HDR do SDR odbywa się na rdzeniach shaderowych, a nie na NVENC, więc kilka strumieni 4K HDR wyczerpie zasoby shaderów znacznie szybciej, niż zostanie osiągnięty limit sesji. Zmierz wydajność w swoim przypadku za pomocą nvidia-smi dmon -s u i obserwuj kolumnę sm, a nie liczbę sesji.

Czy mogę użyć transkodowania sprzętowego na VPS bez GPU?

Nie. Kodowanie wymaga fizycznego bloku NVENC, a lspci -nn | grep -Ei "3d|display|vga" na standardowym VPS wykazuje jedynie wirtualny adapter wyświetlania dostarczony przez hypervisor. Realnym rozwiązaniem w planie bez GPU jest wyeliminowanie transkodowania: ustaw jakość klienta na Auto, używaj natywnej aplikacji zamiast przeglądarki i konwertuj napisy oparte na obrazach na format tekstowy, aby nie wymuszały ponownego kodowania wideo.

Dlaczego 4K HDR zacina się, podczas gdy 1080p transkoduje się poprawnie?

Oba zadania wykorzystują różne części karty. Transkodowanie 1080p SDR to tylko dekodowanie i kodowanie, oba realizowane przez dedykowane bloki sprzętowe. Strumień 4K HDR dodaje mapowanie tonów, czyli filtr CUDA działający na rdzeniach shaderowych, oraz wymaga skalowania znacznie większych klatek. nvidia-smi dmon -s u wskazujące niskie wartości enc i dec przy wysokim sm potwierdza ten problem, ponieważ taki wzorzec oznacza, że bloki dedykowane są bezczynne, a ograniczeniem są rdzenie ogólnego przeznaczenia.