A 24 de julho de 2026, a Microsoft anunciou no seu blogue Linux and Open Source que estava a abrir o código do MLVC, o ML Video Codec. O código está em github.com/microsoft/mlvc sob licença MIT, com os pesos treinados, os scripts de treino e as ferramentas de conversão para diferentes NPU.
O artigo científico que o sustenta, MLVC: Multi-platform Learned Video Codec for Real-World Deployment, saiu no arXiv um mês antes.
Não é uma demonstração de investigação que correu uma vez numa GPU de laboratório. O MLVC é a versão de produto da linha DCVC que a Microsoft Research publica desde 2021, e a Microsoft afirma que já está a ser implementado no Microsoft Teams para chamadas ponto a ponto, com telemetria em direto, testes A/B e recurso a codecs convencionais quando o hardware ou a rede não acompanham.
A afirmação é suficientemente grande para merecer uma verificação a sério, e é isso que este artigo faz: os números, o que medem realmente, o que está de facto no repositório e se algo disto toca uma cadeia de streaming este ano.
Se preferir primeiro a versão curta, mantemos uma definição simples do que é o MLVC no nosso glossário de streaming.
Os números do anúncio
A comparação publicada pela Microsoft, com qualidade subjetiva equivalente:
| Resolução | Bitrate poupado face ao H.264 | Bitrate poupado face ao H.265 |
|---|---|---|
| 360p | 87,8% | 75,5% |
| 540p | 82,7% | 65,4% |
A versão concreta fixa-se melhor. Uma chamada em 360p a 30 imagens por segundo que precisa de 1 Mbps em H.264 precisa de cerca de 122 kbps em MLVC. Aproximadamente um oitavo dos bits, em tempo real, na NPU de um portátil.
Agora as letras miudinhas, porque contam bastante.
São notas humanas, não PSNR
Essas percentagens são pontuações MOS, de um teste subjetivo ITU-T P.910 em que espectadores humanos avaliaram os clipes. O material de origem é o Video Conferencing Dataset, que a Microsoft também construiu e abriu. Trata-se, portanto, de pessoas diante de uma webcam, em 360p e 540p, julgadas a olho.
Se medir o mesmo codec com PSNR sobre o conjunto de teste mais amplo do artigo, o ganho de BD-rate fica mais perto dos 52%. Continua a ser um número muito alto. Mas não 87,8%.
A referência é o H.265 mais fraco que se pode comprar
O termo de comparação é H.265 em hardware sobre Intel Quick Sync, não um x265 bem afinado com presets lentos. Os codificadores por hardware limitados à latência de videoconferência são o chão do que o H.265 consegue fazer, não o teto.
Além disso, em todo o artigo não há qualquer comparação com AV1 ou VVC. Os autores explicam porquê: excluem VTM e ECM por não terem implementações em hardware de consumo, logo não há nada com que medir em tempo real. Defensável como decisão de investigação, mas significa que ninguém mostrou ainda o MLVC frente a um codificador AV1 moderno.
A verdadeira proeza é o determinismo, não a compressão
Esta é a parte que ficou enterrada sob os números de bitrate, e é a história de engenharia mais interessante.
Os codecs neurais batem os convencionais em eficiência de codificação há já algum tempo. Não eram implementáveis, porque não podiam ser descodificados de forma fiável numa máquina diferente daquela que codificou.
A codificação entrópica exige que o codificador e o descodificador calculem probabilidades idênticas. Execute a mesma rede num Apple Neural Engine e num Qualcomm Hexagon e não obterá resultados em vírgula flutuante idênticos, porque os compiladores escolhem núcleos diferentes, fundem operadores de outra forma e arredondam de outra maneira. O fluxo descodifica então para lixo.
O artigo põe um número nisto. O DCVC-RT, sem restrições, obtém cerca de 69,6% de melhoria de BD-rate quando o codificador e o descodificador estão na mesma plataforma. Entre plataformas, o seu BD-rate é infinito, que é a forma educada de dizer que o vídeo não descodifica de todo.
Como resolveram o problema
O MLVC deixa de pedir que as duas pontas concordem por sorte. Transmite explicitamente os parâmetros de escala do modelo entrópico através do hyperprior, de modo que ambos os lados leem os mesmos valores do fluxo em vez de os calcularem cada um por si.
À volta disso, a equipa retirou tudo o resto que diverge. As funções de ativação exóticas desapareceram a favor de ReLU e LeakyReLU com gating ReGLU. A quantização INT8 é rejeitada de imediato, porque a convolução INT8 não é reproduzível entre fabricantes e o silício Apple mais antigo simula-a em FP16 de qualquer forma. Tudo corre em FP16.
Essa disciplina custa compressão a sério. Um DCVC-RT treinado em percetual obtém 81,9% onde o MLVC obtém 75,5%. A Microsoft cedeu cerca de seis pontos de BD-rate para ter um codec que descodifica em hardware que não lhe pertence.
Para quem já pôs vídeo em produção, é evidentemente a troca certa, e é a primeira vez que um codec aprendido a consegue.
O que está realmente no repositório
Vale a pena espreitar diretamente, porque o repositório conta uma história um pouco diferente do anúncio.
O repositório foi criado a 28 de janeiro de 2026 e durante seis meses não conteve mais do que uma licença, um esboço de README e os ficheiros de governação habituais da Microsoft. O código propriamente dito chegou a 22 de julho num único commit intitulado "Hello MLVC", submetido por Tanel Pärnamaa, primeiro autor do artigo. À data em que escrevemos, tem 8 commits, 189 estrelas, 10 forks e nenhuma versão etiquetada.
Portanto isto é um despejo de código, não um projeto desenvolvido à vista de todos. Não é uma crítica, apenas a expectativa correta. As quatro issues abertas são todas atualizações do Dependabot para transformers, jupyterlab e cryptography. A única contribuição externa integrada até agora é uma correção de uma linha que acrescenta #include <cstdint> ao EntropyCoder.h para que o codificador entrópico em C++ compile em GCC 13 e em versões recentes do Clang. Pequeno, mas bom sinal: alguém de fora da Microsoft tentou compilá-lo em poucos dias, e a Microsoft integrou o patch.
O que se obtém
- Quatro checkpoints. O MLVC completo com 18,3 milhões de parâmetros e o MLVC-S mais leve com 5,4 milhões, cada um em variante otimizada para PSNR e otimizada para perceção. As percetuais são treinadas com LPIPS e uma máscara de segmentação facial, o que diz exatamente para que foram construídas.
- Toda a cadeia de treino, para os modelos de imagem e de vídeo, comandada por configurações YAML. A Microsoft documentou também como recolheu os dados de treino, o que é mais do que a maioria das publicações faz.
- Ferramentas de exportação que convertem um modelo para CoreML na Apple, ONNX para Intel e OpenVINO, e QNN para Qualcomm, com dimensões de entrada fixas. Os runtimes suportados são ONNX Runtime em CPU e GPU, ONNX Runtime QNN, OpenVINO e Windows ML.
- Um codificador entrópico rANS em C++ em
packages/msrtc_ranscom ligações Python, mais ferramentas de benchmark que calculam BD-rate, MS-SSIM, LPIPS, VIF e DeQA.
O que não se obtém é uma biblioteca de codec em C++ que se possa ligar a uma aplicação. A Microsoft diz que virá num lançamento posterior. Hoje a superfície utilizável é Python, e precisa de Python 3.12 ou 3.13 e de uv para instalar.
Onde as taxas de imagem realmente ficam
A velocidade é a razão pela qual isto é interessante, por isso a escada de resoluções conta. Débito de codificação segundo o artigo:
| Resolução | MLVC, Apple M3 Pro | MLVC, média de 3 fabricantes | MLVC-S, Apple M3 Pro |
|---|---|---|---|
| 360p | 129,5 fps | 103 fps | não publicado |
| 540p | 65,7 fps | 49 fps | não publicado |
| 720p | 33,8 fps | não publicado | 83,8 fps |
| 1080p | 15,6 fps | não publicado | 39,5 fps |
A descodificação corre alguns fotogramas por segundo mais devagar do que a codificação em toda a linha. No Intel Lunar Lake o valor a 1080p é de 10,5 fps, e os três fabricantes testados são Apple M3 e M4, Intel Lunar Lake e Qualcomm Snapdragon X Elite.
O resumo honesto: 540p a 30 fps é o que se pode prometer, nos três fabricantes, usando menos de metade da NPU. O 1080p em tempo real só existe no modelo reduzido, na Apple, num só sentido. O artigo nota ainda que codificar e descodificar em simultâneo num único dispositivo a 1080p ou acima continua a ser um problema, e é precisamente disso que uma chamada bidirecional precisa.
O roteiro da Microsoft segue essa lógica: primeiro estabilizar o 540p e melhorar a resistência a perdas, depois o 1080p e cenários de streaming mais amplos.
Porque não pode pôr isto numa escada de streaming
A eficiência de compressão nunca decidiu o destino de um codec no streaming. Decidem-no os descodificadores.
Escrevemos um artigo inteiro sobre como o HEVC nunca chegou a ser o futuro que lhe prometeram, e a razão foram as licenças e o suporte dos dispositivos, não as ferramentas de codificação. O AV1 só começou a contar para implementações reais quando os telemóveis passaram a trazer descodificadores por hardware.
O formato são os pesos
O MLVC tem uma versão mais dura desse problema. Não existe uma norma de fluxo MLVC, porque os pesos treinados são o formato. Um fluxo só é descodificável por um dispositivo que tenha exatamente o modelo que o codificou, e que o execute com fidelidade suficiente para reproduzir a aritmética.
Sem fluxos de conformidade. Sem tipo MIME. Sem história de empacotamento, sem história de DRM, e sem nada numa smart TV, numa set-top box ou num navegador capaz de o reproduzir. A sua CDN pode transportá-lo, e do outro lado nada o conseguirá abrir.
O conteúdo não é o seu conteúdo
Os números impressionantes vêm de bustos falantes estáticos em baixa resolução, com um modelo treinado em rostos através de uma máscara de região de interesse. Desporto, grão de película, panorâmicas rápidas e muito movimento são exatamente onde os codecs convencionais justificam as suas heurísticas, e o artigo não reivindica nada disso.
Chega a quantificar uma fraqueza: o mecanismo de referência de longo prazo custa cerca de 2 pontos percentuais de BD-rate nas mudanças de plano bruscas, atenuadas com deteção de cortes na implementação. E um filme é sobretudo mudanças de plano.
E ninguém mediu o consumo
É a limitação com que o próprio artigo termina. O tempo real está resolvido, dizem os autores, portanto o consumo de energia é a próxima fronteira. Pôr uma rede neural a correr na NPU para cada imagem de um filme de duas horas, num dispositivo a bateria, é muito diferente de um descodificador de função fixa otimizado ao longo de uma década.
Onde faz sentido hoje
Em todo o lado onde ambas as pontas são computadores que controla, e onde a restrição é a rede e não o silício.
Isso é videoconferência em primeiro lugar, daí o Teams ser o veículo de lançamento. São também as ligações de contribuição sobre uplinks maus, a produção remota, os drones, a robótica e a videovigilância, ou o cloud gaming e a renderização remota. No anúncio, a Microsoft pede ajuda explicitamente em todas essas frentes, além de streaming e VOD, e ainda ports de plataforma que alarguem a cobertura de NPU.
Se está a construir algo em tempo real e ponto a ponto sobre hardware moderno, isto merece uma tarde do seu tempo já. Se opera um serviço OTT, não.
A parte que devia mesmo preocupar quem trabalha em codecs
Não os 75%. O declive.
A Microsoft afirma que a eficiência de codificação do MLVC melhora com a capacidade do modelo e com a computação de treino, tal como aconteceu com todos os outros sistemas de aprendizagem automática nos últimos anos.
Os codecs convencionais melhoram cerca de 30 a 50% por geração, e uma geração exige quase uma década de normalização, seguida de anos à espera do hardware, seguidos de uma discussão sobre consórcios de patentes. Se um codec aprendido continuar a melhorar sempre que alguém lhe aponta mais computação, e correr em NPU que já vêm em tudo, a forma dessa concorrência muda.
Tem licença MIT, o que remove discretamente o outro fator que matou o HEVC. E reduz-se a um problema de engenharia normal: publica-se uma versão de modelo, negoceia-se como se negoceia um codec, e recua-se quando a outra ponta não a consegue executar.
Nada disto acontece este ano. A distância entre "corre a 540p no meu M3" e "reproduz numa televisão de há cinco anos numa sala de estar" é a mesma que cada codec levou quinze anos a percorrer. Mas já lá vai algum tempo desde que a compressão ficou suficientemente interessante para se ler um artigo científico, e este vale a hora.
O que fazer quanto a isto
Nada muda na sua escada de codificação. Continue a servir H.264 para alcance, HEVC e AV1 onde os dispositivos o permitem, e volte a olhar para isto quando três coisas acontecerem:
- 1080p em tempo real no modelo completo, não apenas MLVC-S na Apple.
- Uma biblioteca C++ que se possa mesmo ligar a um produto.
- Qualquer descodificador fora dos produtos da própria Microsoft.
Clone o repositório se tiver curiosidade, porque a cadeia de treino e a análise multiplataforma são instrutivas, quer venha a publicar um codec neural quer não. O apêndice sobre por que razão a quantização INT8 diverge entre fabricantes é uma explicação compacta de um problema que normalmente ocupa muito mais espaço.
Perguntas frequentes
O MLVC é gratuito?
Sim. A Microsoft publicou-o sob licença MIT, que cobre o código-fonte do modelo, os pesos treinados e os scripts de treino. Não tem nenhum consórcio de patentes associado, o que é uma diferença significativa face ao HEVC.
Posso transmitir MLVC para uma smart TV ou um navegador?
Não. A descodificação exige um dispositivo capaz de executar a rede neural, e exatamente o modelo que codificou o fluxo. Hoje nenhuma televisão, set-top box, telemóvel ou navegador tem um descodificador MLVC, e não existe uma norma de fluxo que possam implementar.
Quanta largura de banda poupa realmente o MLVC?
A Microsoft indica 87,8% menos bitrate do que o H.264 e 75,5% menos do que o H.265 em hardware a 360p, avaliado por espectadores humanos segundo a ITU-T P.910. Medida com PSNR num conjunto de teste mais amplo, a poupança fica mais perto dos 52%. Ambos os valores são face a codificadores por hardware em conteúdo de videoconferência.
Que hardware exige o MLVC?
Uma NPU. A Microsoft testou o Apple Neural Engine em M3 e M4, o Intel Lunar Lake e o Qualcomm Snapdragon X Elite, e indica 540p a 30 fps em tempo real nos três, usando menos de metade da capacidade da NPU.
O MLVC é melhor do que o AV1?
Ninguém publicou essa comparação. O artigo mede apenas contra H.264 e H.265, e omite AV1, VVC e ECM por não terem implementações em hardware de consumo com que comparar em tempo real.
Qual é a diferença entre MLVC e DCVC?
DCVC é a linha de codecs neurais publicada pela Microsoft Research desde 2021. O MLVC é a versão de produto, que troca cerca de seis pontos de eficiência de compressão pela capacidade de descodificar de forma fiável em NPU de fabricantes diferentes.
Precisa de ajuda para perceber o que isto significa para a sua plataforma?
As decisões sobre codecs saem caras quando correm mal, e a maior parte do custo aparece anos depois no suporte de dispositivos e nas licenças, não no bitrate. Os nossos talentos de streaming e broadcast já colocaram em produção codecs, escadas de codificação e cadeias de distribuição em grande escala, e pode expor a um deles diretamente o problema que tem de facto.