Convertir GIF a WebM

Es el argumento menos citado y el más sólido para hacer este cambio. Una animación en GIF se repite hasta que alguien cierra la pestaña: no hay botón de pausa, no hay forma de que el visitante la detenga y no hay ninguna señal del sistema que la frene. Para quien tiene migraña, trastorno vestibular, fotosensibilidad o simplemente dificultad para leer con algo moviéndose al lado, eso no es un adorno, es una barrera.

Un elemento de vídeo cambia esa situación por completo. Se le pueden dar controles, se le puede quitar el bucle, y la preferencia de reducción de movimiento que el visitante ha configurado en su sistema operativo puede consultarse desde la hoja de estilos para no reproducirlo automáticamente. Nada de eso lo permite un GIF, con ningún ajuste, en ningún navegador.

Leer un GIF fotograma a fotograma dentro de una pestaña exige un descodificador de imágenes animadas que no está en todas partes. Nuestro código lo comprueba lo primero y, si no lo encuentra, se detiene con una frase que dice qué falta y nombra los navegadores que sí lo tienen: Chrome, Edge y Opera lo llevan; Safari y Firefox todavía lo están incorporando.

Es un rechazo deliberado y no un fallo escondido. La alternativa habitual de otros sitios sería mandar el archivo a un servidor cuando el navegador no puede, y eso es justamente lo que aquí no se hace: no existe ninguna ruta que envíe tu vídeo a ningún sitio. Si te encuentras con ese mensaje, la solución es abrir la página en otro navegador, no buscar otro archivo.

La tabla de destinos del código declara para WebM el códec de vídeo VP9. No hay elección ni ajuste, y es coherente con la razón de ser del contenedor: WebM existe para que un navegador sepa de antemano que lo que le entregan está dentro del corto conjunto de códecs que sabe descodificar.

Lo que no lleva es sonido. La advertencia del registro para este par lo dice tal cual: el resultado no tiene audio porque un GIF no tiene ninguno que llevarse. Si la animación necesita acompañamiento, hay que añadirlo después con una herramienta de edición; aquí no hay pista de audio que rellenar ni ajuste que la cree.

Los tiempos de un GIF se guardan por fotograma y en centésimas de segundo, así que una animación puede correr a ritmos que ninguna cámara produjo nunca y puede además cambiar de ritmo a mitad: una espera larga en el primer fotograma y después una secuencia rápida. La conversión lleva la duración propia de cada fotograma al vídeo en vez de promediar todo a una tasa constante.

Hay un caso frecuente con una regla explícita: un retardo guardado como cero, que en la práctica significa «tan rápido como pueda la pantalla». Los navegadores llevan mucho tiempo tratándolo como cien milisegundos y esta conversión hace lo mismo. El resultado es que una animación ajustada a ojo en un editor de GIF se reproduce a su velocidad, que es justo lo que una tasa fija habría estropeado.

Los codificadores de vídeo que usa este sitio quieren dimensiones pares y un GIF no tiene ninguna obligación de tenerlas: 401 píxeles de ancho es perfectamente legal en GIF y el codificador lo rechaza sin más. Así que el ancho y el alto se redondean hacia arriba hasta el siguiente número par antes de dibujar el primer fotograma.

Redondear hacia arriba añade una columna en lugar de quitarla, que es la decisión correcta: recortar habría comido un píxel del borde de la animación. Si el vídeo se maqueta con un ancho fijo en la hoja de estilos, ese píxel no aparece nunca; si estás cuadrándolo con una imagen de fondo píxel a píxel, conviene saber que el número se ha movido.

Esta conversión ofrece exactamente un ajuste: baja, media o alta, con media por defecto. No hay control de tamaño, ni de fotogramas por segundo, ni de duración, ni de color de fondo. Es útil saberlo por adelantado para no buscar un ajuste que no existe.

Sobre lo que significan esas tres palabras no vamos a dar un número. Se entregan tal cual a la biblioteca que codifica, que las resuelve por códec, y la cifra que hay detrás no es nuestra, no la sujeta ninguna prueba de este proyecto y podría moverse en una actualización sin que la página lo notara. Tampoco vas a leer aquí cuánto encoge el archivo: nadie ha medido esa proporción en este proyecto y publicarla sería inventarse una cifra que depende sobre todo de la duración, del color y del movimiento del clip concreto.

Cada fotograma de un GIF se dibuja con una paleta de 256 colores como máximo. El degradado suave o la sombra difusa con que empezó la animación quedaron reducidos a eso cuando se escribió el GIF, muchas veces aplicando un tramado para disimular los escalones.

VP9 guarda lo que recibe y no impone paleta propia, así que la animación no empeora al convertirse. Tampoco puede mejorar, y el tramado tiene además un coste real: es ruido, y el ruido es precisamente lo que arruina la búsqueda de repetición en la que se apoya un códec de vídeo. Un GIF muy tramado da un WebM más pesado que uno de colores planos del mismo tamaño, y subir la banda de calidad gasta bytes en conservar el patrón del tramado en lugar de la imagen.

WebM es de los pocos contenedores de vídeo capaces de transportar un canal alfa, y por eso mucha gente lo elige cuando quiere una animación que flote sobre el fondo de la página. Esa capacidad del formato es real.

Lo que no vamos a afirmar es qué hace exactamente esta conversión con un GIF de fondo transparente, porque nuestro código no toma ninguna decisión al respecto y ninguna prueba de este proyecto lo comprueba. Lo que sí es seguro es que este par no ofrece control de color de fondo, así que no hay nada que puedas elegir. Si la transparencia es el objetivo de la animación, comprueba el resultado antes de publicarlo y considera WebP animado, que sí conserva el canal alfa.

Sustituir un elemento de imagen por uno de vídeo no es un cambio equivalente y es el paso donde se estropean más cosas. El vídeo necesita un ancho y un alto explícitos, o una regla de proporción, o la página se recoloca al cargar: eso convierte un problema de peso en un problema de estabilidad visual y deja el informe de rendimiento igual de descontento que antes.

La otra pieza que conviene añadir es un fotograma de portada. Sin él queda un rectángulo vacío hasta que se descodifican los primeros fotogramas, mientras que el GIF al menos mostraba algo. Exportar el primer fotograma como un WebP o un PNG pequeño lo resuelve, y de paso te deja la imagen que necesitas si más adelante decides no reproducir la animación automáticamente.

Un elemento de vídeo admite varias fuentes y el navegador se queda con la primera que entiende. Poner el WebM delante y un MP4 detrás cuesta una línea y elimina la duda sobre navegadores integrados dentro de aplicaciones, dispositivos antiguos y visores empotrados, que son los que suelen fallar sin dejar rastro en las estadísticas.

Si vas a servir un solo archivo, MP4 es el que nunca da sorpresas y este sitio también lo produce desde un GIF. La elección de WebM tiene sentido cuando controlas el marcado y puedes ofrecer las dos cosas; cuando el GIF se va por correo, se sube a un foro o se pega en una presentación, no hay mecanismo de reserva y el argumento se cae.

Los fotogramas los lee el descodificador de imágenes del propio navegador y el vídeo lo escribe su propio codificador, en la pestaña que tienes delante. Ningún módulo de esta página transmite el archivo, no hay cuenta, no hay cola y no hay cupo diario que gastar, porque el trabajo lo hace tu procesador y no una máquina que tengamos que pagar.

El tope son 100 MB por archivo y cien archivos por tanda; lo que exceda de cien se descarta de la lista sin avisar. Para una carpeta de animaciones de documentación eso suele bastar de sobra, pero conviene contar los resultados del comprimido contra los del directorio en lugar de darlo por hecho.