Il 24 luglio 2026 Microsoft ha annunciato sul suo blog Linux and Open Source il rilascio in open source di MLVC, l'ML Video Codec. Il codice è su github.com/microsoft/mlvc con licenza MIT, insieme ai pesi addestrati, agli script di addestramento e agli strumenti di conversione per le diverse NPU.
Il paper che lo accompagna, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, è uscito su arXiv un mese prima.
Non è una demo di ricerca eseguita una volta su una GPU di laboratorio. MLVC è la versione di prodotto della linea DCVC che Microsoft Research pubblica dal 2021, e Microsoft dichiara che è già in distribuzione su Microsoft Teams per le chiamate peer-to-peer, con telemetria live, test A/B e ripiego sui codec convenzionali quando l'hardware o la rete non reggono.
L'annuncio è abbastanza grosso da meritare una verifica seria, ed è quello che fa questo articolo: i numeri, cosa misurano davvero, cosa contiene realmente il repository e se qualcosa di tutto ciò tocchi una catena di streaming quest'anno.
Se preferite prima la versione breve, teniamo una definizione essenziale di cos'è MLVC nel nostro glossario dello streaming.
I numeri dell'annuncio
Il confronto pubblicato da Microsoft, a parità di qualità soggettiva:
| Risoluzione | Bitrate risparmiato vs H.264 | Bitrate risparmiato vs H.265 |
|---|---|---|
| 360p | 87,8% | 75,5% |
| 540p | 82,7% | 65,4% |
La versione concreta si ricorda meglio. Una chiamata a 360p e 30 fotogrammi al secondo che richiede 1 Mbps in H.264 ne richiede circa 122 kbps in MLVC. Grosso modo un ottavo dei bit, in tempo reale, sulla NPU di un portatile.
Ora le note in calce, perché contano parecchio.
Sono voti umani, non PSNR
Quelle percentuali sono punteggi MOS, ricavati da un test soggettivo ITU-T P.910 in cui spettatori umani hanno valutato le clip. Il materiale di partenza è il Video Conferencing Dataset, che Microsoft ha costruito e aperto a sua volta. Si tratta quindi di persone davanti a una webcam, a 360p e 540p, giudicate a occhio.
Se si misura lo stesso codec con il PSNR sull'insieme di test più ampio del paper, il guadagno BD-rate si avvicina piuttosto al 52%. Resta un numero molto alto. Ma non 87,8%.
Il riferimento è l'H.265 più debole in commercio
Il termine di paragone è H.265 in hardware su Intel Quick Sync, non un x265 ben tarato con preset lenti. Gli encoder hardware vincolati alla latenza della videoconferenza sono il pavimento di ciò che H.265 sa fare, non il soffitto.
Inoltre in tutto il paper non c'è alcun confronto con AV1 o VVC. Gli autori spiegano perché: escludono VTM ed ECM perché non hanno implementazioni su hardware di largo consumo, quindi non c'è nulla con cui misurarsi in tempo reale. Difendibile come scelta di ricerca, ma significa che nessuno ha ancora messo MLVC di fronte a un encoder AV1 moderno.
Il vero risultato è il determinismo, non la compressione
Questa è la parte finita sotto ai numeri sul bitrate, ed è la storia ingegneristica più interessante.
I codec neurali battono da tempo quelli convenzionali sull'efficienza di codifica. Non erano distribuibili, perché non si riusciva a decodificarli in modo affidabile su una macchina diversa da quella che aveva codificato.
La codifica entropica richiede che encoder e decoder calcolino probabilità identiche. Eseguite la stessa rete su un Apple Neural Engine e su un Qualcomm Hexagon e non otterrete risultati in virgola mobile identici, perché i compilatori scelgono kernel diversi, fondono gli operatori in modo diverso e arrotondano in modo diverso. Il bitstream si decodifica allora in poltiglia.
Il paper mette un numero su tutto questo. DCVC-RT, senza vincoli, ottiene circa il 69,6% di miglioramento BD-rate quando encoder e decoder stanno sulla stessa piattaforma. Tra piattaforme diverse il suo BD-rate è infinito, che è il modo educato di dire che il video non si decodifica affatto.
Come l'hanno risolto
MLVC smette di chiedere alle due estremità di trovarsi d'accordo per fortuna. Trasmette esplicitamente i parametri di scala del modello entropico attraverso l'hyperprior, così entrambi i lati leggono gli stessi valori dal bitstream invece di calcolarseli ciascuno per conto proprio.
Attorno a questo il team ha rimosso tutto il resto che diverge. Le funzioni di attivazione esotiche spariscono a favore di ReLU e LeakyReLU con gating ReGLU. La quantizzazione INT8 viene respinta in blocco, perché la convoluzione INT8 non è riproducibile tra produttori diversi e il silicio Apple più vecchio la simula comunque in FP16. Tutto gira in FP16.
Quella disciplina costa compressione vera. Un DCVC-RT addestrato in percettivo ottiene l'81,9% dove MLVC ottiene il 75,5%. Microsoft ha ceduto circa sei punti di BD-rate per avere un codec che decodifica su hardware che non le appartiene.
Per chiunque abbia mandato del video in produzione è evidentemente lo scambio giusto, ed è la prima volta che un codec appreso ci riesce.
Cosa c'è davvero nel repository
Vale la pena guardarci dentro, perché il repository racconta una storia un po' diversa dall'annuncio.
Il repository è stato creato il 28 gennaio 2026 e per sei mesi non ha contenuto altro che una licenza, un abbozzo di README e i file di governance standard di Microsoft. Il codice vero è arrivato il 22 luglio in un unico commit intitolato "Hello MLVC", caricato da Tanel Pärnamaa, primo autore del paper. Al momento in cui scriviamo conta 8 commit, 189 stelle, 10 fork e nessuna release taggata.
È quindi un rilascio in blocco, non un progetto sviluppato alla luce del sole. Non è una critica, solo l'aspettativa corretta da avere. Tutte e quattro le issue aperte sono aggiornamenti Dependabot per transformers, jupyterlab e cryptography. L'unico contributo esterno finora integrato è una correzione di una riga che aggiunge #include <cstdint> a EntropyCoder.h perché il codificatore entropico in C++ compili su GCC 13 e sui Clang recenti. Poca cosa, ma un buon segno: qualcuno fuori da Microsoft ha provato a compilarlo nel giro di giorni, e Microsoft ha integrato la patch.
Cosa si ottiene
- Quattro checkpoint. L'MLVC completo da 18,3 milioni di parametri e l'MLVC-S più leggero da 5,4 milioni, ciascuno in una variante ottimizzata per il PSNR e una ottimizzata per la percezione. Le percettive sono addestrate con LPIPS e una maschera di segmentazione del volto, il che dice esattamente per cosa sono state costruite.
- L'intera pipeline di addestramento, per i modelli immagine e video, guidata da configurazioni YAML. Microsoft ha anche documentato come ha raccolto i dati di addestramento, cosa che pochi rilasci fanno.
- Gli strumenti di export che convertono un modello in CoreML per Apple, ONNX per Intel e OpenVINO, e QNN per Qualcomm, a dimensioni di ingresso fisse. I runtime supportati sono ONNX Runtime su CPU e GPU, ONNX Runtime QNN, OpenVINO e Windows ML.
- Un codificatore entropico rANS in C++ in
packages/msrtc_ranscon binding Python, più gli strumenti di benchmark che calcolano BD-rate, MS-SSIM, LPIPS, VIF e DeQA.
Quello che non si ottiene è una libreria codec in C++ da collegare a un'applicazione. Microsoft dice che arriverà in un rilascio successivo. Oggi la superficie utilizzabile è Python, e servono Python 3.12 o 3.13 e uv per installarlo.
Dove finiscono davvero i frame al secondo
La velocità è la ragione per cui la cosa è interessante, quindi la scala delle risoluzioni conta. Throughput di codifica dal paper:
| Risoluzione | MLVC, Apple M3 Pro | MLVC, media 3 produttori | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 fps | 103 fps | non pubblicato |
| 540p | 65,7 fps | 49 fps | non pubblicato |
| 720p | 33,8 fps | non pubblicato | 83,8 fps |
| 1080p | 15,6 fps | non pubblicato | 39,5 fps |
La decodifica gira qualche fotogramma al secondo più lentamente della codifica su tutta la linea. Su Intel Lunar Lake il dato a 1080p è di 10,5 fps, e i tre produttori testati sono Apple M3 e M4, Intel Lunar Lake e Qualcomm Snapdragon X Elite.
Il riassunto onesto: 540p a 30 fps è ciò che si può promettere, su tutti e tre i produttori, usando meno di metà della NPU. Il 1080p in tempo reale esiste solo sul modello ridotto, su Apple, in una sola direzione. Il paper nota inoltre che codificare e decodificare contemporaneamente su un singolo dispositivo a 1080p e oltre resta un problema, ed è esattamente ciò che serve a una chiamata bidirezionale.
La roadmap di Microsoft segue quella logica: prima stabilizzare il 540p e migliorare la resistenza alle perdite, poi il 1080p e scenari di streaming più ampi.
Perché non potete metterlo in una scala di streaming
L'efficienza di compressione non ha mai deciso il destino di un codec nello streaming. Lo decidono i decoder.
Abbiamo dedicato un intero articolo a come HEVC non sia mai diventato il futuro che gli era stato promesso, e il motivo erano le licenze e il supporto dei dispositivi, non gli strumenti di codifica. AV1 ha iniziato a contare per i deployment reali solo quando i telefoni hanno montato decoder hardware.
Il formato sono i pesi
MLVC ha una versione più dura di quel problema. Non esiste uno standard di bitstream MLVC, perché i pesi addestrati sono il formato. Un flusso è decodificabile solo da un dispositivo che possiede esattamente il modello che lo ha codificato, e che lo esegue abbastanza fedelmente da riprodurne l'aritmetica.
Niente flussi di conformità. Niente tipo MIME. Nessuna storia di packaging, nessuna storia di DRM, e niente in una smart TV, in un decoder o in un browser in grado di riprodurlo. La vostra CDN può trasportarlo, e all'altro capo non ci sarà nulla capace di aprirlo.
Il contenuto non è il vostro contenuto
I numeri impressionanti vengono da busti parlanti statici a bassa risoluzione, con un modello addestrato sui volti tramite una maschera di regione di interesse. Sport, grana della pellicola, panoramiche veloci e movimento intenso sono esattamente i casi in cui i codec convenzionali si guadagnano le loro euristiche, e il paper non rivendica nulla di tutto ciò.
Anzi, quantifica una debolezza: il meccanismo di riferimento a lungo termine costa circa 2 punti percentuali di BD-rate sui cambi di scena bruschi, mitigati con il rilevamento degli stacchi in fase di deployment. E un film è soprattutto cambi di scena.
E nessuno ha misurato i consumi
È il limite con cui il paper stesso si chiude. Il tempo reale è risolto, dicono gli autori, quindi il consumo energetico è la prossima frontiera. Far girare una rete neurale sulla NPU per ogni fotogramma di un film di due ore, su un dispositivo a batteria, è tutt'altra cosa rispetto a un decoder a funzione fissa ottimizzato da un decennio.
Dove ha senso oggi
Ovunque entrambe le estremità siano computer che controllate voi, e dove il vincolo sia la rete e non il silicio.
Cioè anzitutto la videoconferenza, ed è per questo che Teams è il veicolo di lancio. Poi i collegamenti di contribuzione su uplink scadenti, la produzione remota, i droni, la robotica e la videosorveglianza, oppure il cloud gaming e il rendering remoto. Nell'annuncio Microsoft chiede esplicitamente aiuto su tutti questi fronti, oltre a streaming e VOD, e su port di piattaforma che allarghino la copertura NPU.
Se state costruendo qualcosa in tempo reale e peer-to-peer su hardware moderno, merita un pomeriggio del vostro tempo fin da subito. Se gestite un servizio OTT, no.
La parte che dovrebbe davvero preoccupare chi lavora sui codec
Non il 75%. La pendenza.
Microsoft sostiene che l'efficienza di codifica di MLVC migliori con la capacità del modello e con il calcolo di addestramento, come è successo a ogni altro sistema di machine learning negli ultimi anni.
I codec convenzionali migliorano di circa il 30-50% per generazione, e una generazione richiede quasi un decennio di standardizzazione, seguito da anni di attesa dell'hardware, seguiti da una lite sul pool di brevetti. Se un codec appreso continua a migliorare ogni volta che qualcuno gli punta contro più calcolo, e gira su NPU già presenti ovunque, la forma di quella competizione cambia.
È sotto licenza MIT, il che elimina in sordina l'altro fattore che ha ucciso HEVC. E si riduce a un normale problema di ingegneria: rilasciate una versione di modello, la negoziate come si negozia un codec, e ripiegate quando l'altro capo non riesce a eseguirla.
Niente di tutto ciò accadrà quest'anno. La distanza tra "gira a 540p sul mio M3" e "si riproduce su un televisore di cinque anni fa in un salotto" è la stessa che ogni codec ha impiegato quindici anni a colmare. Ma era da un po' che la compressione non tornava abbastanza interessante da leggersi un paper, e questo vale l'ora che chiede.
Cosa farne in pratica
Nella vostra scala di codifica non cambia nulla. Continuate a distribuire H.264 per la copertura, HEVC e AV1 dove i dispositivi lo permettono, e tornateci sopra quando succederanno tre cose:
- 1080p in tempo reale sul modello completo, non solo MLVC-S su Apple.
- Una libreria C++ realmente collegabile a un prodotto.
- Un decoder qualsiasi fuori dai prodotti di Microsoft.
Clonate il repository se siete curiosi, perché la pipeline di addestramento e l'analisi multipiattaforma sono istruttive che pubblichiate o meno un codec neurale un giorno. L'appendice sul perché la quantizzazione INT8 diverga tra produttori è una spiegazione compatta di un problema che di solito richiede molto più spazio.
Domande frequenti
MLVC è gratuito?
Sì. Microsoft lo ha pubblicato con licenza MIT, che copre il codice sorgente del modello, i pesi addestrati e gli script di addestramento. Non c'è alcun pool di brevetti collegato, una differenza significativa rispetto a HEVC.
Posso trasmettere MLVC a una smart TV o a un browser?
No. La decodifica richiede un dispositivo capace di eseguire la rete neurale, e precisamente il modello che ha codificato il flusso. Oggi nessun televisore, decoder, telefono o browser dispone di un decoder MLVC, e non esiste uno standard di bitstream che possa implementare.
Quanta banda fa risparmiare davvero MLVC?
Microsoft dichiara l'87,8% di bitrate in meno rispetto a H.264 e il 75,5% in meno rispetto a H.265 in hardware a 360p, con giudizio di spettatori umani secondo ITU-T P.910. Misurato con il PSNR su un insieme di test più ampio, il risparmio si avvicina al 52%. Entrambi i valori sono rispetto a encoder hardware su contenuti di videoconferenza.
Che hardware richiede MLVC?
Una NPU. Microsoft ha testato Apple Neural Engine su M3 e M4, Intel Lunar Lake e Qualcomm Snapdragon X Elite, e dichiara 540p a 30 fps in tempo reale su tutti e tre, usando meno di metà della capacità della NPU.
MLVC è migliore di AV1?
Nessuno ha pubblicato quel confronto. Il paper misura solo contro H.264 e H.265, ed esclude AV1, VVC ed ECM perché non hanno implementazioni su hardware di largo consumo con cui confrontarsi in tempo reale.
Che differenza c'è tra MLVC e DCVC?
DCVC è la linea di codec neurali pubblicata da Microsoft Research dal 2021. MLVC ne è la versione di prodotto, che baratta circa sei punti di efficienza di compressione con la capacità di decodificare in modo affidabile su NPU di produttori diversi.
Serve aiuto per capire cosa significa per la vostra piattaforma?
Le decisioni sui codec costano care quando vanno storte, e la maggior parte del costo arriva anni dopo, sul supporto dei dispositivi e sulle licenze, non sul bitrate. I nostri talenti dello streaming e del broadcast hanno portato in produzione codec, scale di codifica e catene di distribuzione su larga scala, e potete sottoporre a uno di loro direttamente il problema che avete davvero.