Encoder video hardware a confronto: NVENC vs AMF vs QuickSync vs Apple VideoToolbox.

Quattro produttori. Quattro blocchi di silicio a funzione fissa. Un solo compito: trasformare un fotogramma di pixel in pochi kilobyte di H.265 o AV1 in meno di cinque millisecondi, sessanta volte al secondo, senza perderne nessuno. Ecco come si confrontano davvero NVIDIA, AMD, Intel e Apple per lo streaming a bassa latenza, e come Remio sceglie quello giusto a runtime.

Perché gli encoder hardware contano per il desktop remoto

Codifica un singolo fotogramma 1080p con libx264 su un core di CPU veloce. Su un moderno Apple serie M o su un Ryzen 7000 puoi arrivare a circa 8–12 millisecondi con il preset ultrafast, di più per tutto ciò che cerca di preservare la qualità. Sembra tollerabile finché non ricordi il budget: 16,6 millisecondi per fotogramma a 60 FPS. Ora aggiungi cattura, impacchettamento, coda del pacer, uscita di rete, decodifica e rendering. La codifica su CPU non si limita a rallentarti: si mangia l'intero budget di latenza e, oltre i 1080p60, perde fotogrammi.

Gli encoder hardware risolvono il problema dedicando silicio a funzione fissa allo stesso compito. NVIDIA chiama il suo blocco NVENC. AMD chiama il suo AMF (più precisamente il motore VCN pilotato da AMF). Intel chiama il suo QuickSync (il Media Engine dentro la sua iGPU). Apple chiama il suo VideoToolbox (l'API; il silicio è il Media Engine nei chip serie M e serie A). Tutti e quattro esistono per un solo motivo: la codifica software non riesce a rispettare gli obiettivi di latenza e frame rate che schermi, GPU e utenti moderni ormai si aspettano.

Per Remio in particolare, ogni millisecondo risparmiato all'encoder è un millisecondo che l'utente recupera al pacer, in rete e al renderer. Il nostro budget di latenza pubblicato punta a circa 8 ms di elaborazione in LAN (il resto è il ritmo di aggiornamento a 60 Hz del tuo schermo): il tempo di codifica è la singola variabile più grande. La scelta dell'encoder e la sua configurazione determinano tutto ciò che viene dopo.

I quattro produttori a colpo d'occhio

Prima di approfondire ciascuno, conviene capire cosa stiamo davvero confrontando. Non sono librerie intercambiabili: sono blocchi fisici su un die, ciascuno con la propria ISA, il proprio stack di driver, le proprie stranezze e la propria roadmap pluriennale. Differiscono per codec supportati, qualità prodotta, latenza raggiunta, energia assorbita e per le piattaforme su cui esistono.

• NVENC è presente su ogni NVIDIA GeForce, Quadro e RTX dal 2012 (Kepler). Le generazioni seguono le famiglie di architetture: 1ª gen su Kepler, 8ª gen su Ada Lovelace. I componenti Hopper per datacenter hanno una cadenza diversa.
• AMF espone il motore VCN (Video Core Next) di AMD, che ha sostituito il vecchio VCE. Disponibile su ogni GPU Vega, RDNA, RDNA2 e RDNA3, oltre alle APU più recenti.
• QuickSync è presente nelle iGPU Intel da Sandy Bridge nel 2011, il che lo rende l'encoder hardware più diffuso sulla Terra. Le GPU discrete Arc usano la stessa architettura, in scala maggiore.
• VideoToolbox è l'API di Apple; il silicio sottostante è il Media Engine, integrato in ogni Mac Apple Silicon, ogni iPhone dall'A6 e ogni iPad. I chip serie M montano uno o due motori a seconda della versione.

NVENC — otto generazioni di perfezionamento di NVIDIA

NVENC è l'encoder con cui si confronta la maggior parte del software di streaming, in parte perché NVIDIA ha il budget di marketing e in parte perché il silicio è davvero stato eccellente per un decennio. Il blocco ha attraversato otto generazioni:

• 1ª–3ª gen (da Kepler a Maxwell, 2012–2014): solo H.264, valido per lo streaming ma con qualità inferiore a libx264 in modo netto.
• 4ª gen (Pascal, GTX serie 10): aggiunta la codifica H.265. È la generazione in cui la qualità di NVENC ha raggiunto e, si può dire, superato i preset fast di libx264 allo stesso bitrate.
• 6ª gen (Turing, RTX serie 20, GTX serie 16): il salto spesso citato come «NVENC di Turing». La qualità a bassi bitrate è migliorata a tal punto che gli streamer hanno smesso di fingere che la codifica su CPU fosse davvero migliore per i casi d'uso dal vivo.
• 7ª gen (Ampere, RTX serie 30): perfezionamenti, qualità sostanzialmente equivalente a Turing per watt.
• 8ª gen (Ada Lovelace, RTX serie 40): prima generazione NVIDIA con codifica AV1 hardware, più doppio motore di codifica sulle versioni di fascia alta. NVENC di Ada può fare AV1 con una qualità competitiva con i preset medium di libaom-av1 a una minima frazione del costo di CPU.

Per l'uso a bassa latenza, NVENC espone tre modalità di controllo del bitrate rilevanti. CBR con ottimizzazione low-latency e preset p1 (il più veloce) è la configurazione canonica: velocità di uscita deterministica, lookahead di un solo fotogramma, nessun B-frame. Remio usa esattamente questa configurazione con hevc_nvenc su Windows. Il tempo di codifica su Ada Lovelace a 1080p60 H.265 è costantemente di 1–3 ms.

Un'insidia storica: per anni l'NVENC consumer era limitato a tre sessioni di codifica simultanee dal driver NVIDIA. Quel limite è stato portato a otto nel 2023 e poi di fatto rimosso. Se stai leggendo un vecchio thread di forum che lo segnala, l'avviso non vale più.

AMF — l'outsider di AMD che ha finalmente recuperato

AMF (Advanced Media Framework) di AMD è l'API; il motore sottostante ha attraversato due architetture distinte. Il vecchio VCE (Video Coding Engine) era presente sulle schede dell'era GCN dal 2012 ed è stato il perenne punto debole nei confronti diretti tra encoder: qualità visibilmente peggiore di NVENC a parità di bitrate, soprattutto sui contenuti con molto movimento. AMD lo sapeva, la community dello streaming lo sapeva e i benchmark lo confermavano.

Quella storia è cambiata con VCN (Video Core Next), introdotto con Vega e perfezionato a ogni generazione successiva:

• VCN 1.0–2.0 (Vega, RDNA1): H.264 e H.265 con una qualità che finalmente si è avvicinata di un soffio a NVENC Pascal/Turing.
• VCN 3.0 (RDNA2, serie RX 6000): miglioramenti significativi della qualità, in particolare a bassi bitrate. La prima generazione AMD che mi sento di consigliare per lo streaming di giochi.
• VCN 4.0 (RDNA3, serie RX 7000): aggiunge la codifica AV1 in parallelo con NVIDIA Ada. Due encoder sulle versioni di fascia alta per sessioni parallele. La qualità AV1 è competitiva con quella di NVIDIA nei benchmark di terze parti.

Per lo streaming a bassa latenza, AMF espone un preset di utilizzo ultralowlatency, un preset di qualità speed e una modalità di controllo del bitrate cbr. Remio usa hevc_amf con tutti e tre, lo stesso trio di preset documentato nelle nostre note sull'architettura di streaming. Il tempo di codifica su RDNA3 a 1080p60 H.265 sta di solito tra 2 e 4 ms. RDNA2 è intorno a 3–5 ms. Le schede più vecchie dell'era VCN 1.x vanno più vicine a 5–7 ms: ancora dentro il budget, ma con meno margine per i picchi dei keyframe.

Per cinque anni l'encoder di AMD è stato una barzelletta. RDNA2 lo ha sistemato. RDNA3 lo ha reso competitivo su AV1. Il duopolio degli encoder per lo streaming ora è un triopolio, ed è un bene per tutti.

QuickSync — il campione silenzioso dell'ubiquità

QuickSync è l'encoder che quasi certamente possiedi già. È presente in ogni CPU Intel con grafica integrata da Sandy Bridge nel 2011: oltre un decennio di portatili, NUC e desktop da ufficio con codifica video hardware inutilizzata perché l'utente pensava di aver bisogno di una GPU discreta. Non era così.

L'architettura è progredita di pari passo con la linea delle iGPU di Intel:

• Da Sandy Bridge a Skylake (2011–2015): solo H.264, qualità mediocre, ma latenza ed energia al top della classe per un portatile.
• Da Kaby Lake a Coffee Lake (2016–2018): aggiunti H.265, 10 bit e codifica 4K.
• Da Ice Lake in poi (2019+): la iGPU Xe Gen11/Gen12 ha migliorato drasticamente la qualità. Molti benchmark collocano QuickSync Gen12 a pochi punti percentuali da NVENC Turing.
• Arc discrete (2022+): la prima linea di GPU discrete di Intel. Stessa architettura Xe-HPG in scala maggiore, con codifica AV1. Arc è stata la prima GPU consumer a offrire AV1 hardware, battendo sul mercato NVIDIA Ada e AMD RDNA3, e la qualità è sorprendentemente eccellente. Una Intel Arc A380 resta un affare assurdo per pura capacità AV1 per dollaro.

Il profilo termico è il superpotere silenzioso di QuickSync. Poiché vive dentro una iGPU già presente sul SoC, il costo marginale per usarlo è solo il blocco di codifica: niente risveglio di una GPU discreta, niente accensione dei controller di memoria GDDR6. Su un ThinkPad o un NUC, QuickSync offre una qualità paragonabile a NVENC con circa un quarto dell'energia a livello di sistema. Per l'host Windows di Remio, QuickSync è il ripiego di terza scelta dopo NVENC e AMF, non perché sia peggiore, ma perché chi ha GPU discrete di solito vuole la iGPU libera per altri carichi.

VideoToolbox — il Media Engine unificato di Apple Silicon

Apple non dà un nome commerciale al proprio encoder hardware come fa NVIDIA. L'API è VideoToolbox; il silicio è il Media Engine, un blocco progettato da Apple che vive dentro ogni Mac serie M e ogni SoC di iPhone/iPad dall'A6.

Il Media Engine è presente in numero diverso a seconda della versione:

• M1, M2, M3: un Media Engine.
• M1 Pro/Max, M2 Pro/Max, M3 Pro/Max: due Media Engine.
• M1 Ultra, M2 Ultra: quattro Media Engine (due per ogni die fuso).
• M3 Max (CPU a 16 core): due Media Engine.
• Famiglia M4: Media Engine rinnovato con throughput H.265 migliorato.

Ogni Media Engine gestisce in hardware codifica e decodifica di H.264, H.265 e ProRes. La codifica ProRes è la funzione di punta per chi monta video (nessun altro chip consumer la offre), ma per lo streaming le capacità rilevanti sono una codifica H.265 main10 efficiente e una latenza di codifica sorprendentemente bassa.

La lacuna notevole: nessuna codifica AV1 su alcun Apple Silicon in commercio. I chip serie M decodificano AV1 dall'M3, ma non possono codificarlo. Per lo streaming da un Mac, H.265 è la scelta pratica predefinita per il prossimo futuro.

Dove Apple vince davvero è l'efficienza energetica. Su un M2 Pro che codifica 4K60 H.265 a 30 Mbps, l'intero Media Engine assorbe circa 3–5 watt. Il carico NVENC equivalente su una RTX 4070 assorbe più vicino a 35 watt a livello di sistema, in gran parte il consumo a riposo della GPU discreta, non il blocco encoder. Per un host Mac mini acceso 24 ore su 24 in attesa di un client, è la differenza tra «quasi invisibile in bolletta» e «visibile».

Confronto affiancato

Ecco i quattro motori sugli stessi assi. I valori di latenza sono per preset H.265 1080p60 a bassissima latenza, B-frame disattivati, VBV di un fotogramma: la configurazione di Remio. La qualità è una classifica percettiva approssimativa a 8 Mbps CBR; le differenze assolute sono piccole.

Il riassunto onesto: con le impostazioni che lo streaming da desktop remoto usa davvero (CBR, bassa latenza, niente B-frame), tutti e quattro sono abbastanza buoni con un margine ampio. Le differenze stanno nel supporto AV1 (NVIDIA / AMD / Intel, non Apple), nell'efficienza energetica (Apple, poi la iGPU Intel, poi tutti gli altri) e nella disponibilità sulle piattaforme (non puoi scegliere VideoToolbox su un host Windows o NVENC su un Mac).

Cosa sceglie Remio a runtime

Remio rileva le capacità dell'host all'avvio e sceglie un encoder in base a una priorità deterministica. L'host Windows e l'host Mac seguono la stessa logica di selezione.

Sugli host Windows:

1. NVENC (hevc_nvenc / h264_nvenc): scelto per primo quando è presente una GPU NVIDIA e il driver risponde. Preferito perché è l'encoder a bassa latenza più costante sulla più ampia gamma di generazioni hardware.
2. AMF (hevc_amf / h264_amf): scelto per secondo quando è presente una GPU discreta AMD o una APU con VCN. Configurato con usage=ultralowlatency, quality=speed, rc=cbr.
3. QuickSync (hevc_qsv / h264_qsv): scelto per terzo quando è presente una iGPU Intel. Funzionalmente equivalente nella nostra pipeline; preferiamo lasciare libera la iGPU se è disponibile una GPU discreta.
4. Ripiego su CPU con libx264: scelto solo quando nessun encoder hardware risponde. Limitato a 720p60 o 1080p30 per restare nel budget di latenza.

Sugli host Apple: VideoToolbox è l'unica opzione, e l'unica che vogliamo. Il Media Engine di ogni Mac supportato (macOS 15+) gestisce H.265 main10 senza configurazioni. Nessun percorso di ripiego necessario.

La preferenza di codec è H.265 hardware per primo, H.264 come ripiego universale, da un capo all'altro e su ogni piattaforma. Remio oggi non usa AV1 (codifica sull'host, decodifica sul client e negoziazione del codec non sono nella pipeline); si attiene a H.265 anche su hardware che tecnicamente potrebbe fare AV1, perché in LAN il collo di bottiglia è la latenza di codifica, non il bitrate.

Compromessi tra qualità e latenza

Ogni encoder hardware espone la stessa manciata di manopole, e ogni manopola scambia qualità con latenza nella stessa direzione. La configurazione di Remio sta all'estremo più aggressivo del quadrante della latenza, perché il desktop remoto è per definizione un'applicazione in tempo reale in cui un fotogramma più vecchio di 20 ms è peggio di uno leggermente più sfocato del ideale.

• CBR vs VBR. Il bitrate variabile produce qualità migliore alla stessa velocità media spendendo i bit dove servono. Ma il VBR produce anche una dimensione per fotogramma imprevedibile, quindi code del pacer imprevedibili, quindi latenza imprevedibile. Remio usa CBR ovunque. Il costo in qualità è piccolo; la costanza della latenza è enorme.
• B-frame. I B-frame fanno riferimento sia a fotogrammi passati sia futuri, quindi il decodificatore deve attendere l'arrivo del fotogramma futuro prima di decodificare il B-frame. Va bene per il video on demand ed è fatale per il tempo reale. Remio disattiva i B-frame su ogni codec e su ogni piattaforma.
• GOP / intervallo dei keyframe. GOP più lunghi (più fotogrammi tra un keyframe e l'altro) comprimono meglio. GOP più corti si riprendono più in fretta dalla perdita di pacchetti. Remio usa GOP di fatto infiniti e chiede all'host un nuovo keyframe quando il decodificatore segnala una perdita. Un pacchetto perso viene rinviato subito se può ancora arrivare in tempo; se non può, Remio lo salta e chiede un fotogramma nuovo invece di aspettare. Questo è coerente con la nostra filosofia di streaming di mostrare solo l'ultimo fotogramma.
• Lookahead. NVENC, AMF e QuickSync supportano tutti il lookahead su più fotogrammi per la quantizzazione adattiva. Ogni fotogramma di lookahead aggiunge un fotogramma intero di ritardo. Remio usa lookahead zero o di un solo fotogramma, l'impostazione più bassa di ogni encoder.
• Buffer VBV. La finestra del Video Buffering Verifier indica quanti bit l'encoder può «prendere in prestito in anticipo» prima di tornare alla velocità obiettivo. Un VBV più grande dà una qualità più uniforme. Un VBV più piccolo dà un controllo del bitrate più stretto e una latenza più bassa. Remio usa 1 fotogramma di VBV (il bitrate diviso per il frame rate), il valore minimo consentito.

Lo schema è coerente tra tutti e quattro i produttori. Il tempo reale a bassa latenza è un'ottimizzazione vincolata: rinunci a quel poco di qualità che lookahead e B-frame comprano nella codifica offline, in cambio della latenza prevedibile che l'interazione in tempo reale richiede. Ogni prodotto di streaming in commercio, Remio, Parsec, NVIDIA GeForce NOW, Xbox Cloud Gaming, fa lo stesso scambio nella stessa direzione.

Di cosa ti devi davvero preoccupare (tu, utente)

Se sei saltato alla fine: l'encoder hardware di qualsiasi GPU moderna va bene per il desktop remoto.

Le differenze nelle configurazioni in tempo reale sono più piccole del rumore di fondo di qualsiasi benchmark ragionevole. Chi ha una GTX 1060 Pascal ha la stessa esperienza Remio di chi ha una RTX 4090: entrambe saturano la pipeline a 120 FPS con circa 8 ms di latenza di elaborazione (il resto è il ritmo di aggiornamento a 60 Hz del tuo schermo) ed entrambe producono un risultato indistinguibile ai bitrate della LAN.

Le eccezioni, in ordine di quanto spesso contano:

• L'hardware con supporto AV1 aiuta sulle reti lente, in generale. Wi-Fi d'albergo o hotspot mobile: un host Ada / RDNA3 / Arc con client M3+ o RTX serie 40 compra circa il 25 percento di margine in più alla stessa qualità negli strumenti che lo usano. In LAN, nulla. Remio non usa ancora AV1: la pipeline è H.265 da un capo all'altro, quindi oggi è un vantaggio dei produttori, non di Remio.
• I Mac Apple Silicon sono host notevolmente buoni. La bassa latenza del Media Engine, l'eccellente H.265 e il consumo di 3–5 W fanno di un Mac mini o Studio una delle migliori sorgenti di streaming sempre accese che si possano comprare. L'assenza di codifica AV1 è l'unica lacuna, irrilevante in LAN.
• Una Intel Arc A380 è un affare irragionevole per AV1. Circa 120 $ comprano un blocco encoder che batte qualsiasi altra cosa sotto i 400 $.
• Il ripiego su CPU con libx264 è reale. Senza encoder hardware, con un vecchio portatile o un server senza iGPU, Remio funziona comunque. Solo non a 4K 60 e non senza consumare un core di CPU.

Oltre questi casi limite, la risposta giusta è la più semplice: usa la GPU che compreresti comunque. Ogni produttore moderno è convergente sulle stesse capacità, sugli stessi preset a bassa latenza, sulla stessa fascia di qualità. Remio sceglie quello giusto a runtime, così non devi pensarci. Vai avanti con quello per cui hai aperto una sessione di desktop remoto: programmare, montare un video, sistemare un server, pubblicare una correzione da un bar.

È proprio questo il senso del silicio a funzione fissa. Funziona e basta, e smetti di accorgertene.