Convertir MP4 a AVIF

Esta pareja tiene una elegancia que las otras extracciones de fotograma no tienen. Un MP4 suele guardar H.264 o HEVC; un AVIF es un fotograma fijo de AV1, la siguiente generación de esa misma familia de códecs de vídeo. La imagen pasa de un miembro de la familia a otro.

Por eso el resultado sale tan compacto. Todo lo que AV1 aprendió sobre describir un solo fotograma de forma eficiente se aplica igual de bien a un fotograma que vino de un vídeo, y la salida suele pesar una fracción de lo que pesaría la misma imagen como JPG.

En contenido fotográfico, AVIF suele quedar entre un veinte y un treinta por ciento por debajo de un WebP equivalente, y bastante por debajo de un JPG. También maneja mejor lo que abunda en un fotograma de vídeo —escenas oscuras, fondos de estudio, cielos, degradados suaves—, con mucho menos efecto de bandas, gracias a una cuantización más fina incluso a los mismos ocho bits por canal con los que trabaja esta conversión.

Para una imagen de portada de un vídeo, este es el mejor caso posible. Esa imagen se carga antes de que nada empiece a reproducirse, en cada visita, y suele ser el recurso más pesado de toda la página que lleva el vídeo. Quitarle un tercio del peso vale más que el mismo ahorro en cualquier otra parte de esa misma página.

AVIF busca mucho más a fondo que WebP o JPEG, y eso se paga en tiempo — varios segundos para un solo fotograma en alta resolución es lo normal, incluso en un equipo rápido.

Pagado una sola vez, en el momento de preparar la web, ese coste no importa y cada visitante sale ganando. Pagado bajo demanda, por un servidor que genera miniaturas cada vez que alguien sube un vídeo, se convierte en una cuestión de capacidad con una factura detrás. Esa diferencia es la respuesta honesta a si AVIF encaja en un proceso concreto, y explica por qué tantos servicios siguen generando WebP.

Un fotograma sacado de una grabación de pantalla, una diapositiva, una cartela de título o cualquier cosa hecha sobre todo de color plano y bordes duros. Ese tipo de material ya se comprime muy bien de por sí, y AVIF a menudo produce un archivo más pesado que WebP con él — justo el resultado contrario al esperado, y algo que conviene medir en vez de dar por hecho.

Y fuera de un navegador. Visores de imágenes, galerías de móviles algo antiguas, aplicaciones de mensajería, clientes de correo y bastantes formularios de subida todavía se niegan a abrirlo. Un AVIF es un archivo que se sirve, no un archivo que se envía: para un fotograma destinado a una persona, mejor un JPG.

Ningún codificador devuelve el detalle que el vídeo nunca llegó a guardar. Un fotograma sacado en pleno movimiento arrastra el desenfoque y los bloques que dejó el códec, y codificarlo de maravilla conserva esos defectos de maravilla.

Así que el instante en segundos sigue siendo la primera palanca: un momento en el que el motivo está quieto, o el primer fotograma tras un corte, donde el codificador suele colocar un cuadro con todo el detalle. Acierta con el instante y deja que AVIF lo haga pequeño después. Al revés se obtiene una copia muy eficiente de una imagen mediocre.

Todo lo anterior asume que la imagen se va a servir desde una web, que es donde AVIF hace su trabajo. Si el fotograma va a acabar en un documento, en una presentación o enviado por correo a alguien fuera del navegador, esa ventaja de tamaño deja de importar y el problema pasa a ser la compatibilidad: procesadores de texto, visores de PDF y la mayoría de software de oficina todavía no abren AVIF.

La distinción es sencilla de aplicar en la práctica: si el archivo se va a incrustar en HTML y el navegador lo va a decodificar, AVIF es la opción correcta; si alguien va a hacer doble clic sobre él fuera de un navegador, un JPG evita cualquier sorpresa, aunque pese más.

La forma que hace que esto merezca la pena es un elemento picture con una fuente AVIF primero, una WebP después y un JPG de respaldo al final — cada navegador toma la mejor que entiende, sin que nadie tenga que detectar nada.

Para una imagen de portada de un vídeo en concreto, ese atributo solo acepta una imagen, así que lo habitual es dejar que el propio pipeline de imágenes o la CDN sirvan el formato que el navegador anuncia, o usar WebP ahí y reservar AVIF para la cuadrícula de miniaturas alrededor. Cualquiera de las dos opciones es razonable; la única que conviene evitar es servir solo AVIF sin ningún respaldo, porque conservar uno no cuesta nada.

Las dos mitades ocurren en la pestaña del navegador, sobre tu propio procesador: el vídeo se decodifica y el fotograma se codifica, sin que nada salga de tu equipo. Un vídeo grande se lee del disco en vez de transferirse por la red, lo cual en cualquier conversor alojado en la nube es más lento que el propio trabajo.

La segunda mitad importa aquí más que en otras páginas. Codificar AVIF cuesta de verdad, y hacerlo en local significa que ese coste lo paga tu propio equipo durante unos segundos, en vez de una cola, una cuota o una suscripción en otro sitio.

Las dos situaciones piden decisiones distintas. Una única imagen de portada, generada una vez y servida a todos los visitantes, absorbe sin problema el coste de una codificación lenta: se paga una sola vez y beneficia a cada visita siguiente. Un lote de cuarenta miniaturas para una galería de vídeos es otra cosa, porque ese coste se multiplica por cada archivo — si el proceso genera decenas de ellas cada vez que se sube un vídeo, WebP sigue siendo la elección razonable para ese caudal, con AVIF reservado a las imágenes que carga todo el mundo en cada visita.

Aquí ambos casos corren sobre tu propio equipo y no hay cola de servidor de por medio, así que la única variable real es cuánto tiempo estás dispuesto a esperar; para un lote grande, conviene calcular con dos o tres archivos cuánto tarda cada fotograma y multiplicar por el total antes de lanzar la conversión completa. Esa combinación —AVIF donde el ahorro se multiplica por cada visitante, WebP donde se multiplica por cada subida— suele dar mejor resultado que elegir un único formato para todo el catálogo de imágenes del sitio.

El formato AVIF admite diez bits por canal y color de gama amplia, algo que WebP no soporta. Pero esta página no llega a aprovecharlo: el fotograma se lee con un lienzo de canvas corriente, que siempre entrega ocho bits por canal, sea cual sea el vídeo de origen. Esa conversión a ocho bits pasa antes de que el codificador AVIF vea un solo píxel, así que no hay diez bits que guardar en ningún caso.

La diferencia entre AVIF y WebP en este fotograma sigue siendo real —AVIF comprime mejor incluso a ocho bits y eso es lo que explica el ahorro de tamaño de más arriba—, pero no es una diferencia de profundidad de color. Si necesitas conservar de verdad el rango HDR de un vídeo, esta herramienta no es la que lo hace: hace falta un flujo de trabajo que mantenga los diez bits desde la decodificación hasta la codificación, y esta conversión no es ese flujo.

Antes de decidir que AVIF gana en todos los casos, convierte el mismo fotograma a WebP y compara los dos pesos con la calidad visual puesta al lado. En un fotograma fotográfico normal, AVIF suele ganar con claridad; en pantallazos, diapositivas o material con mucho texto pequeño, la diferencia puede desaparecer o invertirse.

Esa comprobación cuesta una conversión extra y evita construir una regla general —«usar siempre AVIF»— sobre un único ejemplo favorable. El fotograma concreto que estás optimizando es el único dato que importa aquí.

Si el AVIF pesa más de lo que anunciaba esta página, lo primero que hay que revisar es el propio contenido del fotograma: ruido de sensor en poca luz, una textura muy fina repetida por toda la imagen o una compresión de vídeo ya muy agresiva en el origen empujan al codificador a gastar más bits de los habituales, y ningún ajuste de este conversor lo compensa.

Lo segundo es comprobar que el instante elegido no cae justo en medio de un corte de plano o de una transición, porque esos fotogramas suelen mezclar dos imágenes distintas y son, en la práctica, más difíciles de comprimir que un fotograma limpio tomado un segundo antes o después.