So a couple of things you need to be aware of:
- The order of your encoders:
order=handbrake,ffmpeg,mencoder
This means it’ll use handbrake first (QuickSync) and then ffmpeg
(NvEnc/CUDA) for hardware encoding.
You have BOTH, QuickSync and CUDA available. In the earlier version due to
a bug in MCEBuddy if both were found it would use ffmpeg first (cuda) and
then handbrake (quicksync).
With 2.4.9 of both hardware encoders are found it’ll use the user specified
encoder first (in your case handbrake, ie. quicksync).
So when it starts QuickSync encoding, the Intel graphics driver fails.
2018-03-15T13:28:46 MCEBuddy.AppWrapper.Handbrake → Handbrake
failed, non 0 return code
This is likely due to a bad graphics driver, try installing one of the
recommended drivers version to get your QuickSync encoder working.
Because the hardware encoder fails, MCEBuddy tries to use the software
version of the same encoder (i.e. handbrake) and this works and this is
what you’re seeing.
MCEBuddy does not try the second available hardware encoder before falling
back to software encoder, this is a known issue and it’s slated to be fixed
in the next version.
Basically you’re facing this issue because your system supports BOTH Cuda
and QuickSync.
The simplest solution is to:
- Fix your Intel graphics driver to that QuickSync works
- Change the order in your profile to
order=ffmpeg,handbrake,mencoder
This make MCEBuddy use CUDA/NvEnc first and hopefully that driver is more
stable then you Intel driver and hardware encoding will be successful.
The dual hardware encoder issue will be addressed in the next release