FFMPEG / libx264: Comment spécifier une fréquence d'images variable mais avec un maximum?

Au lieu de fournir une fréquence d'images fixe à FFMPEG / libx264 (-r / -framerate), je voudrais spécifier une fréquence d'images variable avec une valeur MAXIMALE et permettre à libx264 de réduire la fréquence d'images comme bon lui semble. L'idée ici est d'obtenir une compression supplémentaire lorsqu'il y a quelque chose comme une image fixe étendue (ce qui arrive BEAUCOUP dans mes vidéos source).

Je me rends compte qu'une trame MPEG prédictive ou bidirectionnelle se compressera très bien, mais il est également possible que la fréquence d'images source soit plus petite que celle à laquelle je souhaite transcoder (ce qui pourrait entraîner un PLUS GRAND flux!).

Frustré que vous n'ayez pas trouvé de réponse non plus, j'allais au moins répondre aux questions des autres sur la façon d'activer la sortie VFR (pas V B R) à partir de FFMPEG.

La réponse à cette question est l' -vsyncoption étrangement nommée . Vous pouvez le définir sur plusieurs options différentes, mais celle que vous souhaitez est «2» ou vfr. Depuis la page de manuel:

-vsync parameter
Méthode de synchronisation vidéo. Pour des raisons de compatibilité, les anciennes valeurs peuvent être spécifiées sous forme de nombres. Les valeurs nouvellement ajoutées devront toujours être spécifiées sous forme de chaînes.

• 0, passthrough

  • Chaque trame est passée avec son horodatage du démultiplexeur au multiplexeur.

• 1, cfr

  • Les images seront dupliquées et supprimées pour atteindre exactement la fréquence d'images constante demandée.

• 2, vfr

  • Les trames sont transmises avec leur horodatage ou supprimées de manière à empêcher 2 images d'avoir le même horodatage.

• laissez tomber

  • Comme passthrough mais détruit tous les horodatages, ce qui fait que le multiplexeur génère de nouveaux horodatages basés sur la fréquence d'images.

• -1, automatique

  • Choisit entre 1 et 2 selon les capacités du multiplexeur. Il s'agit de la méthode par défaut.

Notez que les horodatages peuvent être modifiés par le multiplexeur, après cela. Par exemple, dans le cas où l'option de format eviter_negative_ts est activée.

Avec -map, vous pouvez sélectionner à partir de quel flux les horodatages doivent être pris. Vous pouvez laisser la vidéo ou l'audio inchangés et synchroniser le ou les flux restants avec le flux inchangé.

Cependant, je n'ai pas assez de réputation pour poster un commentaire pour simplement répondre à cette «sous-question» que tout le monde semble avoir. Mais j'avais quelques idées sur lesquelles je n'étais honnêtement pas très optimiste ... Mais la première que j'ai essayée a fonctionné . Donc.

Vous avez simplement besoin de combiner l' -vsync 2option avec l' -r $maxfpsoption, bien sûr où vous remplacez $maxfpspar le débit d'images maximal que vous voulez! Et il fonctionne! Il ne duplique pas les images d'un fichier source, mais il supprimera les images qui feront que le fichier dépassera le débit d'images maximal!

Par défaut, il semble que -r $maxfpspar lui-même, il ne fait que dupliquer / supprimer des images pour obtenir une fréquence d'images constante, et -vsync 2par lui-même, il tire les images directement sans vraiment affecter les valeurs PTS.

Je n'étais pas optimiste à ce sujet car je savais déjà que cela le -r $maxfpsmettait à un taux de rafraîchissement constant. Honnêtement, je m'attendais à une erreur ou à ce qu'elle obéisse simplement à la première, à la dernière ou quoi que ce soit. Le fait qu'il fasse exactement ce que je voulais me rend très satisfait des développeurs FFMPEG.

J'espère que cela vous aidera, vous ou quelqu'un d'autre plus tard si vous n'avez plus besoin de le savoir.

Je voudrais spécifier une fréquence d'images variable avec une valeur MAXIMALE et permettre à libx264 de réduire la fréquence d'images comme bon lui semble. L'idée ici est d'obtenir une compression supplémentaire lorsqu'il y a quelque chose comme une image fixe étendue

À ma connaissance, cela peut être d'une manière relativement maladroite, mais n'est pas souhaitable pour des raisons complexes et contre-intuitives

Même si un flux x264 a un (des) débit (s) d'images, la fréquence d'images est plus un problème au niveau du conteneur qu'un codec.

Dans un encodage VFR passthrough, il y aura essentiellement un fichier texte détaillant la fréquence d'images sur quelles images / heures, et dans l'encodage d'une source, une fonction comme tcfile-in ou tcfile-out transmet les horodatages à l'encodage , pour cartographier les emplacements de taux et conserver la vidéo subjectivement cohérente par rapport à la source.

L'idée à faible fréquence d'images est logique, mais ne fonctionne pas pour plusieurs raisons. Bien que x264 soit compatible VFR avec certaines capacités, je ne pense pas qu'il existe une fonction d'analyse qui fera varier le débit d'images en ce qui concerne le mouvement afin de réduire la taille du fichier (d'une manière analogue aux nombreux contrôles de débit binaire).

La source est également un problème: les sources VFR conserveront par défaut leur variabilité de trame, mais apparemment le codage d'un fichier CFR à débit binaire variable (une bonne idée parfois, en particulier lorsque le télécinéma est nécessaire) produira simplement le même CFR.

Cela signifie que vous devrez probablement réécrire le débit binaire à la main (c'est-à-dire les horodatages de scènes lentes muxedées dans le fichier), ou recourir à un algorithme de décimation de trame comme dup, dedup et exactDedup pour avisynth . Si votre vidéo présente un mouvement extrêmement faible, certaines images (même la moitié?) Seront supprimées. Le problème est que ces algorithmes ne sont pas avancés et ne font pas de bons choix avec des séquences "réelles" quant à ce qui contribuera au meilleur encodage.

En outre, la suppression d'images contenant des éléments tels que les images I et B réduit la quantité de détails disponibles au fil du temps, ce qui donne au mouvement un aspect "steppy" et peut interférer avec les autres paramètres vidéo de base et provoquer des artefacts comme l'aliasing.

Et en raison de la façon dont les quantificateurs fonctionnent, x264 diminuera encore plus le débit binaire de manière disproportionnée dans ces scènes de faible mouvement. À moins que vous n'ayez un diaporama d'images identiques, il y aura du mouvement (ne serait-ce que du grain et d'autres artefacts) et il y aura une perte de qualité qui ne serait pas visible sans des changements drastiques du débit binaire.

Et enfin, la raison pour laquelle il n'y a pas beaucoup d'options pour faire ce que vous voulez est que x264 est vraiment bon pour gérer le débit binaire en utilisant simplement la compression temporelle (enregistrement des changements dans des images partielles). Aller à 1/2 framerate ne réduira pas la taille du fichier de moitié; 10% est probablement un gain réaliste à attendre d'un mouvement bas ou d'une animation.

Donc, en bref, la réduction du débit de vos scènes statiques ne fera pas grand-chose pour la taille de votre fichier, mais ajoutera une foule de problèmes de qualité et de synchronisation, sans parler de l'incompatibilité avec le logiciel de montage vidéo.

Si vous voulez essayer un décimateur, vous pourriez être en mesure de limiter la nouvelle fréquence d'images maximale en utilisant les options de niveaux , dont chacune a une résolution et une fréquence d'images maximales. Malheureusement, vous devrez probablement travailler à des résolutions très basses pour obtenir le type de fréquences d'images que vous souhaitez, en utilisant des profils. Il revient à éditer les taux à la main, soit entièrement, soit à corriger les taux d'images que vous jugez trop élevés. Quoi qu'il en soit, il faudra jongler pour garder le son synchronisé avec les nouvelles fréquences d'images si des modifications sont apportées après le processus d'encodage lorsque le fichier tc est conservé.

La conclusion est que passer du temps à optimiser les nombreux paramètres de débit binaire donnera beaucoup plus de gestion de la taille des fichiers et améliorera la qualité de votre vidéo, plutôt que de causer des complications pour un gain faible. Préserver le FPS d'origine est probablement la meilleure idée, sauf si vous visez des normes de diffusion ou de médias. Les lecteurs sont bien capables de lire des débits binaires variables (contrairement aux éditeurs), et plus il y a d'images dans votre vidéo, plus la lecture est fluide et peut-être plus la taille du fichier est petite, en raison de petits changements de mouvement entre les images.

Voici une collection de liens vers des informations sur les normes et des discussions sur le forum qui devraient aider avec cet aspect confus de l'encodage:

- outils de décimation avisynth

- Commutateurs fps et -r
- Général x264 (tcfile, fps)
- Normes de fichiers de timecode
- Niveaux et profils
- Résumé des paramètres CFR / VFR court et clair (section "framerate")

doom9, videohelp, & c discussions théoriques
1 2 3 4 5 6 7