Entonces, hay un par de cosas que debes tener en cuenta:
- El orden de tus codificadores:
order=handbrake,ffmpeg,mencoder
Esto significa que usará handbrake primero (QuickSync) y luego ffmpeg
(NvEnc/CUDA) para la codificación por hardware.
Tienes AMBOS, QuickSync y CUDA disponibles. En la versión anterior debido a
un error en MCEBuddy, si ambos se encontraban, usaría ffmpeg primero (cuda) y
luego handbrake (quicksync).
Con 2.4.9, si se encuentran ambos codificadores de hardware, usará el codificador
especificado por el usuario primero (en tu caso handbrake, es decir, quicksync).
Entonces, cuando comienza la codificación con QuickSync, el controlador de gráficos Intel falla.
2018-03-15T13:28:46 MCEBuddy.AppWrapper.Handbrake → Handbrake
falló, código de retorno distinto de cero
Esto probablemente se deba a un controlador de gráficos defectuoso; intenta instalar una de las
versiones de controlador recomendadas para que funcione tu codificador QuickSync.
Debido a que el codificador de hardware falla, MCEBuddy intenta usar la
versión de software del mismo codificador (es decir, handbrake) y esto funciona, y esto es
lo que estás viendo.
MCEBuddy no intenta el segundo codificador de hardware disponible antes de volver al
codificador de software; este es un problema conocido y está programado para corregirse
en la próxima versión.
Básicamente, te enfrentas a este problema porque tu sistema admite TANTO Cuda
como QuickSync.
La solución más simple es:
- Arregla tu controlador de gráficos Intel para que QuickSync funcione
- Cambia el orden en tu perfil a
order=ffmpeg,handbrake,mencoder
Esto hará que MCEBuddy use CUDA/NvEnc primero y, con suerte, ese controlador es más
estable que tu controlador Intel y la codificación por hardware tendrá éxito.
El problema del doble codificador de hardware se abordará en la próxima versión