Transcodifica hardware NVIDIA di Jellyfin in Docker

Cosa si sta configurando

La transcodifica hardware di Jellyfin su una GPU NVIDIA richiede quattro passaggi in un ordine preciso; soltanto l’ultimo viene eseguito all’interno di Jellyfin. Il container non può vedere una GPU se il driver dell’host non l’ha caricata. Jellyfin non può usare una GPU che il container non riesce a vedere. Seguire questo ordine consente di individuare subito il punto in cui si verifica ogni errore.

1. Installare il driver NVIDIA sull’host, quindi verificarlo con nvidia-smi.
2. Installare NVIDIA Container Toolkit, in modo che Docker possa assegnare una GPU a un container.
3. Riservare la GPU al servizio Jellyfin in docker-compose.yml, quindi verificare che il container riesca a vederla.
4. Abilitare NVENC e NVDEC nelle impostazioni di riproduzione di Jellyfin, quindi verificare che una riproduzione reale li utilizzi.

NVENC (encoder NVIDIA) e NVDEC (decoder NVIDIA) sono blocchi a funzione fissa presenti sulla scheda. Sono circuiti distinti dai core shader che eseguono i carichi CUDA (compute unified device architecture). Questa separazione è il motivo principale per cui la configurazione è utile: un flusso che in modalità software occupa diversi core della CPU richiede soltanto una piccola parte di un core e un blocco hardware dedicato della GPU.

La riproduzione diretta è sempre preferibile alla transcodifica, quindi controlla prima questo aspetto

Prima di configurare qualsiasi componente, verifica se esiste un motivo per cui stai transcodificando e se puoi semplicemente rimuoverlo. Jellyfin transcodifica quando il client non riesce a riprodurre il file nel formato originale. Il motivo rientra quasi sempre in un elenco ristretto: codec video, codec audio, formato del contenitore, sottotitoli basati su immagini, limite di bitrate richiesto dal client oppure risoluzione o altro vincolo segnalato dal client.

Apri Dashboard, poi Playback, e osserva una sessione attiva mentre viene riprodotto un contenuto. Una sessione indicata come Direct playing invia il file senza modificarlo e richiede quasi nessuna CPU. Una sessione indicata come Transcoding mostra il motivo scelto da Jellyfin. Rimuovi quel motivo e la GPU non dovrà eseguire alcuna attività.

Due modifiche eliminano la maggior parte delle transcodifiche. Imposta la qualità dell'app client su Auto o sul valore massimo, perché un client che richiede 4 Mbps forza la ricodifica di un file da 20 Mbps, indipendentemente dal codec utilizzato. Usa quindi un'app client nativa invece di una scheda del browser, perché il browser è il lettore più limitato a tua disposizione e un'app nativa installata sullo stesso televisore riprodurrà spesso direttamente lo stesso file.

I sottotitoli basati su immagini sono l'eccezione che nessuna impostazione del client può risolvere. I sottotitoli PGS estratti da un Blu-ray e i VOBSUB estratti da un DVD sono immagini, quindi devono essere sovrapposti direttamente al video. Questo richiede una ricodifica completa del flusso video. I sottotitoli testuali in SRT vengono inviati al client come traccia separata e non richiedono risorse. Quando possibile, convertire le tracce dei sottotitoli in testo è più utile di una GPU. Per il resto della configurazione lato server, consulta la guida all'esecuzione di un server multimediale Jellyfin su un VPS.

La maggior parte dei piani VPS non include alcuna GPU

I piani VPS standard non includono una GPU. Esegui questo comando sul server prima di pianificare qualsiasi altra attività.

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

Su un VPS KVM tipico, questo comando mostra un adattatore video virtuale fornito dall’hypervisor oppure nulla di utile. Questo dispositivo non può codificare video. Una GPU reale è disponibile solo se il provider assegna alla tua istanza una scheda fisica tramite passthrough oppure una sua porzione. I relativi piani hanno un prezzo adeguato. Quali carichi di lavoro giustificano realmente il costo di un VPS con GPU spiega chi dovrebbe acquistarli e chi no.

Se non è presente una GPU, punta al direct play e considera la transcodifica software un caso raro. Una singola transcodifica software 1080p H.264 è impegnativa, ma può essere gestita da alcuni core della CPU. Una transcodifica software 4K HDR con tone mapping non può essere completata in tempo reale da un VPS di piccole dimensioni. Di conseguenza, lo streaming procede a scatti mentre la CPU resta al 100 percent.

Installare il driver NVIDIA sull'host

Jellyfin 10.11 indica come versione minima del driver NVIDIA su Linux la 520.56.06. Ubuntu include uno strumento che seleziona automaticamente un pacchetto compatibile.

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

--gpgpu seleziona la variante del driver per server headless, adatta a un media server perché sul sistema non è presente un ambiente desktop. Il comando list elenca i rami disponibili e consente di bloccarne uno indicando il nome, ad esempio sudo ubuntu-drivers install --gpgpu nvidia:570-server. Usare un ramo effettivamente elencato dal comando, non quello riportato in questo esempio.

La variante per server non installa sempre nvidia-smi. Installare il pacchetto utils corrispondente al ramo scelto, ad esempio sudo apt install nvidia-utils-570-server. Quindi verificare il driver.

nvidia-smi

Un risultato corretto mostra nell’intestazione una tabella con la versione del driver e la versione di CUDA, elenca la scheda per nome e presenta un elenco dei processi vuoto. In questo caso sono comuni due errori. nvidia-smi: command not found indica che manca il pacchetto utils, non il driver. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver indica che il modulo del kernel non è caricato. Dopo una nuova installazione, nella maggior parte dei casi significa che il sistema non è ancora stato riavviato oppure che Secure Boot impedisce di caricare un modulo non firmato. Verifica che il modulo sia presente con lsmod | grep nvidia. Se il comando non restituisce nulla e sudo modprobe nvidia restituisce un errore con Key was rejected by service, Secure Boot sta bloccando il modulo. La procedura per rimuovere il rifiuto della chiave da parte di Secure Boot illustra come verificare lo stato del firmware e quindi registrare una chiave del proprietario della macchina oppure disabilitare l'imposizione.

Installare NVIDIA Container Toolkit

Il driver consente all'host di utilizzare la GPU. Docker, però, non la passa ancora al container, perché il container non dispone né dei nodi del dispositivo né delle librerie del driver. NVIDIA Container Toolkit inserisce entrambi all'avvio del container. Questi comandi seguono la procedura di installazione ufficiale di NVIDIA per Debian e Ubuntu. La guida attuale di NVIDIA vincola inoltre i pacchetti del toolkit a una singola release tramite una variabile di versione; omettendo il vincolo, come in questo caso, viene installata la release più recente disponibile nel repository.

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

Installare il pacchetto non è sufficiente, perché è necessario comunicare a Docker che il runtime è disponibile.

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

nvidia-ctk runtime configure scrive una voce di runtime nvidia in /etc/docker/daemon.json. Il riavvio è il passaggio che spesso viene saltato; ometterlo produce l'errore più comune dell'intera configurazione. Verificate il funzionamento dell'integrazione prima di intervenire su Jellyfin.

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

Dovrebbe stampare la stessa tabella visualizzata dall'host. Se invece restituisce un errore che indica l'impossibilità di selezionare un driver del dispositivo con funzionalità gpu, il daemon Docker non conosce il runtime nvidia. Eseguite nuovamente il comando di configurazione e riavviate il daemon.

Assegnare la GPU al container Jellyfin in Docker Compose

Questa è la sintassi Compose moderna. Si basa sull'esempio pubblicato da Jellyfin e specifica esplicitamente le due variabili d'ambiente NVIDIA.

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]

Avvia il container e interroga direttamente l'ambiente al suo interno.

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

Se viene visualizzata la tabella dei driver dal container, il pass-through della GPU funziona correttamente. Ogni problema restante riguarda quindi una configurazione di Jellyfin.

Quattro righe di quel file richiedono una spiegazione. capabilities: [gpu] è obbligatoria per Compose stesso. Se viene omessa, Compose rifiuta il servizio invece di avviarlo senza GPU. NVIDIA_DRIVER_CAPABILITIES=all è importante perché il toolkit monta le librerie video nel container soltanto quando viene richiesta la funzionalità video. Se la variabile non è impostata, il valore predefinito include soltanto le funzionalità utility e compute. L'immagine ufficiale di Jellyfin la imposta già. Nell'immagine ufficiale, quindi, questa riga protegge da eventuali sovrascritture. La documentazione di Jellyfin specifica che devi aggiungerla manualmente se crei una tua immagine. Senza la funzionalità video, CUDA funziona ma NVDEC no, e il log della transcodifica riporta Cannot load libnvcuvid.so.1. network_mode: host è il valore usato dall'esempio NVIDIA ufficiale di Jellyfin. La guida ai container di Jellyfin indica la rete host come facoltativa, ma necessaria per DLNA. Se usi invece una rete bridge, devi pubblicare manualmente 8096/tcp e la porta di auto-discovery 7359/udp.

user: 1000:1000 è l'ultima impostazione e non riguarda la GPU. Determina quali file Jellyfin può leggere nel mount dei contenuti multimediali. Se il valore non corrisponde, nella libreria non vengono visualizzati contenuti invece di comparire un errore di autorizzazioni. Come PUID e PGID associano un utente del container ai file sul disco spiega la numerazione. È la stessa numerazione che hai già impostato se esegui lo stack Sonarr e Radarr in Docker Compose insieme a questo.

Perché la maggior parte dei tutorial usa ancora runtime: nvidia

La forma precedente compare in quasi tutte le guide disponibili e non è errata. È una conseguenza della storia del software. Il pacchetto nvidia-docker2 originale registrava un runtime OCI denominato nvidia, quindi l'unico modo per rendere disponibile una GPU in un container era usare --runtime=nvidia insieme a NVIDIA_VISIBLE_DEVICES. Docker 19.03 ha aggiunto il flag --gpus e una vera API per le richieste dei dispositivi. Compose ha impiegato più tempo per adeguarsi e, quando lo ha fatto, la richiesta del dispositivo è stata inserita in deploy.resources.reservations.devices, una chiave che molti avevano imparato a ignorare perché deploy in precedenza indicava Docker Swarm.

Di conseguenza, oggi entrambe le forme funzionano e l'esempio pubblicato da Jellyfin le include entrambe. Mantenere runtime: nvidia non comporta costi e rende il file compatibile con le versioni precedenti di Compose. Se mantieni soltanto runtime: nvidia e rimuovi il blocco deploy, devi mantenere NVIDIA_VISIBLE_DEVICES=all, perché quel percorso legacy legge la variabile d'ambiente per decidere quali dispositivi inserire e non ha una richiesta di dispositivo alternativa da leggere.

Attivare la transcodifica hardware NVIDIA in Jellyfin

Finora nessuna impostazione ha indicato a Jellyfin di usare la scheda. Aprire Dashboard, quindi Playback e Transcoding. Impostare Hardware acceleration su Nvidia NVENC. Selezionare Enable hardware encoding; in caso contrario Jellyfin decodifica sulla GPU e poi codifica sulla CPU. Si crea così uno stato intermedio fuorviante, in cui la GPU mostra attività ma la CPU continua a essere utilizzata intensamente.

Attivare Enable enhanced NVDEC decoder per scegliere il percorso NVDEC attuale invece del precedente percorso CUVID. Lasciarlo attivo. La gestione di Dolby Vision richiede questa opzione per usare NVDEC.

In Enable hardware decoding for, selezionare soltanto i codec che la scheda è effettivamente in grado di decodificare. È questa l'impostazione che causa più errori. Se si seleziona AV1 su una scheda priva di decoder AV1, non viene visualizzato alcun messaggio di errore. Jellyfin richiede la decodifica hardware, non la ottiene e passa alla decodifica software. Il risultato è un utilizzo elevato della CPU e una GPU quasi inattiva, esattamente come se il passthrough non avesse mai funzionato.

Si applica inoltre un'ulteriore limitazione all'intera pagina: l'accelerazione hardware è pienamente supportata soltanto con la build jellyfin-ffmpeg inclusa nel pacchetto. La documentazione di Jellyfin avverte che i binari FFmpeg provenienti da altre fonti consentono soltanto un'accelerazione parziale. Se il percorso di FFmpeg è stato impostato su un'installazione di sistema di FFmpeg, ripristinare il valore precedente.

Quali codec la tua generazione di GPU può decodificare e codificare

Questi sono i limiti documentati da Jellyfin per NVENC e NVDEC. La decodifica e la codifica sono capacità separate: una scheda può supportare l'una senza supportare l'altra.

• H.264 8-bit: ogni GPU NVIDIA con NVENC e NVDEC lo decodifica e lo codifica.
• HEVC 8-bit: decodifica e codifica dalla seconda generazione Maxwell (GM206) in poi.
• HEVC 10-bit: decodifica dalla seconda generazione Maxwell in poi, ma in quella generazione il supporto è presente solo nelle varianti GM206; la codifica è invece disponibile solo da Pascal in poi.
• AV1: decodifica da Ampere in poi, ad eccezione del chip per data center GA100 (la tabella dei decoder NVIDIA indica inoltre che Hopper non supporta la decodifica AV1); codifica da Ada Lovelace in poi, supportata da Jellyfin a partire dalla versione 10.9.

La distinzione relativa a HEVC 10-bit è quella che crea più problemi nella pratica. Una scheda Maxwell basata su GM206 decodifica il file 4K HDR sulla GPU, ma non può codificare un'uscita a 10-bit; Jellyfin codifica quindi in H.264 8-bit. Gli altri chip Maxwell non decodificano affatto HEVC 10-bit tramite hardware. L'uscita H.264 8-bit continua a essere riproducibile ed è comunque la scelta corretta per la maggior parte dei client. Nel 2026, la codifica AV1 è raramente la scelta desiderata, indipendentemente dalla scheda, perché il supporto alla decodifica AV1 lato client è ancora limitato e un transcodifica serve proprio per raggiungere un client che aveva già difficoltà di riproduzione.

Perché il tone mapping riporta silenziosamente la GPU a pieno carico

Il tone mapping da HDR (high dynamic range) a SDR (standard dynamic range) è l'impostazione che annulla il margine disponibile sulla GPU, per motivi architetturali. La decodifica viene eseguita da NVDEC. La codifica viene eseguita da NVENC. Il tone mapping non viene eseguito da nessuno dei due: è un filtro CUDA che viene eseguito sugli shader core, la stessa parte general-purpose della GPU che esegue i carichi di calcolo. Di conseguenza, uno stream 4K HDR che richiede il tone mapping usa il decoder e l'encoder, oltre a caricare gli shader.

Jellyfin documenta il tone mapping CUDA come disponibile su ogni GPU NVIDIA in grado di decodificare HEVC 10-bit. La casella di controllo compare quindi e funziona anche su schede che non riescono a sostenerlo a 4K. Il sintomo è uno stream che parte, entra in buffering e non si stabilizza mai, mentre nvidia-smi indica che l'encoder è utilizzato a malapena.

Per questo è utile monitorare separatamente il carico degli shader.

nvidia-smi dmon -s u

Il comando stampa una riga al secondo, con colonne separate per sm, enc e dec. Valori bassi per enc e dec insieme a un valore sm elevato indicano che il carico riguarda gli shader anziché i blocchi a funzione fissa; il costo probabile è quindi dovuto al tone mapping, allo scaling o al burn-in dei sottotitoli. Consideralo un'indicazione, non una prova: NVIDIA definisce l'utilizzo della GPU come la percentuale del periodo di campionamento durante la quale era in esecuzione almeno un kernel. Un valore elevato indica quindi che gli shader erano occupati, non che erano saturi. Il percorso CUDA gestisce inoltre Dolby Vision profile 5 con zero copy. Questo è importante perché, senza zero copy, i frame vengono trasferiti nella memoria di sistema e poi riportati indietro tra i passaggi del filtro; ogni frame genera quindi un ulteriore consumo di banda.

Il vero limite imposto dal tetto alle sessioni NVENC delle GPU consumer

[
  {
    "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
  }
]

Questi sono i valori pubblicati da NVIDIA nella relativa matrice a ottobre 2026, non misurazioni effettuate in questa sede. Una scheda GeForce è limitata a 12 sessioni di codifica simultanee, indipendentemente dal modello. Il limite è imposto dal driver e non dal silicio. NVIDIA lo ha aumentato più volte nel corso degli anni. Consultate quindi la matrice corrente e non una vecchia discussione su un forum. Il numero di engine è l'aspetto che cambia effettivamente in base alla scheda: GeForce RTX 5090 dispone di 3 engine NVENC, mentre GeForce RTX 4060 ne dispone di 1. Un numero maggiore di engine aumenta la capacità di codifica parallela, ma non il numero massimo di sessioni.

Il limite conta le sessioni di codifica, quindi riguarda soltanto i flussi transcodificati. La riproduzione diretta e il remuxing non aprono mai una sessione di codifica. Le schede per data center, come L4, sono indicate come prive di limitazioni nella stessa matrice. Una scheda per data center è in genere quella fornita da un piano GPU VPS. Per questo motivo, il limite riguarda soprattutto i server domestici.

Quando raggiungete il limite, la transcodifica non riesce e il log di FFmpeg contiene OpenEncodeSessionEx failed: out of memory (10). Il messaggio indica la memoria, ma anche un rifiuto dovuto al limite di sessioni restituisce lo stesso codice. Controllate quindi il numero di flussi simultanei prima di cercare una perdita di VRAM. Nella pratica, la maggior parte degli utenti raggiunge il limite del tone mapping o della larghezza di banda in upload molto prima della dodicesima sessione.

Verificare che la GPU esegua la transcodifica senza affidarsi alla configurazione

Un’impostazione salvata non costituisce una prova. Riproduci un file che sai per certo richiedere la transcodifica, quindi esegui questi tre controlli.

1. Apri Dashboard, quindi Playback. La sessione attiva deve indicare Transcoding e specificarne il motivo. Se indica Direct playing, non è in corso alcuna transcodifica e stai verificando il file sbagliato.
2. Apri Dashboard, quindi Logs, e apri il log FFmpeg.Transcode più recente. Una transcodifica hardware completa mostra -hwaccel cuda e -hwaccel_output_format cuda nella riga di comando, insieme a un encoder NVENC come h264_nvenc o hevc_nvenc, oppure all’encoder AV1 NVENC su Ada Lovelace e versioni successive. Se compare libx264, la codifica viene eseguita via software, indipendentemente da quanto indicato nella pagina delle impostazioni. L’assenza di -hwaccel cuda con un encoder NVENC indica che la decodifica viene eseguita via software.
3. Esegui nvidia-smi sull’host mentre la riproduzione continua. Deve comparire un processo di /usr/lib/jellyfin-ffmpeg/ffmpeg con memoria GPU allocata e nvidia-smi dmon -s u deve mostrare valori diversi da zero nelle colonne enc e dec.

Esegui il terzo controllo sull’host, non all’interno del container. nvidia-smi eseguito all’interno di un container mostra solitamente un elenco di processi vuoto, perché non può visualizzare gli ID dei processi esterni al proprio namespace, mentre i valori di utilizzo vengono comunque letti correttamente. Un elenco di processi vuoto all’interno del container non indica un errore.

Quando passa al software senza avvisare

Jellyfin cerca di continuare la riproduzione. Quando un percorso hardware non è disponibile, passa al software invece di interrompere lo streaming. Il segnale più affidabile è quindi il carico della CPU e il log di FFmpeg, non un banner di errore.

Cannot load libnvcuvid.so.1 nel log della transcodifica indica che la libreria del decoder non è mai stata montata nel container. Imposta NVIDIA_DRIVER_CAPABILITIES=all e ricrea il container, perché una modifica dell'ambiente richiede docker compose up -d per ricrearlo. Un semplice riavvio conserva le impostazioni precedenti.

No capable devices found da h264_nvenc indica che FFmpeg ha raggiunto la libreria dell'encoder, ma non ha trovato alcuna scheda utilizzabile. Controlla di nuovo docker compose exec jellyfin nvidia-smi, perché in genere significa che la prenotazione del dispositivo è stata rimossa oppure che il container è stato ricreato a partire da un file obsoleto.

Un uso elevato della CPU con una GPU quasi inattiva indica spesso che la decodifica sta fallendo senza messaggi evidenti. Deseleziona i codec che la tua generazione hardware non può decodificare, quindi riproduci di nuovo lo stesso file e rileggi il log di FFmpeg per verificare se compare -hwaccel cuda. Se compare e la CPU continua a essere occupata, cerca una fase che Jellyfin non può eseguire sulla GPU, ad esempio il burn-in dei sottotitoli grafici.

Una transcodifica che inizia e poi si blocca con contenuti 4K HDR, mentre 1080p funziona, è in genere limitata dal tone mapping e non da un'installazione danneggiata. Controlla la colonna sm in nvidia-smi dmon -s u, quindi riproduci di nuovo lo stesso file con il tone mapping disattivato. Se lo streaming diventa stabile, il limite era il tone mapping. In questo caso, riduci la risoluzione richiesta dal client oppure mantieni i file 4K HDR sui client che possono riprodurli direttamente.

FAQ

Perché Jellyfin continua a usare la CPU dopo l'abilitazione di NVENC?

Controlla il log FFmpeg.Transcode più recente in Dashboard, quindi Logs. Se contiene libx264, la codifica viene eseguita via software. Se manca anche -hwaccel cuda, non è stato usato alcun percorso hardware: in genere il container non riesce a vedere la GPU, quindi esegui docker compose exec jellyfin nvidia-smi per verificare. Se -hwaccel cuda compare accanto a libx264, la decodifica ha raggiunto la GPU, ma Enable hardware encoding è rimasto disattivato. Se compare h264_nvenc senza -hwaccel cuda, la decodifica viene eseguita via software. Questo accade quando il codec del file non è selezionato in Enable hardware decoding for oppure quando è selezionato un codec che la scheda non sa decodificare. Se sono presenti entrambi e la CPU è ancora sotto carico, il carico proviene da una fase che resta sulla CPU, ad esempio il rendering permanente dei sottotitoli.

Serve ancora la riga runtime: nvidia in Docker Compose?

No, se hai il blocco deploy.resources.reservations.devices e una versione aggiornata di Docker Compose. Il blocco è la forma moderna per richiedere i dispositivi e svolge la stessa funzione. runtime: nvidia è il metodo precedente, risalente all'epoca di nvidia-docker2. Funziona ancora e l'esempio pubblicato da Jellyfin mantiene entrambe le forme. Mantenerle entrambe non causa problemi. Se mantieni soltanto runtime: nvidia, devi mantenere anche NVIDIA_VISIBLE_DEVICES=all, perché questo metodo non contiene una richiesta di dispositivi da leggere e ricava l'elenco dei dispositivi dall'ambiente.

Quanti stream può transcodificare contemporaneamente una GPU NVIDIA?

La matrice pubblicata da NVIDIA limita le schede GeForce a dodici sessioni di codifica simultanee a ottobre 2026, mentre le schede dei data center sono indicate come non soggette a limiti. Questo limite raramente è il fattore determinante. La conversione dei toni da HDR a SDR viene eseguita dagli shader core, non da NVENC. Di conseguenza, pochi stream 4K HDR possono saturare gli shader molto prima che il contatore delle sessioni diventi rilevante. Misura il tuo caso con nvidia-smi dmon -s u e controlla la colonna sm, non il numero di sessioni.

Posso usare la transcodifica hardware su un VPS senza GPU?

No. La codifica richiede il blocco NVENC fisico e, su un VPS standard, lspci -nn | grep -Ei "3d|display|vga" mostra soltanto un adattatore video virtuale fornito dall'hypervisor. Su un piano senza GPU, la soluzione realistica è evitare le transcodifiche: aumenta la qualità del client su Auto, usa un'app client nativa invece del browser e converti le tracce dei sottotitoli basate su immagini in testo, così non forzano una nuova codifica video.

Perché il 4K HDR scatta mentre la transcodifica 1080p funziona correttamente?

I due carichi usano componenti diversi della scheda. Una transcodifica 1080p SDR usa principalmente la decodifica e la codifica, entrambe eseguite dall'hardware a funzione fissa quando la scheda supporta il codec, oltre alle operazioni di ridimensionamento, deinterlacciamento o rendering permanente dei sottotitoli richieste dallo stream. Uno stream 4K HDR aggiunge la conversione dei toni, che è un filtro CUDA eseguito dagli shader core, oltre a un frame molto più grande da ridimensionare. nvidia-smi dmon -s u con valori enc e dec bassi accanto a un valore sm elevato indica questa situazione: i blocchi a funzione fissa sono poco utilizzati, mentre gli shader sono sotto carico. Riproduci nuovamente il file con la conversione dei toni disattivata per confermare la causa.