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.J'ai donc fini par faire ma propre réponse trop longtemps.
Résumé TL; DR: Pour stocker sans perte une séquence d'images, utilisez
libx264oulibx264rgbavec-preset ultrafast -qp 0. Il est presque aussi rapide que ffvhuff, avec un débit binaire beaucoup plus faible et décode plus rapidement.huffyuvest beaucoup plus largement pris en charge en dehors de ffmpeg, mais ne prend pas en charge autant de formats de pixels queffvhuff. C'est donc une autre raison d'utiliser h.264, en supposant que vos autres outils peuvent gérer leHigh 4:4:4 Predictiveprofil h.264 que x264 utilise en mode sans perte. x264 peut fonctionner uniquement en intra si un accès aléatoire rapide à des trames arbitraires est nécessaire.Méfiez-vous d'un bogue ffmpeg affectant libx264rgb lors de la lecture à partir d'un répertoire d'images. (et qui sait quels autres cas.) Testez l'absence de perte dans votre configuration avant de l'utiliser. (facile avec
ffmpeg -i in -pix_fmt rgb24 -f framemd5source et compressé sans perte))edit:
utvideoencode et décode assez rapidement, et est un codec beaucoup plus simple que h.264. C'est fondamentalement un modernehuffyuv, avec un support pour des espaces de couleurs plus utiles. Si vous rencontrez un problème avec h.264, essayez utvideo next pour les fichiers temporaires.edit2: PNG en tant que codec RVB semble bien fonctionner, du moins sur la bande-annonce de Sintel.
Voir aussi ma réponse similaire à une question similaire: https://superuser.com/a/860335/20798
Il y a beaucoup d'informations dans la réponse de Warren Young sur divers formats bruts et codecs. Je pense que la réponse serait plus utile si elle était plus courte, alors je fais une nouvelle réponse. Si vous travaillez avec un logiciel qui ne prend pas en charge la perte sans perte x264 ou ffvhuff, certaines de ces informations sont probablement toujours utiles.
La définition la plus utile de «sans perte» dans ce contexte est que vous pouvez récupérer l'entrée bit à bit. Ne vous inquiétez pas de la dégradation de la qualité due au codage vidéo, quelle que soit votre action.
http://en.wikipedia.org/wiki/Chroma_subsampling
Idéalement, évitez les conversions d'espace colorimétrique multiples. Les erreurs d'arrondi peuvent potentiellement s'accumuler. Si vous allez opérer votre vidéo avec des filtres qui fonctionnent dans l'espace colorimétrique RVB, alors le garder RVB a du sens, tant que les débits binaires plus élevés ne sont pas un problème. Vous allez probablement produire une
yuv 4:2:0vidéo en fin de compte , mais conserver la résolution chromatique supplémentaire est potentiellement utile, selon les filtres que vous allez appliquer.De toute façon, x264 sans perte et ffvhuff à la fois support RVB et YUV
4:4:4,4:2:2et4:2:0. Je suggère x264, car il est rapide à décoder. Si vous essayez de lire une vidéo RVB HD en temps réel, essayez opengl au lieu de xv, car xv sur mon système n'accepte que l'entrée yuv. mplayer prenait du temps CPU supplémentaire pour effectuer une conversion d'espace colorimétrique.Source pour les tests d'encodeur suivants: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Ils ont oublié de compresser les fichiers y4m pour la bande-annonce de sintel, donc le tarball png est en fait beaucoup plus petit.
par exemple
Notez que j'ai oublié de spécifier
-r 24fps, donc il ne gardera pas la synchronisation av avec l'audio. (et les nombres de bitrate (mais pas de taille de fichier) seront également désactivés. ffmpeg par défaut est 25fps). Le processeur de cette machine est un core2duo 2,4 GHz (E6600) de première génération (conroe).résultats:
Notez que
mediainfone connaît pas RVB h.264, il dit toujours que les fichiers sont YUV.Vérifiez qu'il n'a vraiment pas subi de perte:
Ainsi, vous pouvez récupérer l'entrée PNG d'origine de cette façon, c'est-à-dire que vous pouvez créer des fichiers PNG avec des données d'image identiques.
Notez le
-pix_fmt rgb24pour le test x264. Le décodeur h.264 de ffmpeg produit une sortie gbrp (planaire, non compressé), donc les bits sont les mêmes, mais dans un ordre différent. Le "conteneur" framemd5 n'impose aucune sorte de restrictions de format, mais vous n'obtiendrez le même md5 que si les bits sont disposés de la même manière. Je viens de regarder ce que ffmpeg a dit qu'il utilisait pour un fmt pix quand je l'ai alimenté en PNG, puis je l'ai utilisé comme argument-pix_fmtpour décoder. Soit dit en passant, c'est la raison pour laquelle vlc ne lira pas les fichiers RVB h.264 (jusqu'à la prochaine version ou les versions nocturnes actuelles): il ne prend pas en charge le format de pixel gbrp.Pour votre utilisation
libx264, nonlibx264rgb. Vous n'avez pas besoin d'installer une version RVB de x264, la bibliothèque réelle prend en charge les deux. C'est juste ffmpeg qui l'a implémenté comme deux encodeurs nommés différemment. Je pense que s'ils ne l'avaient pas fait, le comportement par défaut serait de laisser l'entrée rgb en tant que rgb et de fonctionner très lentement tout en produisant une sortie de débit binaire beaucoup plus élevée pour la même qualité. (vous devez toujours parfois utiliser-pix_fmt yuv420psi vous le souhaitez420au lieu de la444sortie h.264.Sauf si vous créez des fichiers pour un stockage à long terme, utilisez toujours le
-preset ultrafastx264 sans perte. Plus de cadres de référence et de recherche de mouvement font à peine la différence pour le matériel sans perte, pour le matériel non animé avec du bruit. CABAC prend une énorme quantité de CPU à des débits sans perte, même pour décoder. Utilisez uniquement à des fins d'archivage, pas de fichiers à gratter. (ultra-rapide désactive CABAC). CABAC permet des économies de 10 à 15% sur le débit binaire.Si vous avez besoin que chaque image soit une image clé, définissez
-keyint 1. Ensuite, un logiciel de montage vidéo qui ne veut couper que des images clés ou des e / s ne vous limitera pas.Pour répondre à la question d'origine: voici ce que vous devez faire pour lancer des fichiers temporaires tout en essayant les choses par étapes (par exemple, un désentrelacement lent, enregistrer une sortie sans perte avant d'essayer d'autres choses):
ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkvSi vous avez vraiment besoin de votre sortie dans des fichiers image que vous pouvez modifier avec des outils d'image fixe, alors assurez-vous de décoder en png. Vous ne perdrez rien de plus que peut-être le moins significatif des 8 bits de pour chacune des valeurs Y, Cb et Cr pour chaque pixel.
x264 sort VRAIMENT bien dans ce domaine car il y a beaucoup de cadres noirs avec un peu de texte, un fondu entrant et sortant, et une similitude parfaite entre de grandes zones de nombreux cadres, dont il parvient à profiter même avec
-preset ultrafast. En direct, je vois toujours x264 à la moitié de la taille de fichier de ffvhuff (yuv420).Pour tous ceux qui sont curieux: le codage RVB sans perte à temps processeur élevé avait (noyau x264 144 r2525):
Notez la fraction très élevée de trames p pondérées, ainsi que la fraction vraiment élevée de saut de macroblocs. Chaque transition de scène est un fondu, pas une coupure, et x264 profite si vous lui donnez le temps CPU pour comprendre comment.
autres notes (codecs avec perte pour l'édition):
Pour le défilement avant / arrière dans les clips, les codecs intra-seuls sont généralement privilégiés (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). J'imagine que l'AVC ordinaire avec des GOP courts (1/2 à 1 sec) gommage assez bien aussi, tant que le logiciel sait ce qu'il fait (décoder le cadre I le plus proche lors du nettoyage rapide, décoder dans le GOP pour accéder à une inter-image si vous avez suffisamment zoomé sur une chronologie pour que cela soit nécessaire).
J'ai publié des choses négatives à ce sujet et https://video.stackexchange.com/ à propos de pro-res, comme "quel est l'intérêt si c'est une compression plus lente et pire qu'un codec sans perte", mais il a des fonctionnalités intéressantes. Apple dit qu'il peut décoder à demi-résolution en utilisant aussi peu que 1/3 du temps CPU de décodage complet.
L'implémentation des prores de ffmpeg n'est probablement pas aussi optimisée pour la vitesse que celle d'Apple, c'est pourquoi mes tests avec ffmpeg l'ont rendu lent. Cela ne vaut probablement pas la peine d'être utilisé si vous disposez d'un flux de travail de logiciel gratuit avec des outils basés sur ffmpeg, mais cela peut valoir la peine d'essayer si vous utilisez un logiciel commercial.
Je ne fais pas beaucoup de montage vidéo, principalement de l'encodage, donc je n'ai pas une bonne idée des tests qui seraient appropriés pour les codecs comme les prores. Je suppose que mjpeg serait peut-être une bonne alternative rapide, si le short-GOP x264 ne fonctionne pas bien. Il existe des implémentations accélérées asm de jpeg dans les distributions Linux, et c'est un codec assez simple. Vous pouvez augmenter ou diminuer la qualité au besoin pour comparer la qualité et la taille du fichier + la vitesse d'encodage / décodage. C'est ancien, mais si vous voulez un codec intra-uniquement très rapide, il pourrait battre x264.
Pour x264, j'essaierais quelque chose comme
x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode(Intra-seulement, sans aucun des autres trucs qui sont--avcintra-classdéfinis.) Remarquesuperfast(sans CABAC), oufaster, ceultrafastn'est probablement pas le meilleur pour un fonctionnement avec perte. Je pense que l'ultra-rapide perd beaucoup de qualité sans être beaucoup plus rapide. La qualité inférieure (crf plus élevée) que vous utilisez, plus il vaut la peine de passer un peu plus de temps CPU à trouver un meilleur encodage. Une grande partie de cela n'est probablement pas pertinente avec une taille GOP = 1, cependant.Avec une taille GOP> 1, si vous lancez autant de bits au codage qu'une meilleure inter-prédiction ne sauvera pas beaucoup de bits lors de l'encodage des résidus (car le bruit / le grain / les changements subtils entre les images sont préservés très précisément), alors très rapide est probablement très bien. Sinon, avec
--keyint=30ou quelque chose, ce--preset veryfast --crf 12serait probablement intéressant.En théorie, la qualité à un paramètre CRF donné doit être constante d'un préréglage à l'autre. Si vous recherchez des fichiers plus petits (décodage plus rapide), il est judicieux d'échanger une certaine qualité et un certain temps d'encodage.
la source
Je pense que ffmpeg prend en charge la conversion en vidéo non compressée.
J'ai utilisé ffmpeg -i input.mp4 -vcodec rawvideo out.avi et le .avi résultant était à peu près la bonne taille de fichier. Le lecteur Windows Media ne semblait pas pouvoir le lire correctement mais il pouvait être lu par VirtualDub et je n'ai vu aucune perte de qualité d'image.
la source