30 i/s N’Existe Pas en GIF

Demandez 30 images par seconde à n’importe quel encodeur GIF et il dira oui. Il ment, et la raison se trouve à quatre octets de profondeur dans le format : le délai d’une image de GIF est un nombre entier de centièmes de seconde, et 100/30 n’est pas un nombre entier.

Chaque image d’un GIF porte son propre délai, stocké dans un bloc Graphic Control Extension qui ressemble à ceci :

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

Les deux octets de délai forment un entier 16 bits en little-endian, et son unité est le centième de seconde. Pas la milliseconde. Pas un nombre rationnel. Un compte entier de centièmes, de 0 à 65 535.

Ce seul fait fixe l’ensemble complet des cadences qu’un GIF peut exprimer. Si le délai doit être un entier n, la cadence doit être 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 …

Trente n’y figure pas. Ni 60, ni 24, ni 15 — trois des quatre cadences auxquelles la vidéo est tournée.

Ce qu’un encodeur fait vraiment de votre 30

Il calcule 100/30 = 3,33 centièmes, constate qu’il ne peut pas le stocker, et arrondit à 3. Votre GIF tourne désormais à 33,33 i/s, 11,11 % trop vite. L’erreur n’est pas le plus intéressant ; la durée, si :

Dix secondes de vidéo capturées à 30 i/s, cela fait 300 images. À 3 centièmes chacune, cela fait 900 centièmes — neuf secondes. Le GIF se termine une seconde entière avant le plan dont il est issu. Demandez 60 et il s’allonge dans l’autre sens : 600 images à 2 cs font 12,00 secondes.

Parmi les cadences que l’on demande réellement, seules 50, 25, 20, 10 et 5 reviennent exactes. Tout le reste dérive, et dérive d’un pourcentage fixe qui grandit avec la durée du plan. Montez un GIF sur une musique et voilà l’explication entière du décalage progressif de la boucle.

Les encodeurs le masquent en alternant deux délais

C’est ici que l’on quitte l’arithmétique pour quelque chose que vous pouvez lire dans un fichier de votre disque. Un bon encodeur n’arrondit pas toutes les images de la même façon — il alterne, pour que la moyenne tombe juste.

Nous avons pris un GIF produit par ffmpeg, nominalement à 12 i/s, et parcouru ses blocs pour lire le délai de chaque image :

8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8, 8, 9, 8

Vingt-quatre images. 200 centièmes. Exactement 2,00 secondes, soit exactement 12,0000 images par seconde en moyenne. La moyenne est parfaite — et aucune image du fichier n’est à 12 i/s. Les images consécutives sont espacées de 80 ms puis 90 ms, un écart de 12,5 % entre voisines qui ne se résorbe jamais, parce que l’encodeur paie une cadence impossible avec deux cadences possibles.

La conséquence tient en une phrase : « la cadence d’un GIF » est le plus souvent une moyenne qu’aucune image ne possède. Tout outil qui annonce un nombre unique pour un GIF annonce quelque chose qui n’est pas dans le fichier. Pour savoir ce que fait vraiment votre GIF, il faut regarder tous les délais.

Changer la vitesse ne devrait toucher aucun pixel

Puisque la temporisation tient entièrement dans ces deux octets par image, retemporiser un GIF est une édition d’octets. La palette, les données de pixels compressées en LZW, la position des images, l’indice de transparence — rien de tout cela n’a besoin d’être lu, encore moins réécrit.

La plupart des changeurs de vitesse de GIF font l’inverse : décoder en images, ré-encoder, requantifier la palette. Cela coûte une génération visible de couleur à chaque passage, et c’est pourquoi un GIF passé par deux ou trois outils paraît moins bon que l’original sans que personne puisse dire où.

Nous avons mesuré l’édition d’octets sur le fichier de 24 images ci-dessus, qui pèse 54 596 octets :

Un octet par image, et non deux, pour tout sauf la dernière ligne — parce que l’octet de poids fort du délai vaut zéro des deux côtés de l’édition tant que le délai ne dépasse pas 256 centièmes. Deux octets sont écrits par image ; un seul diffère en général. Dans tous les cas le fichier revient de la même longueur, avec des données de pixels identiques bit pour bit, ce qui est la propriété qui compte.

Pourquoi votre navigateur ne peut rien vous dire de tout cela

La façon évidente de vérifier la temporisation d’un GIF est de le charger et de le regarder. Cela ne marche pas, et l’échec est total, pas approximatif.

Nous avons fabriqué six copies du même GIF de 12 images — pixels identiques, seuls les octets de délai réécrits — avec des délais de 0, 1, 2, 3, 5 et 10 centièmes. Chacune a été affichée à l’écran et dessinée sur un canvas toutes les 4 ms pendant quatre secondes, en hachant les pixels à chaque fois pour compter les changements d’image.

Zéro avancement. Sur les six fichiers. Dessiner un GIF animé sur un canvas renvoie une image fixe : le navigateur anime l’image à l’écran mais ne transmet pas l’image courante à votre code. Ce n’est pas un bug que nous avons contourné — c’est la raison pour laquelle un outil qui veut vous dire la vérité sur un GIF doit analyser le fichier lui-même.

Cela veut dire aussi qu’il y a un chiffre que nous ne vous donnerons pas. Les navigateurs imposent leur propre délai minimum, et les très petites valeurs sont traitées comme quelque chose de plus grand — mais nous n’avons pas pu le mesurer ici, précisément pour la raison ci-dessus, donc aucun chiffre à ce sujet ne figure sur nos pages. Tout le reste de cette page vient d’un fichier réel.

Que faire

Si vous pouvez choisir votre cadence, choisissez-en une qui existe : 25, 20 ou 10 i/s sont exactes, et 25 est assez proche de 24 pour que personne ne voie la différence. S’il vous faut 30 ou 60 exactement, ce n’est pas d’un GIF que vous avez besoin, mais d’un conteneur à base de temps plus fine — c’est la raison honnête de le convertir en MP4. Un MP4 à 30 i/s fait bien 30 i/s, et il pèsera en général une fraction du poids.

Et si vous voulez simplement voir ce que fait votre propre GIF, le changeur de vitesse de GIF dessine le délai de chaque image sous forme de barre, vous donne la cadence exacte que vous obtiendrez pour celle que vous demandez, et indique combien d’octets il a modifiés pour y arriver. Il fonctionne dans votre navigateur ; rien n’est envoyé.

Questions fréquentes