J’ai mis à jour le profil MP4 HEVC pour utiliser le GPU NVIDIA et ajouter des valeurs de saut anticipé. Avec ffmpeg en première position dans l’ordre, j’ai été surpris qu’il utilise HandbrakeCLI ? Pourquoi ?
[MP4 HEVC]
Description=HEVC dans MP4 (H.265/AAC) – NVENC + Forcer 720p + GOP d’environ 2 s fixé (correspond au script PS v7)
order=ffmpeg,handbrake
ffmpeg-general=-threads 0 -fflags +genpts+igndts -analyzeduration 100M -probesize 100M
ffmpeg-video=-ss 0 -c:v hevc_nvenc -preset p4 -tune ll -rc constqp -qp 28 -bf 0 -rc-lookahead 0 -spatial_aq 0 -temporal_aq 0 -g 60 -keyint_min 60 -sc_threshold 0 -strict_gop 1 -tag:v hvc1 -vf yadif=0:-1:1,hqdn3d,scale=w=‘min(1280,iw)’:h=‘min(720,ih)’:force_original_aspect_ratio=decrease:force_divisible_by=2 -map 0:v:0 -map 0:a? -c:a aac -b:a 160k -pix_fmt yuv420p -movflags +faststart -y
ffmpeg-audio=-acodec aac -ab 160k -map 0:a
ffmpeg-audioac3=-acodec aac -ab 160k -map 0:a
ffmpeg-ext=.mp4
ffmpeg-audiodelay=skip
handbrake-general=–decomb --loose-anamorphic --verbose=2 -f mp4
handbrake-video=–start-at duration:0 -e x265 --encoder-preset medium -q 26 --encopts “keyint=60:min-keyint=60:scenecut=0:bframes=0”
handbrake-audio=-E faac -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E faac -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-ext=.mp4
handbrake-audiodelay=skip
PreConversionCommercialRemover=true
On Patrol Live S04E69 2026-04-17-2058.mpg-Convert to MP4-2026-04-18T11-14-04.log (1.7 MB)
Il semble que MCEBuddy bascule sur Handbrake parce que votre commande ffmpeg échoue. Dans MCEBuddy, le paramètre order= indique au moteur quel outil essayer en premier, mais si cet outil renvoie un code d’erreur, il essaie automatiquement le suivant dans la liste.
Sur la base de votre configuration et du comportement courant de l’encodeur NVENC, voici les raisons probables pour lesquelles ffmpeg échoue :
1. Échec de l’encodage matériel (NVENC)
Vous utilisez -c:v hevc_nvenc. Si vos pilotes NVIDIA sont obsolètes, ou si un autre processus utilise toutes les sessions NVENC disponibles (les cartes grand public sont généralement limitées à 3-5 sessions simultanées), ffmpeg quittera avec une erreur.
2. Emplacement non valide de -ss 0
Dans votre ligne ffmpeg-video, vous avez -ss 0 tout au début. Bien que cela soit généralement acceptable, MCEBuddy gère souvent le “seeking” (recherche) en interne. Si ffmpeg rencontre un problème lors du mappage des flux ou de la recherche avec ces indicateurs spécifiques, il échouera.
3. Problèmes de chaîne de filtres
Vous avez une chaîne de filtres complexe :
yadif=0:-1:1,hqdn3d,scale=w='min(1280,iw)':h='min(720,ih)':force_original_aspect_ratio=decrease:force_divisible_by=2
Si le fichier source a un format de pixel inhabituel ou si yadif échoue à s’initialiser sur un flux spécifique, ffmpeg plantera et MCEBuddy passera à handbrake.
Comment vérifier :
- Vérifiez le journal : Ouvrez le fichier journal que vous avez joint et recherchez la chaîne
FFMPEG failed ou Return code. Il indiquera exactement quelle erreur ffmpeg a générée avant de passer à Handbrake.
- Tester la commande : Essayez de supprimer
-ss 0 et de simplifier les filtres -vf pour voir si ffmpeg démarre correctement.
- Vérification des pilotes : Assurez-vous d’avoir installé les derniers pilotes NVIDIA pour prendre en charge les indicateurs
-preset p4 et -tune ll, car ils font partie de la nouvelle API NVENC.
Si vous pouvez copier la section du journal où il est indiqué Running Task: FFMPEG Conversion, je pourrai vous donner le code d’erreur exact !