Op 24 juli 2026 kondigde Microsoft op zijn Linux and Open Source-blog aan dat het MLVC, de ML Video Codec, als open source vrijgeeft. De code staat op github.com/microsoft/mlvc onder de MIT-licentie, met getrainde gewichten, trainingsscripts en de conversietooling voor verschillende NPU's.
Het bijbehorende paper, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, verscheen een maand eerder op arXiv.
Dit is geen onderzoeksdemo die één keer op een lab-GPU draaide. MLVC is de productversie van de DCVC-lijn die Microsoft Research sinds 2021 publiceert, en Microsoft zegt dat het al wordt uitgerold in Microsoft Teams voor peer-to-peer-gesprekken, met live telemetrie, A/B-tests en een terugval op conventionele codecs wanneer de hardware of het netwerk niet meewerkt.
De claim is groot genoeg om fatsoenlijk na te trekken, en dat is wat dit artikel doet: de cijfers, wat ze werkelijk meten, wat er echt in de repository zit, en of iets hiervan dit jaar een streamingketen raakt.
Wilt u eerst de korte versie: we houden een eenvoudige definitie bij van wat MLVC is in onze streamingwoordenlijst.
De cijfers uit de aankondiging
Microsofts eigen vergelijking, bij gelijkwaardige subjectieve kwaliteit:
| Resolutie | Bitrate bespaard t.o.v. H.264 | Bitrate bespaard t.o.v. H.265 |
|---|---|---|
| 360p | 87,8% | 75,5% |
| 540p | 82,7% | 65,4% |
De concrete versie onthoudt u makkelijker. Een gesprek op 360p met 30 beelden per seconde dat 1 Mbps H.264 vraagt, vraagt ongeveer 122 kbps MLVC. Ruwweg een achtste van de bits, in realtime, op de NPU van een laptop.
Nu de kleine lettertjes, want die doen er behoorlijk toe.
Dit zijn menselijke scores, geen PSNR
Die percentages zijn MOS-gebaseerd, uit een subjectieve ITU-T P.910-test waarin menselijke kijkers de fragmenten beoordeelden. Het bronmateriaal is de Video Conferencing Dataset, die Microsoft eveneens heeft gebouwd en vrijgegeven. Het gaat dus om mensen voor een webcam, op 360p en 540p, met het oog beoordeeld.
Meet dezelfde codec met PSNR over de bredere testset van het paper, en de BD-rate-winst komt eerder rond de 52% uit. Nog steeds een heel groot getal. Maar geen 87,8%.
Het ankerpunt is de zwakste H.265 die u kunt kopen
Er wordt vergeleken met H.265 in hardware op Intel Quick Sync, niet met een goed afgestelde x265 op trage presets. Hardware-encoders die aan conferentielatentie gebonden zijn, vormen de ondergrens van wat H.265 kan, niet de bovengrens.
Verder staat er in het hele paper geen vergelijking met AV1 of VVC. De auteurs leggen uit waarom: ze laten VTM en ECM weg omdat daar geen implementaties in consumentenhardware voor bestaan, dus valt er in realtime niets tegen af te zetten. Als onderzoeksbeslissing te verdedigen, maar het betekent dat niemand MLVC nog naast een moderne AV1-encoder heeft gezet.
De echte prestatie is determinisme, niet compressie
Dit is het stuk dat onder de bitratecijfers bedolven raakte, en het is het interessantere technische verhaal.
Neurale codecs verslaan conventionele codecs al een tijd op codeerefficiëntie. Uitrollen lukte niet, omdat ze niet betrouwbaar te decoderen waren op een andere machine dan die had gecodeerd.
Entropiecodering vereist dat encoder en decoder identieke kansen berekenen. Draai hetzelfde netwerk op een Apple Neural Engine en op een Qualcomm Hexagon en u krijgt geen identieke floating-pointresultaten, omdat de compilers andere kernels kiezen, operatoren anders samenvoegen en anders afronden. De bitstream decodeert dan tot rommel.
Het paper zet er een getal op. DCVC-RT haalt zonder beperkingen ongeveer 69,6% BD-rate-verbetering wanneer encoder en decoder op hetzelfde platform zitten. Over platforms heen is de BD-rate oneindig, wat de nette manier is om te zeggen dat de video helemaal niet decodeert.
Hoe ze het hebben opgelost
MLVC vraagt niet langer of beide kanten het toevallig eens worden. Het verstuurt de schaalparameters van het entropiemodel expliciet via de hyperprior, zodat beide uiteinden dezelfde waarden uit de bitstream lezen in plaats van ze elk zelf te berekenen.
Daaromheen heeft het team alles verwijderd wat verder uiteenloopt. Exotische activatiefuncties zijn verdwenen ten gunste van ReLU en LeakyReLU met ReGLU-gating. INT8-kwantisatie wordt ronduit afgewezen, omdat INT8-convolutie tussen fabrikanten niet reproduceerbaar is en oudere Apple-chips het toch in FP16 simuleren. Het geheel draait in FP16.
Die discipline kost echte compressie. Een perceptueel getrainde DCVC-RT haalt 81,9% waar MLVC 75,5% haalt. Microsoft gaf zo'n zes BD-rate-punten op om een codec te krijgen die decodeert op hardware die het bedrijf niet bezit.
Voor wie ooit video in productie heeft gebracht, is dat duidelijk de juiste ruil, en het is de eerste keer dat een geleerde codec hem maakt.
Wat er echt in de repository zit
De moeite waard om zelf te bekijken, want de repository vertelt een iets ander verhaal dan de aankondiging.
De repository is aangemaakt op 28 januari 2026 en bevatte zes maanden lang niets dan een licentie, een README-aanzet en Microsofts standaard governancebestanden. De eigenlijke code kwam op 22 juli in één enkele commit met de titel "Hello MLVC", ingediend door Tanel Pärnamaa, de eerste auteur van het paper. Op het moment van schrijven staat de teller op 8 commits, 189 sterren, 10 forks en helemaal geen getagde releases.
Dit is dus een codedump, geen project dat in de openbaarheid is ontwikkeld. Dat is geen kritiek, alleen de juiste verwachting. Alle vier de open issues zijn Dependabot-updates voor transformers, jupyterlab en cryptography. De enige externe bijdrage die tot nu toe is samengevoegd, is een fix van één regel die #include <cstdint> aan EntropyCoder.h toevoegt zodat de C++-entropiecoder bouwt op GCC 13 en nieuwere Clang. Klein, maar een goed teken: iemand buiten Microsoft probeerde het binnen enkele dagen te compileren, en Microsoft nam de patch over.
Wat u krijgt
- Vier checkpoints. De volledige MLVC met 18,3 miljoen parameters en de lichtere MLVC-S met 5,4 miljoen, elk in een PSNR-geoptimaliseerde en een perceptueel geoptimaliseerde variant. De perceptuele zijn getraind met LPIPS en een gezichtssegmentatiemasker, wat precies verraadt waarvoor ze zijn gebouwd.
- De volledige trainingspijplijn, voor zowel het beeld- als het videomodel, aangestuurd met YAML-configuraties. Microsoft heeft ook gedocumenteerd hoe de trainingsdata zijn verzameld, wat meer is dan de meeste releases doen.
- Exporttooling die een model omzet naar CoreML voor Apple, ONNX voor Intel en OpenVINO, en QNN voor Qualcomm, bij vaste invoerafmetingen. Ondersteunde runtimes zijn ONNX Runtime op CPU en GPU, ONNX Runtime QNN, OpenVINO en Windows ML.
- Een rANS-entropiecoder in C++ in
packages/msrtc_ransmet Python-bindings, plus benchmarktooling die BD-rate, MS-SSIM, LPIPS, VIF en DeQA berekent.
Wat u niet krijgt, is een C++-codecbibliotheek die u in een applicatie kunt linken. Microsoft zegt dat die in een volgende release komt. Vandaag is het bruikbare oppervlak Python, en u hebt Python 3.12 of 3.13 en uv nodig om het te installeren.
Waar de framerates werkelijk uitkomen
Snelheid is de reden dat dit interessant is, dus de resolutieladder telt. Encodeerdoorvoer volgens het paper:
| Resolutie | MLVC, Apple M3 Pro | MLVC, gemiddelde 3 fabrikanten | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 fps | 103 fps | niet gepubliceerd |
| 540p | 65,7 fps | 49 fps | niet gepubliceerd |
| 720p | 33,8 fps | niet gepubliceerd | 83,8 fps |
| 1080p | 15,6 fps | niet gepubliceerd | 39,5 fps |
Decoderen loopt over de hele linie een paar beelden per seconde achter op encoderen. Op Intel Lunar Lake ligt het 1080p-cijfer op 10,5 fps, en de drie geteste fabrikanten zijn Apple M3 en M4, Intel Lunar Lake en Qualcomm Snapdragon X Elite.
De eerlijke samenvatting: 540p op 30 fps is wat er te leveren valt, op alle drie de fabrikanten, met minder dan de helft van de NPU. Realtime 1080p bestaat alleen op het uitgeklede model, op Apple, in één richting. Het paper merkt bovendien op dat gelijktijdig encoderen en decoderen op één apparaat bij 1080p en hoger nog steeds een probleem is, en dat is precies wat een tweerichtingsgesprek nodig heeft.
Microsofts routekaart volgt dat: eerst 540p stabiliseren en de verliesbestendigheid verbeteren, daarna 1080p en bredere streamingscenario's.
Waarom dit nog niet in een streamingladder past
Compressie-efficiëntie heeft nooit bepaald hoe het een codec vergaat in streaming. Decoders bepalen dat.
We schreven een heel artikel over hoe HEVC nooit de beloofde toekomst werd, en de reden lag bij licenties en apparaatondersteuning, niet bij codeergereedschap. AV1 begon pas mee te tellen voor echte uitrol toen telefoons er hardwaredecoders voor kregen.
Het formaat zijn de gewichten
MLVC heeft een hardere variant van dat probleem. Er is geen MLVC-bitstreamstandaard, want de getrainde gewichten zijn het formaat. Een stream is alleen te decoderen door een apparaat dat precies het model heeft dat hem codeerde, en dat model nauwkeurig genoeg uitvoert om de rekenkunde te reproduceren.
Geen conformance streams. Geen MIME-type. Geen packagingverhaal, geen DRM-verhaal, en niets in een smart-tv, settopbox of browser dat het kan afspelen. Uw CDN kan het vervoeren, en aan de andere kant kan niets het openen.
De content is niet uw content
De indrukwekkende cijfers komen van statische pratende hoofden op lage resolutie, met een model dat op gezichten is getraind via een ROI-masker. Sport, filmkorrel, snelle pans en veel beweging zijn precies waar conventionele codecs hun heuristieken verdienen, en daarover claimt het paper niets.
Het becijfert zelfs één zwakte: het long-term-referencemechanisme kost ongeveer 2 procentpunt BD-rate bij abrupte scènewisselingen, opgevangen met scènedetectie tijdens de uitrol. Een film bestaat vooral uit scènewisselingen.
En niemand heeft het stroomverbruik gemeten
Dat is de slotbeperking van het paper zelf. Realtime is opgelost, zeggen de auteurs, dus is stroomverbruik de volgende grens. Een neuraal netwerk op de NPU laten draaien voor elk beeld van een film van twee uur is op een accuapparaat iets heel anders dan een decoder met vaste functie die al tien jaar wordt geoptimaliseerd.
Waar het vandaag wel zin heeft
Overal waar beide uiteinden computers zijn die u beheert, en waar het netwerk de beperking is en niet het silicium.
Dat is in de eerste plaats videovergaderen, vandaar dat Teams het lanceervoertuig is. Het zijn ook aanvoerlijnen over slechte uplinks, productie op afstand, drones, robotica en bewakingsverbindingen, en cloudgaming of remote rendering. Microsoft vraagt in de aankondiging expliciet om hulp op al die terreinen, naast streaming en VOD, plus platformports om de NPU-dekking te verbreden.
Bouwt u iets realtime en peer-to-peer op moderne hardware, dan is dit nu een middag van uw tijd waard. Draait u een OTT-dienst, dan niet.
Het deel dat codecmensen echt zorgen zou moeten baren
Niet de 75%. De helling.
Microsoft stelt dat de codeerefficiëntie van MLVC meegroeit met modelcapaciteit en trainingsrekenkracht, zoals elk ander machine-learningsysteem de afgelopen jaren.
Conventionele codecs verbeteren met ruwweg 30 tot 50% per generatie, en een generatie kost het grootste deel van een decennium aan standaardisatie, gevolgd door jaren wachten op hardware, gevolgd door een ruzie over een patentpool. Als een geleerde codec beter blijft worden zodra iemand er meer rekenkracht op richt, en hij draait op NPU's die toch al overal in zitten, verandert de vorm van die concurrentie.
Hij staat onder de MIT-licentie, wat stilletjes de andere factor wegneemt die HEVC de das omdeed. En hij valt terug op een gewoon technisch probleem: u levert een modelversie uit, u onderhandelt erover zoals u over een codec onderhandelt, en u valt terug wanneer de andere kant hem niet kan draaien.
Niets daarvan gebeurt dit jaar. Het gat tussen "draait op 540p op mijn M3" en "speelt af op een vijf jaar oude tv in iemands woonkamer" is hetzelfde gat waar elke codec vijftien jaar over deed. Maar het is een tijd geleden dat compressie interessant genoeg werd om er een paper voor te lezen, en dit paper is het uur waard.
Wat u eraan moet doen
Aan uw encodeerladder verandert niets. Blijf H.264 leveren voor bereik, HEVC en AV1 waar de apparaten meewerken, en kijk opnieuw wanneer drie dingen gebeuren:
- Realtime 1080p op het volledige model, niet alleen MLVC-S op Apple.
- Een C++-bibliotheek die daadwerkelijk in een product te linken is.
- Enige decoder buiten Microsofts eigen producten.
Kloon de repository als u nieuwsgierig bent, want de trainingspijplijn en de platformoverstijgende analyse zijn leerzaam, of u ooit een neurale codec uitbrengt of niet. De bijlage over waarom INT8-kwantisatie tussen fabrikanten uiteenloopt, is een compacte uitleg van een probleem dat normaal veel meer ruimte kost.
Veelgestelde vragen
Is MLVC gratis te gebruiken?
Ja. Microsoft heeft het uitgebracht onder de MIT-licentie, die de broncode van het model, de getrainde gewichten en de trainingsscripts dekt. Er hangt geen patentpool aan, een betekenisvol verschil met HEVC.
Kan ik MLVC naar een smart-tv of een browser streamen?
Nee. Decoderen vereist een apparaat dat het neurale netwerk kan draaien, en precies het model dat de stream codeerde. Geen enkele tv, settopbox, telefoon of browser heeft vandaag een MLVC-decoder, en er is geen bitstreamstandaard die er een zou kunnen implementeren.
Hoeveel bandbreedte bespaart MLVC werkelijk?
Microsoft meldt 87,8% minder bitrate dan H.264 en 75,5% minder dan H.265 in hardware op 360p, beoordeeld door menselijke kijkers volgens ITU-T P.910. Gemeten met PSNR over een bredere testset ligt de besparing dichter bij 52%. Beide cijfers zijn tegen hardware-encoders op videovergadercontent.
Welke hardware heeft MLVC nodig?
Een NPU. Microsoft testte Apple Neural Engine op M3 en M4, Intel Lunar Lake en Qualcomm Snapdragon X Elite, en meldt realtime 540p op 30 fps op alle drie, met minder dan de helft van de capaciteit van de NPU.
Is MLVC beter dan AV1?
Die vergelijking heeft niemand gepubliceerd. Het paper meet alleen tegen H.264 en H.265, en laat AV1, VVC en ECM weg omdat daar geen implementaties in consumentenhardware voor bestaan om in realtime tegen te vergelijken.
Wat is het verschil tussen MLVC en DCVC?
DCVC is de lijn neurale codecs die Microsoft Research sinds 2021 publiceert. MLVC is de productversie, die ongeveer zes punten compressie-efficiëntie inruilt voor het vermogen om betrouwbaar te decoderen op NPU's van verschillende fabrikanten.
Hulp nodig bij wat dit voor uw stack betekent?
Codeckeuzes zijn duur wanneer ze verkeerd uitpakken, en de meeste kosten komen jaren later terecht bij apparaatondersteuning en licenties, niet bij bitrate. Onze streaming- en broadcasttalenten hebben codecs, encodeerladders en distributieketens op schaal uitgerold, en u kunt er één rechtstreeks briefen over het probleem dat u werkelijk hebt.