Il existe plusieurs façons de retirer un AVI "non compressé" ffmpeg, mais je suppose que vous voulez dire "sans perte". Les deux termes ont un peu de marge de manœuvre dans leurs définitions, comme vous le verrez.
Je vais ancrer cette discussion avec la version HD 720p de Big Buck Bunny , car c'est une vidéo disponible gratuitement que nous pouvons tous tester et obtenir des résultats que nous pouvons comparer. Le débit de données brutes de la vidéo 1280 × 720p à 24 ips est presque égal à celui de votre objectif 1024 × 768 déclaré à 29,97 ips, donc mes résultats devraient être un assez bon guide pour les débits de données que vous pouvez attendre sur votre métrage.
Liste automatique des options disponibles
La commande POSIX suivante¹ vous donne une liste qui correspond pour la plupart² à ce dont nous discutons ci-dessous:
$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'
Vous voudrez peut-être exécuter cette commande sur votre propre machine pour voir ce que votre version de FFmpeg prendra en charge. FFmpeg est rarement construit avec tous les encodeurs possibles activés.
Voyons maintenant ces options.
Entièrement non compressé
Si votre définition de « non compressé » est la forme la vidéo est en droit avant qu'il ne soit tourné vers des photons par un affichage numérique, le plus proche que je vois dans la ffmpeg -codecsliste sont -c:v r210, r10k, v410, v308, ayuvet v408. Ce sont tous sensiblement la même chose, à la différence que dans la profondeur de couleur , l' espace couleur et alpha canal support.
R210 et R10K sont RVB 4: 4: 4 à 10 bits par composant (bpc), ils nécessitent donc environ 708 Mbit / s pour 720p dans mes tests. (C'est environ ⅓ To par heure, mes amis!)
Ces codecs regroupent les composants couleur 3 × 10 bits par pixel dans une valeur de 32 bits pour faciliter la manipulation par les ordinateurs, qui aiment les tailles de puissance de 2. La seule différence entre ces codecs est la fin du mot de 32 bits sur laquelle les deux bits inutilisés sont activés. Cette différence insignifiante est sans doute due au fait qu'elles proviennent d'entreprises concurrentes, Blackmagic Design et AJA Video Systems , respectivement.
Bien qu'il s'agisse de codecs triviaux, vous devrez probablement télécharger les codecs Blackmagic et / ou AJA pour lire les fichiers en les utilisant sur votre ordinateur. Les deux sociétés vous permettra de télécharger leurs codecs sans avoir acheté leur matériel d' abord, car ils savent que vous pouvez traiter des fichiers produits par les clients qui faire ont une partie de leur matériel.
V410 est essentiellement juste la version YUV de R210 / R10K; leurs débits de données sont identiques. Ce codec peut néanmoins coder plus rapidement, car il ffmpegest plus susceptible d'avoir un chemin de conversion accéléré de l'espace colorimétrique entre l'espace colorimétrique de vos trames d'entrée et cet espace colorimétrique.
Cependant, je ne peux pas recommander ce codec, car je n'ai pas pu lire le fichier résultant dans les logiciels que j'ai essayés, même avec les codecs AJA et Blackmagic installés.
Le V308 est la variante 8 bpc du V410, il s'agit donc de 518 Mbit / s lors de mes tests. Comme avec la V410, je n'ai pas pu obtenir la lecture de ces fichiers dans le logiciel de lecture vidéo normal.
AYUV et V408 sont essentiellement la même chose que V308, sauf qu'ils incluent un canal alpha, qu'il soit nécessaire ou non! Si votre vidéo n'utilise pas de transparence, cela signifie que vous payez la pénalité de taille des codecs 10 bpc R210 / R10K ci-dessus sans bénéficier de l'espace colorimétrique plus profond.
AYUV a une vertu: c'est un codec "natif" dans Windows Media, il ne nécessite donc pas de logiciel spécial pour jouer.
Le V408 est censé être natif de QuickTime de la même manière, mais le fichier V408 ne serait pas lu dans QuickTime 7 ou 10 sur mon Mac.
Donc, en rassemblant tout cela, si vos fichiers PNG sont nommés frame0001.png, etc.:
$ ffmpeg -i frame%04d.png -c:v r10k output.mov
...or... -c:v r210 output.mov
...or... -c:v v410 output.mov
...or... -c:v v408 output.mov
...or... -c:v v308 output.mov
...or... -c:v ayuv output.avi
Notez que j'ai spécifié AVI dans le cas d'AYUV, car il s'agit à peu près d'un codec Windows uniquement. Les autres peuvent fonctionner dans QuickTime ou AVI, selon les codecs présents sur votre machine. Si un format de conteneur ne fonctionne pas, essayez l'autre.
Les commandes ci-dessus - et celles ci-dessous également - supposent que vos images d'entrée sont déjà de la même taille que vous le souhaitez pour votre vidéo de sortie. Sinon, ajoutez quelque chose comme -s 1280x720à la commande, avant le nom du fichier de sortie.
RVB compressé, mais également sans perte
Si, comme je le soupçonne, vous voulez réellement dire "sans perte" au lieu de "non compressé", un choix bien meilleur que n'importe lequel des précédents est Apple QuickTime Animation , via-c:v qtrle
Je sais que vous avez dit que vous vouliez un AVI, mais le fait est que vous devrez probablement installer un codec sur une machine Windows pour lire l'un des formats de fichier AVI mentionnés ici, alors qu'avec QuickTime il y a une chance que la vidéo l'application de votre choix sait déjà ouvrir un fichier d'animation QuickTime. (Le codec AYUV ci-dessus est la seule exception que je connaisse, mais son débit de données est terriblement élevé, juste pour bénéficier d'AVI.)
ffmpegse placera qtrledans un conteneur AVI pour vous, mais le résultat peut ne pas être très largement compatible. Lors de mes tests, QuickTime Player se plaindra un peu d'un tel fichier, mais il le lira ensuite. Curieusement, cependant, VLC ne le jouera pas, même s'il est basé en partie sur ffmpeg. Je m'en tiendrai aux conteneurs QT pour ce codec.
Le codec QuickTime Animation utilise un schéma RLE trivial , donc pour les animations simples, il devrait faire à peu près aussi bien que Huffyuv ci-dessous. Plus il y a de couleurs dans chaque image, plus il approchera du débit binaire des options entièrement non compressées ci-dessus. Lors de mes tests avec Big Buck Bunny, j'ai pu me ffmpegdonner un fichier à 165 Mbit / s en mode RVB 4: 4: 4, via -pix_fmt rgb24.
Bien que ce format soit compressé, il donnera des valeurs de pixels de sortie identiques à vos fichiers d'entrée PNG, pour la même raison que la compression sans perte de PNG n'affecte pas les valeurs de pixels.
L' ffmpegimplémentation QuickTime Animation prend également en charge -pix_fmt argb, ce qui vous permet d'obtenir un RVB 4: 4: 4: 4, ce qui signifie qu'il possède un canal alpha. D'une manière très approximative, c'est l'équivalent de QuickTime -c:v ayuv, mentionné ci-dessus. En raison de la compression sans perte, cependant, il ne s'agit que de 214 Mbit / s , soit moins du ⅓ du débit de données d'AYUV avec une perte de qualité ou de fonctionnalités nulle.
Il existe des variantes de QuickTime Animation avec moins de 24 bits par pixel, mais elles sont mieux utilisées pour des styles d'animation progressivement plus simples. ffmpegsemble prendre en charge un seul des autres formats définis par la spécification, ce -pix_fmt rgb555bequi signifie 15 bpp RVB big-endian. Il est tolérable pour certaines vidéos et convient à la plupart des captures d'écran et des animations simples. Si vous pouvez accepter la décimation de l'espace colorimétrique, vous pouvez trouver son débit de données de 122 Mbit / s attrayant.
Mettre tout cela ensemble:
$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24 output.mov
...or... -pix_fmt argb output.mov
...or... -pix_fmt rgb555be output.mov
Effectivement sans perte: l'astuce YUV
Maintenant, le problème avec RVB et YUV 4: 4: 4 est que ces encodages sont très faciles à traiter pour les ordinateurs, mais ils ignorent un fait sur la vision humaine, à savoir que nos yeux sont plus sensibles aux différences en noir et blanc qu'aux différences de couleur .
Les systèmes de stockage et de distribution vidéo utilisent donc presque toujours moins de bits par pixel pour les informations de couleur que pour les informations de luminance. C'est ce qu'on appelle le sous-échantillonnage de la chrominance . Les schémas les plus courants sont 4: 2: 0 et 4: 2: 2.
Le débit de données de 4: 2: 0 YUV est juste 50% plus élevé que pour la vidéo non compressée en noir et blanc (Y uniquement) et la moitié du débit de données de 4: 4: 4 RVB ou YUV.
4: 2: 2 est une sorte de point à mi-chemin entre 4: 2: 0 et 4: 4: 4. Il s'agit du double du débit de données de la vidéo Y uniquement et ⅔ du débit de 4: 4: 4.
Vous voyez également parfois 4: 1: 1, comme dans l'ancien standard de caméra DV . 4: 1: 1 a le même débit de données non compressé que 4: 2: 0, mais les informations de couleur sont organisées différemment.
Le point de tout cela est que si vous commencez avec un fichier H.264 4: 2: 0, le réencoder en RVB non compressé 4: 4: 4 ne vous achète absolument rien au-dessus de YUV 4: 2: 0 compressé sans perte. Cela est vrai même si vous savez que votre flux de travail est autrement 4: 4: 4 RVB, car c'est une conversion triviale; le matériel et les logiciels vidéo effectuent régulièrement ces conversions à la volée.
Vous n'avez vraiment besoin que de 4: 4: 4 lorsque vous regardez des pixels ou que vous effectuez des changements de couleur au niveau des pixels sur la vidéo, et vous devez conserver les valeurs de pixels exactes. Le travail des effets visuels (VFX) est plus facile à faire avec un format 4: 4: 4 pixels, par exemple, donc les maisons VFX haut de gamme sont souvent prêtes à tolérer les débits de données plus élevés dont elles ont besoin.
Effectivement sans perte: choix de codec
Une fois que vous vous êtes ouvert aux codecs YUV avec décimation des couleurs, vos options s'ouvrent également. ffmpegpossède de nombreux codecs sans perte .
Huffyuv
L'option la plus largement compatible est Huffyuv . Vous obtenez ceci via -c:v huffyuv.
Le codec Windows Huffyuv d'origine ne prend en charge que deux formats de pixels: RGB24 et YUV 4: 2: 2. (En fait, il prend en charge deux versions de YUV 4: 2: 2, ne différant que par l'ordre des octets sur le disque.)
Les versions plus anciennes du codec FFmpeg Huffyuv n'incluaient pas le support RGB24, donc si vous l'essayez et FFmpeg vous dit qu'il va utiliser le yuv422pformat pixel, vous devez mettre à jour.
FFmpeg possède également un codec variant Huffyuv appelé FFVHuff, qui prend en charge YUV 4: 2: 0. Cette variante n'est pas compatible avec le codec Windows DirectShow Huffyuv, mais elle devrait s'ouvrir dans tous les logiciels basés sur libavcodec, tels que VLC.
RGB24 - RGB 4: 4: 4 est essentiellement la même chose que l'option d'espace colorimétrique RGB24 de QuickTime Animation. Les deux codecs diffèrent quelque peu en compression pour un fichier donné, mais ils sont généralement proches.
C'est aussi essentiellement la même chose que le mode YUV 4: 4: 4 utilisé par l'option V308 ci-dessus. La différence d'espace colorimétrique ne fait aucune différence pratique, car la conversion de l'espace colorimétrique est facile à faire en temps réel.
En raison de la compression sans perte de Huffyuv, j'ai pu obtenir une vidéo de test à compresser à environ 251 Mbit / s en mode RGB24, avec une qualité visuelle identique à ce que vous obtiendriez de V308 ou AYUV. Si AVI est un must absolu pour vous, l'installation du codec Huffyuv est probablement moins douloureuse que de payer le coût du débit de données 3 × d'AYUV.
YUV 4: 2: 2 - Ce mode est beaucoup plus pratique pour la vidéo que RGB24, ce qui explique sans doute pourquoi les ffmpegdéveloppeurs ont choisi de l'implémenter en premier. Comme vous pouvez vous attendre de la réduction théorique discussed discutée ci-dessus, mon fichier de test a été codé à 173 Mbit / s . C'est à peu près exactement ⅔, si vous prenez en compte le fait que la piste audio n'a pas été modifiée entre ces deux tests.
YUV 4: 2: 0 - Cette option décime les informations de couleur de plus de 4: 2: 2, faisant chuter le débit de données à 133 Mbit / s lors de mes tests.
Mettre tout cela ensemble:
$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24 output.avi
...or... -pix_fmt yuv422p output.avi
...or... -c:v ffvhuff -pix_fmt yuv420p output.avi
Bien que le ffvhuffcodec par défaut soit 4: 2: 0 au moment où j'écris ceci, et en effet ne prend en charge que le format de pixel dans la version finale que j'utilise, cela change , vous devez donc inclure l'indicateur au cas où cette valeur par défaut changerait.
Ut Video
Une option plus récente dans le même esprit que Huffyuv et FFVHuff est Ut Video . Comme Huffyuv, il existe un codec vidéo Windows, ce qui signifie que tout programme Windows capable de lire un film peut lire des vidéos en utilisant ce codec avec le codec installé. Contrairement à Huffyuv, il existe également un codec vidéo Mac, vous n'êtes donc pas limité aux logiciels basés sur FFmpeg ou libavcodecà lire ces fichiers sur Mac.
Ce codec est très flexible en termes d'espaces colorimétriques, je vais donc donner quelques exemples d'espaces colorimétriques courants:
4: 4: 4 RVB via -f avi -c:v utvideo -pix_fmt rgb24donne 178 Mbit / s de sortie
4: 4: 4 YUV via -f avi -c:v utvideo -pix_fmt yuv444pdonne une sortie de 153 Mbit / sec
4: 2: 2 YUV via -f avi -c:v utvideo -pix_fmt yuv422pdonne une sortie de 123 Mbit / sec
4: 2: 0 YUV via -f avi -c:v utvideo -pix_fmt yuv420pdonne une sortie de 100 Mbit / sec
Je soupçonne que 4: 4: 4 YUV fait mieux que 4: 4: 4 RVB dans ce test, bien que ces deux soient techniquement équivalents parce que la vidéo source est 4: 2: 0 YUV, donc organiser les données au format YUV permet une meilleure compression sans perte en regroupant les canaux U et V partiellement redondants dans le fichier.
FFV1
Une autre option intéressante dans cet espace est le propre FFV1codec de FFmpeg . Il est principalement utilisé comme un codec d'archivage plutôt que comme un codec de lecture ou d'édition, mais comme tant de logiciels sont basés sur la libavcodecbibliothèque sous-jacente FFmpeg ou peuvent être saisis libavcodecvia des outils tels que ffdshow, cela peut vous être utile de toute façon.
Par défaut, ffmpegpréservera l'espace colorimétrique de vos fichiers d'entrée lorsque vous utilisez un codec flexible comme FFV1, de sorte que si vous l'alimentez l'un des fichiers MP4 Big Buck Bunny officiels, qui utilisent 4: 2: 0 YUV, c'est ce que vous obtiendrez sauf si vous donnez un -pix_fmtdrapeau ffmpeg. Il en résulte un fichier de sortie à 63 Mbit / s .
Si vous forcez FFV1 à utiliser un espace colorimétrique YUV 4: 4: 4 avec -pix_fmt yuv444p, la taille du fichier ne monte que jusqu'à 86 Mbit / s , mais cela ne nous rapporte rien dans ce cas puisque nous encodons à partir d'un original 4: 2: 0 . Cependant, si vous introduisez un ensemble de fichiers PNG à la place, comme dans la question d'origine, le fichier de sortie est susceptible d'utiliser l' espace de couleur bgraou bgr0, qui ne sont que des réarrangements des espaces de couleur argbet rgb24évoqués ci-dessus.
Sans perte H.264
Une autre alternative intéressante est Lossless H.264 . C'est à peu près une chose x264 uniquement à ce jour, mais ceux qui utilisent FFmpeg du côté de l'encodage utiliseront probablement d'autres logiciels qui incluent libx264du côté du décodage , tels que VLC.
Le moyen le plus simple d'obtenir un tel fichier est:
$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4
Le -qp 0drapeau est la clé: des valeurs plus élevées donnent une compression avec perte. (Vous pouvez également donner -crf 0pour obtenir le même effet.)
Comme avec FFV1, ffmpegj'essaierai de deviner le meilleur espace colorimétrique de sortie étant donné l'espace colorimétrique d'entrée, donc pour la comparaison avec les résultats ci-dessus, j'ai effectué plusieurs passes d'encodage sur le fichier source Big Buck Bunny avec différents espaces colorimétriques:
yuv444p : C'est ce qui ffmpegchoisit lorsque vous lui donnez un flux PNG RVB, comme dans la question d'origine, et donne un fichier 44 Mbit / sec avec notre fichier test
yuv422p : Ceci est similaire à l'espace colorimétrique par défaut pour Huffyuv, mais nous obtenons un fichier à 34 Mbit / sec dans ce cas, une économie considérable!
yuv420p : Il s'agit de la valeur par défaut pour les MP4 officiels Big Buck Bunny avec lesquels je teste, et donne un fichier à 29 Mbit / sec .
Attention, vous échangez beaucoup de compatibilité pour obtenir de si petites tailles de fichiers. C'est pourquoi je n'ai même pas pris la peine d'essayer de mettre ça dans un conteneur AVI ou MOV. Il est si étroitement lié à x264 que vous pourriez tout aussi bien utiliser son type de conteneur standard (MP4). Vous pouvez également utiliser quelque chose comme Matroska pour cela.
Vous pouvez échanger une partie de ce débit binaire pour un temps d'encodage plus rapide en ajoutant -preset ultrafast. Cela a augmenté le débit binaire de mon fichier de test à 44 Mbit / s en mode YUV 4: 2: 2, mais encodé beaucoup plus rapidement, comme promis. Les documents affirment que cela -preset veryslowvaut également la peine, mais cela a entraîné un temps d'encodage beaucoup plus long tout en économisant un tout petit peu d'espace; Je ne peux pas le recommander.
Autres
ffmpegprend également en charge le mode décodage uniquement pour Lagarith et le mode codage uniquement pour Lossless JPEG . Ces deux codecs sont en fait quelque peu similaires et devraient donner des fichiers un peu plus petits que Huffyuv avec la même qualité. Si les ffmpegdéveloppeurs ajoutent jamais l'encodage Lagarith, ce serait une alternative forte à Huffyuv. Cependant, je ne peux pas recommander le JPEG sans perte, car il ne bénéficie pas d'un large support de décodage.
Perceptuellement sans perte: ou, vous pouvez probablement vous en tirer avec une perte
Ensuite, il y a les codecs qui sont sans perte perceptuelle . À moins que vous ne regardiez les pixels, vous ne pouvez certainement pas dire que ceux-ci donnent des résultats visuels différents de ceux des deux groupes précédents. En abandonnant l'idée d'un changement absolument nul entre le capteur de capture vidéo et le dispositif d'affichage, vous réalisez des économies considérables:
Apple ProRes :-c:v proresou-c:v prores_ks- ProRes est un codec basé sur le profil, ce qui signifie qu'il existe plusieurs variantes, chacune avec un compromis qualité / espace différent:
ProRes 4444 code notre vidéo de test en utilisant seulement 114 Mbit / s , tout en étant de qualité VFX . Il existe actuellement troisprores*codecsdifférentsdans FFmpeg, mais neprores_ksprend en charge que ProRes 4444, au moment où j'écris ceci, via l'-profile:v 4444option.
Si vous vous demandez pourquoi vous vous embêtez à utiliser ProRes 4444 sur Lossless H.264, cela dépend de la compatibilité, de la vitesse de décodage, de la prévisibilité et du canal alpha.
ProRes 422 économise encore plus d'espace, ne nécessitant que 84 Mbit / s pour donner un résultat que vous pouvez voir à partir de ProRes 4444 uniquement par pixel-peeping. À moins que vous n'ayez besoin du canal alpha offert par ProRes 4444, il n'y a probablement aucune raison d'insister sur ProRes 4444.
ProRes 422 est un concurrent plus proche de l'option Lossless H.264 ci-dessus, car aucun ne prend en charge un canal alpha. Vous voudrez tolérer le débit binaire plus élevé de ProRes si vous avez besoin de compatibilité avec les applications vidéo Apple Pro, d'un surcoût CPU inférieur pour l'encodage et le décodage, ou de débits binaires prévisibles. Ce dernier est important avec les encodeurs matériels, par exemple. D'un autre côté, si vous pouvez faire face aux problèmes de compatibilité de Lossless H.264, vous avez la possibilité d'utiliser l'espace colorimétrique 4: 2: 0, qui n'est une option d'aucun profil ProRes.
Les trois encodeurs ProRes de FFmpeg prennent en charge le profil ProRes 422, donc l'option la plus simple est d'utiliser -c:v proresplutôt que de -c:v prores_ks -profile hqdépendre de la fonction de profil automatique prores_kspour faire la bonne chose.
Il existe encore plus de profils ProRes parcimonieux, mais ils sont destinés à la vidéo SD ou à des proxys pour des fichiers pleine résolution.
Le principal problème avec ProRes est qu'il n'a pas encore une large prise en charge en dehors des mondes vidéo Apple et pro.
Le DNxHD d'Avid est un codec similaire à ProRes, mais n'est pas lié au monde de la vidéo professionnelle Apple. Avid propose des codecs téléchargeables gratuitement pour Windows et Macintosh, et FFmpeg le prend désormais en charge via-c:v dnxhd.
Étant donné que DNxHD est un codec basé sur un profil comme ProRes, vous choisissez le profil dans l'ensemble prédéfini , et qui indique au codec quelle taille de trame, fréquence de trame et débit binaire à utiliser. Pour le fichier de test Big Buck Bunny, le -b:v 60Mprofil est le plus approprié. Sans surprise, le fichier résultant est d'environ 59 Mbit / s .
MJPEG à faible perte :-vcodec mjpeg -qscale:v 1- C'est beaucoup plus courant que le JPEG sans perte. En fait, c'était autrefois un codec de montage vidéo assez courant, et il est encore fréquemment utilisé par des choses comme les caméras vidéo en streaming en réseau. Tout cet historique signifie qu'il est facile de trouver un logiciel qui le prend en charge.
Attendez-vous à une très grande variabilité des débits de données de ce codec. Un test que je viens de faire ici m'a donné 25 Mbit / s pour la vidéo 720p. C'est une compression suffisamment élevée pour me rendre nerveux à propos de la perte, mais cela me semblait plutôt bien. Sur la base du seul débit de données, je dirais qu'il est probablement de qualité comparable à 12 Mbit / s MPEG-2 ou 6 Mbit / s H.264.
Mettre tout cela ensemble:
$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
...or... -c:v prores_ks -profile:v hq output.mov
...or... -c:v prores output.mov
...or... -c:v dnxhd -b:v 60M output.mov
...or... -c:v mjpeg -qscale:v 1 output.avi
En résumé, à moins que vous ne fassiez quelque chose de très exigeant, «assez bien» est vraiment assez bon.
Notes de bas de page et digressions
La commande devrait fonctionner comme indiqué sur Linux, macOS, les BSD et Unix. Si vous êtes sous Windows, vous pouvez obtenir une ligne de commande POSIX via Cygwin ou WSL .
Il y a plusieurs raisons pour lesquelles la liste produite par cette commande ne correspond pas parfaitement à l'ensemble des codecs que j'ai choisi de discuter ci-dessus:
Le second grepest destiné à filtrer les encodeurs inappropriés comme ceux bmpqui ne sont pas des codecs "vidéo", bien qu'ils soient marqués Vdans cette liste. Bien que, techniquement, vous puissiez probablement en mettre beaucoup dans un conteneur comme AVI, MP4 ou MKV pour obtenir une vidéo à fichier unique, ce fichier ne sera probablement pas lisible par autre chose qu'un programme basé sur ffmpegou libavcodec.
Il y a quelques exceptions à cela, comme cela -f avi -c:v ljpegdonne quelque chose que vous pourriez appeler "Lossless MJPEG", mais en règle générale, nous ne sommes pas intéressés par le remplissage de nombreux fichiers d'images fixes dans un conteneur A / V ici pour faire un film. Nous voulons ici des codecs vidéo largement reconnus, pas une supercherie sémantique.
La commande ne parvient actuellement pas à filtrer certains encodeurs inappropriés tels que GIF car ils ne sont actuellement pas décrits dans les formats de ffmpeg -codecssortie bitmapou de imagefichier.
GIF est un cas intéressant: il prend en charge plusieurs images dans un seul fichier GIF avec des informations de synchronisation pour la lecture de mouvement, mais pour plusieurs raisons, il est tout à fait inapproprié pour notre discussion ici.
Quelques - unes des options qui apparaissent obsolètes ou jamais vraiment eu beaucoup de traction, tels que flashsv, diracet snow, donc il ne vaut pas les discuter ci - dessus.
Certaines des options de cette liste sont uniquement destinées à être utilisées dans des pipelines entre des ffmpeginstances ou entre ffmpeget un autre programme, comme rawvideoet wrapped_avframe, et sont donc inappropriées pour nos besoins ici.
Vers la fin de la discussion ci-dessus, j'étends judicieusement la portée de la question pour inclure quelques options avec perte soigneusement choisies, afin qu'elles ne passent pas le premier grepfiltre de la commande ci-dessus.
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov.