Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

WebP animé vs GIF - Le guide pour enfin virer vos animations de 1987

Par : Korben
6 mars 2026 à 09:55

Le GIF, c'est un format que j'adore mais qui date de 1987. Ouais c'est super vieux quoi (désolé les gens qui sont né cette année là ou avant...On est ensemble...loool). C'est l'époque où Rick Astley cartonnait et où Internet n'existait même pas encore pour le grand public. Et pourtant, y'a encore plein de gens qui s'en servent pour leurs animations avec notamment de la transparence. Alors c'est cool mais aujourd'hui, je vous propose qu'on règle ça une bonne fois pour toute.

Le problème du GIF en fait c'est assez technique puisque ça se compose de 8 bits de couleur (256 couleurs max) et surtout d'un alpha 1 bit. Chaque pixel est donc soit totalement opaque, soit totalement transparent, y'a pas d'entre-deux. Du coup quand vous avez une animation avec des bords arrondis ou des ombres portées, vous vous retrouvez avec des bords tout crénelés et moches. Ça donne un effet "découpage aux ciseaux de maternelle" qu'on aime bien parce que ça fait très rétro mais bon, on peut faire mieux aujourd'hui.

Car avec le WebP animé, c'est une autre histoire. Là on passe à 24 bits de couleur (plus de 16 millions de couleurs) et un alpha 8 bits, c'est-à-dire 256 niveaux de transparence au lieu de juste oui/non. Les dégradés, les ombres, les bords anti-aliasés... tout ça passe nickel et vos animations ont enfin l'air pro au lieu de sortir d'un site GeoCities.

Et niveau poids, y'a pas photo. Google annonce ~64% de réduction en lossy par rapport au GIF même si en pratique, comptez entre 50 et 70% de gain selon la complexité de l'animation. Cela veut dire que sur une page web avec plusieurs animations, ça fait une SACRÉE différence niveau temps de chargement.

Et côté compatibilité, en 2026 la question ne se pose plus puisque Chrome, Firefox, Safari (depuis iOS 14 en 2020), Edge... bref tout le monde supporte le WebP animé. Donc ces conneries de compatibilité, c'est plus une excuse !

Convertir avec gif2webp (la méthode recommandée)

L'outil officiel de Google s'appelle gif2webp (il est inclus dans libwebp ) et c'est ce qu'il y a actuellement de plus fiable pour ce job.

Installez-le d'abord comme ceci :

# macOS
brew install webp

# Ubuntu/Debian
sudo apt install webp

# Windows (via chocolatey)
choco install webp

Ensuite, la conversion de base est plutôt simple :

# Lossy, qualité 70, boucle infinie
gif2webp -lossy -q 70 -loop 0 -m 4 input.gif -o output.webp

# Mode mixed (le meilleur ratio en général)
# Choisit automatiquement lossless ou lossy frame par frame
gif2webp -mixed -q 70 -loop 0 -m 4 input.gif -o output.webp

# Compression max (plus lent, fichier plus petit)
gif2webp -lossy -q 70 -loop 0 -m 6 input.gif -o output.webp

Le paramètre -m c'est la méthode de compression, de 0 (rapide) à 6 (lent mais meilleur ratio). Perso, -m 4 je trouve que c'est le sweet spot comme on dit. Et le mode -mixed est intéressant aussi parce qu'il analyse chaque frame et décide tout seul si c'est mieux en lossy ou lossless.

Avec ffmpeg

Après si vous avez déjà ffmpeg installé (et si vous êtes sur ce blog, y'a de bonnes chances), ça marche aussi :

# Conversion basique GIF vers WebP animé
ffmpeg -i input.gif -c:v libwebp_anim -loop 0 -lossless 0 -q:v 70 output.webp

# Qualité max (lossless)
ffmpeg -i input.gif -c:v libwebp_anim -loop 0 -lossless 1 output.webp

Le -c:v libwebp_anim force l'encodeur WebP animé (sans ça, ffmpeg choisit parfois le mauvais codec et vous obtenez un WebP statique avec juste la première frame... pas génial). Le -q:v va de 0 à 100, et je pense que 70 c'est un bon compromis.

Avec ImageMagick

Avec celui là c'est comme ça :

magick input.gif -coalesce -quality 80 -loop 0 output.webp

Le -coalesce est important car les GIF optimisés stockent souvent juste les différences entre frames pour gagner de la place. Cette option reconstruit chaque frame en entier avant la conversion, sinon vous risquez des artefacts visuels bien moches.

Conversion en masse

Après convertir UN fichier c'est bien, mais si vous avez 200 GIFs à migrer, faut automatiser :

# Convertir tous les GIFs d'un dossier
for f in *.gif; do
 gif2webp -mixed -q 70 -m 4 "$f" -o "${f%.gif}.webp"
 echo "$f converti"
done

# Avec un rapport de taille avant/après
for f in *.gif; do
 gif2webp -mixed -q 70 -m 4 "$f" -o "${f%.gif}.webp"
 size_gif=$(stat -f%z "$f" 2>/dev/null || stat -c%s "$f")
 size_webp=$(stat -f%z "${f%.gif}.webp" 2>/dev/null || stat -c%s "${f%.gif}.webp")
 ratio=$((100 - size_webp * 100 / size_gif))
 echo "$f: -${ratio}%"
done

Intégrer sur un site web

Ensuite pour mettre vos images animées sur votre site web, la méthode propre, c'est l'élément <picture> qui permet de proposer un fallback GIF pour les (rares) navigateurs récalcitrants :

<picture>
 <source srcset="animation.webp" type="image/webp" />
 ![](animation.gif)
</picture>

Après je pense que le fallback GIF n'est vraiment plus indispensable pour le web classique mais par contre si vous envoyez des animations par email comme un le bon boomer que vous êtes, gardez le GIF en fallback parce que les clients mail, c'est un autre monde.

Ah et attention, j'ai lu certains articles qui suggèrent d'utiliser @supports en CSS pour détecter le WebP. Genre @supports (background: url(truc.webp)). Sauf que ça ne marche PAS. La règle @supports teste si une déclaration CSS est syntaxiquement valide, pas si le navigateur sait décoder le format d'image. Donc elle passera toujours, même sans support WebP. Donc si vous avez besoin d'une détection côté CSS, utilisez plutôt image-set() avec type(), mais franchement le <picture> fera le job.

Et l'AVIF animé dans tout ça ?

Alors vous avez peut-être entendu parler de l' AVIF , le format qui fait encore mieux que le WebP en compression. Pour les images statiques, c'est vrai, l'AVIF déchire (support Chrome, Firefox, Safari).

Mais pour les animations ? Bah c'est pas encore ça. Chrome n'affiche que la première frame, Safari ne le supporte pas du tout, et Firefox le cache derrière un flag (image.avif.sequence.enabled).

Bref, on en reparlera dans 2-3 ans.

Quel format pour quel usage ?

Hé oui, y'a un choix à faire parce que le WebP animé n'est pas non plus LA solution à tout. Voici ce que je vous propose en fonction de ce que vous voulez proposer comme animation :

  • WebP animé : stickers, emojis, petites animations en boucle avec transparence. Le meilleur ratio poids/qualité pour ce cas.
  • Vidéo MP4/WebM : si votre animation dépasse 5 secondes ou n'a pas besoin de transparence, une vidéo sera TOUJOURS plus légère. Un MP4 pèse ~50% de moins qu'un WebP animé pour le même contenu. Utilisez ``.
  • Lottie : pour les animations vectorielles (icônes, UI), c'est imbattable en poids (quelques Ko) et c'est scalable. Faut juste le player JS (~60 Ko mis en cache). J'suis sûr que vous ne connaissiez pas !!
  • APNG : si vous avez besoin de lossless absolu (logos, texte animé), c'est supporté partout mais c'est lourdingue.

Voilà, si vous avez encore des GIFs animés avec transparence qui traînent sur votre site, vous savez maintenant ce qu'il vous reste à faire.

Amusez-vous bien !

Constrict - Vos vidéos pile à la bonne taille

Par : Korben
2 mars 2026 à 12:27

Vous avez une vidéo trop lourde pour Discord et sa limite pourrie à 10 Mo ? Du coup, vous passez une demi-heure à bidouiller les réglages d'encodage pour trouver le bon bitrate... sauf que ça marche jamais du premier coup.

Constrict , c'est une app GNOME (Linux uniquement, du coup...) qui règle ce problème de la façon la plus logique possible. Vous lui donnez une taille cible en Mo, et elle se débrouille toute seule pour que votre vidéo rentre pile-poil dedans.

C'est le genre de truc indispensable quand Discord vous bloque à 10 Mo en compte gratuit, que Telegram impose aussi ses propres limites, ou que vous voulez envoyer un fichier par mail sans que ça foire.

En gros, au lieu de deviner quel débit binaire il faut, vous dites juste "je veux que ça fasse 8 Mo" et hop, l'outil calcule automatiquement le bitrate, la résolution, le framerate et la qualité audio pour coller à votre objectif.

Côté codecs, c'est plutôt complet puisqu'on a du H.264 pour la compatibilité, HEVC si vous voulez du lourd sans le poids, AV1 pour les plus patients (attention, l'encodage prend nettement plus longtemps que du H.264... mais le ratio qualité/taille est dingue !) et VP9 pour les adeptes des formats ouverts. Du coup, que vous envoyiez votre clip sur un réseau social, une messagerie instantanée ou par mail, y'a toujours un codec adapté !

Et si vous avez tout un dossier de vidéos à réduire, Constrict gère également le traitement par lot. Vous sélectionnez vos fichiers, vous choisissez la taille cible et un répertoire de sortie, et ça mouline tout seul (sauf si vous lancez 50 fichiers en AV1... là, prévoyez beaucoup de café). En tout cas, c'est quand même plus agréable qu'un script FFmpeg bricolé à la main.

Après si vous essayez de faire rentrer un film 4K de 2h dans 8 Mo... ça va être super moche...

L'app fait de son mieux pour garder un max de qualité, mais y'a des limites physiques (hé oui la compression, ça ne marche pas comme de la magie). D'ailleurs, si la réduction demandée est trop violente, l'outil vous préviendra que c'est mort !

L'app est développée en Python avec GTK4 et Libadwaita, du coup l'interface est native et bien intégrée au bureau GNOME. Elle est certifiée GNOME Circle (ce qui est plutôt bon signe côté qualité) et le code est sous licence GPL-3.0, donc gratuit et open source. Pour l'installation, ça passe par Flatpak sur Flathub ... un :

flatpak install flathub io.github.wartybix.Constrict

... et c'est plié !

Si vous cherchez des alternatives dans le même genre, MystiQ fait de la conversion multiformat et Adapter est un bon couteau suisse basé sur FFmpeg. Mais aucun des deux ne propose ce ciblage par taille, et c'est ça le vrai plus de Constrict !

Merci à Lorenper pour la découverte !

FFmpeg - Comment normaliser le volume audio proprement avec loudnorm

Par : Korben
17 février 2026 à 10:25

Vous avez déjà remarqué comment le volume varie d'une vidéo à l'autre sur YouTube, ou pire, comment certaines pubs sont 10 fois plus fortes que le contenu ? Bah c'est parce que tout le monde n'utilise pas la même norme de volume. Et si vous produisez du contenu audio/vidéo, c'est le genre de détail qui fait la différence entre un truc amateur et un rendu pro.

La bonne nouvelle, c'est que FFmpeg intègre déjà un filtre qui s'appelle loudnorm et qui gère tout ça automatiquement. La norme utilisée, c'est le LUFS (Loudness Units Full Scale), qui est devenue le standard de l'industrie, et YouTube, Spotify, les TV... tout le monde utilise ça maintenant pour mesurer et normaliser le volume audio.

D'ailleurs, si vous débutez complètement avec cet outil, je vous conseille de jeter un œil à mon guide FFmpeg pour les nuls pour bien piger les bases de la ligne de commande.

Allez, c'est partiii ! Temps estimé : 2-5 minutes par fichier (selon la méthode choisie)

Mais, avant de se lancer dans les commandes, un petit point sur les paramètres qu'on va manipuler. Le filtre loudnorm utilise trois valeurs principales. D'abord I (Integrated loudness), c'est le volume moyen global mesuré en LUFS. La valeur standard pour le streaming, c'est -16 LUFS pour YouTube et Spotify, ou -23 LUFS pour la diffusion broadcast. Ensuite TP (True Peak), le niveau maximal que le signal ne doit jamais dépasser. On met généralement -1.5 dB pour avoir une marge de sécurité. Et enfin LRA (Loudness Range), qui définit la plage dynamique autorisée, généralement autour de 11 dB.

Méthode 1 : Normalisation simple (single-pass)

C'est la méthode la plus rapide, parfaite pour du traitement à la volée :

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 sortie.wav

Pourquoi ces valeurs : -16 LUFS c'est le standard YouTube/Spotify, -1.5 dB de true peak évite le clipping, et 11 dB de range dynamique garde un son naturel.

Le truc c'est que cette méthode fait une analyse en temps réel et ajuste à la volée. C'est bien, mais pas parfait. Pour un résultat vraiment précis, y'a mieux.

Méthode 2 : Normalisation en deux passes (dual-pass)

Cette méthode analyse d'abord le fichier complet, puis applique les corrections exactes. C'est plus long mais beaucoup plus précis.

Première passe, on analyse :

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json -f null -

FFmpeg va vous sortir un bloc JSON avec les mesures du fichier (input_i, input_tp, input_lra, input_thresh). Notez-les bien, car vous allez les injecter dans la deuxième passe.

Deuxième passe, on applique avec les valeurs mesurées (remplacez les chiffres par ceux obtenus à l'étape précédente) :

ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-24.35:measured_TP=-2.15:measured_LRA=8.54:measured_thresh=-35.21:offset=0:linear=true -ar 48000 sortie.wav

Pourquoi cette méthode ? En fait, en passant les valeurs mesurées, FFmpeg sait exactement de combien ajuster. L'option linear=true force une normalisation linéaire plutôt que dynamique, ce qui préserve mieux la dynamique originale.

Pour les fichiers vidéo

Le principe est le même, on ajoute juste -c:v copy pour garder la vidéo intacte sans la ré-encoder :

ffmpeg -i video.mp4 -c:v copy -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 video_normalise.mp4

D'ailleurs, pour ceux qui veulent automatiser ça à l'extrême, j'avais parlé de FFmpegfs , un système de fichiers qui transcode automatiquement ce que vous déposez dessus. C'est pratique si vous avez une grosse bibliothèque à gérer.

Traitement par lots avec ffmpeg-normalize

Si vous avez plein de fichiers à traiter, y'a un outil Python qui automatise la méthode dual-pass :

pip install ffmpeg-normalize
ffmpeg-normalize *.wav -o output_folder/ -c:a pcm_s16le

Cet outil fait automatiquement les deux passes et supporte le traitement parallèle. Pratique pour normaliser une bibliothèque entière.

Et en cas de problème ?

Erreur "No such filter: loudnorm" : Votre version de FFmpeg est trop ancienne (il faut la 3.1 minimum). Mettez à jour votre binaire.

Le son est distordu après normalisation : Le fichier source était probablement déjà saturé. Essayez de baisser le target (-18 LUFS au lieu de -16) ou augmentez le headroom du true peak (-2 dB au lieu de -1.5).

Voilà, maintenant vous n'avez plus d'excuse pour avoir des niveaux audio qui varient dans tous les sens. Le LUFS c'est le standard, FFmpeg gère ça nativement, et ça prend 30 secondes.

Vos auditeurs vous remercieront.

Source

❌
❌