Que vous créiez des vidéos, convertissiez des fichiers existants ou prépariez des contenus vidéo pour un site web, le choix du format et des paramètres de compression est l’une des décisions les plus importantes. Le fichier le plus petit n’est pas nécessairement le meilleur : il doit aussi être lu de manière fiable dans les navigateurs, fonctionner sur les smartphones, être décodé efficacement et conserver une qualité visuelle suffis pour l’usage prévu.
J’ai étudié MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, les préréglages de l’encodeur x264, la compatibilité des navigateurs, le décodage matériel sur mobile et les méthodes de mesure de la qualité vidéo. J’ai également effectué des essais pratiques de compression, en encodant une même vidéo source avec différentes valeurs de CRF, puis en comparant les résultats visuellement et à l’aide de mesures objectives.
J’ai finalement choisi de privilégier le MP4 avec H.264 lorsqu’un seul fichier doit fonctionner sur le plus large éventail possible de navigateurs, téléphones et applications externes.
Pour les vidéos courtes principalement destinées aux mobiles, où un chargement rapide et des fichiers légers comptent davantage que la conservation du moindre détail, j’ai retenu x264 avec un CRF de 30 : lors d’une lecture normale, je ne percevais aucune différence significative entre les CRF 22 et 30, même sur un grand écran d’ordinateur.
Cette décision appelle toutefois une précision essentielle : le CRF 30 n’est pas une recommandation pour les films, les productions vidéo haut de gamme ou les séquences exigeant une fidélité visuelle maximale. Dans ces situations, une valeur nettement plus prudente, souvent proche de CRF 20, peut constituer un meilleur point de départ. Je n’ai pas mené d’étude comparable sur des longs métrages ou des images cinématographiques de haute qualité : ces paramètres doivent donc être considérés comme des bases pour des essais distincts.
Je vais expliquer les raisons techniques de ce choix, les résultats réels des compressions, leurs limites et la manière de sélectionner le format vidéo et le niveau de qualité adaptés à votre projet.
1. Conteneurs vidéo et codecs : deux choses différentes
Avant de comparer MP4 et WebM, il faut distinguer le conteneur du codec.
Un conteneur rassemble dans un même fichier la vidéo, l’audio, les horodatages et les métadonnées. Un codec vidéo définit la manière dont les images sont compressées et décodées.
Par exemple, un fichier MP4 peut contenir une vidéo H.264, HEVC ou AV1. Bien qu’elles partagent la même extension, ces combinaisons présentent des caractéristiques de compression et des exigences matérielles différentes.
| Élément | Exemples | Fonction |
|---|---|---|
| Conteneur vidéo | MP4, WebM, MOV, MKV | Regroupe vidéo, audio et données temporelles |
| Codec vidéo | H.264, HEVC, VP9, AV1 | Compresse et décompresse les images vidéo |
| Codec audio | AAC, Opus, MP3 | Compresse et décompresse l’audio |
| Encodeur vidéo | x264, x265, SVT-AV1, libvpx-vp9 | Réalise la compression vidéo |
Renommer un fichier .webm en .mp4 ne convertit pas son codec vidéo. De même, placer une vidéo AV1 dans un conteneur MP4 ne la rend pas lisible sur les appareils dépourvus de décodeur AV1.
Pour évaluer la compatibilité d’une vidéo, il faut toujours considérer l’ensemble : conteneur, codec vidéo, codec audio, profil du codec, profondeur de couleur et environnement de lecture.
2. MP4 ou WebM : lequel choisir pour la vidéo sur le web ?
MP4 et WebM sont tous deux des conteneurs vidéo modernes et parfaitement valables. Aucun n’est supérieur dans tous les cas, car leurs caractéristiques pratiques dépendent des codecs qu’ils renferment.
MP4 avec H.264 : une compatibilité pratique maximale
Le MP4 contenant de la vidéo H.264 et de l’audio AAC bénéficie d’une compatibilité exceptionnellement étendue et éprouvée. Il est pris en charge par les principaux navigateurs sur ordinateur et sur mobile, les lecteurs vidéo des systèmes d’exploitation et de nombreuses applications tierces.
Les décodeurs vidéo matériels des smartphones et des ordinateurs le prennent également très souvent en charge. Par rapport au décodage logiciel, le décodage matériel peut réduire la charge du processeur, améliorer l’efficacité de la lecture et diminuer la consommation d’énergie.
Son principal inconvénient réside dans l’efficacité de la compression. Des codecs plus récents permettent souvent d’atteindre une qualité perçue similaire avec un débit binaire inférieur.
Néanmoins, H.264 reste un excellent choix lorsque la fiabilité de lecture compte davantage que l’obtention du fichier le plus petit possible.
WebM avec VP9 : efficace et bien adapté aux navigateurs
WebM contient généralement une vidéo VP8, VP9 ou AV1, avec un son habituellement encodé en Opus ou Vorbis.
À qualité visuelle comparable, VP9 offre souvent une meilleure efficacité de compression que H.264. Il est largement pris en charge par les navigateurs actuels, y compris les versions modernes de Safari.
Il serait donc faux d’affirmer que Safari ne prend absolument pas en charge WebM ou VP9. La compatibilité des navigateurs s’est considérablement améliorée au fil du temps.
La limite la plus importante concerne plutôt la compatibilité hors du navigateur. Les applications natives, les appareils anciens et certains logiciels tiers peuvent gérer WebM de façon moins constante que le MP4 classique avec H.264.
Pour une application fonctionnant uniquement dans un navigateur, où l’on maîtrise les capacités de lecture, WebM constitue un très bon choix. Si les visiteurs doivent pouvoir télécharger une vidéo et l’ouvrir dans des logiciels variés, MP4/H.264 reste plus prévisible.
La différence en pratique
| Critère | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Lecture dans les navigateurs modernes | Excellente | Très bonne |
| Navigateurs et appareils anciens | Généralement meilleure | Dépend davantage de l’environnement |
| Compatibilité des fichiers téléchargés | Généralement meilleure | Moins prévisible dans les applications natives |
| Efficacité de compression | Bonne | Souvent meilleure |
| Décodage matériel | Très répandu | Courant, mais variable selon l’appareil |
| Usage le plus adapté | Un fichier largement compatible | Diffusion web efficace vers des clients connus |
La vraie question n’est pas de savoir si WebM est un bon format, mais si ses avantages en matière de compression justifient les compromis de compatibilité dans votre environnement.
3. H.264, H.265, VP9 ou AV1 : quel codec choisir ?
Chaque grand codec vidéo présente un équilibre différent entre efficacité de compression, coût de l’encodage, prise en charge matérielle, compatibilité logicielle et licences.
| Codec | Efficacité de compression | Compatibilité pratique | Usages courants |
|---|---|---|---|
| H.264 / AVC | Bonne | Excellente | Vidéo web généraliste, lecture mobile, téléchargements |
| H.265 / HEVC | Généralement meilleure que H.264 | Dépend de l’environnement | Appareils Apple compatibles, environnements maîtrisés, haute résolution |
| VP9 | Généralement meilleure que H.264 | Très bonne dans les navigateurs modernes | Diffusion vidéo dans les navigateurs |
| AV1 | Potentiel d’efficacité excellent | En progression, avec des limites sur les appareils anciens | |
| Streaming moderne et appareils compatibles |
Il s’agit de comparaisons qualitatives, et non d’un classement universel des débits binaires. L’efficacité réelle dépend du contenu, de l’implémentation de l’encodeur, du niveau de qualité visé, du préréglage d’encodage et de la méthode de mesure.
H.264 : éprouvé, rapide à décoder et largement pris en charge
H.264 est très optimisé et pris en charge par une immense variété de matériels et de logiciels. Sa maturité constitue un avantage lorsqu’une vidéo doit être lue de manière fiable sans application spécialisée.
Son point faible est que des codecs plus récents compressent souvent plus efficacement. H.264 soulève aussi des questions de brevets et de licences qu’il convient d’examiner pour les formes de distribution commerciale concernées.
H.265 / HEVC : meilleure compression, mais compromis de compatibilité
À qualité similaire, HEVC peut réduire sensiblement le débit binaire par rapport à H.264. Il est particulièrement intéressant pour la haute résolution et les environnements où la compatibilité des appareils est maîtrisée.
De nombreux appareils Apple prennent très bien en charge HEVC. En revanche, sa prise en charge par les navigateurs et les applications externes varie selon les systèmes d’exploitation et les composants de décodage installés. Les licences entrent également en ligne de compte.
HEVC peut être un excellent choix, mais je n’en ferais pas automatiquement l’unique format téléchargeable d’un site web généraliste.
VP9 : une alternative ouverte et pratique
VP9 offre une bonne compression et une large compatibilité avec les navigateurs modernes. C’est une option intéressante lorsque les vidéos restent dans le navigateur et que l’environnement de lecture est prévisible.
Dans mon cas, son principal inconvénient était l’incertitude liée aux téléchargements et à l’ouverture des vidéos dans des applications natives qui ne prennent pas toujours correctement en charge WebM ou VP9.
AV1 : une excellente efficacité, mais un décodage matériel pas encore universel
AV1 figure parmi les codecs vidéo modernes les plus prometteurs. Il peut permettre des économies de débit importantes par rapport aux codecs plus anciens, et la prise en charge du décodage matériel continue de progresser.
Cependant, les appareils anciens peuvent être dépourvus de décodeur AV1 ou devoir recourir au décodage logiciel. À haute résolution, celui-ci peut solliciter davantage le processeur et la batterie, voire provoquer des problèmes de lecture sur les appareils peu puissants.
Si vous maîtrisez l’environnement de lecture, AV1 mérite une attention particulière. Si un seul fichier doit fonctionner sur des appareils anciens comme récents et dans des lecteurs vidéo externes ordinaires, H.264 reste le choix le plus sûr.
Le guide MDN sur les codecs vidéo fournit des précisions utiles sur ces codecs et leurs exigences de compatibilité avec les navigateurs.
4. Un seul format vidéo ou plusieurs versions ?
C’est l’une des décisions d’architecture les plus importantes pour la diffusion de vidéos.
Lorsqu’on peut proposer plusieurs versions, un site peut servir AV1 ou VP9 aux appareils compatibles et utiliser H.264 comme solution de repli pour les autres. On améliore ainsi potentiellement la compression tout en conservant une large couverture de lecture.
Mais la gestion de plusieurs versions complique aussi l’encodage, le stockage, la mise en cache, la validation et le choix de la version à lire.
Si vous avez besoin d’exactement un fichier vidéo final par source, il est souvent préférable de donner la priorité à la compatibilité.
J’ai choisi MP4/H.264 parce que je voulais un fichier unique, lisible dans les principaux navigateurs, sur les smartphones et dans les usages courants de vidéos téléchargées, sans dépendre de formats alternatifs.
Je ne prétends pas pour autant que MP4/H.264 offre la meilleure compression. Ce choix privilégie la prévisibilité de la lecture plutôt que le gain potentiel de taille d’un codec plus récent.
5. Pourquoi la vidéo mobile impose d’autres priorités
La compression doit être adaptée à la manière dont le contenu sera réellement regardé.
Une courte vidéo principalement visionnée sur smartphone n’a pas les mêmes exigences qu’un long métrage regardé sur un grand téléviseur. Dans le premier cas, la rapidité du chargement et l’économie de données mobiles peuvent compter davantage que les détails les plus subtils. Dans le second, la qualité de l’image peut être l’objectif principal.
Pour les courtes vidéos destinées aux mobiles, les fichiers plus petits offrent plusieurs avantages :
- Moins de données doivent être transférées avant la lecture.
- Les téléchargements peuvent se terminer plus vite sur les connexions limitées.
- Le stockage nécessaire sur l’appareil diminue.
- Les utilisateurs consomment moins de données mobiles.
- La lecture peut mieux résister à un débit réseau limité lorsque le débit binaire encodé est plus faible.
Cependant, un fichier plus petit ne garantit pas l’absence de mises en mémoire tampon ou de blocages. La variabilité du réseau, les pics de débit, le comportement du serveur, la mise en mémoire tampon du lecteur et les performances de décodage de l’appareil jouent aussi un rôle.
La compatibilité mobile ne dépend pas seulement de l’extension du fichier : le décodage matériel, le profil et le niveau du codec, la profondeur de couleur, le sous-échantillonnage de la chrominance, la résolution, la fréquence d’images et les pics de débit comptent tous. Une vidéo affichée sur une largeur de 390 pixels CSS peut occuper bien plus de pixels physiques sur un écran de téléphone à forte densité. Par conséquent, examiner une image réduite à 390 pixels de large n’équivaut pas nécessairement à regarder la vidéo d’origine sur ce téléphone. Faites des essais sur de vrais appareils, dans des conditions de lecture réelles.
Le CRF contrôle la qualité, mais n’impose pas de plafond précis au débit binaire. Une vidéo complexe peut encore présenter des pics de débit exigeants malgré une taille totale relativement faible. Si une lecture fiable sur des connexions particulièrement lentes est indispensable, envisagez des contraintes explicites de débit ou de VBV, des limites de résolution appropriées et des essais dans des conditions réseau réalistes.
Le principe est simple : optimisez l’expérience de visionnage visée, et non un objectif abstrait de qualité maximale.
6. Comprendre le CRF de x264 : plus bas pour la qualité, plus haut pour réduire la taille
Après avoir choisi H.264, il reste à déterminer jusqu’où pousser la compression.
Dans x264, le facteur de qualité constant, ou CRF (« Constant Rate Factor »), règle le compromis entre préservation des détails et taille du fichier.
Un CRF plus faible produit généralement des fichiers plus volumineux et de meilleure qualité. Un CRF plus élevé produit généralement des fichiers plus petits, au prix de pertes de compression plus importantes.
Le CRF ne fixe ni débit binaire exact ni taille de sortie précise. L’encodeur répartit les bits selon la source : une scène simple et une scène très détaillée peuvent donc donner des fichiers de tailles très différentes avec le même CRF.
Le CRF ne détermine pas non plus la compatibilité fondamentale avec les décodeurs. Deux vidéos H.264 correctement encodées avec des CRF de 22 et 30 peuvent présenter le même codec, le même profil, le même niveau, le même format de pixels, les mêmes dimensions et la même fréquence d’images.
La différence tient principalement à la qualité de compression et aux caractéristiques du débit binaire.
Surtout, les valeurs de CRF ne sont pas directement comparables entre différentes implémentations de codecs. Un CRF de 30 dans x264 ne correspond pas à la même qualité visuelle qu’un CRF de 30 dans un encodeur AV1.
7. Mon expérience de compression réelle : CRF de 22 à 32
Je voulais savoir jusqu’où je pouvais compresser une vidéo avant que la différence devienne gênante en lecture normale.
J’ai utilisé une vidéo courte déjà compressée et produit des versions H.264 de comparaison aux CRF 22, 24, 26, 28, 29, 30, 31 et 32.
J’ai conservé les caractéristiques essentielles : résolution, fréquence d’images, durée et nombre d’images. Les réglages de l’encodeur étaient également constants, afin de pouvoir évaluer l’effet du seul changement de CRF.
Les résultats ont montré des différences importantes de taille.
| CRF | Taille approximative par rapport à l’original | Interprétation |
|---|---|---|
| 22 | 63% | Compression plus prudente, meilleure préservation des détails |
| 24 | 49% | Fichier plus petit avec une légère perte de qualité supplémentaire |
| 26 | 38% | Gain supplémentaire tout en conservant beaucoup de détails |
| 28 | 30% | Fichier compact restant relativement proche de la source |
| 29 | 26% | Compression plus agressive |
| 30 | 23% | Mon compromis préféré pour le contenu testé |
| 31 | 21% | Gain supplémentaire avec une fidélité moindre à la source |
| 32 | 19% | Plus petit fichier testé et plus forte perte de qualité mesurée |
Ces pourcentages concernent uniquement la source testée et ne doivent pas être considérés comme des économies habituelles pour n’importe quelle vidéo. Les valeurs du tableau ont été arrondies séparément : pour obtenir les économies relatives exactes, utilisez les tailles de fichiers sous-jacentes plutôt que de diviser les pourcentages arrondis.
Le résultat le plus surprenant a été que je ne distinguais aucune différence visuelle significative entre CRF 22 et CRF 30 pendant une lecture normale, même sur un grand écran d’ordinateur.
J’ai aussi examiné des versions plus fortement compressées, notamment en CRF 32, sans remarquer de différence importante lors du visionnage ordinaire de cet extrait précis.
C’était particulièrement intéressant puisque ces vidéos étaient surtout destinées à des écrans mobiles plus petits. Si la perte de qualité ne me gênait pas sur mon écran d’ordinateur, je voyais peu d’intérêt à accepter un surcoût important en taille pour des détails supplémentaires qui n’amélioraient pas mon expérience de visionnage.
Il s’agissait toutefois d’une observation subjective portant sur un seul type de source. Elle ne démontre pas que tous les utilisateurs, smartphones ou contenus donneront les mêmes résultats. Les écrans mobiles à forte densité et une distance de visionnage réduite peuvent révéler des artefacts, notamment dans les détails fins ou les dégradés.
8. Les mesures objectives ont confirmé une véritable perte de qualité
Ne pas voir de différence pendant la lecture ne signifie pas que deux vidéos sont mathématiquement identiques.
J’ai également comparé les vidéos encodées avec des mesures objectives de qualité d’image. À mesure que le CRF augmentait, leur similarité avec la source diminuait.
Dans une comparaison où toutes les vidéos avaient été réduites à une même résolution pour approximer un écran mobile à forte densité, voici des valeurs SSIM représentatives :
| CRF | SSIM approximatif | Taille par rapport au CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
La tendance est nette : une compression plus forte diminuait la fidélité mesurée de la vidéo encodée. Un examen rapproché révélait également de légères différences dans les traits fins et les textures.
Pourtant, l’expérience de visionnage ordinaire restait très similaire pour la source testée. C’est précisément pourquoi il faut associer mesures objectives et appréciation subjective.
Le SSIM mesure la similarité entre images, pas l’intégralité de l’expérience visuelle humaine. Il ne peut pas rendre pleinement compte des artefacts temporels, de la netteté perçue, du comportement des mouvements ou de l’importance subjective de certains détails.
VMAF est un autre indicateur utile de qualité perceptuelle. Netflix a publié des modèles VMAF v1 en juin 2026, dont un conçu pour des conditions de visionnage sur téléphone. Ces modèles reconnaissent explicitement que la qualité perçue dépend en partie de la taille de l’écran et de la distance relative de visionnage.
Un échantillon encodé de façon prudente dans cette étude affichait un VMAF moyen rapporté d’environ 95, mais je ne disposais pas d’une série de mesures VMAF homogène pour tous les CRF les plus agressifs. Je n’ai donc pas utilisé VMAF pour affirmer que les CRF 30 ou 32 atteignaient un quelconque seuil universel de qualité.
La conclusion pratique était plus limitée : la courte vidéo testée supportait remarquablement bien une forte compression H.264 pendant une lecture normale.
9. Pourquoi j’ai choisi CRF 30 pour les courtes vidéos mobiles
Après avoir comparé les fichiers, j’ai retenu CRF 30 pour des vidéos courtes similaires, principalement regardées sur des appareils mobiles.
Mon raisonnement était simple :
- Les vidéos étaient courtes et ne visaient pas une qualité d’image cinématographique.
- La rapidité du chargement et des téléchargements plus légers étaient importantes.
- Je ne percevais pas de différence significative entre CRF 22 et 30 sur un grand écran d’ordinateur.
- CRF 30 produisait des fichiers beaucoup plus petits que les réglages prudents.
- CRF 32 restait visuellement acceptable sur l’échantillon testé, mais m’inspirait moins confiance pour des contenus plus complexes.
Par rapport à CRF 28, CRF 30 réduisait d’environ 21 % la taille du fichier testé. Par rapport à CRF 22, la réduction dépassait 60 %.
Pour de courts extraits mobiles où l’on recherche une image agréable, un chargement rapide et une consommation raisonnable de bande passante, ce compromis me semblait intéressant.
Mais la condition est essentielle : j’ai choisi 30 en raison de l’usage réel et des résultats obtenus sur le contenu testé, et non parce que 30 serait intrinsèquement le meilleur CRF pour les smartphones.
Un appareil mobile n’exige pas un CRF de 30 : il peut parfaitement afficher une vidéo encodée avec une fidélité bien supérieure. Choisir CRF 30 revient délibérément à échanger une partie de la fidélité à la source contre des fichiers plus petits, lorsque ce compromis est acceptable.
Avant de l’appliquer à une collection de contenus sensiblement différents, je testerais plusieurs extraits représentatifs, notamment des mouvements difficiles, des scènes sombres, des dégradés, du texte et des textures fines.
10. Pourquoi je ne recommande pas CRF 30 pour les films ou les vidéos de haute qualité
C’est la principale limite de cette expérience.
Ne reprenez pas aveuglément mon résultat en CRF 30 pour des longs métrages, des vidéos haut de gamme, des séquences professionnelles ou des contenus destinés à de grands écrans.
Ces contenus peuvent comporter des dégradés subtils, du grain cinématographique, des scènes peu éclairées, des mouvements complexes, des surfaces aux textures fines et un étalonnage des couleurs minutieux. Préserver ces détails peut compter davantage qu’une économie relativement modeste de bande passante.
Pour une vidéo 1080p classique de haute qualité, je commencerais avec un réglage x264 beaucoup plus prudent, autour de CRF 20, puis je testerais des valeurs supérieures et inférieures selon le contenu.
Lorsque la fidélité visuelle est importante, une plage initiale de CRF 18 à 22 peut être pratique, même si la valeur appropriée peut se situer en dehors de cette plage selon la résolution, le contenu et les exigences.
Cette suggestion concorde avec les recommandations d’encodage couramment publiées. Par exemple, la documentation de HandBrake sur la qualité recommande environ RF 20 à 24 pour de nombreux cas d’utilisation de x264 en 1080p.
Je n’ai pas mené la même étude contrôlée sur des longs métrages ou des images cinématographiques haut de gamme. Je ne peux donc pas affirmer que CRF 20 est universellement optimal, que CRF 22 suffit toujours ou qu’un film donné serait nécessairement inacceptable à CRF 30.
La bonne méthode consiste à choisir des scènes représentatives, à les encoder à plusieurs niveaux de qualité, à comparer le résultat sur l’écran visé et à déterminer à partir de quel point une compression supplémentaire devient visiblement dommageable.
Si la vidéo doit être archivée, remontée ou réutilisée pour de futurs encodages, conservez un fichier maître de haute qualité distinct de la version compressée destinée à la diffusion.
11. Pourquoi j’ai utilisé le préréglage veryslow de x264
Le CRF contrôle un aspect de la qualité de compression, tandis que le préréglage x264 détermine les efforts consacrés par l’encodeur à la recherche de décisions de codage efficaces.
x264 propose des préréglages allant du très rapide au très lent. En règle générale, les préréglages plus lents utilisent davantage de temps processeur et peuvent offrir une meilleure efficacité de compression à qualité visuelle comparable.
J’ai comparé les préréglages medium et veryslow sur la même source. Au niveau de qualité testé, veryslow produisait un fichier plus petit.
Pour un encodage hors ligne effectué une seule fois, puis réutilisé à de nombreuses reprises, le temps de traitement supplémentaire peut en valoir la peine.
C’est pourquoi j’ai choisi -preset veryslow.
Ce n’est toutefois pas le meilleur choix dans toutes les situations. Si les vidéos doivent être traitées immédiatement, si les ressources CPU coûtent cher ou si un immense volume de vidéos reste à encoder, slow ou medium peuvent offrir un meilleur équilibre opérationnel.
Le préréglage modifie avant tout la complexité de l’encodage et l’efficacité de compression. Il ne transforme pas H.264 en un autre codec et ne rend pas intrinsèquement le fichier incompatible avec les mobiles.
12. Pour les vidéos d’anime, j’utilise le réglage animation de x264
Lorsque la source contient de l’animation dessinée ou des images de style anime, j’utilise -tune animation avec x264.
Ce réglage est distinct du CRF. Un paramètre de type « tune » modifie certaines décisions de l’encodeur afin de les adapter à des caractéristiques visuelles particulières. Le réglage animation vise les contenus présentant des contours dessinés, des zones de couleurs uniformes et des mouvements stylisés.
Voici donc mes préférences :
- Anime ou vidéo d’animation dessinée :
-preset veryslow -tune animation. - Prises de vues réelles ordinaires : ne pas activer automatiquement le réglage animation ; commencer avec les paramètres par défaut de l’encodeur ou évaluer séparément un réglage adapté.
Il faut bien comprendre ses effets. -tune animation ne garantit ni une amélioration visible de la qualité ni des fichiers plus petits. Il modifie le comportement de l’encodeur, et le résultat dépend du contenu.
J’ai réalisé une comparaison distincte à CRF fixe avec le réglage animation. Dans cet essai précis, son activation a augmenté la taille du fichier d’environ 6 % et légèrement amélioré la similarité d’image mesurée. La différence visuelle était faible.
La comparaison principale des tailles entre CRF 22 et 32 a été réalisée sans le réglage animation. Il ne faut donc pas supposer que les tailles exactes et les rapports de compression de cette expérience restent identiques après activation de -tune animation.
Néanmoins, pour les séquences d’anime, je préfère utiliser le réglage spécifique à l’animation, puis évaluer la taille et la qualité obtenues dans le cadre du profil d’encodage de ce contenu.
Les réglages d’optimisation de l’encodeur doivent être considérés comme des adaptations au contenu, et non comme des améliorations universelles de la qualité.
13. Mes paramètres FFmpeg recommandés pour les courtes vidéos d’anime sur mobile
Pour une vidéo d’anime SDR classique qui nécessite effectivement un transcodage, voici la commande correspondant au profil que je prendrais comme point de départ :
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Cette commande explicite les choix essentiels :
-c:v libx264utilise l’encodeur logiciel H.264.-preset veryslowprivilégie l’efficacité de compression plutôt que la vitesse d’encodage.-tune animationactive les ajustements de l’encodeur adaptés à l’animation.-crf 30applique la cible de qualité constante agressive retenue pour ce type de courte vidéo.-profile:v highsélectionne un profil H.264 couramment pris en charge par les appareils modernes.-pix_fmt yuv420pproduit une vidéo 8 bits en 4:2:0.-map 0:v:0sélectionne le premier flux vidéo.-map '0:a:0?'sélectionne facultativement le premier flux audio.-c:a aac -b:a 128kencode l’audio au format AAC classique lorsqu’une piste audio est présente.-movflags +faststartplace les métadonnées d’initialisation MP4 vers le début du fichier.
Il s’agit d’un exemple, pas d’une commande universelle pour toutes les sources. Les caractéristiques de votre vidéo peuvent nécessiter des traitements supplémentaires.
En particulier, il ne faut pas convertir aveuglément des contenus HDR ou 10 bits en SDR 8 bits sans gestion appropriée des couleurs : cela peut provoquer des couleurs incorrectes, la perte de détails dans les hautes lumières ou des effets de bandes visibles. Les métadonnées de rotation, les fréquences d’images variables, les rapports d’aspect des pixels, les sources entrelacées, les configurations audio inhabituelles et les limites de résolution incompatibles demandent également de l’attention.
Lorsque les dimensions et la fréquence d’images de la source conviennent déjà, les conserver facilite généralement les comparaisons et évite les modifications inutiles d’échelle ou de mouvement. Évitez d’imposer une fréquence d’images constante à une source à fréquence variable sans nécessité : la conversion peut dupliquer ou supprimer des images. En cas de redimensionnement, préservez le rapport d’aspect d’affichage et veillez à ce que les dimensions conviennent au format de pixels 4:2:0 choisi. Des résolutions, des fréquences d’images ou des niveaux H.264 très élevés peuvent dépasser les capacités de décodage des appareils anciens ; la compatibilité exige donc parfois de réduire volontairement la résolution ou la fréquence d’images.
14. Un point de départ FFmpeg plus prudent pour les vidéos de haute qualité
Si la fidélité vidéo compte nettement plus que la taille du fichier, commencez par un CRF plus faible et évaluez le résultat.
Par exemple, la commande suivante constitue une base d’essai raisonnable pour une vidéo SDR classique en prises de vues réelles :
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4Dans cet exemple, le préréglage slow est un point de départ polyvalent et pratique : je ne prétends pas qu’il surpasse veryslow. Utiliser veryslow serait également raisonnable lorsque le temps d’encodage supplémentaire est acceptable.
Ce profil haute qualité est une proposition à tester, pas une configuration démontrée par mon expérience sur les vidéos courtes.
Pour des vidéos haut de gamme, testez des CRF proches de 18, 20 et 22, puis choisissez selon les différences visibles. Un grain ou des mouvements difficiles peuvent nécessiter d’autres paramètres, tandis que les fichiers maîtres destinés à l’archivage peuvent demander une compression bien moins agressive.
15. Ne réencodez pas une vidéo sans raison
La compression vidéo avec perte a un coût en qualité. Réencoder un fichier déjà compressé peut introduire de nouveaux artefacts, même si le résultat semble proche de la source.
Avant un transcodage, demandez-vous si le fichier d’origine satisfait déjà vos exigences de compatibilité, de taille et de qualité.
Si le fichier contient déjà une vidéo H.264 compatible et de l’audio AAC, et qu’aucune transformation visuelle n’est nécessaire, la copie des flux peut être préférable à un nouvel encodage avec perte.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Cette opération copie les flux compressés sans les encoder de nouveau. Elle permet de modifier l’organisation du conteneur sans provoquer une génération supplémentaire de pertes liées à la compression vidéo.
En principe, elle n’apportera pas les mêmes réductions de taille qu’un nouvel encodage à qualité inférieure.
Si votre vidéo actuelle est déjà compacte, compatible et visuellement satisfaisante, la conserver peut être la meilleure optimisation possible.
16. Vérifiez les vidéos encodées au lieu de vous fier uniquement à leur taille
Le fait que FFmpeg se termine sans erreur ne prouve pas automatiquement que la vidéo répond à toutes les exigences.
Commencez par examiner les flux de sortie avec FFprobe :
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Vérifiez le codec, le format de pixels, les dimensions, la fréquence d’images, la durée et les flux audio.
Ensuite, décodez l’intégralité du fichier pour détecter certaines corruptions ou erreurs de décodage :
ffmpeg -v error -xerror -i output.mp4 -f null -Pour vos essais de compression, comparez des résultats issus de la même source. Gardez les variables importantes constantes et ne modifiez qu’un paramètre majeur à la fois.
Regardez la vidéo en mouvement, examinez les détails fins et portez attention aux dégradés, aux zones sombres, aux objets mobiles et au texte.
Si possible, complétez vos comparaisons visuelles par des mesures objectives comme SSIM, PSNR ou VMAF. Un score élevé ne prouve pas à lui seul que tous les artefacts sont invisibles.
Enfin, testez la lecture sur des appareils représentatifs, y compris après téléchargement du fichier. Les informations de compatibilité des navigateurs sont utiles, mais les essais de lecture réels sont particulièrement importants lorsque la compatibilité est l’objectif principal.
17. Assurez-vous que vos fichiers MP4 sont correctement diffusés
De bons paramètres d’encodage ne compensent pas une mauvaise diffusion sur le web.
Pour une lecture MP4 progressive classique, configurez correctement l’en-tête Content-Type: video/mp4 et prenez en charge les requêtes HTTP par plages d’octets lorsque le chargement partiel et la navigation dans la vidéo sont nécessaires.
L’option FFmpeg +faststart déplace les informations d’initialisation du MP4 vers le début d’un fichier classique. Elle facilite le chargement progressif, mais n’améliore ni la qualité visuelle ni le débit binaire.
Un élément vidéo HTML simple peut diffuser un fichier MP4 H.264 :
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>L’attribut preload n’est qu’une indication pour le navigateur, pas une limite stricte de téléchargement. Les politiques de lecture automatique des navigateurs peuvent également imposer une vidéo muette ou sans son.
Si une page contient plusieurs vidéos, évitez de toutes les télécharger immédiatement. Ne les charger qu’au moment voulu peut réduire la consommation de données mobiles et améliorer la réactivité perçue.
Pour les courtes vidéos mobiles, optimiser le déclenchement des téléchargements peut être aussi important que réduire la taille des fichiers encodés.
18. Quel format et quelle qualité vidéo choisir ?
La bonne réponse dépend de votre objectif d’optimisation.
| Votre objectif | Point de départ recommandé |
|---|---|
| Une seule vidéo largement compatible sur le web et après téléchargement | MP4 + H.264 + AAC si une piste audio est présente |
| Diffusion dans les navigateurs modernes avec plusieurs formats | AV1 ou VP9, avec H.264 en solution de repli |
| Compression maximale sur les appareils compatibles | Évaluer AV1 |
| Environnement de lecture maîtrisé et compatible HEVC | Envisager MP4 + HEVC |
| Courtes vidéos mobiles où la taille prime | Envisager x264 CRF 30 après des essais représentatifs |
| Anime ou vidéo d’animation dessinée | Évaluer x264 avec -tune animation |
| Films de haute qualité ou vidéos haut de gamme | Commencer avec un CRF plus prudent, proche de 20, et tester |
| Encodage hors ligne où le temps CPU compte moins | Envisager x264 slow ou veryslow |
| Traitement rapide avec des ressources CPU limitées | Envisager x264 medium ou slow |
| Vidéo existante répondant déjà aux besoins | La conserver ou changer le conteneur sans réencodage |
| Archivage ou montage ultérieur | Conserver un fichier maître de haute qualité séparé des versions diffusées |
19. Mon choix final et ce que l’expérience a réellement démontré
Après avoir étudié les formats vidéo, la compatibilité, l’efficacité de l’encodage et les résultats concrets des compressions, j’ai retenu un profil de diffusion pratique pour les courtes vidéos destinées aux mobiles.
J’ai choisi le format MP4 avec H.264, car une compatibilité prévisible avec les navigateurs, téléphones, téléchargements et applications externes comptait davantage que l’obtention du fichier le plus petit possible avec un codec plus récent.
J’ai retenu l’encodeur libx264 avec le préréglage veryslow, car la vidéo pouvait être encodée hors ligne et le temps de traitement supplémentaire était acceptable.
Pour les vidéos d’anime, j’utilise le réglage animation, tout en sachant qu’il modifie le comportement de l’encodeur sans garantir des fichiers plus petits ou une amélioration visuelle systématique.
Pour les courtes vidéos destinées aux mobiles, j’ai choisi CRF 30, car ma comparaison a montré une réduction substantielle de la taille des fichiers sans différence visuelle significative pendant une lecture normale, même sur un grand écran d’ordinateur.
Ce résultat ne signifie pas que CRF 30 est idéal pour les films ou les vidéos de haute qualité. Lorsque les détails fins, les dégradés, le grain et la fidélité globale comptent davantage, je commencerais les essais vers CRF 20 ou une autre valeur suffisamment prudente. Je n’ai pas réalisé d’étude contrôlée équivalente sur des séquences cinématographiques et ne présente donc pas ce chiffre comme un optimum démontré expérimentalement.
La conclusion essentielle est qu’il n’existe aucun codec, format ou CRF universellement meilleur pour toutes les vidéos.
Si votre priorité est la compatibilité maximale et que vous ne voulez qu’un seul fichier, MP4/H.264 constitue un excellent choix par défaut. Si vous pouvez proposer des formats de repli et recherchez une meilleure compression, étudiez VP9 et AV1. Si vous encodez de courtes vidéos principalement regardées sur téléphone, vérifiez si un CRF plus élevé permet de suffisamment réduire les fichiers sans nuire à l’expérience visée. Pour les films et les séquences haut de gamme, utilisez des paramètres de qualité plus prudents et vérifiez soigneusement le résultat.
Définissez d’abord les exigences de lecture, choisissez ensuite le codec, puis réglez la qualité de compression en dernier. Testez alors le résultat sur les appareils et dans les conditions qui comptent réellement. Cette méthode est plus fiable que l’adoption aveugle d’un codec ou d’un CRF simplement parce qu’il est plus récent, plus efficace ou fréquemment recommandé.