Am 24. Juli 2026 kündigte Microsoft in seinem Linux-and-Open-Source-Blog an, MLVC, den ML Video Codec, als Open Source freizugeben. Der Code liegt unter github.com/microsoft/mlvc unter MIT-Lizenz, mit trainierten Gewichten, Trainingsskripten und dem Konvertierungswerkzeug für verschiedene NPUs.
Das zugehörige Paper, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, erschien einen Monat zuvor auf arXiv.
Das ist keine Forschungsdemo, die einmal auf einer Labor-GPU lief. MLVC ist die Produktversion der DCVC-Linie, die Microsoft Research seit 2021 veröffentlicht, und Microsoft gibt an, sie bereits in Microsoft Teams für Peer-to-Peer-Anrufe auszurollen, mit Live-Telemetrie, A/B-Tests und einem Rückfall auf klassische Codecs, wenn Hardware oder Netz nicht mitspielen.
Die Schlagzeile ist groß genug, um sie ordentlich zu prüfen, und genau das tut dieser Beitrag: die Zahlen, was sie tatsächlich messen, was wirklich im Repository liegt, und ob irgendetwas davon in diesem Jahr einen Streaming-Stack berührt.
Wenn Sie zuerst die Kurzfassung wollen: Wir führen eine schlichte Definition davon, was MLVC ist, in unserem Streaming-Glossar.
Die Zahlen aus der Ankündigung
Microsofts eigener Vergleich, bei gleichwertiger subjektiver Qualität:
| Auflösung | Bitrate gespart ggü. H.264 | Bitrate gespart ggü. H.265 |
|---|---|---|
| 360p | 87,8 % | 75,5 % |
| 540p | 82,7 % | 65,4 % |
Die konkrete Fassung lässt sich leichter merken. Ein 360p-Anruf mit 30 Bildern pro Sekunde, der in H.264 1 Mbps braucht, braucht in MLVC etwa 122 kbps. Grob ein Achtel der Bits, in Echtzeit, auf der NPU eines Notebooks.
Jetzt das Kleingedruckte, denn es zählt erheblich.
Das sind menschliche Bewertungen, kein PSNR
Diese Prozentwerte sind MOS-basiert, aus einem subjektiven ITU-T-P.910-Test, in dem menschliche Betrachter die Clips bewertet haben. Das Ausgangsmaterial ist das Video Conferencing Dataset, das Microsoft ebenfalls aufgebaut und offengelegt hat. Es handelt sich also um Menschen vor Webcams, in 360p und 540p, nach Augenmaß beurteilt.
Misst man denselben Codec stattdessen mit PSNR über den breiteren Testsatz des Papers, landet der BD-Rate-Gewinn eher bei 52 %. Immer noch eine sehr große Zahl. Aber nicht 87,8 %.
Der Referenzpunkt ist das schwächste H.265, das man kaufen kann
Verglichen wird mit H.265 in Hardware auf Intel Quick Sync, nicht mit einem gut abgestimmten x265 in langsamen Presets. Hardware-Encoder unter Konferenzlatenz sind die Untergrenze dessen, was H.265 kann, nicht die Obergrenze.
Außerdem findet sich im gesamten Paper kein Vergleich mit AV1 oder VVC. Die Autoren begründen das: Sie lassen VTM und ECM weg, weil es dafür keine Implementierungen in Endkundenhardware gibt, also nichts, wogegen man in Echtzeit messen könnte. Als Forschungsentscheidung nachvollziehbar, aber es heißt, dass MLVC bislang niemand gegen einen modernen AV1-Encoder gezeigt hat.
Die eigentliche Leistung ist Determinismus, nicht Kompression
Das ist der Teil, der unter den Bitratenzahlen verschwunden ist, und er ist die interessantere Ingenieursgeschichte.
Neuronale Codecs schlagen klassische Codecs bei der Codiereffizienz schon eine ganze Weile. Einsetzbar waren sie nicht, weil sie sich nicht zuverlässig auf einer anderen Maschine decodieren ließen als der, die codiert hatte.
Entropiecodierung verlangt, dass Encoder und Decoder identische Wahrscheinlichkeiten berechnen. Führt man dasselbe Netz auf einer Apple Neural Engine und einer Qualcomm Hexagon aus, erhält man keine identischen Fließkommaergebnisse, weil die Compiler andere Kernel wählen, Operatoren anders verschmelzen und anders runden. Der Bitstrom decodiert dann zu Müll.
Das Paper beziffert das. DCVC-RT erreicht ohne Einschränkungen rund 69,6 % BD-Rate-Verbesserung, wenn Encoder und Decoder auf derselben Plattform sitzen. Plattformübergreifend ist seine BD-Rate unendlich, was die höfliche Umschreibung dafür ist, dass sich das Video überhaupt nicht decodieren lässt.
Wie sie das gelöst haben
MLVC verlässt sich nicht mehr darauf, dass sich beide Seiten zufällig einig sind. Es überträgt die Skalenparameter des Entropiemodells explizit über den Hyperprior, sodass beide Enden dieselben Werte aus dem Bitstrom lesen, statt sie jeweils selbst zu berechnen.
Drumherum hat das Team alles andere entfernt, was divergiert. Exotische Aktivierungsfunktionen sind zugunsten von ReLU und LeakyReLU mit ReGLU-Gating verschwunden. INT8-Quantisierung wird rundheraus verworfen, weil INT8-Faltung herstellerübergreifend nicht reproduzierbar ist und ältere Apple-Chips sie ohnehin in FP16 simulieren. Das Ganze läuft in FP16.
Diese Disziplin kostet echte Kompression. Ein perzeptuell trainiertes DCVC-RT erreicht 81,9 %, wo MLVC 75,5 % erreicht. Microsoft hat rund sechs BD-Rate-Punkte aufgegeben, um einen Codec zu bekommen, der auf Hardware decodiert, die dem Unternehmen nicht gehört.
Für jeden, der schon einmal Video in Produktion gebracht hat, ist das offensichtlich der richtige Handel, und es ist das erste Mal, dass ein gelernter Codec ihn schafft.
Was tatsächlich im Repository liegt
Ein Blick lohnt sich, denn das Repository erzählt eine etwas andere Geschichte als die Ankündigung.
Das Repository wurde am 28. Januar 2026 angelegt und enthielt sechs Monate lang nichts außer einer Lizenz, einem README-Rumpf und Microsofts üblichen Governance-Dateien. Der eigentliche Code kam am 22. Juli in einem einzigen Commit mit dem Titel „Hello MLVC", eingereicht von Tanel Pärnamaa, dem Erstautor des Papers. Zum Zeitpunkt des Schreibens sind es 8 Commits, 189 Sterne, 10 Forks und überhaupt keine getaggten Releases.
Das ist also ein Code-Drop, kein offen entwickeltes Projekt. Das ist kein Vorwurf, nur die richtige Erwartungshaltung. Alle vier offenen Issues sind Dependabot-Updates für transformers, jupyterlab und cryptography. Der einzige bisher übernommene Beitrag von außen ist ein Einzeiler, der #include <cstdint> zu EntropyCoder.h hinzufügt, damit der C++-Entropiecodierer unter GCC 13 und neueren Clang-Versionen baut. Klein, aber ein gutes Zeichen: Jemand außerhalb von Microsoft hat binnen Tagen versucht zu kompilieren, und Microsoft hat den Patch übernommen.
Was Sie bekommen
- Vier Checkpoints. Das vollständige MLVC mit 18,3 Millionen Parametern und das leichtere MLVC-S mit 5,4 Millionen, jeweils in einer PSNR-optimierten und einer perzeptuell optimierten Variante. Die perzeptuellen sind mit LPIPS und einer Gesichtssegmentierungsmaske trainiert, was genau verrät, wofür sie gebaut wurden.
- Die vollständige Trainingspipeline für Bild- und Videomodelle, gesteuert über YAML-Konfigurationen. Microsoft hat außerdem dokumentiert, wie die Trainingsdaten erhoben wurden, was mehr ist, als die meisten Releases bieten.
- Export-Werkzeuge, die ein Modell nach CoreML für Apple, ONNX für Intel und OpenVINO sowie QNN für Qualcomm konvertieren, bei festen Eingabedimensionen. Unterstützte Runtimes sind ONNX Runtime auf CPU und GPU, ONNX Runtime QNN, OpenVINO und Windows ML.
- Ein rANS-Entropiecodierer in C++ in
packages/msrtc_ransmit Python-Bindings, dazu Benchmark-Werkzeuge für BD-Rate, MS-SSIM, LPIPS, VIF und DeQA.
Was Sie nicht bekommen, ist eine C++-Codec-Bibliothek, die Sie in eine Anwendung linken können. Microsoft kündigt sie für ein Folgerelease an. Heute ist die nutzbare Oberfläche Python, und Sie brauchen Python 3.12 oder 3.13 sowie uv zur Installation.
Wo die Bildraten tatsächlich landen
Tempo ist der Grund, warum die Sache interessant ist, also zählt die Auflösungsleiter. Encoding-Durchsatz aus dem Paper:
| Auflösung | MLVC, Apple M3 Pro | MLVC, Mittel aus 3 Herstellern | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 fps | 103 fps | nicht veröffentlicht |
| 540p | 65,7 fps | 49 fps | nicht veröffentlicht |
| 720p | 33,8 fps | nicht veröffentlicht | 83,8 fps |
| 1080p | 15,6 fps | nicht veröffentlicht | 39,5 fps |
Das Decodieren läuft durchweg ein paar Bilder pro Sekunde langsamer als das Codieren. Auf Intel Lunar Lake liegt der 1080p-Wert bei 10,5 fps, und die drei getesteten Hersteller sind Apple M3 und M4, Intel Lunar Lake und Qualcomm Snapdragon X Elite.
Die ehrliche Zusammenfassung: 540p bei 30 fps ist das, was ausgeliefert werden kann, auf allen drei Herstellern, bei unter der Hälfte der NPU. Echtzeit-1080p gibt es nur auf dem abgespeckten Modell, auf Apple, in einer Richtung. Das Paper merkt außerdem an, dass gleichzeitiges Codieren und Decodieren auf einem Gerät bei 1080p und darüber weiterhin ein Problem ist, und genau das braucht ein Zweiwege-Anruf.
Microsofts Roadmap folgt dem: zuerst 540p stabilisieren und die Verlustrobustheit verbessern, dann 1080p und breitere Streaming-Szenarien.
Warum das noch in keine Streaming-Ladder gehört
Über das Schicksal eines Codecs im Streaming entscheidet nie die Kompressionseffizienz. Es entscheiden die Decoder.
Wir haben einen ganzen Beitrag darüber geschrieben, wie HEVC nie die versprochene Zukunft wurde, und der Grund lagen bei Lizenzen und Geräteunterstützung, nicht bei den Codierwerkzeugen. AV1 begann erst dann für echte Deployments zu zählen, als Telefone Hardware-Decoder dafür mitbrachten.
Das Format sind die Gewichte
MLVC hat eine härtere Variante dieses Problems. Es gibt keinen MLVC-Bitstrom-Standard, weil die trainierten Gewichte das Format sind. Ein Stream ist nur von einem Gerät decodierbar, das genau das Modell hält, welches ihn codiert hat, und es nah genug ausführt, um die Arithmetik zu reproduzieren.
Keine Conformance-Streams. Kein MIME-Typ. Keine Packaging-Geschichte, keine DRM-Geschichte, und nichts in einem Smart-TV, einer Set-Top-Box oder einem Browser, das es abspielen kann. Ihr CDN kann es ausliefern, und am anderen Ende kann es dann nichts öffnen.
Der Inhalt ist nicht Ihr Inhalt
Die beeindruckenden Zahlen stammen von statischen sprechenden Köpfen in niedriger Auflösung, mit einem Modell, das über eine Gesichts-ROI-Maske auf Gesichter trainiert wurde. Sport, Filmkorn, schnelle Schwenks und viel Bewegung sind genau die Fälle, in denen klassische Codecs ihre Heuristiken rechtfertigen, und das Paper behauptet dazu nichts.
Es beziffert sogar eine Schwäche: Der Long-Term-Reference-Mechanismus kostet bei abrupten Szenenwechseln rund 2 Prozentpunkte BD-Rate, abgefedert durch Szenenschnitterkennung im Betrieb. Ein Spielfilm besteht aber überwiegend aus Szenenwechseln.
Und den Stromverbrauch hat niemand gemessen
Das ist die abschließende Einschränkung des Papers selbst. Echtzeit sei gelöst, schreiben die Autoren, also sei der Stromverbrauch die nächste Front. Für jedes Einzelbild eines zweistündigen Films ein neuronales Netz auf der NPU laufen zu lassen, ist auf einem Akkugerät etwas ganz anderes als ein Festfunktionsdecoder, der seit einem Jahrzehnt optimiert wird.
Wo es heute Sinn ergibt
Überall dort, wo beide Enden Rechner sind, die Sie kontrollieren, und wo das Netz die Beschränkung ist, nicht das Silizium.
Das ist zuerst Konferenzvideo, weshalb Teams das Startvehikel ist. Es sind auch Zuspielstrecken über schlechte Uplinks, Fernproduktion, Drohnen, Robotik und Überwachungsstrecken sowie Cloud-Gaming und Remote-Rendering. Microsoft bittet in der Ankündigung ausdrücklich um Hilfe bei all dem, neben Streaming und VOD, dazu um Portierungen zur Verbreiterung der NPU-Abdeckung.
Wenn Sie etwas Echtzeitfähiges und Peer-to-Peer auf moderner Hardware bauen, ist das jetzt einen Nachmittag Ihrer Zeit wert. Wenn Sie einen OTT-Dienst betreiben, nicht.
Was Codec-Leute wirklich beunruhigen sollte
Nicht die 75 %. Die Steigung.
Microsoft behauptet, die Codiereffizienz von MLVC verbessere sich mit Modellkapazität und Trainingsrechenleistung, so wie es in den vergangenen Jahren bei jedem anderen ML-System war.
Klassische Codecs verbessern sich um rund 30 bis 50 % je Generation, und eine Generation braucht den besseren Teil eines Jahrzehnts an Standardisierung, gefolgt von Jahren des Wartens auf Hardware, gefolgt von einem Streit über Patentpools. Wenn ein gelernter Codec jedes Mal besser wird, sobald jemand mehr Rechenleistung darauf richtet, und er auf NPUs läuft, die ohnehin überall verbaut sind, ändert sich die Form dieses Wettbewerbs.
Er steht unter MIT-Lizenz, was den anderen Faktor, der HEVC erledigt hat, still und leise beseitigt. Und er lässt sich auf ein normales Engineering-Problem herunterbrechen: Sie liefern eine Modellversion aus, Sie handeln sie aus wie einen Codec, Sie fallen zurück, wenn die Gegenstelle sie nicht ausführen kann.
Nichts davon passiert in diesem Jahr. Die Lücke zwischen „läuft in 540p auf meinem M3" und „spielt auf einem fünf Jahre alten Fernseher im Wohnzimmer" ist dieselbe Lücke, für die jeder Codec fünfzehn Jahre gebraucht hat. Aber es ist eine Weile her, dass Kompression interessant genug wurde, um dafür ein Paper zu lesen, und dieses ist die Stunde wert.
Was jetzt zu tun ist
An Ihrer Encoding-Ladder ändert sich nichts. Liefern Sie weiter H.264 für Reichweite, HEVC und AV1 dort, wo die Geräte mitspielen, und schauen Sie wieder hin, wenn drei Dinge eintreten:
- Echtzeit-1080p auf dem vollen Modell, nicht nur MLVC-S auf Apple.
- Eine C++-Bibliothek, die sich tatsächlich in ein Produkt linken lässt.
- Irgendein Decoder außerhalb von Microsofts eigenen Produkten.
Klonen Sie das Repository, wenn Sie neugierig sind, denn die Trainingspipeline und die plattformübergreifende Analyse sind lehrreich, ganz gleich ob Sie je einen neuronalen Codec ausliefern. Der Anhang darüber, warum INT8-Quantisierung zwischen Herstellern divergiert, ist eine kompakte Erklärung eines Problems, dessen Beschreibung sonst weit mehr Platz braucht.
Häufige Fragen
Ist MLVC kostenlos nutzbar?
Ja. Microsoft hat es unter MIT-Lizenz veröffentlicht, die den Modellquellcode, die trainierten Gewichte und die Trainingsskripte abdeckt. Es hängt kein Patentpool daran, was ein bedeutsamer Unterschied zu HEVC ist.
Kann ich MLVC an einen Smart-TV oder einen Browser streamen?
Nein. Das Decodieren erfordert ein Gerät, das das neuronale Netz ausführen kann, und genau das Modell, das den Stream codiert hat. Kein Fernseher, keine Set-Top-Box, kein Telefon und kein Browser hat heute einen MLVC-Decoder, und es gibt keinen Bitstrom-Standard, den einer davon implementieren könnte.
Wie viel Bandbreite spart MLVC wirklich?
Microsoft nennt 87,8 % weniger Bitrate als H.264 und 75,5 % weniger als H.265 in Hardware bei 360p, bewertet von menschlichen Betrachtern nach ITU-T P.910. Mit PSNR über einen breiteren Testsatz gemessen liegt die Ersparnis eher bei 52 %. Beide Werte beziehen sich auf Hardware-Encoder und Konferenzvideo-Inhalte.
Welche Hardware braucht MLVC?
Eine NPU. Microsoft hat Apple Neural Engine auf M3 und M4, Intel Lunar Lake und Qualcomm Snapdragon X Elite getestet und meldet Echtzeit-540p mit 30 fps auf allen dreien, bei unter der Hälfte der NPU-Kapazität.
Ist MLVC besser als AV1?
Diesen Vergleich hat niemand veröffentlicht. Das Paper misst nur gegen H.264 und H.265 und lässt AV1, VVC und ECM weg, weil es dafür keine Implementierungen in Endkundenhardware gibt, gegen die man in Echtzeit vergleichen könnte.
Was ist der Unterschied zwischen MLVC und DCVC?
DCVC ist die Linie neuronaler Codecs, die Microsoft Research seit 2021 veröffentlicht. MLVC ist die produktisierte Fassung, die rund sechs Punkte Kompressionseffizienz gegen die Fähigkeit eintauscht, zuverlässig auf NPUs verschiedener Hersteller zu decodieren.
Hilfe bei der Einordnung für Ihren Stack?
Codec-Entscheidungen sind teuer, wenn sie schiefgehen, und der größte Teil der Kosten fällt Jahre später bei Geräteunterstützung und Lizenzen an, nicht bei der Bitrate. Unsere Streaming- und Broadcast-Talente haben Codecs, Encoding-Ladders und Distributionsketten im großen Maßstab ausgeliefert, und Sie können eines davon direkt zu dem Problem briefen, das Sie tatsächlich haben.