Le 24 juillet 2026, Microsoft a annoncé sur son blog Linux and Open Source qu'il passait MLVC, le ML Video Codec, en open source. Le code est sur github.com/microsoft/mlvc sous licence MIT, avec les poids entraînés, les scripts d'entraînement et l'outillage de conversion pour cibler différents NPU.
L'article scientifique qui l'accompagne, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, est paru sur arXiv un mois plus tôt.
Ce n'est pas une démo de recherche lancée une fois sur un GPU de laboratoire. MLVC est la version produit de la lignée DCVC que Microsoft Research publie depuis 2021, et Microsoft indique qu'il est déjà en cours de déploiement dans Microsoft Teams pour les appels en pair à pair, avec télémétrie en direct, tests A/B et repli sur des codecs classiques quand le matériel ou le réseau ne suit pas.
L'annonce est assez spectaculaire pour mériter une vérification sérieuse, et c'est l'objet de cet article : les chiffres, ce qu'ils mesurent réellement, ce que contient vraiment le dépôt, et si tout cela touche une chaîne de streaming cette année.
Si vous voulez d'abord la version courte, nous gardons une définition simple de ce qu'est le MLVC dans notre glossaire du streaming.
Les chiffres annoncés
La comparaison publiée par Microsoft, à qualité subjective équivalente :
| Résolution | Débit économisé vs H.264 | Débit économisé vs H.265 |
|---|---|---|
| 360p | 87,8 % | 75,5 % |
| 540p | 82,7 % | 65,4 % |
La version concrète est plus facile à retenir. Un appel en 360p à 30 images par seconde qui demande 1 Mbps en H.264 demande environ 122 kbps en MLVC. Soit à peu près un huitième des bits, en temps réel, sur le NPU d'un ordinateur portable.
Passons maintenant aux petites lignes, parce qu'elles comptent beaucoup.
Ce sont des notes humaines, pas du PSNR
Ces pourcentages sont des scores MOS, issus d'un test subjectif ITU-T P.910 où des spectateurs humains ont noté les séquences. Le matériel source est le Video Conferencing Dataset, que Microsoft a également constitué et ouvert. Il s'agit donc de personnes filmées en webcam, en 360p et 540p, jugées à l'œil.
Mesurez le même codec en PSNR, sur le jeu de test plus large de l'article, et le gain BD-rate tombe plutôt autour de 52 %. Cela reste un très gros chiffre. Mais pas 87,8 %.
La référence est le H.265 le plus faible du marché
Le point de comparaison est un H.265 matériel sur Intel Quick Sync, pas un x265 bien réglé en preset lent. Les encodeurs matériels contraints à la latence de la visioconférence représentent le plancher de ce que sait faire le H.265, pas son plafond.
Il n'y a par ailleurs aucune comparaison avec AV1 ou VVC dans tout l'article. Les auteurs expliquent pourquoi : ils écartent VTM et ECM parce qu'ils n'ont pas d'implémentation matérielle grand public, donc rien à comparer en temps réel. C'est défendable comme choix de recherche, mais cela signifie que personne n'a encore montré MLVC face à un encodeur AV1 moderne.
La vraie prouesse, c'est le déterminisme, pas la compression
Voici la partie enterrée sous les chiffres de débit, et c'est l'histoire d'ingénierie la plus intéressante.
Les codecs neuronaux battent les codecs classiques en efficacité de codage depuis un moment déjà. Ils étaient indéployables, parce qu'ils ne pouvaient pas être décodés de façon fiable sur une machine différente de celle qui avait encodé.
Le codage entropique exige que l'encodeur et le décodeur calculent des probabilités identiques. Exécutez le même réseau sur un Apple Neural Engine et sur un Qualcomm Hexagon et vous n'obtenez pas des résultats flottants identiques, parce que les compilateurs choisissent des noyaux différents, fusionnent les opérateurs différemment et arrondissent différemment. Le flux se décode alors en bouillie.
L'article chiffre le problème. DCVC-RT, sans contrainte, obtient environ 69,6 % d'amélioration BD-rate quand l'encodeur et le décodeur sont sur la même plateforme. D'une plateforme à l'autre, son BD-rate est infini, ce qui est la façon polie de dire que la vidéo ne se décode pas du tout.
Comment ils ont corrigé cela
MLVC cesse de demander aux deux extrémités de se mettre d'accord par chance. Il transmet explicitement les paramètres d'échelle du modèle entropique dans l'hyperprior, si bien que les deux côtés lisent les mêmes valeurs dans le flux au lieu de les calculer chacun de leur côté.
Autour de cela, l'équipe a supprimé tout le reste de ce qui diverge. Les fonctions d'activation exotiques ont disparu au profit de ReLU et LeakyReLU avec un gating ReGLU. La quantification INT8 est rejetée d'emblée, parce que la convolution INT8 n'est pas reproductible d'un fondeur à l'autre et que les puces Apple plus anciennes la simulent de toute façon en FP16. Tout tourne en FP16.
Cette discipline coûte de la compression bien réelle. Un DCVC-RT entraîné en perceptuel obtient 81,9 % là où MLVC obtient 75,5 %. Microsoft a cédé environ six points de BD-rate pour obtenir un codec qui se décode sur du matériel qu'il ne possède pas.
Pour quiconque a déjà mis de la vidéo en production, c'est évidemment le bon arbitrage, et c'est la première fois qu'un codec appris y parvient.
Ce que contient vraiment le dépôt
Cela vaut la peine d'aller y regarder, parce que le dépôt raconte une histoire un peu différente de l'annonce.
Le dépôt a été créé le 28 janvier 2026 et n'a contenu pendant six mois qu'une licence, une ébauche de README et les fichiers de gouvernance habituels de Microsoft. Le code est arrivé le 22 juillet dans un unique commit intitulé « Hello MLVC », poussé par Tanel Pärnamaa, premier auteur de l'article. Au moment où nous écrivons, on compte 8 commits, 189 étoiles, 10 forks et aucune version taguée.
C'est donc un dépôt de code livré d'un bloc, pas un projet développé au grand jour. Ce n'est pas un reproche, juste la bonne attente à avoir. Les quatre tickets ouverts sont tous des montées de version Dependabot pour transformers, jupyterlab et cryptography. La seule contribution extérieure fusionnée à ce jour est un correctif d'une ligne ajoutant #include <cstdint> à EntropyCoder.h pour que le codeur entropique C++ compile sur GCC 13 et les Clang récents. Modeste, mais bon signe : quelqu'un d'extérieur à Microsoft a tenté de le compiler en quelques jours, et Microsoft a fusionné le correctif.
Ce que vous obtenez
- Quatre points de contrôle. Le MLVC complet à 18,3 millions de paramètres et le MLVC-S allégé à 5,4 millions, chacun en variante optimisée PSNR et optimisée perceptuelle. Les variantes perceptuelles sont entraînées avec LPIPS et un masque de segmentation de visage, ce qui vous dit exactement pour quoi elles ont été conçues.
- Toute la chaîne d'entraînement, pour les modèles image et vidéo, pilotée par des fichiers YAML. Microsoft a aussi documenté sa collecte de données d'entraînement, ce que peu de publications font.
- L'outillage d'export qui convertit un modèle en CoreML pour Apple, ONNX pour Intel et OpenVINO, et QNN pour Qualcomm, à dimensions d'entrée fixes. Les runtimes pris en charge sont ONNX Runtime sur CPU et GPU, ONNX Runtime QNN, OpenVINO et Windows ML.
- Un codeur entropique rANS en C++ dans
packages/msrtc_ransavec des bindings Python, plus l'outillage de benchmark qui calcule BD-rate, MS-SSIM, LPIPS, VIF et DeQA.
Ce que vous n'obtenez pas, c'est une bibliothèque codec C++ à lier dans une application. Microsoft annonce cela pour une prochaine version. Aujourd'hui la surface utilisable est en Python, et il vous faut Python 3.12 ou 3.13 et uv pour l'installer.
Où se situent réellement les débits d'images
La vitesse est ce qui rend l'ensemble intéressant, donc l'échelle de résolution compte. Débit d'encodage relevé dans l'article :
| Résolution | MLVC, Apple M3 Pro | MLVC, moyenne 3 fondeurs | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 ips | 103 ips | non publié |
| 540p | 65,7 ips | 49 ips | non publié |
| 720p | 33,8 ips | non publié | 83,8 ips |
| 1080p | 15,6 ips | non publié | 39,5 ips |
Le décodage tourne quelques images par seconde plus lentement que l'encodage sur toute la ligne. Sur Intel Lunar Lake, le chiffre en 1080p est de 10,5 ips, et les trois fondeurs testés sont Apple M3 et M4, Intel Lunar Lake et Qualcomm Snapdragon X Elite.
Le résumé honnête : le 540p à 30 ips est la promesse commercialisable, sur les trois fondeurs, à moins de la moitié du NPU. Le 1080p temps réel n'existe que sur le modèle allégé, sur Apple, dans un seul sens. L'article note aussi qu'encoder et décoder simultanément sur un même appareil en 1080p et au-delà reste un problème, ce qui est précisément ce qu'exige un appel bidirectionnel.
La feuille de route de Microsoft suit cette logique : stabiliser le 540p et améliorer la résistance aux pertes d'abord, puis le 1080p et des scénarios de streaming plus larges.
Pourquoi vous ne pouvez pas mettre cela dans une échelle de streaming
L'efficacité de compression n'a jamais décidé du sort d'un codec en streaming. Ce sont les décodeurs qui décident.
Nous avons consacré tout un article à la façon dont le HEVC n'est jamais devenu l'avenir qu'on lui promettait, et la raison tenait aux licences et au support des appareils, pas aux outils de codage. AV1 n'a commencé à compter pour de vrais déploiements que lorsque les téléphones ont embarqué des décodeurs matériels.
Le format, ce sont les poids
MLVC souffre d'une version plus dure de ce problème. Il n'existe pas de norme de flux MLVC, parce que les poids entraînés sont le format. Un flux n'est décodable que par un appareil détenant exactement le modèle qui l'a encodé, et l'exécutant d'assez près pour en reproduire l'arithmétique.
Pas de flux de conformité. Pas de type MIME. Pas d'histoire d'empaquetage, pas d'histoire de DRM, et rien dans un téléviseur connecté, un décodeur ou un navigateur qui sache le lire. Votre CDN peut le transporter, et à l'autre bout rien ne pourra l'ouvrir.
Le contenu n'est pas votre contenu
Les chiffres impressionnants viennent de bustes parlants statiques en basse résolution, avec un modèle entraîné sur des visages via un masque de région d'intérêt. Le sport, le grain argentique, les panoramiques rapides et les mouvements amples sont exactement là où les codecs classiques justifient leurs heuristiques, et l'article ne revendique rien de tout cela.
Il chiffre même une faiblesse : le mécanisme de référence à long terme coûte environ 2 points de BD-rate sur les changements de plan brutaux, atténués par une détection de coupe au déploiement. Or un film, c'est surtout des changements de plan.
Et personne n'a mesuré la consommation
C'est la limite que l'article retient pour finir. Le temps réel est réglé, disent les auteurs, donc la consommation électrique est la prochaine frontière. Faire tourner un réseau de neurones sur le NPU pour chaque image d'un film de deux heures sur un appareil sur batterie n'a rien à voir avec un décodeur à fonction figée optimisé depuis dix ans.
Où cela a du sens aujourd'hui
Partout où les deux extrémités sont des ordinateurs que vous contrôlez, et où la contrainte est le réseau plutôt que le silicium.
C'est d'abord la visioconférence, d'où le choix de Teams comme véhicule de lancement. Ce sont aussi les liens de contribution sur des liaisons montantes médiocres, la production distante, les drones, la robotique et la vidéosurveillance, ou encore le cloud gaming et le rendu déporté. Microsoft demande explicitement de l'aide sur tous ces terrains dans son annonce, en plus du streaming et de la VOD, ainsi que des portages pour élargir la couverture NPU.
Si vous construisez quelque chose de temps réel et de pair à pair sur du matériel récent, cela vaut un après-midi de votre temps dès maintenant. Si vous exploitez un service OTT, non.
Ce qui devrait vraiment inquiéter les gens du codec
Pas les 75 %. La pente.
Microsoft affirme que l'efficacité de codage de MLVC progresse avec la capacité du modèle et le calcul d'entraînement, comme tous les autres systèmes d'apprentissage automatique ces dernières années.
Les codecs classiques progressent d'environ 30 à 50 % par génération, et une génération demande près d'une décennie de normalisation, suivie d'années d'attente du matériel, suivies d'une querelle de pool de brevets. Si un codec appris continue de s'améliorer chaque fois qu'on lui consacre plus de calcul, et qu'il tourne sur des NPU déjà présents partout, la nature de cette concurrence change.
Il est sous licence MIT, ce qui écarte discrètement l'autre facteur qui a tué le HEVC. Et il se ramène à un problème d'ingénierie ordinaire : vous livrez une version de modèle, vous la négociez comme vous négociez un codec, vous repliez quand l'autre extrémité ne sait pas l'exécuter.
Rien de tout cela n'arrivera cette année. L'écart entre « tourne en 540p sur mon M3 » et « se lit sur un téléviseur de cinq ans dans un salon » est le même écart qu'il a fallu quinze ans à chaque codec pour franchir. Mais la dernière fois que la compression est devenue assez intéressante pour qu'on lise un article scientifique remonte à un moment, et celui-ci vaut bien une heure.
Que faire concrètement
Rien ne change dans votre échelle d'encodage. Continuez à livrer du H.264 pour la portée, du HEVC et de l'AV1 là où les appareils suivent, et revenez sur le sujet quand trois choses se produiront :
- Le 1080p temps réel sur le modèle complet, pas seulement MLVC-S sur Apple.
- Une bibliothèque C++ réellement intégrable dans un produit.
- Un décodeur en dehors des produits maison de Microsoft.
Clonez le dépôt si vous êtes curieux, parce que la chaîne d'entraînement et l'analyse multiplateforme sont instructives, que vous livriez un jour un codec neuronal ou non. L'annexe sur la divergence de la quantification INT8 d'un fondeur à l'autre est une explication compacte d'un problème qui prend d'ordinaire bien plus de place à décrire.
Questions fréquentes
MLVC est-il gratuit ?
Oui. Microsoft l'a publié sous licence MIT, qui couvre le code du modèle, les poids entraînés et les scripts d'entraînement. Aucun pool de brevets n'y est attaché, ce qui constitue une différence notable avec le HEVC.
Puis-je diffuser du MLVC vers un téléviseur connecté ou un navigateur ?
Non. Le décodage exige un appareil capable d'exécuter le réseau de neurones, et exactement le modèle qui a encodé le flux. Aucun téléviseur, décodeur, téléphone ou navigateur ne dispose aujourd'hui d'un décodeur MLVC, et il n'existe aucune norme de flux qu'ils pourraient implémenter.
Combien de bande passante MLVC économise-t-il réellement ?
Microsoft annonce 87,8 % de débit en moins que H.264 et 75,5 % de moins que le H.265 matériel en 360p, jugé par des spectateurs humains selon l'ITU-T P.910. Mesurée en PSNR sur un jeu de test plus large, l'économie approche plutôt 52 %. Les deux chiffres se comparent à des encodeurs matériels sur du contenu de visioconférence.
Quel matériel MLVC exige-t-il ?
Un NPU. Microsoft a testé l'Apple Neural Engine sur M3 et M4, Intel Lunar Lake et Qualcomm Snapdragon X Elite, et annonce du 540p à 30 images par seconde en temps réel sur les trois, à moins de la moitié de la capacité du NPU.
MLVC est-il meilleur qu'AV1 ?
Personne n'a publié cette comparaison. L'article ne teste que face à H.264 et H.265, et écarte AV1, VVC et ECM parce qu'ils n'ont pas d'implémentation matérielle grand public permettant une comparaison en temps réel.
Quelle différence entre MLVC et DCVC ?
DCVC est la lignée de codecs neuronaux publiée par Microsoft Research depuis 2021. MLVC en est la version produit, qui échange environ six points d'efficacité de compression contre la capacité à décoder de façon fiable sur des NPU de fondeurs différents.
Besoin d'aide pour évaluer ce que cela change chez vous ?
Les décisions de codec coûtent cher quand elles sont mauvaises, et l'essentiel du coût apparaît des années plus tard, dans le support des appareils et les licences, pas dans le débit. Nos talents du streaming et de la diffusion ont livré des codecs, des échelles d'encodage et des chaînes de distribution à grande échelle, et vous pouvez briefer l'un d'eux directement sur le problème que vous avez réellement.