Den 24 juli 2026 meddelade Microsoft på sin Linux and Open Source-blogg att MLVC, ML Video Codec, släpps som öppen källkod. Koden finns på github.com/microsoft/mlvc under MIT-licens, med tränade vikter, träningsskript och konverteringsverktygen för olika NPU:er.
Artikeln bakom, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, publicerades på arXiv en månad tidigare.
Det här är ingen forskningsdemo som kördes en gång på en labb-GPU. MLVC är produktversionen av den DCVC-linje som Microsoft Research publicerat sedan 2021, och Microsoft uppger att den redan rullas ut i Microsoft Teams för peer-to-peer-samtal, med live-telemetri, A/B-tester och återfall till konventionella kodekar när hårdvaran eller nätet inte räcker till.
Påståendet är stort nog att förtjäna en ordentlig granskning, och det är vad den här artikeln gör: siffrorna, vad de faktiskt mäter, vad som verkligen finns i repositoriet och om något av det rör en streamingkedja i år.
Vill du ha kortversionen först håller vi en enkel definition av vad MLVC är i vår streamingordlista.
Siffrorna i meddelandet
Microsofts egen jämförelse, vid likvärdig subjektiv kvalitet:
| Upplösning | Sparad bitrate mot H.264 | Sparad bitrate mot H.265 |
|---|---|---|
| 360p | 87,8 % | 75,5 % |
| 540p | 82,7 % | 65,4 % |
Den konkreta versionen är lättare att komma ihåg. Ett samtal i 360p med 30 bilder per sekund som kräver 1 Mbps H.264 kräver ungefär 122 kbps MLVC. Grovt räknat en åttondel av bitarna, i realtid, på en bärbar dators NPU.
Så till det finstilta, för det spelar stor roll.
Det här är mänskliga betyg, inte PSNR
Procenttalen är MOS-baserade, från ett subjektivt ITU-T P.910-test där mänskliga tittare betygsatte klippen. Källmaterialet är Video Conferencing Dataset, som Microsoft också byggt och öppnat. Det handlar alltså om människor framför en webbkamera, i 360p och 540p, bedömda med ögat.
Mäter man samma kodek med PSNR över artikelns bredare testuppsättning hamnar BD-rate-vinsten snarare kring 52 %. Fortfarande en väldigt stor siffra. Men inte 87,8 %.
Referensen är den svagaste H.265 du kan köpa
Jämförelsepunkten är H.265 i hårdvara på Intel Quick Sync, inte en välinställd x265 med långsamma presets. Hårdvarukodare som är bundna till konferenslatens utgör golvet för vad H.265 klarar, inte taket.
Det finns heller ingen jämförelse mot AV1 eller VVC någonstans i artikeln. Författarna förklarar varför: de utelämnar VTM och ECM eftersom de saknar implementationer i konsumenthårdvara, så det finns inget att mäta mot i realtid. Försvarbart som forskningsbeslut, men det innebär att ingen ännu visat MLVC mot en modern AV1-kodare.
Den verkliga bedriften är determinism, inte kompression
Det här är den del som begravdes under bitrate-siffrorna, och det är den mer intressanta ingenjörshistorien.
Neurala kodekar har slagit konventionella kodekar på kodningseffektivitet ett bra tag. De gick inte att rulla ut, eftersom de inte kunde avkodas tillförlitligt på en annan maskin än den som kodat.
Entropikodning kräver att kodare och avkodare beräknar identiska sannolikheter. Kör samma nätverk på en Apple Neural Engine och en Qualcomm Hexagon och du får inte identiska flyttalsresultat, eftersom kompilatorerna väljer andra kärnor, slår ihop operatorer på annat sätt och avrundar annorlunda. Bitströmmen avkodas då till skräp.
Artikeln sätter en siffra på det. DCVC-RT når utan begränsningar omkring 69,6 % BD-rate-förbättring när kodare och avkodare sitter på samma plattform. Över plattformsgränser är dess BD-rate oändlig, vilket är det artiga sättet att säga att videon inte avkodas alls.
Så löste de det
MLVC slutar be de två ändarna att vara överens av tur. Den skickar entropimodellens skalparametrar explicit via hyperprioren, så att båda sidor läser samma värden ur bitströmmen i stället för att var och en räkna ut dem.
Runt det har teamet tagit bort allt annat som divergerar. Exotiska aktiveringsfunktioner är borta till förmån för ReLU och LeakyReLU med ReGLU-gating. INT8-kvantisering avvisas rakt av, eftersom INT8-faltning inte är reproducerbar mellan tillverkare och äldre Apple-kisel simulerar den i FP16 ändå. Alltihop körs i FP16.
Den disciplinen kostar verklig kompression. En perceptuellt tränad DCVC-RT når 81,9 % där MLVC når 75,5 %. Microsoft gav upp ungefär sex BD-rate-poäng för att få en kodek som avkodar på hårdvara företaget inte äger.
För var och en som satt video i produktion är det uppenbart rätt byte, och det är första gången en inlärd kodek klarar det.
Vad som faktiskt finns i repositoriet
Värt att titta på direkt, för repositoriet berättar en något annan historia än meddelandet.
Repositoriet skapades den 28 januari 2026 och innehöll i sex månader inget annat än en licens, ett README-utkast och Microsofts vanliga styrningsfiler. Själva koden landade den 22 juli i en enda commit med titeln "Hello MLVC", inskickad av Tanel Pärnamaa, artikelns förste författare. I skrivande stund finns 8 commits, 189 stjärnor, 10 forkar och inga taggade utgåvor alls.
Det här är alltså en kodsläpp i ett stycke, inte ett projekt utvecklat i öppenhet. Det är ingen kritik, bara rätt förväntan att ha. Alla fyra öppna ärenden är Dependabot-uppdateringar för transformers, jupyterlab och cryptography. Det enda externa bidrag som hittills slagits samman är en enradsfix som lägger till #include <cstdint> i EntropyCoder.h så att C++-entropikodaren byggs på GCC 13 och nyare Clang. Litet, men ett gott tecken: någon utanför Microsoft försökte kompilera den inom några dagar, och Microsoft tog in patchen.
Vad du får
- Fyra checkpoints. Den fullständiga MLVC med 18,3 miljoner parametrar och den lättare MLVC-S med 5,4 miljoner, var och en i en PSNR-optimerad och en perceptuellt optimerad variant. De perceptuella är tränade med LPIPS och en ansiktssegmenteringsmask, vilket säger precis vad de byggts för.
- Hela träningspipelinen, för både bild- och videomodellen, styrd med YAML-konfigurationer. Microsoft har också dokumenterat hur träningsdata samlades in, vilket är mer än de flesta släpp gör.
- Exportverktyg som konverterar en modell till CoreML för Apple, ONNX för Intel och OpenVINO samt QNN för Qualcomm, med fasta indimensioner. Stödda runtimes är ONNX Runtime på CPU och GPU, ONNX Runtime QNN, OpenVINO och Windows ML.
- En rANS-entropikodare i C++ i
packages/msrtc_ransmed Python-bindningar, plus benchmarkverktyg som beräknar BD-rate, MS-SSIM, LPIPS, VIF och DeQA.
Vad du inte får är ett C++-kodekbibliotek att länka in i en applikation. Microsoft säger att det kommer i ett senare släpp. I dag är den användbara ytan Python, och du behöver Python 3.12 eller 3.13 och uv för att installera det.
Var bildfrekvenserna faktiskt hamnar
Hastigheten är skälet till att det här är intressant, så upplösningsstegen spelar roll. Kodningsgenomströmning enligt artikeln:
| Upplösning | MLVC, Apple M3 Pro | MLVC, snitt av 3 tillverkare | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 fps | 103 fps | ej publicerat |
| 540p | 65,7 fps | 49 fps | ej publicerat |
| 720p | 33,8 fps | ej publicerat | 83,8 fps |
| 1080p | 15,6 fps | ej publicerat | 39,5 fps |
Avkodning går några bilder per sekund långsammare än kodning rakt igenom. På Intel Lunar Lake är 1080p-siffran 10,5 fps, och de tre testade tillverkarna är Apple M3 och M4, Intel Lunar Lake och Qualcomm Snapdragon X Elite.
Den ärliga sammanfattningen: 540p vid 30 fps är vad som går att leverera, hos alla tre tillverkare, med under halva NPU:n. Realtids-1080p finns bara på den bantade modellen, på Apple, i en riktning. Artikeln noterar dessutom att samtidig kodning och avkodning på en enhet vid 1080p och uppåt fortfarande är ett problem, och det är precis vad ett tvåvägssamtal kräver.
Microsofts färdplan följer det: först stabilisera 540p och förbättra förlusttåligheten, sedan 1080p och bredare streamingscenarier.
Varför du inte kan lägga in det i en streamingstege
Kompressionseffektivitet har aldrig avgjort en kodeks öde inom streaming. Det gör avkodarna.
Vi skrev en hel artikel om hur HEVC aldrig blev den framtid den utlovades bli, och orsaken var licenser och enhetsstöd, inte kodningsverktyg. AV1 började betyda något för riktiga utrullningar först när telefoner fick hårdvaruavkodare för den.
Formatet är vikterna
MLVC har en hårdare variant av det problemet. Det finns ingen MLVC-bitströmsstandard, eftersom de tränade vikterna är formatet. En ström går bara att avkoda av en enhet som har exakt den modell som kodade den, och som kör den tillräckligt likt för att återskapa aritmetiken.
Inga conformance-strömmar. Ingen MIME-typ. Ingen paketeringsberättelse, ingen DRM-berättelse, och inget i en smart-tv, en digitalbox eller en webbläsare som kan spela upp den. Ditt CDN kan frakta den, och i andra änden finns inget som kan öppna den.
Innehållet är inte ditt innehåll
De imponerande siffrorna kommer från statiska talande huvuden i låg upplösning, med en modell tränad på ansikten via en ROI-mask. Sport, filmkorn, snabba panoreringar och mycket rörelse är precis där konventionella kodekar gör sig förtjänta av sina heuristiker, och det gör artikeln inga anspråk på.
Den sätter till och med siffror på en svaghet: mekanismen för långtidsreferens kostar omkring 2 procentenheter BD-rate vid tvära scenbyten, dämpat med klippdetektering i drift. En spelfilm består mest av scenbyten.
Och ingen har mätt strömförbrukningen
Det är artikelns egen avslutande begränsning. Realtid är löst, skriver författarna, så strömförbrukning är nästa front. Att köra ett neuralt nätverk på NPU:n för varje bildruta i en två timmar lång film är på en batteridriven enhet något helt annat än en avkodare med fast funktion som optimerats i ett decennium.
Var det är vettigt i dag
Överallt där båda ändarna är datorer du styr, och där nätet är begränsningen snarare än kislet.
Det är videomöten i första hand, och därför är Teams lanseringsfordonet. Det är också tillspelslänkar över dåliga upplänkar, fjärrproduktion, drönare, robotik och övervakningslänkar, samt molnspel och fjärrrendering. Microsoft ber uttryckligen om hjälp på alla de fronterna i meddelandet, vid sidan av streaming och VOD, plus plattformsporteringar som breddar NPU-täckningen.
Bygger du något i realtid och peer-to-peer på modern hårdvara är det värt en eftermiddag av din tid redan nu. Driver du en OTT-tjänst är det inte det.
Den del som verkligen borde oroa kodekfolket
Inte de 75 %. Lutningen.
Microsoft hävdar att MLVC:s kodningseffektivitet förbättras med modellkapacitet och träningsberäkning, på samma sätt som alla andra maskininlärningssystem de senaste åren.
Konventionella kodekar förbättras med ungefär 30 till 50 % per generation, och en generation kräver större delen av ett decennium av standardisering, följt av år av väntan på hårdvara, följt av ett gräl om patentpooler. Om en inlärd kodek fortsätter bli bättre varje gång någon riktar mer beräkning mot den, och den kör på NPU:er som ändå sitter i allt, ändras formen på den konkurrensen.
Den är MIT-licensierad, vilket tyst tar bort den andra faktorn som tog livet av HEVC. Och den kokar ner till ett vanligt ingenjörsproblem: du släpper en modellversion, du förhandlar om den som du förhandlar om en kodek, och du faller tillbaka när andra änden inte kan köra den.
Inget av det händer i år. Avståndet mellan "kör i 540p på min M3" och "spelas upp på en fem år gammal tv i ett vardagsrum" är samma avstånd som varje kodek behövt femton år för att ta sig över. Men det var ett tag sedan kompression blev intressant nog att läsa en artikel om, och den här är värd sin timme.
Vad du ska göra åt det
Inget ändras i din kodningsstege. Fortsätt leverera H.264 för räckvidd, HEVC och AV1 där enheterna klarar det, och titta igen när tre saker inträffar:
- Realtids-1080p på den fullständiga modellen, inte bara MLVC-S på Apple.
- Ett C++-bibliotek som faktiskt går att länka in i en produkt.
- Någon avkodare utanför Microsofts egna produkter.
Klona repositoriet om du är nyfiken, för träningspipelinen och analysen över plattformsgränser är lärorika oavsett om du någonsin släpper en neural kodek. Bilagan om varför INT8-kvantisering divergerar mellan tillverkare är en kompakt förklaring av ett problem som annars kräver betydligt mer utrymme.
Vanliga frågor
Är MLVC gratis att använda?
Ja. Microsoft släppte den under MIT-licens, som täcker modellens källkod, de tränade vikterna och träningsskripten. Ingen patentpool hänger med, vilket är en betydande skillnad mot HEVC.
Kan jag strömma MLVC till en smart-tv eller en webbläsare?
Nej. Avkodning kräver en enhet som kan köra det neurala nätverket, och exakt den modell som kodade strömmen. Ingen tv, digitalbox, telefon eller webbläsare har en MLVC-avkodare i dag, och det finns ingen bitströmsstandard som de skulle kunna implementera.
Hur mycket bandbredd sparar MLVC egentligen?
Microsoft anger 87,8 % lägre bitrate än H.264 och 75,5 % lägre än H.265 i hårdvara vid 360p, bedömt av mänskliga tittare enligt ITU-T P.910. Mätt med PSNR över en bredare testuppsättning ligger besparingen närmare 52 %. Båda siffrorna gäller mot hårdvarukodare på videomötesinnehåll.
Vilken hårdvara kräver MLVC?
En NPU. Microsoft testade Apple Neural Engine på M3 och M4, Intel Lunar Lake och Qualcomm Snapdragon X Elite, och anger realtids-540p vid 30 fps på alla tre, med under halva NPU:ns kapacitet.
Är MLVC bättre än AV1?
Den jämförelsen har ingen publicerat. Artikeln mäter bara mot H.264 och H.265, och utelämnar AV1, VVC och ECM eftersom de saknar implementationer i konsumenthårdvara att jämföra mot i realtid.
Vad är skillnaden mellan MLVC och DCVC?
DCVC är den linje av neurala kodekar som Microsoft Research publicerat sedan 2021. MLVC är produktversionen, som byter bort ungefär sex poäng kompressionseffektivitet mot förmågan att avkoda tillförlitligt på NPU:er från olika tillverkare.
Behöver du hjälp att avgöra vad det betyder för din plattform?
Kodekbeslut blir dyra när de blir fel, och merparten av kostnaden dyker upp år senare i enhetsstöd och licenser, inte i bitrate. Våra streaming- och broadcasttalanger har levererat kodekar, kodningsstegar och distributionskedjor i stor skala, och du kan briefa en av dem direkt om problemet du faktiskt har.