MISE À JOUR LE 3 AOÛT 2017 : Selon une réponse plus récente de l'utilisateur , ffmpeg a maintenant un support pour l'encodage VP9 via VAAPI. Je n'ai toujours pas le matériel nécessaire pour tester cela cependant, donc ma réponse sera d'une aide limitée. Je vais laisser ma réponse originale sur la façon d'encoder VP9 dans le logiciel ci-dessous.
Pour une raison quelconque, FFmpeg ne supporte pas l'encodage VP9 sur l'encodeur matériel QuickSync d'Intel, même s'ils supportent H.264 et HEVC. . Une recherche dans le dépôt de code source de FFmpeg montre qu'il ne s'agit même pas d'une désactivation, la fonctionnalité n'a tout simplement pas encore été implémentée. Mais si elle devient disponible à un moment donné dans le futur, elle devrait être utilisable d'une manière similaire aux autres encodeurs QuickSync : un commutateur comme -c:v vp9_qsv au lieu de -c:v libvpx-vp9 devrait faire l'affaire.
L'utilisation de la ligne de commande de FFmpeg est la même sur toutes les plateformes, avec la seule exception notable que je connaisse, les utilisateurs de Windows devant utiliser NUL au lieu de /dev/null pour la sortie lors de la première passe d'un codage à deux passes. Mais puisque vous faites un passage unique et sans perte, cela ne devrait pas vous affecter.
Si vous voulez accélérer vos encodages, la chose la plus évidente à essayer est de définir une valeur de vitesse d'encodage avec la fonction -speed interrupteur. Les valeurs recommandées sont des nombres de 0 à 4, 0 étant vraiment, vraiment lent (pensez à -preset placebo en x264 mais en pire) mais de haute qualité et 4 étant rapide tout en étant de qualité inférieure. ffmpeg utilise -speed 1 par défaut, ce qui est un bon compromis entre vitesse et qualité pour un encodage avec perte. Cependant, je viens de faire un test rapide de l'encodage sans perte avec différentes valeurs de vitesse et j'ai remarqué une réduction de 32% de la taille du fichier en passant de -speed 1 à -speed 0 avec un encodage sans perte. Le temps d'encodage a cependant triplé, donc c'est à vous de voir si l'utilisation de 0 en vaut la peine. Le fichier produit par -speed 4 n'était que de 1,1% plus grande que celle produite par -speed 1 mais il a été encodé 43% plus vite. Donc, je dirais que si vous faites du lossless et -speed 0 est trop lent, vous pouvez tout aussi bien utiliser -speed 4 .
Une autre amélioration importante des performances d'encodage consiste à activer le multi-threading avec l'option -threads libvpx n'utilise pas automatiquement plusieurs threads donc cela doit être défini manuellement par l'utilisateur. Vous devez également définir le nombre de colonnes de tuiles avec l'option -tile-columns interrupteur. Cette option permet à libvpx de diviser la vidéo en plusieurs tuiles et d'encoder ces tuiles en parallèle pour un meilleur multi-threading. Vous pouvez trouver les nombres recommandés pour le nombre de colonnes de tuiles et de threads dans la section "Recommandations sur les tuiles et les threads" du site web de Guide d'encodage VP9 de Google . Comme vous pouvez le constater, le nombre de threads utilisés augmente avec le nombre de tuiles, ce qui signifie qu'en fonction du nombre de cœurs de processeur disponibles, votre processeur peut ne pas être entièrement saturé lors de l'encodage de vidéos en basse résolution HD. Si vous encodez principalement des vidéos à basse résolution, vous devriez envisager d'encoder plusieurs fichiers en même temps.
Cependant, il y a encore une fois moyen d'accélérer l'encodage VP9 : le multi-threading dans une seule tuile de colonne qui peut être activé avec la fonction -row mt 1 . Au 4 avril (2017, bonjour les gens du futur), il ne fait pas partie d'une version publiée de libvpx mais sera très probablement dans libvpx 1.6.2. Si vous voulez l'essayer avant la prochaine version, vous devez compiler des versions git récentes de libvpx et ffmpeg à partir des sources. Il suffit de suivre Guide de compilation de FFmpeg pour la distro de votre choix, mais au lieu de télécharger et d'extraire une archive de version, faites git pull https://chromium.googlesource.com/webm/libvpx ではなく
Quant à la veryslow qui n'est utilisé que dans x264 et x265. libvpx utilise le préréglage -speed et en plus le -quality best , -quality good または -quality realtime pour définir le temps que l'encodeur est autorisé à passer à encoder une image. La valeur par défaut est -quality good parce que -quality best est si lent qu'il est inutilisable et -quality realtime est destiné à être utilisé pour des applications à délai de réponse critique, comme les appels vidéo et le livestreaming.
