J’ai téléchargé et utilisé la dernière version 64 bits de MCEBuddy et, en convertissant un fichier de 1,6 Go, l’utilisation de la mémoire de handbrakecli.exe a grimpé à 100 % (sur 32 Go) jusqu’à ce que mon ordinateur se bloque. Je suis allé sur le site Web de HandBrake et j’ai téléchargé la version stable CLI 64 bits 1.0.7, et le problème a disparu pour le même fichier.
Merci de nous avoir prévenus. Pouvez-vous téléverser la vidéo originale qui vous a permis de détecter ce problème afin que nous puissions l’ajouter à notre suite de tests ? Aucune de nos vidéos de test actuelles n’a provoqué le problème, donc ce serait un bon ajout.
Vous trouverez les détails du serveur FTP de téléversement dans le message ReadMe
Malheureusement, j’ai déjà converti le fichier avec succès, donc j’ai supprimé l’original. Je joins mes profils et la configuration si cela peut aider.mcebuddy.conf (5,9 Ko)
profiles.conf (17,1 Ko)
Le profil utilisé était le premier. (MP4 Matthew’s Custom 16:9 Rip 23.976)
Merci. La version 1.0.7 est en cours de test et sera incluse dans la prochaine version s’il n’y a aucun problème.
Mise à jour à ce sujet, la dernière version stable de HandBrake 1.0.7 se bloque lors de l’utilisation de l’encodage Intel QuickSync avec certains fichiers de test. Nous ne pouvons donc pas encore mettre à jour HandBrake tant qu’ils n’ont pas résolu le problème. Je vais laisser ce ticket ouvert pour le moment. Si vous tombez sur un autre fichier présentant le problème de fuite mémoire, veuillez le télécharger sur le serveur.
J’ai compilé le dernier paquet HandBreak à partir de la branche git master. Les versions nocturnes ont encore quelques jours de retard et n’ont pas le correctif de son et QSV que cette version possède. handbreakCLI_20170716_b77f66d.zip
Dans la prochaine version majeure 2.4.8, nous prévoyons de revoir complètement l’encodage H/W pour améliorer les performances. Nous mettrons à jour la version de HandBrake dans la version 2.4.8.
J’ai rencontré cette erreur à nouveau. J’ai téléchargé mon profil, ma configuration et mon fichier vidéo dans le dossier ftp avec un fichier texte de description courte.
Nous pouvons reproduire le problème. Tout d’abord, mettez à niveau vers la dernière version nightly de HandBrake, cela résoudra le problème de mémoire à 100 %.
Deuxièmement, votre fichier est corrompu : il contient des EOF (end of file) au milieu du flux.
hb_ts_stream_decode - eof
Si vous enregistrez cela en OTA, alors vous avez un pilote ou un firmware de tuner TV défectueux qui insère des EOF au milieu du fichier.
J’ai également remarqué que vous avez supprimé le -ss 5 du profil remux et de votre profil personnalisé, ces paramètres sont là pour aider dans des situations comme celle-ci lorsque les débuts de fichiers sont corrompus. Essayez de le remettre et cela devrait fonctionner correctement.
Cette fois, ce n’était pas un OTA, mais un rip web. (D’où le retrait du -ss 5, je voulais garder les 5 premières secondes de la vidéo). Pourriez-vous m’aider à convertir mon profil HandBrake en profil ffmpeg avec le -ss 5 ? Mon idée est de les ordonner : HandBrake, ffmpeg, et d’avoir le HandBrake sans le -ss 5 et le ffmpeg avec. Ainsi, quand HandBrake échoue sur un cas comme celui-ci, il passe automatiquement au -ss 5 et je ne perds ces 5 secondes que quand c’est absolument nécessaire. J’ai déjà essayé de convertir vers ffmpeg, mais je ne le connais pas du tout aussi bien que HandBrake.
Cela a été corrigé dans la version BETA 2.4.8 d’aujourd’hui. Nous avons également ajouté le support du décodage matériel quicksync avec cette version et diverses autres optimisations de performance matérielle.
Ouais… je l’avais remarqué il y a un moment. J’ai simplement téléchargé la dernière version CLI et l’ai remplacée dans le répertoire d’installation de MCEBuddy. Cela a aussi réglé mon problème d’encodage matériel avec QuickSync et Intel HD Graphics 530.