Den 24. juli 2026 kunngjorde Microsoft på sin Linux and Open Source-blogg at MLVC, ML Video Codec, slippes som åpen kildekode. Koden ligger på github.com/microsoft/mlvc under MIT-lisens, med trente vekter, treningsskript og konverteringsverktøyet for ulike NPU-er.
Artikkelen bak, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, kom på arXiv en måned tidligere.
Dette er ingen forskningsdemo som kjørte én gang på en lab-GPU. MLVC er produktversjonen av DCVC-linjen som Microsoft Research har publisert siden 2021, og Microsoft opplyser at den allerede rulles ut i Microsoft Teams for peer-to-peer-samtaler, med sanntidstelemetri, A/B-testing og tilbakefall til konvensjonelle kodeker når maskinvaren eller nettet ikke strekker til.
Påstanden er stor nok til å fortjene en skikkelig gjennomgang, og det er det denne artikkelen gjør: tallene, hva de faktisk måler, hva som virkelig ligger i repositoriet, og om noe av det berører en strømmekjede i år.
Vil du ha kortversjonen først, holder vi en enkel definisjon av hva MLVC er i strømmeordlisten vår.
Tallene fra kunngjøringen
Microsofts egen sammenligning, ved tilsvarende subjektiv kvalitet:
| Oppløsning | Spart bitrate mot H.264 | Spart bitrate mot H.265 |
|---|---|---|
| 360p | 87,8 % | 75,5 % |
| 540p | 82,7 % | 65,4 % |
Den konkrete versjonen er lettere å huske. En samtale i 360p med 30 bilder i sekundet som krever 1 Mbps H.264, krever omtrent 122 kbps MLVC. Grovt regnet en åttendedel av bitene, i sanntid, på NPU-en i en bærbar.
Så til det med liten skrift, for det betyr mye.
Dette er menneskelige vurderinger, ikke PSNR
Prosentene er MOS-baserte, fra en subjektiv ITU-T P.910-test der menneskelige seere vurderte klippene. Kildematerialet er Video Conferencing Dataset, som Microsoft også har bygget og åpnet. Det dreier seg altså om mennesker foran et webkamera, i 360p og 540p, bedømt med øyet.
Måler man samme kodek med PSNR over artikkelens bredere testsett, havner BD-rate-gevinsten snarere rundt 52 %. Fremdeles et svært stort tall. Men ikke 87,8 %.
Referansen er den svakeste H.265 du får kjøpt
Sammenligningsgrunnlaget er H.265 i maskinvare på Intel Quick Sync, ikke en godt innstilt x265 med trege presets. Maskinvarekodere bundet til konferanselatens er gulvet for hva H.265 klarer, ikke taket.
Det finnes heller ingen sammenligning mot AV1 eller VVC noe sted i artikkelen. Forfatterne forklarer hvorfor: de utelater VTM og ECM fordi de mangler implementasjoner i forbrukermaskinvare, så det er ingenting å måle mot i sanntid. Forsvarlig som forskningsvalg, men det betyr at ingen ennå har vist MLVC mot en moderne AV1-koder.
Den egentlige bragden er determinisme, ikke kompresjon
Dette er delen som ble begravd under bitrate-tallene, og det er den mer interessante ingeniørhistorien.
Nevrale kodeker har slått konvensjonelle kodeker på kodingseffektivitet en god stund. De lot seg ikke rulle ut, fordi de ikke kunne dekodes pålitelig på en annen maskin enn den som hadde kodet.
Entropikoding krever at koder og dekoder regner ut identiske sannsynligheter. Kjør samme nettverk på en Apple Neural Engine og en Qualcomm Hexagon, og du får ikke identiske flyttallsresultater, fordi kompilatorene velger andre kjerner, slår sammen operatorer ulikt og avrunder ulikt. Bitstrømmen dekodes da til søppel.
Artikkelen setter et tall på det. DCVC-RT oppnår uten begrensninger rundt 69,6 % BD-rate-forbedring når koder og dekoder sitter på samme plattform. På tvers av plattformer er BD-raten uendelig, som er den høflige måten å si at videoen ikke dekodes i det hele tatt.
Slik løste de det
MLVC slutter å be de to endene om å bli enige ved flaks. Den sender entropimodellens skalaparametre eksplisitt gjennom hyperprioren, slik at begge ender leser de samme verdiene ut av bitstrømmen i stedet for at hver av dem regner dem ut.
Rundt det har teamet fjernet alt annet som divergerer. Eksotiske aktiveringsfunksjoner er borte til fordel for ReLU og LeakyReLU med ReGLU-gating. INT8-kvantisering avvises blankt, fordi INT8-konvolusjon ikke er reproduserbar på tvers av produsenter, og eldre Apple-brikker simulerer den i FP16 uansett. Alt kjører i FP16.
Den disiplinen koster reell kompresjon. En perseptuelt trent DCVC-RT oppnår 81,9 % der MLVC oppnår 75,5 %. Microsoft ga fra seg rundt seks BD-rate-poeng for å få en kodek som dekoder på maskinvare selskapet ikke eier.
For alle som har satt video i produksjon, er det åpenbart den riktige byttehandelen, og det er første gang en lært kodek klarer den.
Hva som faktisk ligger i repositoriet
Verdt å se på direkte, for repositoriet forteller en litt annen historie enn kunngjøringen.
Repositoriet ble opprettet 28. januar 2026 og inneholdt i seks måneder ikke annet enn en lisens, et README-utkast og Microsofts vanlige styringsfiler. Selve koden landet 22. juli i én eneste commit med tittelen "Hello MLVC", sendt inn av Tanel Pärnamaa, artikkelens førsteforfatter. I skrivende stund er det 8 commits, 189 stjerner, 10 forker og ingen taggede utgivelser i det hele tatt.
Dette er altså et kodeslipp i ett stykke, ikke et prosjekt utviklet i åpenhet. Det er ingen kritikk, bare den riktige forventningen. Alle fire åpne saker er Dependabot-oppdateringer for transformers, jupyterlab og cryptography. Det eneste eksterne bidraget som hittil er flettet inn, er en énlinjes rettelse som legger #include <cstdint> til EntropyCoder.h slik at C++-entropikoderen bygger på GCC 13 og nyere Clang. Lite, men et godt tegn: noen utenfor Microsoft forsøkte å kompilere den i løpet av dager, og Microsoft tok inn rettelsen.
Hva du får
- Fire sjekkpunkter. Den fulle MLVC med 18,3 millioner parametre og den lettere MLVC-S med 5,4 millioner, hver i en PSNR-optimert og en perseptuelt optimert variant. De perseptuelle er trent med LPIPS og en ansiktssegmenteringsmaske, som forteller nøyaktig hva de er bygget for.
- Hele treningspipelinen, for både bilde- og videomodellen, styrt av YAML-konfigurasjoner. Microsoft har også dokumentert hvordan treningsdataene ble samlet inn, som er mer enn de fleste utgivelser gjør.
- Eksportverktøy som konverterer en modell til CoreML for Apple, ONNX for Intel og OpenVINO, og QNN for Qualcomm, ved faste inndimensjoner. Støttede kjøretidsmiljøer er ONNX Runtime på CPU og GPU, ONNX Runtime QNN, OpenVINO og Windows ML.
- En rANS-entropikoder i C++ i
packages/msrtc_ransmed Python-bindinger, pluss benchmarkverktøy som beregner BD-rate, MS-SSIM, LPIPS, VIF og DeQA.
Det du ikke får, er et C++-kodekbibliotek du kan lenke inn i en applikasjon. Microsoft sier det kommer i en senere utgivelse. I dag er den brukbare flaten Python, og du trenger Python 3.12 eller 3.13 og uv for å installere det.
Hvor bildefrekvensene faktisk havner
Farten er grunnen til at dette er interessant, så oppløsningsstigen betyr noe. Kodingsgjennomstrømning fra artikkelen:
| Oppløsning | MLVC, Apple M3 Pro | MLVC, snitt av 3 produsenter | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 fps | 103 fps | ikke publisert |
| 540p | 65,7 fps | 49 fps | ikke publisert |
| 720p | 33,8 fps | ikke publisert | 83,8 fps |
| 1080p | 15,6 fps | ikke publisert | 39,5 fps |
Dekoding går noen bilder i sekundet tregere enn koding hele veien. På Intel Lunar Lake er 1080p-tallet 10,5 fps, og de tre testede produsentene er Apple M3 og M4, Intel Lunar Lake og Qualcomm Snapdragon X Elite.
Den ærlige oppsummeringen: 540p ved 30 fps er det som kan leveres, hos alle tre produsenter, med under halve NPU-en. Sanntids-1080p finnes bare på den avslankede modellen, på Apple, i én retning. Artikkelen bemerker dessuten at samtidig koding og dekoding på én enhet ved 1080p og oppover fortsatt er et problem, og det er nettopp det en toveissamtale trenger.
Microsofts veikart følger det: først stabilisere 540p og bedre tapstoleransen, deretter 1080p og bredere strømmescenarier.
Hvorfor du ikke kan legge dette inn i en strømmestige
Kompresjonseffektivitet har aldri avgjort skjebnen til en kodek innen strømming. Det gjør dekoderne.
Vi skrev en hel artikkel om hvordan HEVC aldri ble fremtiden den ble lovet å bli, og årsaken var lisenser og enhetsstøtte, ikke kodingsverktøy. AV1 begynte først å bety noe for reelle utrullinger da telefoner fikk maskinvaredekodere for den.
Formatet er vektene
MLVC har en hardere variant av det problemet. Det finnes ingen MLVC-bitstrømsstandard, fordi de trente vektene er formatet. En strøm kan bare dekodes av en enhet som har nøyaktig den modellen som kodet den, og som kjører den nært nok til å gjenskape aritmetikken.
Ingen conformance-strømmer. Ingen MIME-type. Ingen pakkehistorie, ingen DRM-historie, og ingenting i en smart-TV, en dekoder eller en nettleser som kan spille den av. CDN-et ditt kan frakte den, og i den andre enden finnes ingenting som kan åpne den.
Innholdet er ikke innholdet ditt
De imponerende tallene kommer fra statiske pratende hoder i lav oppløsning, med en modell trent på ansikter via en ROI-maske. Sport, filmkorn, raske panoreringer og mye bevegelse er nettopp der konvensjonelle kodeker gjør seg fortjent til heuristikkene sine, og det hevder artikkelen ingenting om.
Den tallfester til og med én svakhet: langtidsreferansemekanismen koster rundt 2 prosentpoeng BD-rate ved brå scenebytter, dempet med klippdeteksjon i drift. Og en spillefilm består for det meste av scenebytter.
Og ingen har målt strømforbruket
Det er artikkelens egen avsluttende begrensning. Sanntid er løst, skriver forfatterne, så strømforbruk er neste front. Å kjøre et nevralt nettverk på NPU-en for hvert bilde i en to timer lang film er på en batteridrevet enhet noe helt annet enn en dekoder med fast funksjon som er optimert gjennom et tiår.
Hvor det gir mening i dag
Overalt der begge ender er datamaskiner du styrer, og der nettet er begrensningen snarere enn silisiumet.
Det er videomøter først og fremst, og derfor er Teams lanseringsvognen. Det er også tilspillslenker over dårlige opplenker, fjernproduksjon, droner, robotikk og overvåkingslenker, samt skyspill og fjernrendering. Microsoft ber uttrykkelig om hjelp på alle disse feltene i kunngjøringen, ved siden av strømming og VOD, pluss plattformporteringer som utvider NPU-dekningen.
Bygger du noe i sanntid og peer-to-peer på moderne maskinvare, er dette verdt en ettermiddag av tiden din allerede nå. Driver du en OTT-tjeneste, er det ikke det.
Delen som virkelig burde bekymre kodekfolk
Ikke de 75 %. Stigningen.
Microsoft hevder at MLVCs kodingseffektivitet forbedres med modellkapasitet og treningsberegning, slik ethvert annet maskinlæringssystem har gjort de siste årene.
Konvensjonelle kodeker forbedres med rundt 30 til 50 % per generasjon, og en generasjon krever mesteparten av et tiår med standardisering, fulgt av år med venting på maskinvare, fulgt av en krangel om patentpuljer. Hvis en lært kodek fortsetter å bli bedre hver gang noen retter mer regnekraft mot den, og den kjører på NPU-er som uansett sitter i alt, endrer formen på den konkurransen seg.
Den er MIT-lisensiert, noe som stille fjerner den andre faktoren som tok livet av HEVC. Og den koker ned til et helt vanlig ingeniørproblem: du slipper en modellversjon, du forhandler om den slik du forhandler om en kodek, og du faller tilbake når den andre enden ikke får kjørt den.
Ingenting av dette skjer i år. Avstanden mellom "kjører i 540p på min M3" og "spilles av på en fem år gammel TV i en stue" er den samme avstanden hver eneste kodek har brukt femten år på å krysse. Men det er en stund siden kompresjon ble interessant nok til å lese en artikkel om, og denne er timen verdt.
Hva du bør gjøre med det
Ingenting endres i kodingsstigen din. Fortsett å levere H.264 for rekkevidde, HEVC og AV1 der enhetene klarer det, og se på dette igjen når tre ting skjer:
- Sanntids-1080p på den fulle modellen, ikke bare MLVC-S på Apple.
- Et C++-bibliotek som faktisk lar seg lenke inn i et produkt.
- En hvilken som helst dekoder utenfor Microsofts egne produkter.
Klon repositoriet hvis du er nysgjerrig, for treningspipelinen og analysen på tvers av plattformer er lærerike enten du noen gang slipper en nevral kodek eller ikke. Vedlegget om hvorfor INT8-kvantisering divergerer mellom produsenter er en kompakt forklaring på et problem som ellers krever langt mer plass.
Ofte stilte spørsmål
Er MLVC gratis å bruke?
Ja. Microsoft ga den ut under MIT-lisens, som dekker modellens kildekode, de trente vektene og treningsskriptene. Det følger ingen patentpulje med, noe som er en vesentlig forskjell fra HEVC.
Kan jeg strømme MLVC til en smart-TV eller en nettleser?
Nei. Dekoding krever en enhet som kan kjøre det nevrale nettverket, og nøyaktig den modellen som kodet strømmen. Ingen TV, dekoder, telefon eller nettleser har en MLVC-dekoder i dag, og det finnes ingen bitstrømsstandard de kunne implementere.
Hvor mye båndbredde sparer MLVC egentlig?
Microsoft oppgir 87,8 % lavere bitrate enn H.264 og 75,5 % lavere enn H.265 i maskinvare ved 360p, vurdert av menneskelige seere etter ITU-T P.910. Målt med PSNR over et bredere testsett er besparelsen nærmere 52 %. Begge tallene er mot maskinvarekodere på videomøteinnhold.
Hvilken maskinvare krever MLVC?
En NPU. Microsoft testet Apple Neural Engine på M3 og M4, Intel Lunar Lake og Qualcomm Snapdragon X Elite, og oppgir sanntids-540p ved 30 fps på alle tre, med under halvparten av NPU-ens kapasitet.
Er MLVC bedre enn AV1?
Den sammenligningen har ingen publisert. Artikkelen måler bare mot H.264 og H.265, og utelater AV1, VVC og ECM fordi de mangler implementasjoner i forbrukermaskinvare å sammenligne mot i sanntid.
Hva er forskjellen på MLVC og DCVC?
DCVC er linjen av nevrale kodeker Microsoft Research har publisert siden 2021. MLVC er produktversjonen, som bytter bort rundt seks poeng kompresjonseffektivitet mot evnen til å dekode pålitelig på NPU-er fra ulike produsenter.
Trenger du hjelp til å vurdere hva dette betyr for plattformen din?
Kodekvalg blir dyre når de går galt, og mesteparten av kostnaden dukker opp år senere i enhetsstøtte og lisenser, ikke i bitrate. Våre strømme- og kringkastingstalenter har levert kodeker, kodingsstiger og distribusjonskjeder i stor skala, og du kan briefe en av dem direkte om problemet du faktisk har.