30 FPS No Existe en GIF

Pídele 30 fotogramas por segundo a cualquier codificador de GIF y te dirá que sí. Miente, y el motivo está a cuatro bytes de profundidad en el formato: el retardo de un fotograma de GIF es un número entero de centésimas de segundo, y 100/30 no es un número entero.

Cada fotograma de un GIF lleva su propio retardo, guardado en un bloque Graphic Control Extension que tiene esta pinta:

0x21 0xF9 0x04 <packed> <delay lo> <delay hi> <transparent> 0x00

Los dos bytes de retardo son un entero de 16 bits little-endian, y su unidad son centésimas de segundo. No milisegundos. No un número racional. Un recuento entero de centésimas, de 0 a 65.535.

Ese único dato fija todo el conjunto de tasas de fotogramas que un GIF puede expresar. Si el retardo tiene que ser un entero n, la tasa tiene que ser 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, 6,25, 5,88, 5,56, 5,26, 5,00 …

Treinta no está en esa lista. Ni 60, ni 24, ni 15 — tres de las cuatro tasas a las que se graba casi todo el vídeo.

Qué hace en realidad un codificador con tu 30

Calcula 100/30 = 3,33 centésimas, descubre que no puede guardarlo y redondea a 3. Tu GIF va ahora a 33,33 fps, un 11,11 % rápido. El error no es lo interesante; lo interesante es la duración:

Diez segundos de vídeo capturados a 30 fps son 300 fotogramas. A 3 centésimas cada uno, eso son 900 centésimas — nueve segundos. El GIF termina un segundo entero antes que el clip del que salió. Pide 60 y se alarga en el otro sentido: 600 fotogramas a 2 cs son 12,00 segundos.

De las tasas que la gente pide de verdad, solo 50, 25, 20, 10 y 5 vuelven exactas. Todo lo demás se desvía, y se desvía un porcentaje fijo que crece con la duración del clip. Monta un GIF contra música y ahí tienes la explicación entera de por qué el bucle se separa del ritmo.

Los codificadores lo disimulan alternando dos retardos

Aquí deja de ser aritmética y pasa a ser algo que puedes leer de un archivo de tu disco. Un codificador bien hecho no redondea todos los fotogramas igual — alterna, para que la media salga bien.

Cogimos un GIF producido por ffmpeg, nominalmente a 12 fps, y recorrimos sus bloques para leer el retardo de cada fotograma:

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 fotogramas por segundo de media. La media es perfecta — y ningún fotograma del archivo va a 12 fps. Los fotogramas consecutivos están a 80 ms y luego 90 ms, un salto del 12,5 % entre vecinos que no se resuelve nunca, porque el codificador está comprando una tasa imposible con dos posibles.

La consecuencia merece una sola frase: «la tasa de fotogramas de un GIF» suele ser una media que ningún fotograma tiene. Cualquier herramienta que informe de un número único para un GIF está informando de algo que no está en el archivo. Si quieres saber qué hace realmente tu GIF, tienes que mirar todos los retardos.

Cambiar la velocidad no debería tocar un píxel

Como la temporización vive entera en esos dos bytes por fotograma, retemporizar un GIF es una edición de bytes. La paleta, los datos de píxel comprimidos en LZW, las posiciones de los fotogramas, el índice de transparencia — nada de eso hace falta leerlo, y mucho menos reescribirlo.

La mayoría de cambiadores de velocidad de GIF lo hacen al revés: decodifican a fotogramas, recodifican, recuantizan la paleta. Eso cuesta una generación visible de color cada vez que tocas el archivo, y es por lo que un GIF que ha pasado por dos o tres herramientas se ve peor que el original sin que nadie sepa señalar dónde.

Medimos la edición de bytes sobre el archivo de 24 fotogramas de arriba, que son 54.596 bytes:

Un byte por fotograma, no dos, en todo salvo la última fila — porque el byte alto del retardo vale cero a ambos lados de la edición salvo que el retardo pase de 256 centésimas. Se escriben dos bytes por fotograma; normalmente solo uno de ellos difiere. En cualquier caso el archivo vuelve con la misma longitud y con los datos de píxel idénticos bit a bit, que es la propiedad que importa.

Por qué tu navegador no puede contarte nada de esto

La forma obvia de comprobar la temporización de un GIF es cargarlo y mirarlo. No funciona, y el fallo es absoluto, no aproximado.

Construimos seis copias del mismo GIF de 12 fotogramas — píxeles idénticos, solo reescritos los bytes de retardo — con retardos de 0, 1, 2, 3, 5 y 10 centésimas. Cada una se mostró en pantalla y se dibujó en un canvas cada 4 ms durante cuatro segundos, con un hash de los píxeles cada vez para contar cuántas veces cambiaba el fotograma.

Cero avances. En los seis archivos. Dibujar un GIF animado en un canvas devuelve un fotograma estático: el navegador anima la imagen en pantalla pero no le pasa el fotograma actual a tu código. No es un fallo que hayamos esquivado — es la razón por la que una herramienta que quiera decirte la verdad sobre un GIF tiene que analizar el archivo ella misma.

También significa que hay un número que no te vamos a dar. Los navegadores imponen su propio retardo mínimo, y los valores muy pequeños se tratan como algo mayor — pero no pudimos medirlo aquí, exactamente por el motivo de arriba, así que no aparece ninguna cifra al respecto en ninguna de nuestras páginas. Todo lo demás de esta página salió de un archivo real.

Qué hacer al respecto

Si puedes elegir la tasa, elige una que exista: 25, 20 o 10 fps son exactas, y 25 está lo bastante cerca de 24 como para que nadie vea la diferencia. Si necesitas 30 o 60 exactos, no necesitas un GIF — necesitas un contenedor con una base de tiempo más fina, que es la razón honesta para convertirlo a MP4. Un MP4 a 30 fps va a 30 fps, y normalmente será una fracción del tamaño.

Y si solo quieres ver qué hace tu propio GIF, el cambiador de velocidad de GIF dibuja el retardo de cada fotograma como una barra, te dice la tasa exacta que vas a obtener para la que pediste, e informa de cuántos bytes cambió para llegar ahí. Funciona en tu navegador; no se sube nada.

Preguntas frecuentes