Den 24. juli 2026 meddelte Microsoft på sin Linux and Open Source-blog, at MLVC, ML Video Codec, frigives som open source. Koden ligger på github.com/microsoft/mlvc under MIT-licens, med trænede vægte, træningsscripts og konverteringsværktøjet til forskellige NPU'er.
Artiklen bag, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, udkom på arXiv en måned tidligere.
Det er ikke en forskningsdemo, der kørte én gang på en GPU i et laboratorium. MLVC er produktudgaven af den DCVC-linje, som Microsoft Research har publiceret siden 2021, og Microsoft oplyser, at den allerede rulles ud i Microsoft Teams til peer-to-peer-opkald, med live-telemetri, A/B-test og tilbagefald til konventionelle codecs, når hardwaren eller netværket ikke kan følge med.
Påstanden er stor nok til at fortjene et ordentligt eftersyn, og det er, hvad denne artikel gør: tallene, hvad de faktisk måler, hvad der reelt ligger i repositoriet, og om noget af det rører en streamingkæde i år.
Vil du have den korte version først, holder vi en enkel definition af, hvad MLVC er, i vores streamingordbog.
Tallene fra meddelelsen
Microsofts egen sammenligning, ved tilsvarende subjektiv kvalitet:
| Opløsning | Bitrate sparet vs. H.264 | Bitrate sparet vs. H.265 |
|---|---|---|
| 360p | 87,8 % | 75,5 % |
| 540p | 82,7 % | 65,4 % |
Den konkrete udgave er lettere at huske. Et opkald i 360p ved 30 billeder i sekundet, der kræver 1 Mbps H.264, kræver omkring 122 kbps MLVC. Groft sagt en ottendedel af bittene, i realtid, på en bærbars NPU.
Så til det med småt, for det betyder en hel del.
Det er menneskelige bedømmelser, ikke PSNR
Procenterne er MOS-baserede, fra en subjektiv ITU-T P.910-test, hvor menneskelige seere gav klippene karakter. Kildematerialet er Video Conferencing Dataset, som Microsoft ligeledes har bygget og frigivet. Det er altså mennesker foran et webkamera, i 360p og 540p, bedømt med øjet.
Måler man den samme codec med PSNR på artiklens bredere testsæt, lander BD-rate-gevinsten nærmere 52 %. Stadig et meget stort tal. Bare ikke 87,8 %.
Referencen er den svageste H.265, man kan købe
Sammenligningsgrundlaget er H.265 i hardware på Intel Quick Sync, ikke en velindstillet x265 med langsomme presets. Hardware-encodere bundet til konferencelatens er bunden af, hvad H.265 kan, ikke toppen.
Der er heller ingen sammenligning med AV1 eller VVC nogen steder i artiklen. Forfatterne forklarer hvorfor: de udelader VTM og ECM, fordi de ikke har implementeringer i almindelig forbrugerhardware, så der er intet at måle imod i realtid. Forsvarligt som forskningsbeslutning, men det betyder, at ingen endnu har vist MLVC over for en moderne AV1-encoder.
Den egentlige bedrift er determinisme, ikke kompression
Det er den del, der forsvandt under bitrate-tallene, og det er den mere interessante ingeniørhistorie.
Neurale codecs har slået konventionelle codecs på kodningseffektivitet et stykke tid. De kunne ikke udrulles, fordi de ikke kunne afkodes pålideligt på en anden maskine end den, der havde kodet.
Entropikodning kræver, at encoder og decoder beregner identiske sandsynligheder. Kør det samme netværk på en Apple Neural Engine og en Qualcomm Hexagon, og du får ikke identiske flydende tal, fordi compilerne vælger andre kerner, sammensmelter operatorer anderledes og afrunder anderledes. Bitstrømmen afkodes så til noget vrøvl.
Artiklen sætter tal på det. DCVC-RT opnår uden begrænsninger omkring 69,6 % BD-rate-forbedring, når encoder og decoder sidder på samme platform. På tværs af platforme er dens BD-rate uendelig, hvilket er den høflige måde at sige, at videoen slet ikke afkodes.
Sådan løste de det
MLVC holder op med at bede de to ender om at være enige ved held. Den sender entropimodellens skalaparametre eksplicit gennem hyperprioren, så begge ender læser de samme værdier ud af bitstrømmen i stedet for hver især at beregne dem.
Rundt om det har holdet fjernet alt andet, der divergerer. Eksotiske aktiveringsfunktioner er væk til fordel for ReLU og LeakyReLU med ReGLU-gating. INT8-kvantisering afvises helt, fordi INT8-foldning ikke er reproducerbar på tværs af producenter, og ældre Apple-silicium simulerer den alligevel i FP16. Det hele kører i FP16.
Den disciplin koster reel kompression. En perceptuelt trænet DCVC-RT opnår 81,9 %, hvor MLVC opnår 75,5 %. Microsoft gav omkring seks BD-rate-point væk for at få en codec, der afkoder på hardware, virksomheden ikke ejer.
For enhver, der har sat video i produktion, er det åbenlyst den rigtige byttehandel, og det er første gang, en lært codec klarer den.
Hvad der faktisk ligger i repositoriet
Værd at kigge direkte på, for repositoriet fortæller en lidt anden historie end meddelelsen.
Repositoriet blev oprettet den 28. januar 2026 og indeholdt i seks måneder intet ud over en licens, et README-udkast og Microsofts sædvanlige governance-filer. Selve koden landede den 22. juli i ét enkelt commit med titlen "Hello MLVC", indsendt af Tanel Pärnamaa, artiklens førsteforfatter. I skrivende stund er der 8 commits, 189 stjerner, 10 forks og slet ingen taggede udgivelser.
Det er altså et koderelease i ét stykke, ikke et projekt udviklet i det åbne. Det er ikke en kritik, blot den rigtige forventning. Alle fire åbne issues er Dependabot-opdateringer til transformers, jupyterlab og cryptography. Det eneste eksterne bidrag, der hidtil er flettet ind, er en rettelse på én linje, der tilføjer #include <cstdint> til EntropyCoder.h, så C++-entropikoderen kan bygges på GCC 13 og nyere Clang. Småt, men et godt tegn: nogen uden for Microsoft forsøgte at kompilere den inden for få dage, og Microsoft flettede rettelsen ind.
Hvad du får
- Fire checkpoints. Den fulde MLVC med 18,3 millioner parametre og den lettere MLVC-S med 5,4 millioner, hver i en PSNR-optimeret og en perceptuelt optimeret variant. De perceptuelle er trænet med LPIPS og en ansigtssegmenteringsmaske, hvilket fortæller præcis, hvad de er bygget til.
- Hele træningspipelinen, til både billed- og videomodellen, styret af YAML-konfigurationer. Microsoft har også dokumenteret, hvordan træningsdata blev indsamlet, hvilket er mere end de fleste udgivelser gør.
- Eksportværktøjer, der konverterer en model til CoreML til Apple, ONNX til Intel og OpenVINO samt QNN til Qualcomm, ved faste inputdimensioner. Understøttede runtimes 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, plus benchmarkværktøjer, der beregner BD-rate, MS-SSIM, LPIPS, VIF og DeQA.
Det, du ikke får, er et C++-codecbibliotek, du kan linke ind i en applikation. Microsoft siger, det kommer i en senere udgivelse. I dag er den brugbare overflade Python, og du skal bruge Python 3.12 eller 3.13 og uv for at installere det.
Hvor billedhastighederne reelt lander
Hastigheden er grunden til, at det er interessant, så opløsningsstigen betyder noget. Kodningsgennemløb fra artiklen:
| Opløsning | MLVC, Apple M3 Pro | MLVC, gennemsnit af 3 producenter | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 fps | 103 fps | ikke offentliggjort |
| 540p | 65,7 fps | 49 fps | ikke offentliggjort |
| 720p | 33,8 fps | ikke offentliggjort | 83,8 fps |
| 1080p | 15,6 fps | ikke offentliggjort | 39,5 fps |
Afkodning kører nogle få billeder i sekundet langsommere end kodning hele vejen igennem. På Intel Lunar Lake er 1080p-tallet 10,5 fps, og de tre testede producenter er Apple M3 og M4, Intel Lunar Lake og Qualcomm Snapdragon X Elite.
Den ærlige opsummering: 540p ved 30 fps er det, der kan leveres, på alle tre producenter, med under halvdelen af NPU'en. Realtids-1080p findes kun på den slankede model, på Apple, i én retning. Artiklen bemærker desuden, at samtidig kodning og afkodning på én enhed ved 1080p og derover stadig er et problem, og det er netop, hvad et tovejsopkald kræver.
Microsofts køreplan følger det: først stabilisere 540p og forbedre tabsrobustheden, derefter 1080p og bredere streamingscenarier.
Hvorfor du ikke kan sætte det ind i en streamingstige
Kompressionseffektivitet har aldrig afgjort en codecs skæbne i streaming. Det gør decoderne.
Vi skrev en hel artikel om, hvordan HEVC aldrig blev den fremtid, den blev lovet, og årsagen var licenser og enhedsunderstøttelse, ikke kodningsværktøjer. AV1 begyndte først at betyde noget for rigtige udrulninger, da telefoner fik hardwaredecodere til den.
Formatet er vægtene
MLVC har en hårdere udgave af det problem. Der findes ingen MLVC-bitstrømsstandard, fordi de trænede vægte er formatet. En strøm kan kun afkodes af en enhed, der har præcis den model, som kodede den, og som kører den tæt nok på til at gengive aritmetikken.
Ingen conformance-strømme. Ingen MIME-type. Ingen packaging-historie, ingen DRM-historie, og intet i et smart-tv, en set-top-boks eller en browser, der kan afspille den. Dit CDN kan transportere den, og i den anden ende er der intet, der kan åbne den.
Indholdet er ikke dit indhold
De imponerende tal stammer fra statiske talende hoveder i lav opløsning, med en model trænet på ansigter via en ROI-maske. Sport, filmkorn, hurtige panoreringer og megen bevægelse er netop dér, hvor konventionelle codecs gør deres heuristikker fortjent, og det hævder artiklen intet om.
Den sætter endda tal på én svaghed: long-term-reference-mekanismen koster omkring 2 procentpoint BD-rate ved bratte scenskift, afbødet med klipdetektion i drift. Og en spillefilm er mest af alt scenskift.
Og ingen har målt strømforbruget
Det er artiklens egen afsluttende begrænsning. Realtid er løst, skriver forfatterne, så strømforbrug er den næste front. At køre et neuralt netværk på NPU'en for hvert billede i en to timer lang film er på en batteridrevet enhed noget helt andet end en fastfunktionsdecoder, der er optimeret gennem et årti.
Hvor det giver mening i dag
Alle steder hvor begge ender er computere, du styrer, og hvor netværket er begrænsningen frem for siliciummet.
Det er først og fremmest videomøder, og derfor er Teams lanceringsvognen. Det er også tilspilsforbindelser over dårlige uplinks, fjernproduktion, droner, robotter og overvågningsforbindelser, samt cloud gaming og fjernrendering. Microsoft beder udtrykkeligt om hjælp på alle de områder i meddelelsen, ved siden af streaming og VOD, samt platformsporteringer, der udvider NPU-dækningen.
Bygger du noget i realtid og peer-to-peer på moderne hardware, er det en eftermiddag af din tid værd nu. Driver du en OTT-tjeneste, er det ikke.
Den del, der virkelig burde bekymre codec-folk
Ikke de 75 %. Hældningen.
Microsoft hævder, at MLVC's kodningseffektivitet forbedres med modelkapacitet og træningsberegning, sådan som ethvert andet maskinlæringssystem har gjort de seneste år.
Konventionelle codecs forbedres med cirka 30 til 50 % pr. generation, og en generation kræver det meste af et årti med standardisering, efterfulgt af år med venten på hardware, efterfulgt af en strid om patentpuljer. Hvis en lært codec bliver ved med at blive bedre, hver gang nogen retter mere beregning mod den, og den kører på NPU'er, der alligevel sidder i alt, ændrer den konkurrence form.
Den er MIT-licenseret, hvilket stille og roligt fjerner den anden faktor, der slog HEVC ihjel. Og den koger ned til et helt almindeligt ingeniørproblem: du udgiver en modelversion, du forhandler om den, som du forhandler om en codec, og du falder tilbage, når den anden ende ikke kan køre den.
Intet af det sker i år. Afstanden mellem "kører i 540p på min M3" og "afspiller på et fem år gammelt fjernsyn i en stue" er den samme afstand, hver eneste codec har brugt femten år på at tilbagelægge. Men det er et stykke tid siden, kompression blev interessant nok til at læse en artikel om, og denne er timen værd.
Hvad du skal gøre ved det
Der ændrer sig intet i din kodningsstige. Bliv ved med at levere H.264 for rækkevidde, HEVC og AV1 hvor enhederne kan følge med, og kig igen, når tre ting sker:
- Realtids-1080p på den fulde model, ikke kun MLVC-S på Apple.
- Et C++-bibliotek, der rent faktisk kan linkes ind i et produkt.
- En hvilken som helst decoder uden for Microsofts egne produkter.
Klon repositoriet, hvis du er nysgerrig, for træningspipelinen og analysen på tværs af platforme er lærerige, uanset om du nogensinde udgiver en neural codec. Appendikset om, hvorfor INT8-kvantisering divergerer mellem producenter, er en kompakt forklaring på et problem, der normalt kræver langt mere plads.
Ofte stillede spørgsmål
Er MLVC gratis at bruge?
Ja. Microsoft har udgivet den under MIT-licens, som dækker modellens kildekode, de trænede vægte og træningsscriptene. Der hænger ingen patentpulje ved, hvilket er en væsentlig forskel fra HEVC.
Kan jeg streame MLVC til et smart-tv eller en browser?
Nej. Afkodning kræver en enhed, der kan køre det neurale netværk, og præcis den model, der kodede strømmen. Intet fjernsyn, ingen set-top-boks, telefon eller browser har en MLVC-decoder i dag, og der findes ingen bitstrømsstandard, de kunne implementere.
Hvor meget båndbredde sparer MLVC egentlig?
Microsoft angiver 87,8 % lavere bitrate end H.264 og 75,5 % lavere end H.265 i hardware ved 360p, bedømt af menneskelige seere efter ITU-T P.910. Målt med PSNR på et bredere testsæt er besparelsen nærmere 52 %. Begge tal er mod hardware-encodere på videomødeindhold.
Hvilken hardware kræver MLVC?
En NPU. Microsoft har testet Apple Neural Engine på M3 og M4, Intel Lunar Lake og Qualcomm Snapdragon X Elite og angiver realtids-540p ved 30 fps på alle tre, med under halvdelen af NPU'ens kapacitet.
Er MLVC bedre end AV1?
Den sammenligning har ingen offentliggjort. Artiklen måler kun mod H.264 og H.265 og udelader AV1, VVC og ECM, fordi de ikke har implementeringer i almindelig forbrugerhardware at sammenligne med i realtid.
Hvad er forskellen på MLVC og DCVC?
DCVC er den linje af neurale codecs, Microsoft Research har publiceret siden 2021. MLVC er produktudgaven, der bytter cirka seks point kompressionseffektivitet for evnen til at afkode pålideligt på NPU'er fra forskellige producenter.
Brug for hjælp til at vurdere, hvad det betyder for din platform?
Codec-beslutninger er dyre, når de går galt, og størstedelen af omkostningen dukker op år senere i enhedsunderstøttelse og licenser, ikke i bitrate. Vores streaming- og broadcast-talenter har leveret codecs, kodningsstiger og distributionskæder i stor skala, og du kan briefe en af dem direkte om det problem, du faktisk har.