Compression avec perte est un compromis entre le débit (taille du fichier) et la qualité, et ne consiste pas seulement à obtenir les fichiers les plus petits. Si c'est tout ce que vous voulez, utilisez -preset veryslow -crf 51 (et éventuellement réduire l'échelle à 256x144) pour obtenir un fichier minuscule qui n'est principalement constitué que de taches floues sans aucun détail.
L'encodage est un compromis à trois voies entre le temps de l'unité centrale, la qualité et le débit, ce qui est très différent d'une compression sans perte telle que la compression de l'eau. zip où la taille du fichier est la mesure de la "meilleure" compression, et c'est ce que vous échangez contre le temps dans un compromis à deux voies. 1 Ou 3 voies si les vitesses de compression et de décompression sont indépendantes...
-preset veryslow vous offre le meilleur compromis que x264 puisse offrir 2 en consacrant plus de temps de l'unité centrale à la recherche de moyens de représenter plus de détails par bit. (c'est-à-dire le meilleur compromis entre taux par distorsion ).
Ceci est principalement orthogonal au contrôle du débit, qui décide du nombre total de bits à utiliser. Le contrôle du débit par défaut de x264 est CRF 23 ( ffmpeg -crf 23 ) ; si vous voulez des fichiers plus petits, utilisez -preset veryslow -crf 26 ou quelque chose du genre, afin de dépenser moins de bits pour la même complexité, ce qui se traduit par un plus grand flou. C'est logarithmique, de sorte que l'augmentation du CRF de quelques chiffres peut modifier le débit binaire d'un facteur 2, pour une qualité presque transparente, -crf 18 o 20 est souvent bonne, mais coûte plus de débit.
Le mode CRF n'est pas une véritable qualité constante (SSIM, PSNR ou toute autre mesure). Avec des préréglages d'encodage plus rapides, x264 utilise un processus de prise de décision plus simple pour décider où et comment dépenser les bits, ce qui entraîne une certaine variation du débit pour le même paramètre CRF.
Avec différents outils de recherche pour trouver la redondance, comme l'explique @szatmary, un préréglage plus élevé peut trouver un moyen beaucoup plus petit d'encoder quelque chose qui n'est que légèrement moins bon. Ou une façon d'encoder certains blocs qui semble beaucoup plus mauvaise. meilleur mais il est à peine plus grand. En fonction de l'évolution moyenne de ces éléments, le même CRF avec des préréglages de qualité différents aura une qualité différente. y un débit binaire différent.
C'est pourquoi vous n'obtenez pas de fichiers progressivement plus petits pour une qualité identique ; -preset veryfast La situation est généralement pire. -preset ultrafast est généralement très mauvais, même à haut débit, mais d'autres préréglages peuvent être aussi bons que le veryfast si vous dépensez beaucoup plus de débit.
Un fichier plus petit ne signifie pas une meilleure compression. N'oubliez pas que la qualité est également variable . Si vous avez utilisé ffmpeg -i in.mp4 -ssim 1 -tune ssim -preset veryslow out.mkv pour que libx264 calcule la métrique de qualité visuelle SSIM, vous trouverez que veryslow a une meilleure qualité par bitrate que veryfast. (Si vous comparez la qualité, faites-le à bitrate fixe, c'est-à-dire 2-pass et non CRF. Voir https://trac.ffmpeg.org/wiki/Encode/H.264 )
Gardez à l'esprit que les optimisations psychovisuelles qui rendent les images plus agréables à regarder pour les humains (comme le -psy-rd=1.0:0.15 ) peut obtenir de moins bons résultats pour certaines mesures de qualité. ne vouloir -tune ssim . Psy-rd signifie prendre en compte la perception humaine lors de l'optimisation du compromis entre débit et distorsion. L'AQ (quantification adaptative) est une autre optimisation psy, mais qui SSIM est suffisamment sophistiquée pour être reconnue comme bénéfique, contrairement à l'approche plus simple de la PSNR la mesure de la qualité.
Les humains ont tendance à percevoir le bruit à haute fréquence (spatiale) comme un détail s'il est à petite échelle, même s'il ne s'agit pas du même détail que dans l'image source. Par exemple, les artefacts de franges et d'anneaux résultant de la quantification = de l'arrondissement des coefficients DCT peuvent en fait paraître plus intéressants que le simple fait de tout brouiller, s'ils sont mineurs. Des choses qui semblent pires lorsque vous faites une pause et que vous zoomez peuvent tromper votre œil de manière agréable lorsque vous regardez normalement. (Le h.264 possède un filtre de déblocage en boucle, appliqué avant que les images ne soient affichées et utilisées comme références, de sorte qu'il évite plus facilement le blocage que les codecs antérieurs tels que DivX / h.263. En augmentant ce filtre, on risque de tout brouiller à faible débit).
L'idée est similaire à ce que font les MP3 et autres codecs audio avancés pour le son, sauf qu'il y a plus de place pour l'optimisation psychoacoustique car les sons forts empêchent vraiment les oreilles d'entendre les sons calmes à des fréquences proches.
Si vous n'encodez qu'une seule fois pour conserver le résultat pendant une longue période et/ou pour le diffuser sur Internet, utilisez -preset veryslow . Ou à le moins -preset medium . Vous payez le coût de l'unité centrale une fois, et vous récoltez les économies réalisées en termes de taille de fichier (pour une qualité donnée) à plusieurs reprises.
Mais si vous ne regardez un encodage qu'une seule fois, par exemple pour placer une vidéo sur un appareil mobile où vous la regarderez une fois puis la supprimerez, alors -preset faster -crf 20 est judicieux si vous disposez de l'espace de stockage nécessaire. Il suffit de dépenser un peu plus.
Note de bas de page 1 : Dans la compression sans perte, vous arbitrez entre la taille du fichier et la vitesse de compression et/ou de décompression (qui peut être différente ; certains codecs sont très rapides à décompresser même s'ils permettent une bonne compression lente). En fait, l'utilisation de la RAM / l'empreinte du cache peut également être une variable si vous souhaitez entrer dans ce niveau de détail. Dans la compression sans perte, la qualité est fixée à "parfaite", comme x264 -qp 0
Les performances du décodage h.264 peuvent varier en fonction du nombre de trames de référence, un plus grand nombre de trames ayant une empreinte mémoire plus importante et donc un plus grand nombre d'erreurs de cache pour un décodeur CPU. Mais souvent, le décodage h.264 est effectué par le matériel. Comme pour de nombreux systèmes de compression sans perte, les performances de décodage ne varient fortement qu'avec des codecs totalement différents (comme h.265), et non avec des options différentes pour le même codec. Supplémentaire coder Le temps est consacré à la recherche de différentes manières d'encoder les mêmes bits, alors qu'il n'y a qu'une seule manière de décoder.
Et oui, h.264 dispose d'un mode sans perte, dans le cadre de la norme Profil Hi444PP . Non, vous ne voulez pas l'utiliser sur Internet ; de nombreux décodeurs autres que FFmpeg ne prennent pas en charge cette fonction spéciale, et le débit binaire est énorme, de l'ordre de 100 à 200 Mbit/s pour 1080p30 YUV 4:2:0 ou RGB 4:4:4. Comment créer un AVI non compressé à partir d'une série de milliers d'images PNG à l'aide de FFMPEG ? présente les résultats des tests effectués sur la remorque Sintel.
Note de bas de page 2 : D'autres codecs comme h.265 (avec l'encodeur x265) ou VP9 peuvent offrir des compromis de distorsion de taux encore meilleurs, mais au prix de viel plus de temps CPU pour l'encodage. Pour un temps d'encodage fixe, je ne suis pas sûr qu'il y ait un avantage à utiliser x265 plutôt que x264. Mais la compatibilité des décodeurs avec h.265 est beaucoup moins répandue qu'avec h.264.
La compatibilité de décodage est très bonne pour h.264 profil principal et, espérons-le, également très en vue ces jours-ci. (Le DCT 8x8 est plus utile pour les hautes résolutions comme le 1080p et surtout le 4k.) La valeur par défaut de x264 est un profil élevé. Certains appareils mobiles obsolètes peuvent n'avoir qu'un décodage matériel pour le profil de base h.264, mais la qualité par débit est nettement moins bonne (pas de trames B, ni de CABAC, seulement le CAVLC moins efficace pour l'étape finale de codage sans perte des structures dans un flux binaire).
