Cambiador de Velocidad de GIF
SOLO CAMBIAN LOS BYTES DE RETARDO, NI UN PÍXEL
Suelta aquí un GIF animado
o haz clic para elegirlo — se lee en tu navegador, nunca se envía
Cada fotograma de un GIF lleva su propio retardo, guardado en su Graphic Control Extension:
0x21 0xF9 0x04 <packed> <delay lo> <delay hi> <transparent> 0x00
Esos dos bytes de retardo son un número de 16 bits en centésimas de segundo. Un número entero. Ese detalle decide todo lo demás: las únicas tasas de fotogramas que un GIF puede expresar son 100/n.
100, 50, 33,33, 25, 20, 16,67, 14,29, 12,5, 11,11, 10, 9,09, 8,33, 7,69, 7,14, 6,67 … y nada entre medias. 30 no está en esa lista. Ni 60, ni 24, ni 15.
Un codificador al que se le piden 30 fps calcula 100/30 = 3,33 centésimas, no puede guardarlo y redondea a 3. Tu GIF pasa a reproducirse a 33,33 fps. Esta es la tabla entera, y la última columna es la que importa:
| Pides | Retardo guardado | Se reproduce de verdad a | Error | Diez segundos pasan a |
|---|---|---|---|---|
| 60 fps | 2 cs | 50,00 fps | −16,67 % | 12,00 s |
| 50 fps | 2 cs | 50,00 fps | exacto | 10,00 s |
| 30 fps | 3 cs | 33,33 fps | +11,11 % | 9,00 s |
| 25 fps | 4 cs | 25,00 fps | exacto | 10,00 s |
| 24 fps | 4 cs | 25,00 fps | +4,17 % | 9,60 s |
| 20 fps | 5 cs | 20,00 fps | exacto | 10,00 s |
| 15 fps | 7 cs | 14,29 fps | −4,76 % | 10,50 s |
| 12 fps | 8 cs | 12,50 fps | +4,17 % | 9,60 s |
| 10 fps | 10 cs | 10,00 fps | exacto | 10,00 s |
Diez segundos de vídeo capturados a 30 fps son 300 fotogramas. Tres centésimas cada uno dan 900 centésimas — nueve segundos. El GIF termina un segundo entero antes que el clip del que salió, y si lo estás cuadrando con música o cortándolo contra un vídeo, de ahí viene el desfase. Solo 50, 25, 20, 10 y 5 vuelven exactas.
No redondean todos los fotogramas igual. Cogimos un GIF hecho con ffmpeg nominalmente a 12 fps y leímos sus retardos directamente de los bytes:
8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8
Veinticuatro fotogramas, 200 centésimas, exactamente 2,00 segundos — lo que da exactamente 12,0000 fps de media. La media es perfecta. Pero los fotogramas consecutivos están a 80 ms y luego 90 ms, una fluctuación del 12,5 % entre vecinos que no desaparece nunca, porque el codificador está pagando una tasa imposible alternando dos posibles.
Conviene decir la consecuencia sin rodeos: «la tasa de fotogramas de un GIF» suele ser una media que ningún fotograma tiene. Una herramienta que te enseña un número te está enseñando algo que no está en el archivo. Esta página te enseña todos los retardos, una barra por fotograma, para que veas si el tuyo es uniforme o alternado.
Aquí está lo que diferencia a esta herramienta de cualquier otro cambiador de velocidad de GIF. Cambiar la velocidad de un GIF es escribir esos dos bytes de retardo por fotograma. Nada más. La paleta, los datos de píxel comprimidos en LZW, las posiciones de los fotogramas, la transparencia — nada de eso entra.
La mayoría de las herramientas decodifican el GIF en fotogramas y lo recodifican, lo que recuantiza la paleta y cuesta una generación visible de color cada vez que lo tocas. Esta escribe solo los dos bytes de retardo de cada fotograma y devuelve el resto intacto.
Cuántos bytes difieren de verdad es aún menos, y la página los cuenta por ti en vez de prometerlo. Retemporizamos un GIF de 24 fotogramas de 54.596 bytes y cambiaron 24 bytes — uno por fotograma, el 0,044 % del archivo. Uno y no dos, porque el byte alto del retardo vale cero siempre que el retardo sea menor de 256 centésimas de segundo, así que pasar de 8 a 20 mueve un solo byte. Pide un retardo de 3,00 segundos y el segundo byte también se mueve, y la cuenta pasa a 48. El número de tu archivo está en la página, junto a su tamaño total.
Cabría esperar leer la temporización de un GIF cargándolo y mirándolo. No se puede. Dibujar un GIF animado en un canvas devuelve un fotograma estático — probamos seis archivos con retardos de 1 a 10 centésimas, muestreando cada 4 ms durante cuatro segundos cada uno, y obtuvimos cero avances de fotograma en los seis. El decodificador de imágenes del navegador anima el GIF en pantalla pero no le pasa el fotograma actual a tu código.
Así que una herramienta que quiera decirte la verdad sobre un GIF tiene que leer el archivo ella misma, que es lo que hace esta, en tu navegador, sin subir nada.
Hay una cosa que deliberadamente no afirmamos. Los navegadores también imponen su propio retardo mínimo, y los valores muy pequeños se tratan como algo mayor — pero no pudimos medirlo aquí, por el motivo de arriba, así que en esta página no aparece ninguna cifra al respecto. Si necesitas temporización exacta, la respuesta no es un GIF: conviértelo a MP4, donde la base de tiempo es la que tú quieras.
No. El archivo lo lee tu navegador, se analiza en la propia página, y la copia retemporizada se construye en memoria y se te devuelve como descarga. Nunca llega a un servidor, que es también por qué sigue funcionando con la pestaña sin conexión una vez cargada la página.
No puede. Solo se escriben los dos bytes de retardo de cada fotograma; la paleta y los datos de píxel comprimidos pasan intactos. La página informa de cuántos bytes difieren entre el archivo que le diste y el que te devuelve — en nuestro GIF de prueba de 24 fotogramas fueron 24 de 54.596, y si estuviera recodificando sería casi el archivo entero.
Porque el formato guarda el retardo como un número entero de centésimas de segundo, y 100/30 es 3,33. Ese retardo no existe. Tres centésimas dan 33,33 fps y cuatro dan 25. Si necesitas 30, necesitas un formato con una base de tiempo más fina — MP4 o WebM.
Casi seguro que no. Los codificadores alternan entre dos retardos para que una media imposible salga bien — 8, 9, 8, 8, 9 da exactamente 12 fps de media. También es normal que un GIF hecho a mano mantenga un fotograma a propósito. La tira de barras de esta página enseña todos los retardos para que sepas cuál es tu caso.
Significa que el archivo no especifica ninguno, y cada visor decide por su cuenta. Es el único caso en el que de verdad no puedes predecir la reproducción, y merece la pena poner un valor real en vez de dejarlo así. Elige «retardo exacto por fotograma» y dale uno.
Sí — el multiplicador de velocidad va de 0,25× a 4×, y divide el retardo existente de cada fotograma en lugar de sustituirlo, así que un GIF alternado a propósito conserva su ritmo relativo. Fijar una tasa de fotogramas objetivo, en cambio, deja todos los fotogramas uniformes.
No. El archivo retemporizado tiene exactamente la misma longitud que el original, byte a byte, porque se sobrescriben dos bytes en lugar de insertarlos. Si necesitas un GIF más pequeño, la palanca es el número de fotogramas o la paleta, no la temporización.
Sí. El trabajo es proporcional al número de fotogramas, no al de píxeles, porque los datos de píxel no se decodifican nunca. Un GIF con cientos de fotogramas se retemporiza tan rápido como uno con diez.