Microsoft Mage-VL: un modelo de video 4B nativo de códec, lanzado sin anuncio

No hay ninguna publicación de blog de Microsoft sobre Mage-VL. No hay entrada en la sala de prensa de Azure, ni ficha en el catálogo de Foundry, ni hilo de lanzamiento, nada en los canales de producto donde Microsoft suele presentar un modelo. Lo que existe en su lugar es un repositorio de Hugging Face — microsoft/Mage-VL, seis commits, 10.8 GB de pesos, Apache-2.0 — una carpeta de GitHub con scripts de inferencia, una página de proyecto mantenida por algo que se hace llamar Microsoft Mage Team, y un informe de arXiv con 23 autores. Leídos en conjunto, esos artefactos describen un modelo de visión y lenguaje de 4B de escala cuya idea central es genuinamente inusual: en lugar de decodificar el vídeo en fotogramas espaciados uniformemente y pasar una cuadrícula densa de parches por un codificador preentrenado en la web, Mage-VL lee directamente el flujo de bits comprimido, usando un codificador creado desde cero llamado Mage-ViT para conservar solo los parches en los que el códec gastó bits. Microsoft informa que esto reduce los tokens visuales en más del 75% y logra una aceleración de hasta 3.5x en tiempo de reloj, a la vez que iguala a Qwen3-VL-4B en imágenes estáticas y supera al propio Phi-4-Reasoning-Vision de 15B de Microsoft en vídeo.

Esa última frase es la parte que conviene mantener a distancia. Cada cifra de rendimiento de este artículo se remonta al propio documento, la ficha del modelo o la página del proyecto de Microsoft. Diez días después de que aparecieran los pesos, ninguna entidad independiente ha reproducido nada de ello, ninguna clasificación de terceros incluye el modelo y —como afirma claramente la página de Hugging Face— «no está desplegado por ningún proveedor de inferencia», de modo que ni siquiera hay un endpoint alojado que alguien pudiera haber evaluado de manera informal. Lo que sigue separa lo que el repositorio demuestra de lo que Microsoft simplemente afirma, porque en un lanzamiento sin anuncio se trata de categorías muy diferentes.

Lo que realmente existe, a los diez días

La superficie verificable de esta versión es pequeña y vale la pena enumerarla con precisión.

• Pesos, con fecha del 26 de julio de 2026. Dos fragmentos safetensors de 4,97 GB y 4,52 GB, más un archivo independiente de 1,07 GB llamado streammind_gate.safetensors. El propio lector de Hugging Face reporta 5B parámetros en BF16 — 4B en el decodificador de lenguaje, el resto dividido entre el codificador visual y esa puerta.

• Un informe técnico, presentado el 27 de julio de 2026 (arXiv 2607.24904), una versión, 23 autores, titulado "Mage-VL: An Efficient Codec-Native Streaming Multimodal Foundation Model."

• Código ejecutable, no solo pesos.El repositorio incluye modeling_mage_vl.py, processing_mage_vl.py, dos procesadores de video —incluido un codec_video_processing_mage_vl.py dedicado— y streammind_gate.py; unos 175 KB de Python personalizado. El auto_map en config.json enruta seis clases de Transformers a esos archivos, por lo que el repositorio lleva la etiqueta custom_code.

• Dos licencias, no una. Mage-VL es Apache-2.0; el codificador Mage-ViT independiente se publica por separado bajo MIT.

• Una demo funcional que no tienes que instalar. Microsoft ejecuta microsoft/mage-vl-demo como un Space de Hugging Face en ZeroGPU, y dos Spaces de la comunidad ya usan el modelo.

• Impulso temprano de la comunidad, formándose más rápido que las propias comunicaciones del proveedor. 268 me gusta, 435,784 descargas registradas el último mes, nueve cuantizaciones de la comunidad y dos afinamientos en el árbol del modelo. Los contadores de descargas incluyen extracciones automatizadas y de espejos, así que trate el número bruto como una señal de atención más que de implementación.

• Un hermano. Mage-Flow, un modelo de texto a imagen y edición de instrucciones construido con el mismo presupuesto fijo de 4B, se lanzó cuatro días antes, el 22 de julio. El repositorio de GitHub presenta a Mage como «una familia de modelos multimodales ligeros y aptos para la investigación», que es lo más parecido a una declaración de posicionamiento que se haya publicado.

Frente a eso, la lista de cosas que no existen es igualmente informativa. No hay ninguna publicación de blog ni comunicado de prensa de Microsoft. No hay ningún listado en Azure AI Foundry, lo que significa que no hay ruta de soporte empresarial, ni SLA, ni punto final administrado. Ningún proveedor de inferencia lo ofrece. No hay soporte de vLLM ni SGLang: una solicitud de la comunidad para agregar Mage-VL a SGLang se presentó el 28 de julio como el issue #32646 y, al momento de escribir esto, sigue abierta sin una pull request vinculada ni respuesta del mantenedor. Y no hay ninguna evaluación independiente de ningún tipo: el modelo está ausente de las tablas de clasificación neutrales donde una afirmación como "supera a un modelo de 15B en video" normalmente se pondría a prueba.

La única idea: leer el códec, no los fotogramas

Casi todos los VLM con capacidad de video en producción hacen lo mismo. Decodifican el video en fotogramas RGB, los muestrean uniformemente — uno por segundo, o 32 a lo largo del clip, o lo que permita el presupuesto — y pasan cada fotograma muestreado por un transformer de visión como una cuadrícula densa de parches. Cada parche de cada fotograma muestreado se convierte en tokens. Una pared de fondo estática cuesta exactamente tantos tokens como la persona que camina frente a ella, y vuelve a costarlos en el siguiente fotograma, y en el siguiente.

Esa es una cantidad enorme de cómputo redundante, y los códecs de video modernos ya resolvieron el problema subyacente hace décadas. H.264 y HEVC no almacenan cada fotograma; almacenan fotogramas ancla (I) ocasionales en su totalidad y luego describen los fotogramas intermedios como vectores de movimiento más residuales: "este bloque se movió aquí, y esto es lo que cambió." Las partes interesantes de un video son, casi por definición, las partes en las que el codificador gastó bits.

Mage-ViT aprovecha eso directamente. Al operar con una granularidad de parches de 16x16, conserva todos los parches de los fotogramas de anclaje y, para los fotogramas predichos, retiene solo los parches marcados como salientes por los vectores de movimiento y la energía residual del propio códec — las regiones que contienen información real, movimiento o un cambio de escena — mientras descarta los de baja redundancia y los totalmente redundantes. Microsoft sitúa la reducción resultante en más del 75% de los tokens visuales, con el contexto espacio-temporal preservado porque los fotogramas de anclaje siguen conteniendo la escena completa. El diseño es independiente del códec: la ruta tradicional acepta H.264 o HEVC, y una ruta neuronal acepta DCVC-RT.

La elegancia radica en que la estimación de movimiento ya estaba hecha. Cada video comprimido en internet llega con un mapa de dónde está la acción, calculado por el codificador y pagado por quien lo subió. Un proceso convencional descarta ese mapa en el instante en que decodifica a RGB, para luego gastar tiempo de GPU redescubriendo la misma información. Mage-VL simplemente se niega a desecharlo. Ya sea que los resultados de referencia se sostengan o no, esa observación es la contribución duradera aquí — y es la razón por la que esta publicación merece la pena leerse incluso si nunca descargas los pesos.

Lo más limpio del experimento

Oculto en la configuración hay una decisión de diseño que hace que los resultados sean mucho más interpretables que un lanzamiento de modelo típico, y casi nadie que cubre esta publicación lo ha señalado: el modelo de lenguaje se mantiene fijo.

El decodificador de Mage-VL es Qwen3-4B-Instruct-2507, sin modificar. La línea base de comparación, Qwen3-VL-4B, utiliza el mismo backbone Qwen3 de 4B con un codificador visual convencional preentrenado en web. Por lo tanto, cuando Mage-VL mejora respecto a Qwen3-VL-4B, la diferencia se atribuye al codificador y a la tokenización nativa del códec, no a un modelo de lenguaje más grande o mejor entrenado. Eso es una ablación controlada presentada como una comparación de productos, y es la característica metodológica más sólida del lanzamiento.

También aplica en el otro sentido, y la honestidad exige decirlo. Una comparación con el mismo backbone es la prueba más justa de la idea del codificador y, a la vez, el encuadre que con más probabilidad la favorece: Microsoft eligió la línea base que aísla su propia contribución. Las comparaciones de Phi-4 no tienen esa propiedad: Phi-4-Reasoning-Vision-15B y Phi-4-MM-5.6B tienen distintos backbones, distintas recetas de entrenamiento y distinto post-entrenamiento. «Supera a nuestro modelo de 15B en video» es un resultado real, pero mucho más laxo, y además es una comparación contra el trabajo anterior de la propia Microsoft, que es el tipo más fácil de ganar.

La escala de entrenamiento es el otro punto donde el artículo hace una afirmación genuinamente sorprendente. Mage-ViT se preentrenó desde cero con aproximadamente 560M de imágenes sin etiquetar y 100M de fotogramas de video sin etiquetar — un corpus grande en términos absolutos, pero muy por debajo de los miles de millones de pares de imagen-texto curados que respaldan a los codificadores con los que compite. El primer hallazgo declarado del artículo es que un codificador VLM fuerte no requiere datos supervisados a escala web. Si eso se sostiene bajo un escrutinio independiente, importa considerablemente más que cualquier fila de puntos de referencia.

Los números, y de quién son los números.

Lo que sigue es información reportada por Microsoft en su totalidad, en el propio banco de pruebas de evaluación de Microsoft, contra líneas de base seleccionadas por Microsoft. Nada de esto ha sido reproducido por un tercero. Considérelo como una hipótesis con barras de error inusualmente específicas, no como un marcador.

• Video-MME — Mage-VL-4B 64.0 frente a Qwen3-VL-4B 59.7 frente a Phi-4-Reasoning-Vision-15B 55.3

• NExT-QA — 83.1 vs 79.8 vs 69.0

• LongVideoBench — 61.3 vs 57.7 vs 51.2

• VideoEval-Pro — 45.2 vs 20.7 para Phi-4

• Timelens-QVHighlight (grounding temporal) — 57.4 vs 34.9 vs 11.6

• Ref-DAVIS17 (seguimiento de referencias) — 25.83 vs 7.48 vs 2.15

• DocVQA-val — 95.14 vs 94.69 vs 92.79 (Phi-4-MM-5.6B)

• OCRBench — 81.80 vs 81.60 vs 81.70

• ChartQA — 84.88 vs 83.96 vs 83.40

• MMStar — 67.32 vs 62.04 vs 59.63

• RealWorldQA — 70.46 vs 70.85 vs 70.72, una de las filas en las que Mage-VL pierde

• MMBench-EN-dev — 84.02 vs 83.25, con Phi-4-Reasoning-Vision-15B superando a ambos con 84.19

• CV-Bench-3D / CV-Bench-2D — 94.75 vs 92.30, y 82.13 vs 81.00

• EmbSpatial — 82.67 vs 77.50

• OVO-Bench (streaming) — 64.00 en general, descrito como el estado del arte entre las arquitecturas de streaming; el subconjunto de percepción visual en tiempo real promedia 79.84% frente al 72.8% para Qwen3-VL-4B, a 1 fps

• Mage-ViT como codificador independiente — por encima del 86.3% en ImageNet con un presupuesto de 676 tokens, y por encima del 96.1% en Food-101

Tres lecturas de esa tabla valen más que la propia tabla.

En imágenes, "paridad" es la palabra honesta. DocVQA por 0,45, OCRBench por 0,20, ChartQA por 0,92, MMBench por 0,77 — estos están dentro del rango en el que una plantilla de prompt diferente o una semilla de decodificación podrían invertir el orden, y RealWorldQA en realidad favorece a Qwen3-VL-4B. Microsoft dice lo mismo, enmarcando el rendimiento en imágenes como paridad más que como una victoria, y ese enfoque es correcto. Si tu carga de trabajo es la respuesta a preguntas sobre documentos e imágenes, esta versión no te da ninguna razón para cambiar.

En el video y el anclaje temporal, las brechas son grandes y consistentes. Timelens-QVHighlight casi duplica la línea base; Video-MME, NExT-QA y LongVideoBench se mueven todos entre 3,6 y 4,3 puntos en la misma dirección con la red troncal fija. La consistencia entre puntos de referencia que enfatizan cosas diferentes es el patrón que cabría esperar si el cambio de codificador es real y no un artefacto de ajuste.

Dos filas no deben citarse sin contexto. Ref-DAVIS17 con 25.83 frente a 7.48 parece una demolición de 3.5x, y los deltas espaciales más destacados del artículo incluyen +11.0 en VSI-Bench y +53.1 en CrossPoint. Cuando una línea base obtiene una puntuación cercana al mínimo en una tarea, el delta mide principalmente qué modelo fue entrenado para entender el formato de la tarea, no qué modelo es más capaz. La misma precaución se aplica a los resultados de streaming en términos absolutos: en SoccerNet, las cifras reportadas de Mage-VL son 55.54 TimVal, 83.14 ROC-AUC y un F1 de 16.35. Un F1 de 16.35 es una cifra de vanguardia en una evaluación incipiente, no un problema resuelto. La percepción proactiva en streaming es incipiente, y la puntuación absoluta del líder así lo indica.

La compuerta: un modelo que decide cuándo hablar.

La segunda idea arquitectónica es la que tiene las implicaciones de producto más claras, y explica ese misterioso archivo de 1.07 GB.

Mage-VL divide el streaming en dos procesos, enmarcados en el artículo como System 1 y System 2. System 1 es una "compuerta de cognición" ligera que observa cada ventana deslizante de características del códec y estima la probabilidad de que algo digno de mencionar haya terminado de suceder. Por debajo de un umbral, permanece en silencio y la parte costosa del modelo nunca se ejecuta. Por encima de él, se invoca al decodificador completo para producir una respuesta. La configuración de demostración utiliza ventanas causales de 30 segundos a 1 fps, la CLI expone el umbral directamente como --gate_threshold, y el punto de entrada de streaming procesa el video segmento por segmento (inference_streaming.py --video_backend codec --segment_sec 8). Solo la compuerta se entrena en la etapa final, con 3.35M muestras de streaming.

Hay dos cosas que merece la pena señalar al respecto. Primero, la compuerta no es un pequeño cabezal de clasificación acoplado en la parte superior: 1.07 GB de pesos BF16 son aproximadamente quinientos millones de parámetros, un modelo real por derecho propio, distribuido como un checkpoint separado. Segundo, el nombre del archivo es streammind_gate.safetensors — el nombre sugiere que este componente desciende de trabajos anteriores de percepción en streaming, en lugar de haber sido inventado para este artículo, aunque el propio repositorio no detalla esa procedencia.

Por qué importa comercialmente: para video siempre activo, el costo dominante no es la latencia por llamada, sino la frecuencia de llamadas. Una transmisión de cámara funcionando 24/7 a través de un VLM convencional a 1 fps significa 86,400 pasadas hacia adelante al día, ocurra o no algo. Una compuerta que permanece en silencio durante el 99% del metraje donde no ocurre nada cambia la forma de esa factura, no solo su tamaño. Si la compuerta de Microsoft es lo suficientemente precisa como para confiarle esa decisión es exactamente lo que nadie fuera del laboratorio ha probado.

¿De verdad puedes ejecutarlo hoy?

Sí, si tienes una GPU y paciencia. La fricción es real y reside principalmente en el pipeline de video, más que en el modelo.

Memoria.Microsoft no publica un requisito de VRAM. Según el índice de pesos: 9,49 GB de shards más el gate de 1,07 GB suman unos 10,6 GB de parámetros BF16, por lo que una tarjeta de 16 GB es un mínimo realista para trabajo con imágenes y 24 GB o más es el objetivo sensato una vez que añades caché KV para vídeo largo o una ventana de streaming. Eso es aritmética a partir de los tamaños de archivo, no una especificación del proveedor — mide antes de aprovisionar.

El código personalizado es obligatorio. auto_map apunta cada punto de entrada de Transformers a los módulos propios del repositorio, por lo que se requiere trust_remote_code. Estás ejecutando el Python de Microsoft, no solo cargando tensores. Aún no existe una ruta de vLLM o SGLang, lo que significa que no hay atención paginada, ni batching continuo, ni stack de servicio de producción — una brecha significativa si esperabas poner esto detrás de un endpoint.

La ruta del códec requiere herramientas del sistema. FFmpeg y ffprobe deben estar en tu PATH. El backend de códec tradicional depende de un paquete codec-video-prep que proporciona un paso cv-preinfer; la ruta neuronal necesita DCVC-RT; el backend de fotogramas sin procesar necesita Decord. Los requisitos también incluyen flash-attn y mamba-ssm, que compilan extensiones CUDA: instala primero una compilación de PyTorch que coincida con tu kit de herramientas o reserva una tarde para la compilación.

Lo que la configuración te dice que la tarjeta no hace. Los embeddings de posición máximos son 262,144, por lo que el decodificador hereda el contexto largo de Qwen3-4B. El lado de visión funciona con entrada de 448 píxeles con parches de 16x16, un codificador de 24 capas con 1024 unidades ocultas, fusión espacial 2x2, un token por segundo de video y una ventana de cuatro fotogramas. El entrenamiento alcanzó 384 fotogramas de longitud temporal en la tercera etapa. Un límite de 262K no es lo mismo que 262K de comportamiento validado, y 384 fotogramas es la longitud que el modelo realmente fue entrenado para manejar.

Bordes sin pulir conocidos. Una discusión abierta en el repositorio, presentada el 4 de agosto y aún sin respuesta, reporta desalineación de tokens cuando se pasan imágenes y videos en la misma solicitud. El software de diez días se comporta como software de diez días. Si quieres probarlo sin nada de esto, el Space gestionado por Microsoft en ZeroGPU es la opción sin instalación.

La línea de licencia no es tan simple como "Apache-2.0"

La tarjeta del modelo indica Apache-2.0. El encoder Mage-ViT indica MIT. Ambas licencias son tan permisivas como los pesos abiertos pueden llegar a ser. Pero el repositorio de la familia afirma que «estos modelos se publican solo con fines de investigación», con énfasis en la revisión de IA responsable y la supervisión humana — y esa frase encaja mal con una concesión Apache-2.0, que no restringe el uso comercial. Añade las dependencias: DCVC-RT y las herramientas de preparación del códec tienen sus propios términos, independientes de los del modelo.

Para un proyecto de hobby, esto es ruido. Para cualquier cosa que se envíe a clientes, es el tipo de ambigüedad que debería ir a asesoría legal antes de pasar a producción, y la clase de pregunta que vale la pena plantear en el propio repositorio — donde, notablemente, actualmente no hay ningún representante de Microsoft respondiendo.

¿Deberías construir sobre esto?

La decisión se divide limpiamente en una línea: si tu problema es un flujo o una solicitud.

Si estás haciendo percepción siempre activa — una transmisión de cámara, una transmisión en vivo, el campo de visión de un robot, una reunión que dura una hora — Mage-VL apunta directamente a ti, y la economía del autoalojamiento juega a tu favor. El precio de API por token escala con los fotogramas, un modelo implacable para el video continuo; un modelo de 4B en tu propio hardware con una compuerta que permanece en silencio durante secuencias sin incidentes es una curva de costos fundamentalmente diferente. El inconveniente es que también te comprometes a ser la primera persona fuera de Microsoft en descubrir si el juicio de la compuerta es realmente bueno.

Si tu problema tiene forma de solicitud — un usuario sube un documento, un PDF, una captura de pantalla, un clip corto y espera una respuesta — el argumento es mucho más débil. En exactamente esas tareas, Mage-VL está a la par con un modelo que aún tendrías que alojar tú mismo, y los endpoints multimodales alojados están a una sola llamada de API, sin GPU, sin compilación de ffmpeg y sin trust_remote_code. En OrcaRouter, Gemini 3.6 Flash cuesta $1.50 por millón de tokens de entrada y $7.50 por millón de salida, que es el precio de lista del proveedor trasladado directamente — no aplicamos ningún margen, así que cuando un proveedor baja precios, el recorte se aplica en nuestro lado el mismo día en lugar de después de una revisión de precios. Una sola clave da acceso a más de 200 modelos con conmutación automática por error si un proveedor se degrada, que es la razón práctica para mantener un endpoint alojado como opción predeterminada y reservar el autoalojamiento para las cargas de trabajo que realmente lo necesitan.

Para ser explícitos, porque la distinción importa: no alojamos Mage-VL, y tampoco lo hace nadie más. La propia página del modelo de Hugging Face dice que ningún proveedor de inferencia lo ha desplegado. Hoy, ejecutarlo significa ejecutarlo tú mismo.

¿Qué cambiaría esta lectura?

Cuatro cosas, en orden aproximado de cuánto importarían.

Una evaluación independiente es la más importante. Cada número anterior es una afirmación, y la afirmación que más necesita ponerse a prueba no es una puntuación de referencia, sino la aceleración de 3.5x, que se midió contra el muestreo uniforme de fotogramas en NExT-QA sin detalles publicados de hardware, resolución o número de fotogramas. El preprocesamiento del códec mueve el trabajo real a la CPU y a ffmpeg; una victoria en tiempo de pared medida de extremo a extremo en el equipo de otra persona es la única versión de ese número que vale la pena tener en cuenta al planificar.

Segundo, soporte de servido. Una implementación combinada de vLLM o SGLang convertiría esto de un checkpoint de investigación en algo que puedes poner detrás de un balanceador de carga. El issue de SGLang está abierto y sin reclamar; ese es el hilo a seguir.

En tercer lugar, una inclusión en Azure AI Foundry, lo que indicaría que Microsoft pretende que esto sea un producto y no un artículo. Nada en la versión actual sugiere que eso sea inminente.

Cuarto, y lo más extraño de todo: si Microsoft dice algo alguna vez. Un informe técnico de 23 autores, una página de proyecto mantenida, un Space de demostración alojado y un modelo generativo hermano cuatro días antes no describen una fuga ni un accidente — describen una publicación de investigación deliberada que omitió por completo el megáfono de producto. La comunidad llenó el silencio de todos modos, con nueve cuantizaciones y dos afinamientos en diez días.

Para la mayoría de los equipos, la decisión correcta es leer el artículo, no descargar los pesos. La idea nativa del códec es la conclusión clave, y es transferible: si reutilizar los vectores de movimiento que el codificador ya calculó realmente logra una reducción del 75% en tokens con la misma precisión, esa técnica aparecerá en modelos con anuncios de lanzamiento, soporte de proveedores y benchmarks reproducidos. Si hoy trabajas con video continuo, el cálculo es diferente: clona el repositorio, ejecuta tus propios clips en ambos backends y mide la aceleración tú mismo, porque ahora mismo serías el primero.

Preguntas que realmente vale la pena hacer

¿Es Mage-VL simplemente Qwen3-VL con una etiqueta de Microsoft?

No, aunque la confusión es comprensible. El decodificador de lenguaje es Qwen3-4B-Instruct-2507, usado tal cual: Microsoft no entrenó un nuevo LLM. Todo lo demás es nuevo: Mage-ViT fue preentrenado desde cero, la tokenización nativa de códec no tiene equivalente en Qwen3-VL, y la puerta de streaming es un modelo adicional de quinientos millones de parámetros. Reutilizar un backbone abierto y cambiar el front-end visual es una estrategia de investigación legítima y cada vez más común, y aquí además es lo que hace interpretable la comparación directa. Si tienes requisitos de cumplimiento en cuanto a la procedencia del modelo, ten en cuenta que el linaje proviene de los pesos de Qwen3 de Alibaba y revisa ambas licencias.

¿Significa "3.5x más rápido" que es 3.5x más barato de servir?

No de manera fiable. La cifra es una aceleración de tiempo de reloj en NExT-QA frente al muestreo uniforme de fotogramas, y Microsoft la presenta como "hasta". Dos cosas la diluyen en la práctica. La inferencia nativa de códec necesita un paso de preparación — ffmpeg, ffprobe y el paso cv-preinfer, o una recodificación DCVC-RT para la ruta neuronal — que consume tiempo de CPU que una canalización de fotogramas ingenua no consume, y que no aparece en una medición del lado de la GPU. Y la ganancia proviene de la reducción de tokens, por lo que escala con lo redundante que sea tu metraje: una cámara de seguridad mayormente estática debería superar la cifra citada, mientras que el vídeo editado con cortes rápidos, donde casi cada parche cambia, debería ir peor. Mídelo en tus propios clips.

¿Necesito archivos de video especiales para usar la ruta del códec?

Mayormente no, y esa es la agradable sorpresa. Los archivos MP4 comunes ya son H.264 o HEVC, que es exactamente lo que consume el backend de códec tradicional: los vectores de movimiento que necesita ya están en el archivo que tienes. Lo único que necesitas añadir son las herramientas: FFmpeg y ffprobe en tu PATH, además del paquete de preparación del códec. El backend neuronal es la excepción; DCVC-RT espera video codificado con ese códec, por lo que tendrías que volver a codificar. Y el backend de fotogramas simples sigue disponible como alternativa que se comporta como cualquier otro VLM, lo cual también es la forma honesta de comparar A/B la afirmación del códec por ti mismo.

¿Puedo usarlo comercialmente?

La licencia dice {{1}}Apache-2.0{{/1}}, que permite uso comercial, modificación y redistribución. El repositorio también dice que los modelos están {{2}}"publicados solo con fines de investigación."{{/2}} Esas dos declaraciones apuntan en direcciones diferentes, y la brecha no ha sido aclarada por nadie en Microsoft — {{3}}lo cual{{/3}}, en un lanzamiento sin anuncio, sin listado de producto y sin presencia del proveedor en las discusiones del repositorio, no es sorprendente. Si el dinero depende de la respuesta, contrata a un abogado para que lea ambos documentos y las licencias de las dependencias, en lugar de confiar únicamente en la insignia de la licencia.