J’ai posté un sujet dans la section « General Discussion », mais je me demande maintenant s’il ne s’agit pas d’un problème d’encodage matériel. Le sujet en question est ICI. Les seuls changements sur mon système sont les suivants :
Windows 8.1 a mis à jour le pilote Nvidia il y a quelques jours, mais cela n’a eu aucun effet direct.
Hier, j’ai complètement supprimé MCEBuddy 2.5.4, tous les fichiers de configuration, ainsi que .NET Framework 4 et 3.
J’ai réinstallé la version 2.4.11 et, pour la première fois sur cette machine, l’accélération matérielle a fonctionné : mes temps d’encodage sont maintenant inférieurs à une heure pour un film de 2 h, alors qu’avant ils étaient de 4 à 6 heures… sauf que mes images-clés passent maintenant toutes les 9 s au lieu de 0,8 s.
Aujourd’hui, je suis revenu à .NET Framework 3, puis à 4, sans changement de vitesse ni d’intervalle d’images-clés.
Je n’ai aucune idée de comment résoudre ce problème. Je ne peux plus monter certains de mes fichiers correctement avec des images-clés aussi espacées, mais j’adore le gain de vitesse énorme. J’utilise le même profil « MKV Normal Quality » qui indique un intervalle d’images-clés de 25, ce qui correspondait à peu près à 0,8 s sur une vidéo 30 FPS… mais j’obtiens désormais des images-clés dix fois plus espacées, sans savoir pourquoi.
Je recommanderais de télécharger la dernière version BETA, puis de joindre les journaux de cette version. Ainsi, nous pourrons établir une référence et voir ce qui se passe avant de revenir à des versions antérieures.
J’ai fait comme vous avez suggéré. J’ai installé la dernière version BETA et maintenant les images-clés sont à nouveau correctes, mais je suis de retour à des performances exécrables et des temps d’encodage très longs. Un fichier a pris 4 heures 47 minutes, un autre 3 heures 36 minutes, et un autre 2 heures 18 minutes. Avec la réinstallation de la version 2.4.11, je faisais en moyenne moins d’une heure par film, le plus long étant 1 heure 7 minutes… J’ai converti 41 films en 36 heures avec le mauvais intervalle d’images-clés cependant. Je vais inclure les journaux des trois que j’ai utilisés avec la version 2.5.5 pour convertir la nuit dernière.
Les journaux ont été utiles. La différence entre l’ancienne et la nouvelle version de MCEBuddy est que désormais la nouvelle version peut utiliser à la fois handbrake et ffmpeg pour effectuer des conversions matérielles avec NVidia.
Il existe de légères différences dans les paramètres de handbrake et ffmpeg pour le même profil qui, dans votre cas, semblent affecter votre encodeur matériel, il n’est pas capable de gérer les filtres vidéo de handbrake.
La solution est simple, il suffit d’ouvrir votre profil et de changer l’ordre de votre profil de
Eh bien, ce n’est pas une bonne solution non plus ; c’est mieux, mais c’est encore une perte de temps et d’électricité. Je réencode le même film qui a pris 4 h 47 min, le journal que j’ai déjà inclus dans mon message original. J’ai réinstallé la 2.4.11 en attendant votre réponse et le journal est ci-dessous.
Pour l’instant, j’utilise la 2.5.5 pour réencoder le même film et le temps estimé est plus de 4 fois supérieur à celui de la 2.4.11, et un peu moins de la moitié du temps nécessaire avant le changement de profil que vous avez suggéré.
Peut-on simplement corriger le problème d’intervalle de images-clés dans la 2.4.11 ? J’ai réencodé des films déjà faits et, si une différence de qualité existe, je ne la vois pas, mais cela prend 5 à 10 fois moins de temps ; je n’ai donc pas besoin d’une version plus récente si elle fonctionne aussi mal.
Pouvez-vous joindre les journaux avec le profil mis à jour afin que nous puissions comparer ce qui se passe entre les deux. S’ils utilisent tous les deux ffmpeg, il ne devrait pas y avoir de différence.
Je suis actuellement en train d’encoder le même film avec les modifications de profil que vous m’avez demandé de faire et cela prendra encore environ 2 heures, donc j’ajouterai ce journal une fois terminé
Vous n’avez pas modifié l’ordre dans votre fichier profiles.conf, donc il n’y aura aucun changement.
Vous devez ouvrir profiles.conf dans le répertoire de configuration de votre installation MCEBuddy, localiser votre profil (vous utilisez MKV Normal Quality) puis changer
order=handbrake,ffmpeg,mencoder
en
order=ffmpeg,handbrake,mencoder
Après avoir fait cela, enregistrez le fichier (gardez à l’esprit qu’il s’agit d’un dossier administratif, vous devrez peut-être copier le fichier sur votre bureau, le modifier puis le remettre). Une fois cela fait, relancez la conversion et elle sera aussi rapide que 2.4.11. Vous utilisez du matériel plus ancien GeForce GT 730 qui ne fonctionne pas bien avec les filtres handbrake et fonctionnerait mieux avec ffmpeg.
J’ai bien fait comme vous avez dit, mais je n’ai pas encore terminé de travail avec ces paramètres car cela prend plus de 4 fois plus de temps qu’avec la version 2.4.11. Je viens de vérifier le fichier de configuration et la modification y est bien présente. J’ajouterai ce journal dès que ce sera terminé dans une heure et demie.
OK, voici le journal pour le même film dont j’ai déjà mis deux autres journaux. Celui-ci inclut la modification du profil que tu m’as demandée de faire. Il était en passe de prendre environ 2 h 25 pour s’achever, soit environ deux fois plus qu’avec la version 2.5.5 téléchargée et installée, et environ 4,5 fois plus qu’avec la 2.4.11.
Très utile. La version 2.5.5 utilise une nouvelle version de ffmpeg qui nécessite un nouveau pilote pour nvidia. Votre pilote est trop ancien, c’est pourquoi l’opération échoue et bascule vers handbrake :
2020-06-16T16:53:27 MCEBuddy.AppWrapper.FFmpeg → [h264_nvenc @ 000000cbe0959800] Driver does not support the required nvenc API version. Required: 9.0 Found: 8.1
2020-06-16T16:53:27 MCEBuddy.AppWrapper.FFmpeg → [h264_nvenc @ 000000cbe0959800] The minimum required Nvidia driver for nvenc is 418.81 or newer
2020-06-16T16:53:27 MCEBuddy.AppWrapper.FFmpeg → 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
Vous pouvez donc soit mettre à jour votre pilote, soit copier la version d’ffmpeg de 2.4.11 et la placer dans le dossier ffmpeg de 2.5.5, cela devrait fonctionner. Idéalement, il vaut mieux mettre à jour vos pilotes.
J’installe le tout nouveau pilote sur le site de Nvidia en ce moment, mais s’il s’agit d’un problème de pilote, devrais-je essayer de donner la priorité à Handbrake après avoir installé le nouveau pilote graphique ?.. en 2.4.11, Handbrake a la priorité et fonctionne le plus rapidement sur mon système.
Le nouveau pilote Nvidia a ramené les temps d’encodage avec ffmpeg à environ une heure comme hier, je compresse un film différent de celui d’avant. Suggéreriez-vous d’essayer Handbrake en premier plutôt que ffmpeg comme priorité définie par défaut dans MCEBuddy ? Handbrake est-il supérieur à ffmpeg ?
Le seul problème, c’est que j’utilise maintenant la version 2.5.5 avec une bonne vitesse, mais la raison pour laquelle je suis venu ici n’est pas réglée… l’intervalle des images clés est encore incorrect, à presque 9 secondes.
Les trois films que j’ai encodés avec la version 2.5.5 tôt ce matin, avant que vous ne trouviez le problème avec ma vitesse, ont tous utilisé l’encodage logiciel et l’intervalle des images clés est correct… Chaque fichier que j’ai encodé avec l’accélération matérielle a un mauvais intervalle d’images clés, d’environ 9 secondes. Alors, comment corrigeons-nous cela ?
J’ai aussi remarqué qu’en analysant le fichier avec MediaInfo, le nombre d’images de référence affichées est de 1, et non 3 comme dans les paramètres. Est-ce que cela signifie que les configurations ne sont pas transmises correctement lorsque l’accélération matérielle est utilisée ?
J’ai modifié l’intervalle des images clés dans le fichier de configuration à 2 et le minimum à 2, mais il n’y a eu aucun changement dans l’intervalle des images clés du fichier encodé suivant.
Que faisons-nous maintenant ? L’encodage matériel semble faire ce qu’il veut et ignorer le fichier de configuration. Tous les fichiers encodés en matériel que j’ai vérifiés n’avaient qu’une seule image de référence alors que le fichier de configuration en spécifie 3, et l’intervalle des images clés est dix fois plus long que ce qu’il devrait être.
Cela rend les fichiers résultants inutilisables, peu importe la vitesse d’encodage.