La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: vivien le 16 mai 2016 à 09:39:08
-
Comment réduire le poids de ses vidéos en les ré-encodant en VP9 / Opus ?
Vous avez peut-être une caméra qui filme en full HD ou en 4k. C'est sympa, mais les fichiers sont très lourds. Si vous avez besoin de mettre vos vidéos sur un blog familial, la taille pose probablement problème. Vous souhaitez réduire sensiblement la taille (débit de 1 à 1,5 Mb/s), tout en gardant la qualité de Youtube en 720p ?
On va utiliser ffmpeg qui va réduire la résolution à 720p, encoder la vidéo en VP9 (le codec le plus efficace supporté par les navigateurs web) et l'audio avec le codec Opus, le codec audio le plus efficace)
Installation : sudo apt install ffmpeg libavcodec-extra
Voici la ligne de commande à utiliser pour une compression en une seule passe :
ffmpeg -i source.mp4 -vf scale=1280:-1 -c:v libvpx-vp9 -b:v 0 -crf 40 -threads 4 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 64k -f webm destination.webm
Détail des options utilisées :
-i source.mp4 : fichier source
-vf scale=1280:-1 : Option pour changement la résolution => résolution cible (-1 garde le ratio rappel: 1920×1080 = 1280×720 = 16/9)
-c:v libvpx-vp9 : Codec vidéo de destination. libvpx-vp9 encode en VP9.
-b:v 0 : Débit maximum, pour une qualité constante (déterminée par crf), il faut le mettre à 0. Pour mettre une limite haute du débit à 1 Mb/s c'est -b:v 1000K
-crf 40 : Qualité perçue : la valeur CRF peut être entre 0 et 63. Des valeurs plus faibles signifient une meilleure qualité. 32 à 45 = iso Youtube. Si on souhaite encoder à débit fixe, il ne faut pas mettre cette option. Il est toutefois plus pertinent d'encoder à une qualité perçue fixe, plutôt que un débit fixe.
-threads 4 : Encodage sur 4 threads en parallèle. SI vous avez 8 cœurs physiques, vous pouvez utiliser -threads 8. Sans cette option, l'encodage n'utilise qu'un seul cœur et est malheureusement assez lent.
-speed 1 : Compromis entre vitesse de compression et qualité. speed 1, la valeur par défaut, produit qualité de sortie très proche de la vitesse speed 0, mais speed 1 encode généralement beaucoup plus vite que speed 0. Pour un encodage en deux passe, on speed 4 est un bon compromis pour la première passe. Les valeurs possible vont de -16 a 16.
-tile-columns 6 -frame-parallel 1 : Permet de créer un ficher vidéo qui pourra être lu en multi-threaded (coté client). -tile-columns 6 -frame-parallel 1 sont les valeurs par défaut.
-auto-alt-ref 1 : Le décodeur va choisir en fonction du contenu quand prendre une image de référence (image fixe complètement décrite, alors que les autres images codent ce qui a changé par rapport à l'image précédente ou à l'image suivante). concrètement a chaque changement de plan, une image de référence sera insérée.
-lag-in-frames 25 : nombre d'images à regarder vers l'avenir pour l'encodage , 0 aucune limite. [min 0 - max 25]
-c:a libopus : Codec audio de destination (avec libopus il y a par déault -vbr on -compression_level 10)
-b:a 64k : Débit cible 64 Kb/s (Youtube encode dans 3 débits théoriques : 50 Kb/s , 70 Kb/s et 160 Kb/s en réalité on est un peu en dessous).
-f webm : Force le format de sortie en webm
destination.webm : fichier destination compressé en VP9 / Opus
Voici les lignes de commande à utiliser pour une compression en deux passes (permettant d'avoir une meilleure qualité pour un même débit) :
ffmpeg -i source.mp4 -vf scale=1280:-1 -c:v libvpx-vp9 -pass 1 -b:v 0 -crf 40 -threads 4 -tile-columns 6 -frame-parallel 1 -an -f webm -y /dev/null
ffmpeg -i source.mp4 -vf scale=1280:-1 -c:v libvpx-vp9 -pass 2 -b:v 0 -crf 40 -threads 4 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 64k -f webm destination.webm
Détail des nouvelles options utilisées :
-pass 1 : Le numéro de passe (1 ou 2). Les statistiques de la vidéo de la première passe sont enregistrées dans un fichier journal (PREFIX-N.log où N est un nombre spécifique au flux de sortie).
-an : désactiver audio qui est inutile pour la première passe
/dev/null : la sortie NULL sous Linux/ Unix / MacOS X pour ne pas enregistrer le fichier vidéo généré. Sous Windows, il faut utiliser NUL
-y : na pas avertir que le fichier existe déjà (sans ça, on a la question "File '/dev/null' already exists. Overwrite ?")
J'ai testé la compression du flux 1080p H.264 en 720p VP9/Opus de deux vidéos :
- PSY - GANGNAM STYLE => Il faut mettre la qualité à 43 (-crf 43) pour avoir un fichier 720p VP9 de la taille de celui de Youtube
- Michael Jackson - Hold My Hand => Il faut mettre la qualité à 33 (-crf 33) pour avoir un fichier 720p VP9 de la taille de celui de Youtube
Youtube n'encode pas à débit constant (les vidéos qui bougent beaucoup utilisent plus de débit que les vidéo avec une image fixe) mais pas uniquement à qualité constante, vu que quand on choisit ce mode, on voit que le paramètre qualité varie sensiblement pour avoir une taille iso Youtube.
Quels sont les navigateurs qui supportent VP9 + Opus ?
- Google Chrome / Chromium
- Opéra
- Mozilla Firefox (sous Linux depuis Firefox 43 et sous Windows, à partir de Firefox 47, qui sort le 7 juin 2016)
- Microsoft Edge (a partir de Windows 10 anniversary update, qui sort fin juillet 2016)
- Android 5, sortie en 2014 mais pas encore sur tous les téléphones.
Tous les processeurs, même ceux qui ont 8an d'age, arrivent à décoder logiciellement le 720p en VP9 / Opus
Safari gère Opus depuis 2012, mais par le codec VP9 :(
Comparatif des codec audios (enfin il manque l'AC3) :
(https://lafibre.info/images/tv/201501_comparatif_codec_audio.png)
-
ici des paramètres complèmentaires : http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide
et notamment -threads 8 -tile-columns 6 pour la vitesse
et -auto-alt-ref 1 -lag-in-frames 25 pour la qualité
-
Merci pour le lien.
Plusieurs paramètres sont des paramètres par défaut de libvpx-vp9 1.4.0:
- profile=0
- threads=0
- quality=good (deadline=1000000)
- cpu-used=1 (-cpu-used = -speed)
- frame-parallel=1
- tile-columns=6
- auto-alt-ref=1
- lag-in-frames=25
- aq-mode=0
- kf_max_dist=9999 (-g)
Par contre "-threads 4" est nécessaire pour l'avoir 4 threads. J'ai mis à jour mon premier message avec les optimisations proposées.
Faut-il faire une passe ou deux passe quand on encode à une qualité perçue fixe ? J'étais persuadé que la double passe était pour les encodage avec une limitation de débit (débit fixe ou qualité + débit maximum) mais non : il y a aussi un gain pour un encodage avec une qualité perçue fixe. J'imagine que c'est grâce à un meilleur placement des images de références (images i) et je suis étonné d'avoir un gain significatif.
J'ai testé une vidéo tout simple (non montée) et récente pour voir la qualité d'un encodage Youtube 720p VP9 en partant d'un flux 1080p H264.
https://www.youtube.com/watch?v=kt59iTM2ADc
- Fichier Youtube 1080p H.264 30images par secondes : 52,6 Mo
- Fichier Youtube 720p VP9 30images par secondes : 18,8 Mo
- Encodage 720p VP9 double passe qualité crf 40 depuis 1080p H.264 (lignes de commande plus haut) : 17,9 Mo
- Encodage 720p VP9 double passe qualité crf 39 depuis 1080p H.264 (lignes de commande plus haut) : 19,5 Mo
- Encodage 720p VP9 double passe qualité crf 33 depuis 1080p H.264 (lignes de commande plus haut) : 28,1 Mo
-
Compresser via une commande tous les fichiers de votre appareil photo (à exécuter la nuit)
Script bash pour compresser toutes les vidéos .MP4 du dossier où est exécuté le script et réduire leur résolution en 720p :
for i in *.MP4 ; do
((n++))
date '+===> %kh%M %Ssec: Vidéo N°'$n' Passe 1/2 '$i' => '${i/.MP4}'.webm'
ffmpeg -i "$i" -vf scale=1280:-1 -c:v libvpx-vp9 -pass 1 -b:v 0 -crf 40 -threads 4 -speed 4 -tile-columns 6 -frame-parallel 1 -an -loglevel warning -f webm -y /dev/null
date '+===> %kh%M %Ssec: Vidéo N°'$n' Passe 2/2 '$i' => '${i/.MP4}'.webm'
ffmpeg -i "$i" -vf scale=1280:-1 -c:v libvpx-vp9 -pass 2 -b:v 0 -crf 40 -threads 4 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 64k -loglevel warning -f webm -y "${i/.MP4}".webm
done
date '+===> %kh%M %Ssec: Encodage vidéo VP9 terminé'
Script bash pour compresser toutes les vidéos .MOV du dossier où est exécuté le script et réduire leur résolution en 720p :
for i in *.MOV ; do
((n++))
date '+===> %kh%M %Ssec: Vidéo N°'$n' Passe 1/2 '$i' => '${i/.MOV}'.webm'
ffmpeg -i "$i" -vf scale=1280:-1 -c:v libvpx-vp9 -pass 1 -b:v 0 -crf 40 -threads 4 -speed 4 -tile-columns 6 -frame-parallel 1 -an -loglevel warning -f webm -y /dev/null
date '+===> %kh%M %Ssec: Vidéo N°'$n' Passe 2/2 '$i' => '${i/.MOV}'.webm'
ffmpeg -i "$i" -vf scale=1280:-1 -c:v libvpx-vp9 -pass 2 -b:v 0 -crf 40 -threads 4 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 64k -loglevel warning -f webm -y "${i/.MOV}".webm
done
date '+===> %kh%M %Ssec: Encodage vidéo VP9 terminé'
Les fichiers traités sont numérotés (pour estimer où en est le script) et l'heure affichée à chaque étape.
J'ai rajouté -loglevel warning pour n'afficher que les avertissement / erreurs.
En cas de fichier destination déjà existant, le fichier est supprimé (option -y)
-
Deux petits commentaires:
Voici les lignes de commande à utiliser pour une compression en deux passes (permettant d'avoir une meilleure qualité pour un même débit)
Le double passe n'est utile que si tu as des contraintes de bitrate à respecter
Sinon, le vbr est ce qui te donne le meilleur résultat
-crf 40 : Qualité perçue : la valeur CRF peut être entre 0 et 63. Des valeurs plus faibles signifient une meilleure qualité. 32 à 45 = iso Youtube. Si on souhaite encoder à débit fixe, il ne faut pas mettre cette option. Il est toutefois plus pertinent d'encoder à une qualité perçue fixe, plutôt que un débit fixe.
C'est vraiment le crf utilisé par youtube ? Il est un peu .. viril, disons
-
Perso je les upload brut sur youtube en privé. puis ensuite les download dans la résolution et codec (vp9 ou h264) qui m’intéressent grace a youtube-dl.
-
Mes vidéos sur Youtube (peu de vues) n'ont pas de VP9 :
$ youtube-dl -F https://www.youtube.com/watch?v=dgHNWfwE3mM
[youtube] dgHNWfwE3mM: Downloading webpage
[youtube] dgHNWfwE3mM: Downloading video info webpage
[youtube] dgHNWfwE3mM: Extracting video information
[youtube] dgHNWfwE3mM: Downloading MPD manifest
[youtube] dgHNWfwE3mM: Downloading MPD manifest
[info] Available formats for dgHNWfwE3mM:
format code extension resolution note
140 m4a audio only DASH audio 130k , m4a_dash container, mp4a.40.2@128k (44100Hz)
160 mp4 256x144 DASH video 108k , avc1.4d400b, 25fps, video only
133 mp4 426x240 DASH video 242k , avc1.4d400c, 25fps, video only
134 mp4 640x360 DASH video 604k , avc1.4d401e, 25fps, video only
135 mp4 854x480 DASH video 1155k , avc1.4d4014, 25fps, video only
136 mp4 1280x720 DASH video 2310k , avc1.4d4016, 25fps, video only
137 mp4 1920x1080 DASH video 4331k , avc1.64001e, 25fps, video only
36 3gp 320x? small , mp4v.20.3, mp4a.40.2
17 3gp 176x144 small , mp4v.20.3, mp4a.40.2@ 24k
5 flv 400x240 small , h263, mp3 @ 64k
43 webm 640x360 medium , vp8.0, vorbis@128k
18 mp4 640x360 medium , avc1.42001E, mp4a.40.2@ 96k
22 mp4 1280x720 hd720 , avc1.64001F, mp4a.40.2@192k (best)
https://www.youtube.com/watch?v=dgHNWfwE3mM
-
Effectivement ca a du changé avec le nombre de vue. Ca peut se comprendre vu les ressources cpu que ca prend pour convertir en vp9.
-
Deux petits commentaires:Le double passe n'est utile que si tu as des contraintes de bitrate à respecter
Moi aussi, je pensais ça.
Le site officiel recommande 2 passes : http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide
J'ai donc testé avec la vidéo Michael Jackson - Hold My Hand en source le 1080p H264 et en destination du VP9 720p avec la qualité 43
1 passe : 20,7 Mo
Ligne de commande :
ffmpeg -i source.mp4 -vf scale=1280:-1 -c:v libvpx-vp9 -b:v 0 -crf 43 -threads 4 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 64k -f webm destination.webm
2 passes : 17,8 Mo
Lignes de commande :
ffmpeg -i source.mp4 -vf scale=1280:-1 -c:v libvpx-vp9 -pass 1 -b:v 0 -crf 43 -threads 4 -speed 4 -tile-columns 6 -frame-parallel 1 -an -f webm -y /dev/null
ffmpeg -i source.mp4 -vf scale=1280:-1 -c:v libvpx-vp9 -pass 2 -b:v 0 -crf 43 -threads 4 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 -c:a libopus -b:a 64k -f webm destination.webm
Il y a donc un gain, même si je ne m'explique pas pourquoi. Le placement des images de référence est mieux optimisé ?
-
Hoh, c'est très intéressant ça
Je me note de faire des tests pour savoir si c'est spécifique au codec
Merci de l'info Vivien!
-
En théorie le type des images est choisi lors de la première passe et ne change plus ensuite.
-
Je ne sais plus trop pourquoi,vérifiez les changelog, mais j'ai eu à recompiler ffmpeg dernièrement.
-
Je vous donne le résultat : j'ai passé les 54 vidéos de mon bébé filmés principalement avec mon appareil photo ou des téléphones :
- H.264 1080p 30img/sec : 9,5 Go (176 Mo / vidéo)
- VP9 720p 30img/sec : 327 Mo (6 Mo / vidéo)
=> La taille est divisée par 50 en moyenne et la différence n'est pas perceptible quand on visionne la vidéo en 720p.
L'encodage a pris 3 heures, sur un Intel Core i3-4150 CPU @3.50GHz (processeur 2 cœurs HT)
Je ne m'attendais pas à un tel résultat, j'ai tout de suite pensé a cette vidéo ;D
https://www.youtube.com/watch?v=IbZ3h089GZg
-
J'ai fait un petit test avec une vidéo 1080p issue de mon appareil photo.
Ca demande tout de même pas mal de ressource pour obtenir une vitesse d'encodage correcte.
J'ai fait le test avec un serveur dédié chez ovh que je possède, avec un xeon D-1520 (je ne sais absolument pas ce qu'il vaut...) et bien ca tournait à 1 FPS.
Sur mon NUC (i5-5250u) qui est loin d'être un PC dédié au calcul, j'avais 4-5 FPS.
Ca serait interessant de tester, j'ai vu que Amazon supportait désormais le VP9 sur le service AWS Elastic Trancoder.
-
Tiens, il est interessant de constater chez Youtube qu'en 3840x2160 le fichier VP9 est plus lourd que le H264.
Je ne suis pas en mesure de juger de la différence de qualité entre les deux, je ne suis pas équipé.
C:\youtube-dl>youtube-dl.exe -F https://www.youtube.com/watch?v=gEnkA5jR410
[youtube] gEnkA5jR410: Downloading webpage
[youtube] gEnkA5jR410: Downloading video info webpage
[youtube] gEnkA5jR410: Extracting video information
[youtube] gEnkA5jR410: Downloading MPD manifest
[info] Available formats for gEnkA5jR410:
format code extension resolution note
249 webm audio only DASH audio 56k , opus @ 50k (48000Hz), 2.85MiB
250 webm audio only DASH audio 78k , opus @ 70k (48000Hz), 3.62MiB
171 webm audio only DASH audio 121k , vorbis@128k (44100Hz), 6.38MiB
140 m4a audio only DASH audio 128k , m4a_dash container, mp4a.40.2@128k (44100Hz), 7.69MiB
251 webm audio only DASH audio 150k , opus @160k (48000Hz), 7.40MiB
278 webm 256x144 DASH video 117k , webm container, vp9, 30fps, video only, 5.64MiB
160 mp4 256x144 DASH video 123k , avc1.4d400c, 30fps, video only, 6.55MiB
133 mp4 426x240 DASH video 256k , avc1.4d4015, 30fps, video only, 14.51MiB
242 webm 426x240 DASH video 272k , vp9, 30fps, video only, 9.44MiB
243 webm 640x360 DASH video 493k , vp9, 30fps, video only, 17.69MiB
134 mp4 640x360 DASH video 640k , avc1.4d401e, 30fps, video only, 18.05MiB
244 webm 854x480 DASH video 960k , vp9, 30fps, video only, 31.01MiB
135 mp4 854x480 DASH video 1170k , avc1.4d401f, 30fps, video only, 38.10MiB
247 webm 1280x720 DASH video 1923k , vp9, 30fps, video only, 62.48MiB
136 mp4 1280x720 DASH video 2342k , avc1.4d401f, 30fps, video only, 75.52MiB
248 webm 1920x1080 DASH video 3383k , vp9, 30fps, video only, 111.43MiB
137 mp4 1920x1080 DASH video 4359k , avc1.640028, 30fps, video only, 141.98MiB
264 mp4 2560x1440 DASH video 10591k , avc1.640032, 30fps, video only, 351.25MiB
271 webm 2560x1440 DASH video 11802k , vp9, 30fps, video only, 308.19MiB
313 webm 3840x2160 DASH video 21217k , vp9, 30fps, video only, 794.71MiB
266 mp4 3840x2160 DASH video 23364k , avc1.640033, 30fps, video only, 752.21MiB
17 3gp 176x144 small , mp4v.20.3, mp4a.40.2@ 24k
36 3gp 320x180 small , mp4v.20.3, mp4a.40.2
5 flv 426x240 small , h263, mp3 @ 64k
43 webm 640x360 medium , vp8.0, vorbis@128k
18 mp4 640x360 medium , avc1.42001E, mp4a.40.2@ 96k
22 mp4 1280x720 hd720 , avc1.64001F, mp4a.40.2@192k (best)
-
La configuration minimum pour lire une vidéo VP9 / Opus :
- Google Chrome 27 (sortie le 21 mai 2013) et suivantes
- Mozilla Firefox 47 (sortie le 7 juin 2016) et suivantes
- Microsoft Edge 14 (sortie prévue fin juillet 2016) et suivantes
- Opera depuis 2014
- Android 5 (sortie sur en 3 novembre 2014 sur les Nexus et en 2015 sur les autres téléphones récents)
- VLC 2.1.3 (février 2014) et suivants
Les navigateurs qui ne peuvent pas lire une vidéo VP9 / Opus :
- Microsoft Edge 12/13 (versions actuellement en prod)
- Microsoft Internet Explorer (pas de prise en charge de VP9, ni d'Opus)
- Apple Safari (pas de prise en charge de VP9, ni d'Opus)
- Apple iOS (pas de prise en charge de VP9, ni d'Opus)
-
Je suis étonné de la politique d'Olympus : les appareils photo compact haut de gamme neuf ne proposent que deux formats pour l'enregistrement des vidéos :
- MOV (format Apple, non lisible sur Windows 7 sans installer un logiciel / codec)
- MJPEG (suite d'image JPEG, prend une place énorme)
J'ai utilisé la plus forte compression "MOV" en 720p d'Olympus :
=> 10min et 2sec de vidéo = 488 Mo en MOV 720p (48,8 Mo/min)
Après compression double-passe en VP9, on passe de 488 Mo (48,8 Mo/min) a... 22 Mo (2,2 Mo/min), sans changement de résolution !
La taille est divisée par plus de 22 sans perte de qualité !
J'ai encodé 16 vidéos MOV (4,7Go) => sans perte visible de qualité cela fait 212 Mo en VP9.
Durée de la compression double passe : 3 heures sur un Core i3-4150 @3.50GHz (toute la partie décodage .MOV se fait en utilisant un seul cœur)
-
Globalement, les APN ne compressent que très peu la vidéo (et la photo). Problème de ressources ? Manière d'éviter une compression destructrice ?
-
Probablement un peu des deux (et peut-être un peu d'optimisation des couts aussi).
-
il doit aussi y avoir un problème de dissipation de la chaleur que ca pourrait génerer.
Je crois me souvenir qu'à une époque pas si lointaine certains modèles d'APN très haut de gamme chauffaient tellement en mode vidéo qu'il ne pouvait enregistrer que pendant quelques minutes.
Et puis il doit y avoir aussi une politique vis à vis du traitement d'image qu'on peut faire derrière. C'est un peu comme le RAW versus le JPEG.
-
Suis je le seul qui n'arrive pas à avancer/reculer dans une vidéo encodée en vp9 avec ffmpeg?
-
Désolé, pour la latence de réponse.
Je n'ai pas le problème avec VP9, mais avec AV1, cf Tutoriel pour encoder AV1 et réduire une vidéo de 3 Go à 30 Mo ! (https://lafibre.info/tv-numerique-hd-3d/encoder-av1/)
Tu as testé cette solution ?
D'après https://ffmpeg.org/ffmpeg.html, -force_key_frames expr:gte(t,n_forced*5) pour une toutes les 5s (soit on fait comme YouTube en VP9, mais en acceptant un temps de seek plus long, soit il faudrait réduire pour tenir compte de la lourdeur du décodage).
Ah, OK :)
-
Edit commandes modifiées avec les solutions trouvées à la page suivante (rajout de -pix_fmt yuv420p)
J'ai un souci pour les vidéos crées depuis VirtualBox (version 6.0.14).
Il y a pas mal d'options, mais le codec est obligatoirement VP8. Ce n'est pas grave, je préfère que le PC perdre peu de temps à encoder en temps réel pour laisser le maximum de CPU pour le machine virtuelle.
Je règle donc la qualité vidéo au maximum, vu que je post-traiterais le fichier à posteriori.
Je me limite à 6 images par seconde, comme ça en visualisant les images à 30 images par seconde, je fais un accéléré de x5.
(https://lafibre.info/testdebit/ubuntu/201911_virtualbox_video_1.png)
Avec le post-traitement, tous les logiciels utilisés se sont révélés inefficaces, car VirtualBox ne met aucune image de référence : pour chaque image, il faut faire le calcul depuis le début de la vidéo et je n'ai réussi à faire avec me logiciels habituels (Avidemux ou OpenShot Video Editor n'arrivnet pas a traiter le fichier en raison d'absence de keyframes).
J'ai opté pour une méthode radicale : je transforme la vidéo en autant des milliers d'images :
Convertir une vidéo en x images .png :
ffmpeg -i video.webm image%d.png
Cela générera des fichiers image1.png, image2.png…etc dans le répertoire courant. Les formats supportés sont PGM, PPM, PAM, PGMYUV, JPEG, GIF, PNG, TIFF, SGI.
Cette opération fonctionne bien et les images sont plutôt de bonne qualité.
Cela me permet de facilement supprimer ce qui doit être supprimé ou édité.
Script bash pour diviser le nombre d'images d'une capture par 3 :
#!/bin/bash
i="1"
j="1"
while [ $i -lt "5621" ]
do
mv ./image$i.png ./image$j.png
i=$[$i+1]
j=$[$j+1]
mv ./image$i.png ./sauvegarde/
i=$[$i+1]
mv ./image$i.png ./sauvegarde/
i=$[$i+1]
done
Script bash pour supprimer les 290 premières images :
#!/bin/bash
i="290"
j="1"
while [ $i -lt "1908" ]
do
mv ./image$i.png ./image$j.png
i=$[$i+1]
j=$[$j+1]
done
Ensuite je fais l'opération dans l'autre sens pour récupérer une vidéo bien faite.
Convertir une série d'images en vidéo VP9 :
ffmpeg -f image2 -framerate 30 -i image%d.png -c:v libvpx-vp9 -pix_fmt yuv420p -b:v 0 -crf 30 -threads 4 -speed 1 -tile-columns 6 -frame-parallel 1 -auto-alt-ref 1 -lag-in-frames 25 video-source.webm
Rajouter un fichier audio à la vidéo :
ffmpeg -i audio-source.mp3 -vn -c:a libopus -b:a 160k -f webm audio-source.webm
ffmpeg -i video-source.webm -i audio-source.webm -c copy -map 0:0 -map 1:0 destination.webm
Le résultat est ce fichier vidéo VP9 : (nouvelle vidéo qui est parfaite, depuis le rajout de -pix_fmt yuv420p)
https://lafibre.info/videos/materiel/201911_dell_poweredge_r330_maj.webm
Il est plus ou moins lisible selon les les lecteurs. Firefox le refuse directement "La vidéo ne peut être visionnée, car le fichier est corrompu", Chrome et VLC cela passe plutôt bien, pour d'autres lecteur, les couleurs sont déformées alors que je n'ai pas eu d'erreur pendant la compression du fichier VP9 :
(https://lafibre.info/testdebit/ubuntu/201911_virtualbox_video_2.png)
(https://lafibre.info/testdebit/ubuntu/201911_virtualbox_video_3.png)
J'ai testé plusieurs option d'encodage et plusieurs niveau de qualité: cela ne change rien.
J'ai mis dans ce fichier compressé 201911_dell_poweredge_r330_maj.tar.xz (https://lafibre.info/videos/materiel/201911_dell_poweredge_r330_maj.tar.xz) les source de la vidéo : les 5769 images.png et le fichier audio source au format .mp3 (musique Creative Commons).
-
Edit: commandes d'origine modifiées avec les solutions détaillées dans les messages ci-dessous.
C'est un peu hors-sujet, mais je rajouter le tutoriel pour le faire en H.264.
Convertir une vidéo en x images .png :
ffmpeg -i source.webm image%d.png
Cela générera des fichiers image1.png, image2.png…etc dans le répertoire courant. Les formats supportés sont PGM, PPM, PAM, PGMYUV, JPEG, GIF, PNG, TIFF, SGI.
Convertir une série d'images en vidéo H.264 :
ffmpeg -f image2 -framerate 30 -i image%d.png -c:v libx264 -pix_fmt yuv420p -preset veryslow -profile:v high -level:v 4.0 -crf 20 video-source.mp4
Options de l'encodeur libx264 :
-pix_fmt yuv420p : Certains lecteurs pourraient ne pas être en mesure de gérer le résultat sans un sous-échantillonnage de chrominance 4:2:0 (https://fr.wikipedia.org/wiki/Sous-%C3%A9chantillonnage_de_la_chrominance#4:2:0)
-preset veryslow : Permet d'avoir une compression plus forte pour une même qualité (au prix d'un encodage plus long)
-profile:v high -level:v 4.0 : Les différents niveaux sont expliqués sur https://en.wikipedia.org/wiki/Advanced_Video_Coding
- -level:v 4.0 : Résolution 1920x1080 à 30 images par seconde ou inférieur / résolution 12180x720 à 60 images par seconde ou inférieur
- -level:v 4.1 : Idem level 4.1, mais avec un débit qui dépasse 20 Mb/s
- -level:v 4.2 : Résolution 1920x1080 à 60 images par seconde
-crf 20 : qualité d'image élevée
Gestion du nb d'image par secondes :
-framerate : concerne la source
-r : concerne la destination
Pour faire une vidéo à un débit de 25 images/seconde, mais avec une source à 1 image par seconde - chaque image est dupliquée 25 fois :
ffmpeg -f image2 -framerate 1 -i image%d.png -c:v libx264 -pix_fmt yuv420p -preset veryslow -profile:v high -level:v 4.0 -crf 20 -r 25 video-source.mp4
Rajouter un fichier audio AAC à la vidéo :
ffmpeg -i audio-source.mp3 audio-source.wav
ffmpeg -i audio-source.wav -c:a aac -b:a 160k audio-source.m4a
ffmpeg -i video-source.mp4 -i audio-source.m4a -c copy -map 0:0 -map 1:0 destination.mp4
Monter le son de 6 décibels sans ré-encoder la vidéo :
ffmpeg -i source.mp4 -vcodec copy -af "volume=6dB" destination.mp4
Le résultat la aussi n'est pas lisible avec Firefox, mais cela passe bien avec les autres lecteurs :
https://lafibre.info/videos/materiel/201911_dell_poweredge_r330_maj.mp4
Retour de ffmpeg :
$ ffmpeg -f image2 -framerate 30 -i image%d.png -c:v libx264 -crf 20 destination.mp4
ffmpeg version 4.1.4-1build2 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9 (Ubuntu 9.2.1-4ubuntu1)
configuration: --prefix=/usr --extra-version=1build2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
WARNING: library configuration mismatch
avcodec configuration: --prefix=/usr --extra-version=1build2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared --enable-version3 --disable-doc --disable-programs --enable-liblensfun --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libtesseract --enable-libvo_amrwbenc
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Input #0, image2, from 'image%d.png':
Duration: 00:03:12.30, start: 0.000000, bitrate: N/A
Stream #0:0: Video: png, rgb24(pc), 1024x768, 30 fps, 30 tbr, 30 tbn, 30 tbc
Stream mapping:
Stream #0:0 -> #0:0 (png (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 0x56078b55d400] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x56078b55d400] profile High 4:4:4 Predictive, level 3.1, 4:4:4 8-bit
[libx264 @ 0x56078b55d400] 264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=20.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'destination.mp4':
Metadata:
encoder : Lavf58.20.100
Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv444p, 1024x768, q=-1--1, 30 fps, 15360 tbn, 30 tbc
Metadata:
encoder : Lavc58.35.100 libx264
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
frame= 5769 fps=142 q=-1.0 Lsize= 2908kB time=00:03:12.20 bitrate= 124.0kbits/s speed=4.72x
video:2840kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.398931%
[libx264 @ 0x56078b55d400] frame I:33 Avg QP: 8.86 size: 15981
[libx264 @ 0x56078b55d400] frame P:1495 Avg QP:12.61 size: 1146
[libx264 @ 0x56078b55d400] frame B:4241 Avg QP:15.46 size: 157
[libx264 @ 0x56078b55d400] consecutive B-frames: 1.6% 0.9% 0.9% 96.7%
[libx264 @ 0x56078b55d400] mb I I16..4: 91.6% 0.0% 8.4%
[libx264 @ 0x56078b55d400] mb P I16..4: 3.8% 0.0% 0.3% P16..4: 1.0% 0.2% 0.1% 0.0% 0.0% skip:94.6%
[libx264 @ 0x56078b55d400] mb B I16..4: 0.0% 0.0% 0.0% B16..8: 1.9% 0.0% 0.0% direct: 0.1% skip:97.9% L0:64.8% L1:34.8% BI: 0.3%
[libx264 @ 0x56078b55d400] coded y,u,v intra: 6.5% 1.0% 1.0% inter: 0.1% 0.1% 0.0%
[libx264 @ 0x56078b55d400] i16 v,h,dc,p: 39% 59% 2% 0%
[libx264 @ 0x56078b55d400] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 30% 33% 20% 2% 2% 2% 6% 3% 3%
[libx264 @ 0x56078b55d400] Weighted P-Frames: Y:2.2% UV:2.1%
[libx264 @ 0x56078b55d400] ref P L0: 43.2% 6.7% 40.4% 8.9% 0.9%
[libx264 @ 0x56078b55d400] ref B L0: 42.7% 56.1% 1.2%
[libx264 @ 0x56078b55d400] ref B L1: 98.0% 2.0%
[libx264 @ 0x56078b55d400] kb/s:120.97
-
Le fichier crée par ffmpeg est lisible avec divers logiciels de lecture vidéo et le navigateur Chromium, mas pas Firefox.
Twitter refuse de l'importer, donc je pense bien que cela doit être une erreur dans ma ligne de commande ffmpeg
(https://lafibre.info/testdebit/ubuntu/201911_virtualbox_video_4.png)
-
Essaie avec "-profile:v high -level:v 4.1" pour voir.
-
Alors c'est radical: ffmpeg refuse de faire la vidéo avec ces paramètres.
J'ai l'erreur suivante :
[libx264 @ 0x56220f3eaa00] Error setting profile high.
[libx264 @ 0x56220f3eaa00] Possible profiles: baseline main high high10 high422 high444
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!
La ligne de commande et le retour complet : (c'est le ffmpeg des dépôts Ubuntu 19.10)
$ ffmpeg -f image2 -framerate 30 -i image%d.png -c:v libx264 -profile:v high -level:v 4.1 -crf 20 destination.mp4
ffmpeg version 4.1.4-1build2 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9 (Ubuntu 9.2.1-4ubuntu1)
configuration: --prefix=/usr --extra-version=1build2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
WARNING: library configuration mismatch
avcodec configuration: --prefix=/usr --extra-version=1build2 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared --enable-version3 --disable-doc --disable-programs --enable-liblensfun --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libtesseract --enable-libvo_amrwbenc
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
Input #0, image2, from 'image%d.png':
Duration: 00:03:12.30, start: 0.000000, bitrate: N/A
Stream #0:0: Video: png, rgb24(pc), 1024x768, 30 fps, 30 tbr, 30 tbn, 30 tbc
Stream mapping:
Stream #0:0 -> #0:0 (png (native) -> h264 (libx264))
Press [q] to stop, [?] for help
x264 [error]: high profile doesn't support 4:4:4
[libx264 @ 0x56220f3eaa00] Error setting profile high.
[libx264 @ 0x56220f3eaa00] Possible profiles: baseline main high high10 high422 high444
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!
J'ai mis dans ce fichier compressé 201911_dell_poweredge_r330_maj.tar.xz (https://lafibre.info/videos/materiel/201911_dell_poweredge_r330_maj.tar.xz) les source de la vidéo : les 5769 images.png et le fichier audio source au format .mp3 (musique Creative Commons).
-
Pour le coup la vraie erreur est "x264 [error]: high profile doesn't support 4:4:4". Du même coup ça nous donne l'explication de pourquoi certains outils/sites peinent à traiter la vidéo produite sans ces options.
Ajoute l'option "-pix_fmt yuv420p".
Un peu de lecture pour la culture : https://fr.wikipedia.org/wiki/Sous-%C3%A9chantillonnage_de_la_chrominance.
-
Merci, cela fonctionne parfaitement et le fichier est vraiment de toute petite taille.
Pourquoi forcer le profil 4.1 ?
Le profil 4.2 n'est pas plus intéressant ? (cela semble plutôt bien supporté aujourd'hui, sur les iPhone, à partir de l'iPhone 5s)
J'ai comparé, mon fichier fait la même taille que ce soit en profil 4.0 , profil 4.1 ou profil 4.2.
Du coup coté VP9, cela doit être la même cause de pb ?
-
Pourquoi forcer le profil 4.1 ?
A l'époque c'était le plus compatible avec le décodage matériel mais aujourd'hui c'est potentiellement moins un problème.
Le profil 4.2 n'est pas plus intéressant ? (cela semble plutôt bien supporté aujourd'hui, sur les iPhone, à partir de l'iPhone 5s)
L'intérêt du level 4.2 c'est qu'il permet le full HD à 60 fps ce que ne permet pas le level 4.1.
J'ai comparé, mon fichier fait la même taille que ce soit en profil 4.0 , profil 4.1 ou profil 4.2.
C'est que tu n'as pas atteint les limites du profil 4.0 avec cette source et les paramètres utilisés.
Du coup coté VP9, cela doit être la même cause de pb ?
Je connais moins bien le VP9 mais c'est très probable.
Pour le x264, une autre option intéressant est "-preset:v" pour changer les paramètres d'encodage en fonction du ratio vitesse/qualité ou vitesse/taille du fichier recherché.
-
Merci, les différents niveaux sont expliqués sur https://en.wikipedia.org/wiki/Advanced_Video_Coding
Pas besoin level 4.2 si on ne dépasse pas résolutions 1,280×720 à 60 images par seconde ou 1,920×1,080 à 30 images par seconde.
Je connais moins bien le VP9 mais c'est très probable.
Je pensais il y a quelques années que le VP9 serait supporté par tous les appareils après quelques années, le temps que la nouveauté se diffuse.
Aujourd'hui je comprends qu'il n'y aura probablement jamais de support de VP9 sur iOS ou safari. Aujourd'hui un utilisateur sur 5 n'a pas de support du VP9 et il n'y a plus trop de progressions, sauf pour Edge quand il va passer sur la base Chromium.
AV1 sera sans doute la solution de convergence, mais dans 5 ans... aucun support matériel aujourd'hui.
Bref en attendant, H264 semble un bon compromis vu qu'il est supporté par presque l'intégralité du parc, malgré le fait qu'il soit propriétaire.
-
Pour le x264, une autre option intéressant est "-preset:v" pour changer les paramètres d'encodage en fonction du ratio vitesse/qualité ou vitesse/taille du fichier recherché.
Impressionnant.
Pour une même qualité :
- ultrafast : 5766 Ko
- superfast : 3118 Ko
- veryfast : 2396 Ko
- faster : 2247 Ko
- fast : 2210 Ko
- medium – default preset :2173 Ko
- slow : 2069 Ko
- slower : 1223 Ko
- veryslow : 1004 Ko
- placebo : 1040 Ko
-
Pour une même qualité :
Avec un bémol tout de même sur ce qu'on appelle "qualité" : à "crf" égal, il peut y avoir des variations de qualité perçue selon les paramètres utilisés.
C'est très difficile pour un encodeur d'avoir une notion de qualité qui colle à la perception humaine (voir tout ce qui tourne autour des métriques comme PSNR, SSIM, etc).