nVidia n’est pas utilisé pour l’encodage H.265

MCEBuddy fonctionne bien. J’ai fait la mise à jour vers une nouvelle nVidia 2060. Pas d’amour pour l’encodage matériel. Qu’est-ce que j’ai oublié ?

INFORMATION> 2020-10-28T23:23:08 MCEBuddy.Transcode.Convert → Conversion avec Handbrake, type : HardwareOnly, gpu: {
“hardwareBrand”: “NVidia”, “codecType”: “Encoder”,
“hardwareCodecPresent”: true, “h265Codec”: true, “h264Codec”: true
}
INFORMATION> 2020-10-28T23:23:08 MCEBuddy.Transcode.ConvertWithHandbrake
→ Configuration des paramètres généraux de conversion : --decomb --loose-anamorphic --verbose=2
→ Configuration du PreDRC
→ Configuration des paramètres de nom de fichier d’entrée
→ Configuration des paramètres de conversion vidéo : --start-at duration:0 -e x265 --encoder-preset medium -q 26
→ Taille vidéo prédéfinie → False
→ Configuration des paramètres de recadrage
→ Recadrage vidéo automatique Handbrake
→ Vérification si un redimensionnement vidéo est requis
→ Configuration du rapport d’aspect si nécessaire
→ Configuration des paramètres de débit et de qualité
→ Configuration des paramètres de conversion audio : -E ffac3 -R auto -B 256 -D 0 -a 1,2,3,4,5
→ Sélection de la piste audio : -1
→ Laisser Handbrake choisir la meilleure piste audio
AVERTISSEMENT> 2020-10-28T23:23:08 MCEBuddy.Transcode.ConvertWithHandbrake
→ Impossible d’obtenir les détails des flux audio et vidéo, poursuite avec la sélection de langue audio par défaut
INFORMATION> 2020-10-28T23:23:08 MCEBuddy.Transcode.ConvertWithHandbrake
→ Configuration de l’ajustement du volume : 0,4 dB
→ Configuration du PostDRC
→ Configuration des canaux audio
→ Demande de limitation des canaux audio à 2
→ Configuration du nom de fichier de sortie
→ Remplacement des paramètres spécifiés par l’utilisateur
INFORMATION> 2020-10-28T23:23:08 MCEBuddy.Transcode.ConvertWithHandbrake
→ Conversion de la vidéo - Conversion principale
ERREUR> 2020-10-28T23:28:10 MCEBuddy.AppWrapper.Handbrake
→ L’encodage matériel semble avoir planté, aucune progression au cours des 300 dernières secondes.
Cela est probablement dû à un pilote d’affichage graphique instable. Essayez de mettre à jour ou d’utiliser un pilote d’affichage graphique stable.
Arrêt du processus.
ERREUR> → Erreur irrécupérable rencontrée. Processus probablement bloqué, arrêt en cours
ERREUR> 2020-10-28T23:28:10 [repeat]
ERREUR> 2020-10-28T23:28:11 [repeat]
ERREUR> 2020-10-28T23:28:11 [repeat]
ERREUR> 2020-10-28T23:28:11 [repeat]
ERREUR> 2020-10-28T23:28:11 [repeat]
ERREUR> 2020-10-28T23:28:12 [repeat]
ERREUR> 2020-10-28T23:28:12 [repeat]
ERREUR> 2020-10-28T23:28:12 [repeat]
ERREUR> 2020-10-28T23:28:12 [repeat]
ERREUR> → Processus bloqué, arrêt du processus
ERREUR> 2020-10-28T23:28:12 MCEBuddy.AppWrapper.Handbrake
→ L’encodage matériel semble avoir planté, aucune progression au cours des 300 dernières secondes.
Cela est probablement dû à un pilote d’affichage graphique instable. Essayez de mettre à jour ou d’utiliser un pilote d’affichage graphique stable.
Arrêt du processus.
ERREUR> 2020-10-28T23:28:12 MCEBuddy.Transcode.ConvertWithHandbrake → Échec de la conversion Handbrake
ERREUR> 2020-10-28T23:28:12 MCEBuddy.Transcode.ConvertWithHandbrake → Échec de la conversion de la vidéo
ERREUR> 2020-10-28T23:28:12 MCEBuddy.Transcode.Convert → Handbrake n’a pas converti avec succès, utilisation de la solution de secours si configurée
INFORMATION> 2020-10-28T23:28:12 MCEBuddy.Transcode.ConvertWithFfmpeg → Vérification du profil non pris en charge pour la combinaison conteneur/codec
INFORMATION> 2020-10-28T23:28:12 MCEBuddy.Transcode.Convert → Conversion avec FFMpeg, type : HardwareOnly, gpu: {
“hardwareBrand”: “NVidia”,
“codecType”: “Encoder”,
“hardwareCodecPresent”: true,
“h265Codec”: true,
“h264Codec”: true
}
INFORMATION> 2020-10-28T23:28:12 MCEBuddy.Transcode.ConvertWithFfmpeg → Configuration des paramètres généraux de conversion : -threads 0
→ Configuration du PreDRC
→ Configuration des paramètres de nom de fichier d’entrée
→ Configuration des paramètres de conversion vidéo : -ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec libx265 -preset medium -crf 26 -map 0:v -sn
→ Taille vidéo prédéfinie → False
→ Configuration des paramètres de recadrage
INFORMATION> 2020-10-28T23:28:12 MCEBuddy.VideoProperties.VideoInfo → Obtention des informations de recadrage via FFMpeg
AVERTISSEMENT> → Erreur de processus de détection de recadrage FFMpeg - nouvelle tentative avec MEncoder
ERREUR> → Aucune réponse du processus depuis 300 secondes, processus probablement bloqué - arrêt en cours
ERREUR> → Processus bloqué, arrêt du processus
AVERTISSEMENT> → Erreur de processus de détection de recadrage MEncoder - le recadrage ne sera pas effectué
INFORMATION> 2020-10-28T23:34:52 MCEBuddy.Transcode.ConvertWithFfmpeg
→ FFMpeg n’a trouvé aucun recadrage vidéo
→ Vérification si un redimensionnement vidéo est requis
→ Configuration du rapport d’aspect si nécessaire
→ Configuration des paramètres de débit et de qualité
→ Configuration des paramètres de conversion audio : -acodec ac3 -ab 256k -map 0:a
→ Sélection de la piste audio : -1
→ Laisser ffmpeg choisir la meilleure piste audio
→ Impossible d’obtenir les détails du flux audio, poursuite avec la sélection de langue audio par défaut
→ Configuration de l’ajustement du volume : 0,4 dB
→ Configuration du PostDRC
→ Configuration des canaux audio
→ Demande de limitation des canaux audio à 2
→ Configuration du nom de fichier de sortie
→ Remplacement des paramètres spécifiés par l’utilisateur
→ Conversion de la vidéo - Conversion principale
AVERTISSEMENT> → Échec de conversion Ffmpeg, nouvelle tentative avec GenPts
AVERTISSEMENT> 2020-10-28T23:48:48 MCEBuddy.Transcode.ConvertWithFfmpeg → Échec de conversion Ffmpeg avec décodeur matériel, nouvelle tentative sans décodeur matériel

La conversion se poursuit ensuite, mais sans accélération matérielle puisqu’elle revient à l’encodage CPU.
Des indices sur ce qu’il faut chercher quand j’augmente le niveau de détail des journaux ?

À partir des journaux :

ERROR> 2020-10-28T23:28:10 MCEBuddy.AppWrapper.Handbrake
–> L’encodage matériel semble avoir planté, aucune progression au cours des 300 dernières secondes.
Cela est probablement dû à un pilote d’affichage graphique instable. Essayez de le mettre à jour ou d’utiliser un pilote d’affichage graphique stable.

J’utilise le dernier pilote WHQL de nVidia. Je posterai plus tard la version exacte, et l’application GeForce Experience me dit que je suis à jour.

Malheureusement, la dernière version n’est pas toujours la meilleure pour les pilotes graphiques. @RBoy a écrit de nombreux pilotes WHQL dans sa vie et a souvent mentionné qu’il ne faut pas mettre à jour les pilotes graphiques sauf si nécessaire, car les nouveaux pilotes introduisent souvent des bogues que la certification WHQL ne capture pas toujours.

Voir la liste des versions de pilotes recommandées, basées sur les retours de la communauté concernant les pilotes les plus stables pour l’encodage matériel :

Il semble que ce soit un problème de pilote, car la mise à jour suivante du pilote nVidia semble avoir résolu le problème. J’utilise le pilote version 457.30 avec une RTX2060. Je peux confirmer que le GPU est utilisé par MCEBuddy dans le moniteur de performance Windows du Gestionnaire des tâches.

Cependant, ce que je remarque, c’est que le GPU n’est utilisé que pendant la phase finale de transcodage et pas du tout pendant les phases de détection de publicités comskip ou de démultiplexage, seulement lors de la dernière étape de remultiplexage des pistes vidéo et audio dans le MKV. J’espérais que le GPU serait utilisé pour une plus grande partie du traitement. Cela dit, il traite définitivement cette dernière étape avec une amélioration d’environ 10x (~50 fps contre ~500 fps). La phase de démultiplexage prend toujours autant de temps. Aussi, l’exécution de Handbrake en standalone détecte et utilise également le GPU.