El 24 de julio de 2026, Microsoft anunció en su blog Linux and Open Source que liberaba MLVC, el ML Video Codec, como código abierto. El código está en github.com/microsoft/mlvc bajo licencia MIT, con los pesos entrenados, los scripts de entrenamiento y las herramientas de conversión para distintas NPU.
El artículo científico que lo respalda, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, se publicó en arXiv un mes antes.
No es una demostración de investigación que se ejecutó una vez en una GPU de laboratorio. MLVC es la versión de producto de la línea DCVC que Microsoft Research publica desde 2021, y Microsoft afirma que ya se está desplegando en Microsoft Teams para llamadas entre pares, con telemetría en vivo, pruebas A/B y repliegue a códecs convencionales cuando el hardware o la red no acompañan.
El titular es lo bastante grande como para merecer una comprobación seria, y eso es lo que hace este artículo: las cifras, qué miden en realidad, qué hay de verdad en el repositorio y si algo de esto toca una cadena de streaming este año.
Si prefiere primero la versión corta, mantenemos una definición sencilla de qué es MLVC en nuestro glosario de streaming.
Las cifras del titular
La comparación publicada por Microsoft, a calidad subjetiva equivalente:
| Resolución | Bitrate ahorrado frente a H.264 | Bitrate ahorrado frente a H.265 |
|---|---|---|
| 360p | 87,8 % | 75,5 % |
| 540p | 82,7 % | 65,4 % |
La versión concreta se retiene mejor. Una llamada en 360p a 30 fotogramas por segundo que necesita 1 Mbps en H.264 necesita unos 122 kbps en MLVC. Aproximadamente una octava parte de los bits, en tiempo real, sobre la NPU de un portátil.
Ahora la letra pequeña, porque importa mucho.
Son puntuaciones humanas, no PSNR
Esos porcentajes son MOS, de una prueba subjetiva ITU-T P.910 en la que espectadores humanos puntuaron los clips. El material de origen es el Video Conferencing Dataset, que Microsoft también construyó y liberó. Se trata, por tanto, de personas ante una webcam, en 360p y 540p, juzgadas a ojo.
Si se mide el mismo códec con PSNR sobre el conjunto de pruebas más amplio del artículo, la ganancia en BD-rate se acerca más al 52 %. Sigue siendo una cifra muy alta. Pero no el 87,8 %.
La referencia es el H.265 más flojo que se puede comprar
El punto de comparación es H.265 por hardware sobre Intel Quick Sync, no un x265 bien afinado con presets lentos. Los codificadores por hardware limitados a la latencia de videoconferencia son el suelo de lo que puede hacer H.265, no el techo.
Tampoco hay comparación alguna con AV1 ni VVC en todo el artículo. Los autores explican por qué: descartan VTM y ECM porque no tienen implementaciones en hardware de consumo, así que no hay nada contra lo que medir en tiempo real. Es defendible como decisión de investigación, pero significa que nadie ha mostrado todavía MLVC frente a un codificador AV1 moderno.
El verdadero logro es el determinismo, no la compresión
Esta es la parte que quedó enterrada bajo las cifras de bitrate, y es la historia de ingeniería más interesante.
Los códecs neuronales llevan tiempo superando a los convencionales en eficiencia de codificación. No se podían desplegar, porque no se podían descodificar de forma fiable en una máquina distinta de la que había codificado.
La codificación entrópica exige que el codificador y el descodificador calculen probabilidades idénticas. Ejecute la misma red en un Apple Neural Engine y en un Qualcomm Hexagon y no obtendrá resultados en coma flotante idénticos, porque los compiladores eligen núcleos distintos, fusionan operadores de otra forma y redondean de otra manera. El flujo se descodifica entonces como basura.
El artículo pone número a esto. DCVC-RT, sin restricciones, obtiene alrededor de un 69,6 % de mejora en BD-rate cuando codificador y descodificador están en la misma plataforma. Entre plataformas su BD-rate es infinito, que es la forma educada de decir que el vídeo no se descodifica en absoluto.
Cómo lo resolvieron
MLVC deja de pedir que ambos extremos coincidan por suerte. Transmite explícitamente los parámetros de escala del modelo entrópico a través del hyperprior, de modo que ambos lados leen los mismos valores del flujo en lugar de calcularlos cada uno por su cuenta.
Alrededor de eso, el equipo eliminó todo lo demás que diverge. Las funciones de activación exóticas desaparecen en favor de ReLU y LeakyReLU con gating ReGLU. La cuantización INT8 se descarta de plano, porque la convolución INT8 no es reproducible entre fabricantes y el silicio de Apple más antiguo la simula en FP16 de todos modos. Todo funciona en FP16.
Esa disciplina cuesta compresión real. Un DCVC-RT entrenado en perceptual obtiene un 81,9 % donde MLVC obtiene un 75,5 %. Microsoft cedió unos seis puntos de BD-rate para conseguir un códec que descodifica en hardware que no le pertenece.
Para cualquiera que haya puesto vídeo en producción, ese es evidentemente el intercambio correcto, y es la primera vez que un códec aprendido lo consigue.
Qué hay realmente en el repositorio
Merece la pena mirarlo directamente, porque el repositorio cuenta una historia algo distinta de la del anuncio.
El repositorio se creó el 28 de enero de 2026 y durante seis meses no contuvo más que una licencia, un esbozo de README y los archivos de gobernanza habituales de Microsoft. El código llegó el 22 de julio en un único commit titulado "Hello MLVC", subido por Tanel Pärnamaa, primer autor del artículo. En el momento de escribir esto acumula 8 commits, 189 estrellas, 10 forks y ninguna versión etiquetada.
Es decir, es un volcado de código, no un proyecto desarrollado a la vista. No es una crítica, solo la expectativa correcta. Las cuatro incidencias abiertas son actualizaciones de Dependabot para transformers, jupyterlab y cryptography. La única contribución externa fusionada hasta ahora es un parche de una línea que añade #include <cstdint> a EntropyCoder.h para que el codificador entrópico en C++ compile en GCC 13 y versiones recientes de Clang. Pequeño, pero buena señal: alguien ajeno a Microsoft intentó compilarlo en cuestión de días, y Microsoft integró el parche.
Qué se obtiene
- Cuatro puntos de control. El MLVC completo con 18,3 millones de parámetros y el MLVC-S más ligero con 5,4 millones, cada uno en variante optimizada para PSNR y optimizada para percepción. Las perceptuales están entrenadas con LPIPS y una máscara de segmentación facial, lo que revela exactamente para qué se construyeron.
- La cadena de entrenamiento completa, para los modelos de imagen y de vídeo, gobernada por configuraciones YAML. Microsoft también documentó cómo recopiló los datos de entrenamiento, algo que hacen pocas publicaciones.
- Herramientas de exportación que convierten un modelo a CoreML para Apple, ONNX para Intel y OpenVINO, y QNN para Qualcomm, con dimensiones de entrada fijas. Los entornos de ejecución admitidos son ONNX Runtime en CPU y GPU, ONNX Runtime QNN, OpenVINO y Windows ML.
- Un codificador entrópico rANS en C++ en
packages/msrtc_ranscon enlaces de Python, más herramientas de benchmark que calculan BD-rate, MS-SSIM, LPIPS, VIF y DeQA.
Lo que no se obtiene es una biblioteca de códec en C++ que se pueda enlazar en una aplicación. Microsoft dice que llegará en una entrega posterior. Hoy la superficie utilizable es Python, y hace falta Python 3.12 o 3.13 y uv para instalarlo.
Dónde caen realmente las tasas de fotogramas
La velocidad es la razón por la que esto resulta interesante, así que la escalera de resoluciones importa. Rendimiento de codificación según el artículo:
| Resolución | MLVC, Apple M3 Pro | MLVC, media de 3 fabricantes | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 fps | 103 fps | no publicado |
| 540p | 65,7 fps | 49 fps | no publicado |
| 720p | 33,8 fps | no publicado | 83,8 fps |
| 1080p | 15,6 fps | no publicado | 39,5 fps |
La descodificación va unos fotogramas por segundo más lenta que la codificación en toda la tabla. En Intel Lunar Lake la cifra de 1080p es de 10,5 fps, y los tres fabricantes probados son Apple M3 y M4, Intel Lunar Lake y Qualcomm Snapdragon X Elite.
El resumen honesto: 540p a 30 fps es lo que se puede prometer, en los tres fabricantes, usando menos de la mitad de la NPU. El 1080p en tiempo real solo existe en el modelo recortado, en Apple, en un solo sentido. El artículo señala además que codificar y descodificar a la vez en un mismo dispositivo a 1080p o más sigue siendo un problema, que es justo lo que necesita una llamada bidireccional.
La hoja de ruta de Microsoft va en esa línea: primero estabilizar el 540p y mejorar la resistencia a pérdidas, después 1080p y escenarios de streaming más amplios.
Por qué no puede meter esto en una escalera de streaming
La eficiencia de compresión nunca ha decidido el destino de un códec en streaming. Lo deciden los descodificadores.
Escribimos un artículo entero sobre cómo HEVC nunca llegó a ser el futuro que le prometieron, y el motivo fueron las licencias y el soporte de dispositivos, no las herramientas de codificación. AV1 solo empezó a contar para despliegues reales cuando los teléfonos incorporaron descodificadores por hardware.
El formato son los pesos
MLVC tiene una versión más dura de ese problema. No existe un estándar de flujo MLVC, porque los pesos entrenados son el formato. Un flujo solo lo puede descodificar un dispositivo que tenga exactamente el modelo que lo codificó y que lo ejecute lo bastante fielmente como para reproducir la aritmética.
Sin flujos de conformidad. Sin tipo MIME. Sin historia de empaquetado, sin historia de DRM, y sin nada en un televisor conectado, un descodificador o un navegador capaz de reproducirlo. Su CDN puede transportarlo, y al otro lado no habrá nada que pueda abrirlo.
El contenido no es su contenido
Las cifras impresionantes vienen de bustos parlantes estáticos en baja resolución, con un modelo entrenado sobre rostros mediante una máscara de región de interés. El deporte, el grano de película, los barridos rápidos y el movimiento intenso son precisamente donde los códecs convencionales justifican sus heurísticas, y el artículo no reclama nada de eso.
Incluso cuantifica una debilidad: el mecanismo de referencia a largo plazo cuesta unos 2 puntos porcentuales de BD-rate en los cambios de plano bruscos, mitigados con detección de corte en el despliegue. Y una película es sobre todo cambios de plano.
Y nadie ha medido el consumo
Es la limitación con la que cierra el propio artículo. El tiempo real está resuelto, dicen los autores, así que el consumo eléctrico es la siguiente frontera. Ejecutar una red neuronal en la NPU para cada fotograma de una película de dos horas en un dispositivo con batería es algo muy distinto de un descodificador de función fija optimizado durante una década.
Dónde sí tiene sentido hoy
En todos los sitios donde ambos extremos son ordenadores que usted controla, y donde la restricción es la red y no el silicio.
Eso es videoconferencia en primer lugar, de ahí que Teams sea el vehículo de lanzamiento. También son los enlaces de contribución sobre subidas malas, la producción remota, los drones, la robótica y la videovigilancia, o el cloud gaming y el renderizado remoto. Microsoft pide ayuda explícitamente en todos esos frentes en el anuncio, además de streaming y VOD, y también portes de plataforma que amplíen la cobertura de NPU.
Si está construyendo algo en tiempo real y entre pares sobre hardware moderno, esto merece una tarde de su tiempo ahora mismo. Si opera un servicio OTT, no.
La parte que debería preocupar de verdad a la gente de códecs
No el 75 %. La pendiente.
Microsoft afirma que la eficiencia de codificación de MLVC mejora con la capacidad del modelo y el cómputo de entrenamiento, igual que ha ocurrido con todos los demás sistemas de aprendizaje automático en los últimos años.
Los códecs convencionales mejoran entre un 30 y un 50 % por generación, y una generación exige casi una década de normalización, seguida de años esperando al hardware, seguidos de una discusión sobre patentes. Si un códec aprendido sigue mejorando cada vez que alguien le dedica más cómputo, y funciona sobre NPU que ya vienen en todo, la forma de esa competencia cambia.
Tiene licencia MIT, lo que elimina discretamente el otro factor que mató a HEVC. Y se reduce a un problema de ingeniería normal: publica una versión de modelo, la negocia como se negocia un códec, y repliega cuando el otro extremo no puede ejecutarla.
Nada de esto va a ocurrir este año. La distancia entre "funciona a 540p en mi M3" y "se reproduce en un televisor de hace cinco años en un salón" es la misma que a cada códec le ha llevado quince años recorrer. Pero hacía tiempo que la compresión no se ponía lo bastante interesante como para leerse un artículo científico, y este merece la hora.
Qué hacer al respecto
Nada cambia en su escalera de codificación. Siga sirviendo H.264 por alcance, HEVC y AV1 donde los dispositivos lo permitan, y vuelva a mirar esto cuando ocurran tres cosas:
- 1080p en tiempo real con el modelo completo, no solo MLVC-S en Apple.
- Una biblioteca en C++ que se pueda enlazar de verdad en un producto.
- Algún descodificador fuera de los propios productos de Microsoft.
Clone el repositorio si tiene curiosidad, porque la cadena de entrenamiento y el análisis multiplataforma son instructivos tanto si algún día publica un códec neuronal como si no. El apéndice sobre por qué la cuantización INT8 diverge entre fabricantes es una explicación compacta de un problema que normalmente ocupa mucho más.
Preguntas frecuentes
¿MLVC es gratuito?
Sí. Microsoft lo publicó bajo licencia MIT, que cubre el código fuente del modelo, los pesos entrenados y los scripts de entrenamiento. No lleva asociado ningún consorcio de patentes, una diferencia importante respecto a HEVC.
¿Puedo transmitir MLVC a un televisor conectado o a un navegador?
No. La descodificación exige un dispositivo capaz de ejecutar la red neuronal, y exactamente el modelo que codificó el flujo. Hoy ningún televisor, descodificador, teléfono o navegador dispone de un descodificador MLVC, y no existe un estándar de flujo que puedan implementar.
¿Cuánto ancho de banda ahorra MLVC en realidad?
Microsoft declara un 87,8 % menos de bitrate que H.264 y un 75,5 % menos que H.265 por hardware en 360p, según el juicio de espectadores humanos conforme a ITU-T P.910. Medido con PSNR sobre un conjunto de pruebas más amplio, el ahorro se acerca más al 52 %. Ambas cifras se comparan con codificadores por hardware sobre contenido de videoconferencia.
¿Qué hardware necesita MLVC?
Una NPU. Microsoft probó Apple Neural Engine en M3 y M4, Intel Lunar Lake y Qualcomm Snapdragon X Elite, y declara 540p a 30 fps en tiempo real en las tres, usando menos de la mitad de la capacidad de la NPU.
¿MLVC es mejor que AV1?
Nadie ha publicado esa comparación. El artículo solo mide frente a H.264 y H.265, y omite AV1, VVC y ECM porque no tienen implementaciones en hardware de consumo con las que comparar en tiempo real.
¿Qué diferencia hay entre MLVC y DCVC?
DCVC es la línea de códecs neuronales que Microsoft Research publica desde 2021. MLVC es la versión de producto, que cambia unos seis puntos de eficiencia de compresión por la capacidad de descodificar de forma fiable en NPU de distintos fabricantes.
¿Necesita ayuda para decidir qué significa esto para su plataforma?
Las decisiones sobre códecs salen caras cuando se tuercen, y la mayor parte del coste aparece años después en el soporte de dispositivos y las licencias, no en el bitrate. Nuestros talentos de streaming y broadcast han desplegado códecs, escaleras de codificación y cadenas de distribución a gran escala, y puede plantearle a uno directamente el problema que tiene de verdad.