La conversione HDR serve quando la sorgente è HDR ma il display o il percorso di riproduzione vogliono SDR. Non basta rendere l’immagine più chiara: stai comprimendo un intervallo di luminanza ampio dentro uno stretto, e il mestiere è conservare il dettaglio nelle luci e nelle ombre mentre lo fai. Dove il tuo server esegue quella compressione, e se debba proprio eseguirla, decide quanto ti costa un film in 4K.
Che cosa il server legge come HDR
Due segnali, letti entrambi dalla sonda e nessuno dei due dal nome del file. Una sorgente conta come HDR10 quando la sua funzione di trasferimento è SMPTE ST.2084, la curva PQ, oppure quando porta i metadati del display di mastering o del content light level, che restano un segnale affidabile anche su un file a cui la caratteristica di trasferimento si è persa per strada. Una sorgente conta come HLG quando la funzione di trasferimento è ARIB STD-B67, la curva usata in broadcast. In entrambi i casi il file finisce nello stesso secchio e da lì la domanda sul tone mapping non si può evitare.
Il Dolby Vision, in quella decisione, non ha un ramo tutto suo. Lo scanner il profilo e il livello li legge davvero dal flusso, e le statistiche della libreria contano quei file sotto una gamma dinamica loro, quindi nella scheda Statistiche li vedrai separati. Quello che guarda la decisione di streaming è la funzione di trasferimento. Quasi tutto quello che riverserai porta uno strato Dolby Vision sopra una base HDR10, quella base segnala PQ, e il file viene convertito come HDR10 lasciando i metadati per scena non interpretati.
Converti solo quando la destinazione lo richiede
Le app desktop e mobile dichiarano al server di saper aprire il file da sé, il che manda la sessione sulla strada del direct file prima ancora che una sola capacità venga confrontata. Lì il controllo sull’HDR non viene mai raggiunto, e i byte escono dalla macchina come stanno sul disco. Entrambi i profili dichiarano comunque l’HDR10, quindi anche una sessione che dovesse finire su HLS non perderebbe la gamma.
Ma il caso interessante è il browser. Il profilo browser moderno copre da H.264 ad AV1 fino al 4K e ai 25 Mbps, e l’HDR10 lo lascia fuori di proposito, quindi un film HDR aperto in una scheda viene convertito in SDR a meno che non sia chi guarda a chiedere altro. I ricevitori AirPlay mantengono l’HDR10 e prendono l’HEVC, perciò una Apple TV riceve la gamma com’è stata autorizzata in origine. Il ricevitore predefinito di un Chromecast prende H.264 e AAC e nient’altro, il che significa che un titolo HDR mandato da un telefono viene convertito su due fronti, una volta per il codec e una per la gamma.
Ogni conversione che eviti tiene intatta la qualità e lascia un core libero per una sessione che non ha scelta.
Quale backend fa il tone mapping
Sei encoder possono finire a servire una transcodifica, e solo alcuni fanno la conversione HDR sull’hardware grafico. Quale ti tocca? NVIDIA è il caso lineare: una sessione NVENC o CUDA spinge il lavoro attraverso libplacebo su un dispositivo Vulkan, e quel dispositivo viene scelto indipendentemente dall’encoder, prima le schede discrete e poi le integrate, con i rasterizzatori software e i dispositivi virtuali esclusi in partenza.
Intel Quick Sync usa invece la propria unità di elaborazione video, e la ragione è la dimensione del divario. Misurato su un titolo 4K HDR, trenta secondi di contenuto hanno preso 3,43 secondi passando per l’unità Quick Sync contro 27,4 secondi passando per libplacebo sullo stesso chip integrato. Anche VAAPI su Linux converte dentro l’unità di elaborazione video, e questo copre sia la grafica Intel sia quella AMD, purché i fotogrammi decodificati siano ancora sul dispositivo. Dove la decodifica è ripiegata sul software non c’è niente da filtrare sulla scheda, quindi gira la catena del processore e il risultato va caricato sul dispositivo per l’encoder.
Il backend AMF di AMD su Windows e VideoToolbox di Apple su macOS codificano sull’hardware e fanno il tone mapping sul processore. Se hai una Radeon sotto Windows, la risposta è questa, e la stessa scheda in un host Linux rimetterebbe la conversione sulla GPU attraverso VAAPI. È l’unico punto in cui il sistema operativo sotto al tuo server cambia quello che l’hardware ti costa.
Auto prende il primo backend che si valida, nell’ordine NVENC, Quick Sync, VAAPI, VideoToolbox, AMF, e su Linux per ultimo un dispositivo V4L2 con codec. Puoi forzarne uno da Impostazioni, nella scheda Qualità, alla voce Transcoding server, che è un comando da amministratore. Quello che la tua macchina ha validato davvero lo trovi come chip nella scheda Info e diagnostica, sotto Backend di accelerazione hardware, e un backend che la sua verifica a runtime non l’ha mai passata lì non compare.
L’immagine non dovrebbe cambiare quando cambia il backend
L’operatore è Hable dappertutto. La catena software porta l’immagine in luce lineare con un picco nominale di cento nit, fa il tone mapping con Hable e senza desaturazione, poi torna fuori in BT.709; a libplacebo viene passato di proposito lo stesso operatore Hable, così che i due si somiglino. E la cosa conta più di quanto sembri. Se spostare il server dal processore alla scheda grafica cambiasse la resa, una misura presa prima dello spostamento non direbbe niente su una presa dopo.
Quando una scheda si sfila a metà sessione
Una sessione hardware che muore prima di scrivere il suo primo segmento non ti viene semplicemente sbattuta in faccia. Il server la rilancia con la decodifica software e l’encoder hardware mantenuto, facendo il tone mapping sul processore per quel tentativo. Se anche il secondo avvio muore allo stesso modo il backend viene marcato come guasto, la sessione riparte del tutto in software, e ogni sessione successiva dentro quel processo va dritta a libx264 senza chiedere di nuovo.
Il log racconta tutto, quindi non devi tirare a indovinare. Trovi Hardware decode failed at startup on {backend}; retrying with software decode per il primo passo e Hardware acceleration {backend} tainted per il secondo. Quel contrassegno vive in memoria, quindi riavviare il server lo azzera e il backend torna a essere sondato. Altre due righe val la pena riconoscerle. GPU HDR tonemap support detected: False vuol dire che il filtro libplacebo o il dispositivo Vulkan non si sono alzati, e un avviso che dice di un dispositivo Vulkan, chiamato per nome, che corrompe i trasferimenti dei fotogrammi vuol dire che quel dispositivo non ha passato la verifica introdotta dopo che un server è stato trovato a produrre colore corrotto su hardware che dichiarava supporto.
La capacità si prova con media reali
Risoluzione, codec sorgente, profondità di bit, sottotitoli impressi, bitrate in uscita: ognuna di queste cose sposta il costo di una transcodifica. HDR e burn-in insieme sono la cosa più pesante che il server faccia, perché la sovrimpressione vuole il fotogramma di ritorno nella memoria di sistema e solo NVIDIA e Quick Sync riescono a tenersi l’encoder hardware attraversandola. Su qualsiasi altro backend quella combinazione butta l’intera sessione nel software, e una libreria piena di dischi riversati con sottotitoli bitmap è esattamente dove la incontrerai. La guida ai dischi spiega che cosa costa sceglierne una.
Prendi un file 4K HDR che rappresenti la tua libreria, di quelli che guarderesti davvero un venerdì sera, e riproducilo con il client e la rete che userai davvero, abbastanza a lungo perché l’encoder si assesti. Un controllo di capacità sa dirti che un dispositivo c’è. Solo un carico prolungato ti dirà se la riproduzione regge, ed è quello che va misurato.
In ordine di preferenza. Prima la riproduzione HDR diretta. Poi un percorso di tone mapping accelerato che sia sopravvissuto a una sessione vera. Infine il processore, che va dappertutto e vuole margine abbondante ad alta risoluzione.
Domande frequenti
Perché la mia Radeon codifica ma non fa il tone mapping?
Perché sei su Windows, dove il backend AMF fa la codifica sulla scheda e passa la conversione HDR al processore. È Linux a cambiare le cose: lì una scheda AMD viene pilotata attraverso VAAPI, la cui unità di elaborazione video converte i fotogrammi sul posto mentre sono ancora sul dispositivo.
Ieri il server usava la scheda grafica e oggi usa il processore. Che cosa è cambiato?
Con ogni probabilità una sessione è fallita all’avvio e il backend è stato scartato per la durata del processo. Cerca tainted nel log del server e vedrai quale e quando. Riavviare il server azzera quello stato e rimette il backend alla prova; se fallisce una seconda volta hai un guasto vero da guardare invece di un contrassegno rimasto lì.
Posso impedire a un browser di convertire in SDR un film HDR?
Sì. Impostazioni, scheda Qualità, Mantieni l'HDR (no tonemap SDR) tiene l’immagine HDR10 attraverso la transcodifica, e la descrizione accanto nomina i browser capaci di disegnarla: Safari, Edge oppure Chrome con HEVC. Lascialo spento se sullo schermo l’HDR non ti torna, perché è proprio un monitor SDR a cui arriva un flusso HDR a dare quell’immagine grigia. L’app desktop si toglie la domanda di mezzo prendendosi il file intero.
Il server capisce il Dolby Vision?
Legge la base HDR10 che quasi ogni file Dolby Vision porta con sé, e converte su quella. I metadati dinamici per scena vengono registrati durante la scansione e contati nelle tue statistiche, e per il tone mapping non vengono interpretati. Riprodurre il file intatto su un’app desktop o mobile lascia in pace l’intero flusso, quello strato compreso, e che cosa ne faccia il tuo display è poi una faccenda fra il lettore e il pannello.