This project has moved and is read-only. For the latest updates, please go here.

Handbrake Conversion Always Fails

Jan 16, 2015 at 1:53 AM
Every one of my recent conversion logs shows a Handbrake failure, at 0% completion. MCEB seems to go on to use ffmpeg for conversion instead so my conversions are eventually getting done, but presumably this is not optimal. I'm not sure how long this has been happening, but I clean-installed the latest Beta this morning, and still see the Handbrake failures every time.

Does anyone else have this issue? Any suggestions on how to fix Handbrake would be appreciated. Thanks,

Sample log:
Jan 16, 2015 at 3:25 AM
Wierdly interesting, it quits after it detects 8 cores on your CPU (very cool BTW).

Try this, open your profile and in the handbrake-video line of the profiles changes
> threads=auto


> threads=4

See if that fixes the issue. If it does then please download the latest nightly build of handbrake 64bit and replace it in the MCEBuddy handbrake directory. Let me know the results.

Jan 16, 2015 at 9:41 AM
threads=4 did not solve the problem. MCEB still detected all 8 logical processors, and Handbrake immediately failed, same as before.

I tried the latest nightly Handbrake, and got the same result - failure at zero percent completion. Also tried a conversion to mp4 (instead of mkv), and got the same Handbrake failure.

Please let me know if you have any other recommendations. Thanks,
Jan 16, 2015 at 2:52 PM
Okay that case it's your intel driver. Try updating it. It may be causing the crash when handbrake tries to poll it's capabilities.

Jan 16, 2015 at 3:32 PM
My hardware is AMD, not Intel. I updated my AMD display driver just a few days ago.
Jan 16, 2015 at 4:27 PM
This ones a doozie

Jan 16, 2015 at 4:31 PM
One other thing I notice - since updating MCEB earlier this week, the size of my converted files has increased substantially - they are now more than 50% larger than the files I previously produced using v2.3.15 with the same video quality settings.
Jan 17, 2015 at 1:23 AM
TRy rolling back to the old driver, when query OpenCL capabilities it may be crashing.
Jan 20, 2015 at 11:54 PM
I don't think I can roll back. Windows 8.1 has grayed out the "Roll Back Driver" option, and I don't know what my previous driver version was, nor where I could obtain that driver now. Please let me know if you have any other recommendations. Is there a way to prevent the OpenCL capability query? I tried de-selecting "Hardware encoding" in mcebuddy, but that had no effect.

I am now getting this message just before the Handbrake failure: 2015-01-19T21:08:22 MCEBuddy.AppWrapper.Handbrake --> unknown option (-4)
Sample log:
Jan 22, 2015 at 2:26 AM
Try to remove the -4 parameter from the handbrake-general line in profiles.conf for the profile you're using.
Also regarding roll back, you don't need to just uninstall the driver and select the option to delete the driver when uninstalling, then refresh (It'll load the older driver) and repeat the process until it doesn't give you an option to delete the driver. Now update from Windows update.

Jan 22, 2015 at 9:04 AM
OK, this one is getting complicated....

Handbrake does not like the -4 parameter (maybe this is ok for MP4 conversions, but not for MKV?). If I delete the -4, Handbrake works -- but only under certain conditions. These conditions relate to my display adapters - I have two (I use the motherboard's on-board video chip to drive a third monitor). Disabling the onboard display adapter does not fix Handbrake, and deleting the driver for the onboard adapter does not fix Handbrake. But somehow, it appears that updating the driver for my main PCIE display adapter temporarily prevents my onboard adapter from working, and that DOES fix Handbrake (but only if I remove the -4 input parameter). That does not make much sense to me, but that's what I'm seeing. Here are two log files with identical settings and source files - in one, Handbrake works and in the other it fails. The only difference I can see is that just before the failed Handbrake conversion, I had disabled and then re-enabled the onboard display adapter (to get it working again, after it had gotten blocked by the PCIE display adapter driver update). Seems crazy, so I tested it twice, and got the same results.

Please let me know if my second display adapter could be causing this problem, and any suggestions for resolving the conflict. (Disabling the onboard video in BIOS might work, but I'd prefer to keep my third monitor if possible). Also, the logs linked above show that the ffmpeg-converted file is 85% larger (26239 KB vs 14169 KB) than the Handbrake-converted file for the same source video and quality settings. Is such a large difference normal? If so, I'd certainly rather have the Handbrake conversion working.

Jan 25, 2015 at 2:45 AM
A little more about how this is happening -

Whenever I re-install the driver for onboard video, Windows stupidly insists on installing the same driver for my main display adapter. If I then update the driver for the main adapter, the onboard video has a problem (Code 43), and needs to be uninstalled/reinstalled, causing the onboard video driver to be applied to both adapters, and leading to a vicious cycle. I tried every combination I could think of for rolling back, rolling forward, uninstalling, reinstalling, using Windows Update, using Device Manager, using manufacturer install files, etc. Windows just won't let the right drivers work on both display adapters at the same time. Even though this worked fine for months previously, it doesn't work now.

The old (onboard video) driver seems to work ok for ffmpeg, and everything else, except Handbrake. I don't suppose there's anything MCEBuddy can do about this, but please let me know if any other ideas. Also, I am still curious as to why the ffmpeg converted files are so much larger than the Handbrake files, or is that normal? Thanks,
Marked as answer by rboy1 on 1/31/2015 at 9:42 AM
Jan 31, 2015 at 5:42 PM
It comes down the parameters used (bitrate/quality) in the profile. You can tweak the numbers to match, generally I've found handbrake quality to be marginally better than ffmpeg for the same quality/bitrate parameters (can't explain why since they use the same x264 libs).
Feb 8, 2015 at 8:30 AM
Thanks for the explanation. I generally use the .mkv profile, and with that profile it appears to me that the ffmpeg quality is much higher than the handbrake quality, which would be consistent with the much larger file sizes I'm seeing. I have no idea how I would go about tweaking the parameters for either program to equalize quality (I suppose I'd need to do some research), but am happy with the Handbrake results as file size is more important to me than video quality. I am now driving all three of my monitors from my main video card (eyefinity), so I disabled the onboard video and have had no further problems with handbrake failing. Thanks again!
Feb 8, 2015 at 2:14 PM
That's interesting, it should be that different. Can you post your profile here (use the "code" blocks while posting) to see.
Feb 8, 2015 at 6:31 PM
The ffmpeg file sizes are about 85% bigger than the handbrake files, and the resulting ffmpeg video quality is better. Below is the profile I used. The transcoder parameters are what came with the standard profiles.conf file installed by MCEBuddy, the latest beta as of a few weeks ago. I have not changed them.

Do both transcoders use the same quality settings from the MCEB Conversion Task settings? E.g. Max Width and Quality? I usually set MCEB "Quality" to -50% - maybe ffmpeg doesn't get that adjustment?
[MKV Fast]
Description=Average quality 1 pass MKV (H.264/AC3). Fastest and smallest conversion but lower quality, more sensitive to errors in the source video.
ffmpeg-general=-threads 0
ffmpeg-video=-ss 3 -vcodec libx264 -b 1000k -x264opts cabac=0:ref=2:bframes=1:weightp=0:8x8dct=0:trellis=0:subq=6:me=hex:b-adapt=0:threads=auto -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 128k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 160k -map 0:a
handbrake-general=--loose-anamorphic --verbose=2 -O
handbrake-video=--start-at duration:3 -e x264 -b 1000 -x cabac=0:ref=2:bframes=1:weightp=0:8x8dct=0:trellis=0:subq=6:me=hex:b-adapt=0:threads=auto
handbrake-audio=-E ffac3 -R auto -B 128 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E ffac3 -R auto -B 160 -D 0 -a 1,2,3,4,5
PostCustomCommandPath=C:\Program Files\MCEBuddy2x\config\post.bat
Feb 8, 2015 at 10:54 PM
I'm thinking you may be right. See of you can post the log with ffmpeg and one with handbrake to compare so we can get to the bottom if this. (Zip them to make it small)

Feb 20, 2015 at 5:06 AM
Logs are linked below. Also, I ran a test file a few different ways and confirmed that the "Quality" setting has no effect on ffmpeg conversion - file size is identical, regardless of Quality setting. For Handbrake conversion, the Quality setting has a big impact on file size, as would be expected. I was using the MKV Fast profile for these tests.
Feb 20, 2015 at 2:38 PM
you're right when ffmpeg is used the quality multiple doesn't seem to be workign correctly. will look into it thanks for reporting.

BTW, I assume you're upgraded handbrake to the latest build since I'm seeing this error:
2015-01-22T00:24:14 MCEBuddy.AppWrapper.Handbrake --> unknown option (-4)

The latest version of handbrake doesn't support the -4 option, you need to remove it from your profile if you want to use handbrake.

Feb 20, 2015 at 7:52 PM
@bob0909 thanks for reporting this issue. The bug has been fixed, it was introcued in 2.4.1 when we added support for x265 causing mcebuddy to ignore the quality parameter for ffmpeg accidentally.
Try the new 2.4.2 beta
Marked as answer by rboy1 on 2/20/2015 at 11:52 AM