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

GPU Acceleration questions

Feb 9, 2014 at 4:37 PM
I have a AMD HD5450 and a Intel i3 CPU with Intel 4400 graphics quicksync in my HTPC. The Intel i3 OpenCL processing is likely much more capable then the HD5450 in my system.

When I use the latest MCEBuddy 2.3.15 with the hardware acceleration check box on.....

Which GPU will it use to accelerate? HD5450, Quicksync or both?
Does the conversion profile I select make a difference as to how and which GPU acceleration is active?
Feb 9, 2014 at 8:52 PM
Handbrake will select the best one to use. If you open the conversion log you will see which one handbrake uses. You can customize the profile to force using a specific piece of hardware (see handbrake cli manual for which option to use)

Feb 9, 2014 at 11:20 PM
I can't get the gpu acceleration to work. Here's what I'm doing:
  • Using the new beta version, just downloaded today
  • Hardware acceleration is checked; log files show " --> Auto Enable Hardware Encoding : True"
  • Edited profile to put Handbrake in first priority position
  • Installed GPU supports OpenCL 1.2 - (AMD Radeon HD 7750)
I see no improvement in processing times, conversion still uses near 100% of all eight CPU cores, and I see no indication in the log files of gpu hardware usage.

Am I missing some hardware/software requirement or some configuration/setting?
Feb 10, 2014 at 2:12 AM
Post your log, how can one tell otherwise what's doing on
Feb 10, 2014 at 2:30 AM
OK. I tried updating the driver for the video card, and now I have a different problem - MCEBuddy runs normally through "analyzing video", then fails as soon as the conversion step begins. Log file here:
Feb 10, 2014 at 2:41 AM
hmm someting is not right, handbrake isn't even starting on your system which is why it's not able to do anything.

Are you using a custom profile or stock profile? I'm asking because stock mkv fast profile has ffmpeg as a backup encoder which in your doesnt' seem to kick in after handbrake fails to launch.

Feb 10, 2014 at 2:41 AM
Can you check if handbrakecli.exe exists in your mcebuddy installation\handbrake folder?

Feb 10, 2014 at 3:02 AM
I think the driver update just went bad for some reason - after updating, I couldn't even open WMC or MPC-HC.

So, I re-installed the latest video card driver, and MCEBuddy is working again, but still appears to be using CPU rather than GPU. Log linked below. I'd appreciate any suggestions. I expect it's no longer relevant, but handbrakecli.exe exists. I see that in my profiles.conf, most of the 'fast' profiles (all except DivX) show handbrake only with no backup. I don't believe I ever changed this configuration.
Feb 10, 2014 at 3:08 AM
I've replicated your exact settings on 64bit win 8.1 and it works fine.

I think you may have a corrupted installation, try doing a clean install. Also you have a max width of 683 (kinda funny number)
Feb 10, 2014 at 5:18 AM
Yes, 683 is probably unusual - it's half the width of my tv screens (1366) - I'm not a stickler for video quality...

No good. I carefully followed the clean reinstall instructions, and still see no hardware acceleration. Here's another log, in case it helps:

Is there any reason OpenCL might not be available, when my card is known to support it? Maybe some setting is needed to enable it? I'd love to try the GPU acceleration, but can't think of anything else to do to make it work. Thanks,
Feb 10, 2014 at 1:50 PM
you don't seem to have QuickSync which is what MCEBuddy for to auto enable hardware encoding.

Try this, open your profiles.conf, goto the profile you're using (MKV Fast), under handbrake-video replace -e x264 with -e qsv_h264 and see if that works.

Feb 10, 2014 at 2:30 PM
No difference.

Quick Sync seems to be an Intel thing. I suspect I can't get it because my cpu is AMD.
Feb 10, 2014 at 3:22 PM
Did you try the suggestion above?

Feb 10, 2014 at 9:02 PM
bob0909 wrote:
No difference.

Quick Sync seems to be an Intel thing. I suspect I can't get it because my cpu is AMD.
Can you post the log file after your changed the profile from -e x264 to -e qsv_h264
If that works, then I can modify MCEbuddy to auto enable hardware encodng for ATI cards also
Feb 10, 2014 at 10:36 PM
Yes, I did try the profile change, but still did not see any sign of gpu encoding. Log file here:
Feb 11, 2014 at 1:04 AM
Right. So while your card does support OpenCL it does not support QuickSync (Intel)

However you can enable the OpenCL optimizations

In the handbrake-video section at the end of the line add -P and then post back the log. You should improvement in the frame rates.

Feb 11, 2014 at 1:23 AM
Edited Feb 11, 2014 at 4:33 AM
Everything seems to be working great for me. I did have to make use of a "fake" display setup to get my intel quicksync to be visible to mcebuddy/handbrake since I also have a ATI HD5450 card in my setup.

Fake display trick here:

Once I created the fake display, then handbrake/mcebuddy picked up the quicksync no problem. I was able to watch the GPU load on my intel chip go way up during the mcebuddy transcode using the techpowerup GPU-Z utility.
Feb 11, 2014 at 2:37 AM
to bob0909....Before I did the "fake" display trick, I also did not see any signs of GPU encoding. In fact ffmpeg ran instead of handbrake on my system just like yours since I also have a AMD card in my system. Implementing the "fake" display allowed my intel quicksync i3 chip to be visible to mcebuddy and handbrake.
Feb 11, 2014 at 6:02 AM
Added -P as instructed. Log linked below. Did not see any difference in file size or processing time. Would better frame rates show up as improved video quality?

Thanks, dumpinground. Unfortunately I don't have an intel chip, so no quick sync.
Feb 11, 2014 at 6:45 AM
So couple I points
1. Yes it has increased your average frame rate has increased from 233fps to 263fps with -P which is like a 15% increase.
That's pretty good (not awesome) considering that there is no cropping and scaling happening. If you scale and crop your videos then you should see an even greater increase. You try it by reducing the max width to say 320 and then run with and without -P and see the difference in the average fps

2. The amount of fps depends upon the hardware and driver implementation

3. There is another option -U. Try adding that in addition to -P and see if that helps further. It offloads decoding to OpenCL hardware. This helps particicularly with slower CPUs

Feb 12, 2014 at 12:10 AM
Okay so here are some tips to summarize:

MCEBuddy will auto detect if you have an Intel QuickSync enabled chipset and enabled QuickSync encoding.
  1. If you have an Intel chipset and another graphics card and MCEBuddy is not detecting the QuickSync, use the FakeMonitor trick described by @dumpingground above to enable the Intel graphics chipset and get MCEBuddy to recognize it.
  2. If you have an older CPU like a Pentium/Core/Core 2 and good graphics card from Nvidia or ATI, then you may want to add -U the handbrake-video profile. This will enable hardware decoding. This ONLY works if the GPU is more powerful than the CPU, it will reduce the performance on new CPU's which are much more powerful at decoding compared to graphics cards.
  3. If you have a newer graphics card (very powerful) which support OpenCL 1.1 then add -P to the handbrake-video in the profile. This works if you're using cropping reducing the video size (or the profile is using lookahead). Again, this will help only with a powerful graphics card with OpenCL drivers. If used on a weak graphics card it can reduce performance.
MCEBuddy cannot auto tune 2 and 3 since it is graphics card vs CPU dependent. MCEBuddy can only auto enable QuickSync if detected.
Marked as answer by rboy1 on 2/11/2014 at 4:10 PM
Feb 12, 2014 at 4:30 AM
just a clarification. I think this is the correct link for the fake display trick to enable the intel quick sync.

sorry for any confusion.
Marked as answer by rboy1 on 2/14/2014 at 8:08 AM
Feb 12, 2014 at 7:07 PM
Just FYI to all QuickSync users: another method to enable it is to just unplug your monitor from your graphics card and plug your monitor into the (digital) output from your motherboard. This is how I've done QS encoding in the past. It's not as slick as the fake display trick, but it definitely works, and doesn't require you to extend your display to a non-existent monitor (which can be annoying). It may require a re-boot, I don't recall. I rarely need my good graphics card (gaming and CAD only, both of which are rare for me) so I just leave it plugged into the mobo's graphics output most of the time. I transcode video way more frequently, (almost every night there's a new recording from 7MC to transcode) and when I'm gaming or doing something like CAD, I don't want the system transcoding anyway.
Feb 15, 2014 at 10:21 PM
Edited Feb 15, 2014 at 11:05 PM
I found something interesting. I am using the default MKV High profile with an Intel QSV enabled GPU and no discrete graphics card. I could not figure out why HW encoding was not working and then found this in the log
WARNING> 2014-02-15T12:04:43 MCEBuddy.Transcode.ConvertWithHandbrake --> QuickSync does not support 2 Pass, using 1 pass.

In the "converting Video File" phase I was still chewing through 80% CPU utilization

Performance Summary (~30 minute WTV, 1920x1080 input, 1920x1080 output, 3.81GB WTV file)
HW encode ewnabled
MKV High: 20.43
MKV Normal: 18:02

<Turned on debug log here>
disabled HW encode
MKV High: 1:05:54 (actually did 2 passes) 36.2 fps task 1, 16.9 fps task 2
MKV Normal: 40:10 (one pass only) 20.6 fps task 1

This not an apples to apples compare (high vs. normal) but it is one point of reference.
Also of note is that i am using microsoft remote desktop to rdp to the pc which mce buddy is running on. Maybe this is keeping QuickSync from activating? I see the reduction in conversion time but dont know why CPU utilization is still so high.
Feb 15, 2014 at 10:53 PM
Edited Feb 15, 2014 at 10:54 PM
I also noticed that mcebuddy when transcoding was using a 1 pass profile with quicksync. But even with the 1 pass it was using quicksync GPU and offloaded my CPU.

I use VNC to remote desktop into my HTPC which is serving as the mcebuddy server. You should consider installing the mcebuddy remote client on one of your other "manned" machines so that you can keep an eye on your mcebuddy server.
Feb 15, 2014 at 11:50 PM
How were you sure it was using Quick Sync? Are you just judging by CPU utilization? Looking at the dime delta i got ~2x improvement, but given i still see 80% cpu it makes me think something is not quite setup properly
Feb 15, 2014 at 11:57 PM
that is normal, hardware encoding does not support 2 pass. So essentially the difference between HW and normal for QuickSync enabled enabled profiles are the other encoding parameters. (yes that are difference to improve quality). See the profile for more details.

And yes your computer is using QuickSync as your can see the difference in encoding times (whcih also tells you there is a difference between HQ and Normal otherwise it would be the same.

Remote desktop is fine, as long as user is logged in, remote, or local it doesn't matter, MCEBuddy will take care of the rest.

You can see if Quicksync is enabled by looking at the logs. It will mention:

QuickSync encoding supported availble -> True

Feb 16, 2014 at 12:33 AM
I was judging by GPU utilization as the encode was being processed. I used GPU-Z utility to monitor the load on the quicksync GPU.
Feb 16, 2014 at 5:07 AM
look at the log file output, can't say what's going on with your GPU but can tell by the log file.
Post it here.

Feb 16, 2014 at 6:57 AM
log file posted to folder GPU Acceleration questions

2x improvement is good - but I expected more.
Feb 16, 2014 at 3:34 PM
2x? How did you figure that?

In your last post you mentioned down from 1 hour 5 minutes to 18 minutes that almost a 4x reduction in time.

Feb 16, 2014 at 3:41 PM
Your log file also indicates that qsv is being used (search for qsv).

2014-02-15T19:02:09 MCEBuddy.AppWrapper.Handbrake --> [19:02:09] thread 1e03740 started ("H.264/AVC encoder (Intel QSV)")

Feb 16, 2014 at 11:13 PM
I was comparing 1 pass to 1 pass. It seemed unfair to compare the 2 pass CPU encode to a 1 pass GPU encode. So 1 pass (MKV Normal) was ~40 minutes and HW accelerated (MKV normal or high) both are about 20 minutes.

The good news is that basically gets me to a bit faster than real time encode (a 22 minute MPEG2 file takes less than 20 minutes to remove commercials and re-encode in H.264. I was expecting more like a 10x reduction in encode time

"However, Quick Sync drops a Core i7-4770K from 113 seconds (using the x86 cores-only) to 14.",3521-2.html

Or this review stating HD4000 GFX does 126 fps

My last encode job ran at 11.4 fps (posted the same place), and it ran for about 7 hours when a output file length of ~2:30. no intentional changes to the config
Feb 17, 2014 at 2:24 AM
I'm sure you know this but I'll say it for everyone's benefit.

FPS depends a lot on various parameters. Input video size, output video size, bit rate, options selected (trellis, deinterlacing, look ahead etc etc).

So really your comparison with the "websites" have no basis.
I can you show you a log file running on my laptop showing mp4 fast profile giving me 460fps. It's only an ivy chipset. So there you go.

And as for x increase factor it depends upon your processor and chipset. I have a really old core processor with a sandy bridge chipset test machine and I see a 50x increase in performance - that's because the processor does a crawly 4fps

Hope this puts a perspective on your approach and expectations.

Feb 19, 2014 at 4:48 PM
I too had questions about the hardware encoding, I did donate to get the latest version not specifically for the added benefits, but because this developer has created this fantastic product that NEEDS to be supported. The hours and hours this program saves me is well worth the donation. With that said... I read this post about the hardware encoding, while I am no programmer (I am sane), its confusing. Is it possible to get a step by step list of things to do if the hardware encoding is not working. It appears a lot of what is required is hardware dependent, which makes sense. If a list of minimum required items would be nice.

My PC has an old processor, I7 (first generation), newer graphics card GeForce 650, I don't know about the Intel Quick Sync, couldn't really find any good information about it. A simple flow chart would be nice on the things to try and the order they should be tried in. Thanks...
Feb 19, 2014 at 5:50 PM
Essentially in the simplest form currently (as I am aware) to get QuickSync from Intel, you need hardware which has an Intel Sandy Bridge, Intel Ivy or Intel Haswell chipset in it.

You can google and try to find out if you chipset is either one of the above 3 generations and you can also google Intel QuickSync to confirm that you hardware has QuickSync.
If it does then you need to download and install the latest Intel drivers for your chipset/display and MCEBuddy will take care of the rest.

Remember you need BOTH, the hardware AND the latest drivers to use QuickSync,

Feb 20, 2014 at 1:16 AM
I actually found someone who has deep knowledge on handbrake. I am working on tweaking the MKV High profile to speed it up on a i7-3770. First things that came up was decomb. I will post updates as/if we make any progress

Mar 21, 2014 at 3:27 AM
rboy: I guess I just don't get it. I looked at all these posts and tried the stuff and don't seem to get hardware encoding. I have an AMD cpu (no QuickSync) and an ATI Radeon 6670 video card (downloaded latest driver today) with OpenCL 1.2 support. I tried to add -P and/or -U to the handbrake-video line of my profile and tried several test recordings. I don't get any activity on the gpu, and total domination of the four cores.

Here's my profile (modified obviously):
[M4V Apple High Quality]
Description=Apple compatible 2 pass MP4 (H.264/AAC) high quality conversion. 4GB file size limit. More sensitive to errors in the source video.
handbrake-general=--loose-anamorphic --verbose=2 -T -f mp4
handbrake-video=--start-at duration:3 -e x264 -b 1600 -q 22 -w 960 -x -P
handbrake-audio=-a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,none -R Auto,Auto -D 0.0,0.0 --audio-copy-mask aac,ac3,dtshd,dts,mp3 --audio-fallback ffac3
handbrake-audioac3=-a 1,1 -E faac,copy:ac3 -B 160,160 -6 dpl2,none -R Auto,Auto -D 0.0,0.0 --audio-copy-mask aac,ac3,dtshd,dts,mp3 --audio-fallback ffac3
CustomCommandPath=C:\Program Files\MCEBuddy2x\atomicparsley\AtomicParsley.exe
CustomCommandParameters=""%convertedfile%" --overWrite --title "%episodename%" --TVShowName "%showname%" --genre "TV Show" --comment "Original air date: %airmonth% %airday% %airyear%" "S%season%E%episode%""

It's intended to push the limits of the AppleTV 2 and it takes a long time to encode, so I would love to drop it off on the gpu. I don't know where to throw up a log (just joined here a moment ago) and if you tell me how, I'll get it to you post haste. Really, though, like one asked before, what are the steps we should try to get OpenCL use when we have an AMD cpu and no QuickSync?

Thanks for the great program and for your anticipated help.
Mar 21, 2014 at 6:13 AM
Without QuickSync OpenCL accelleration is limited to a few things like cropping, scaling, deinterlacing etc. The -P and -U option should offload some of the stuff to your hardware but it depends up on the video.

Upload the conversion log to the mcebuddy server or dropbox (read the sticky thread) and post the link here. Will go through it and let you know what I see.

Mar 22, 2014 at 6:06 PM
Did you get my log for Scandal? I prefixed it with mgoblue01-
Mar 23, 2014 at 4:18 PM
You need to set the level to debug (right now it is information) for me to see what's going on.

Mar 24, 2014 at 3:50 PM
Thanks. I put a new one up for "Burn Notice." Please take your time, but let me know if you see anything that could shorten the time without compromising the quality.
Mar 25, 2014 at 1:19 AM
Couple of points here that I see conflicting information
  1. You've put -x but no parameters (remove it)
  2. You're using -b 1600 and -q 22, which is it? (you can't use both, either use -q or -b), try using -b 1600 only if you're unsure
  3. You've set -w 960, and set MCEBuddy 720 max width - why both? Either create a custom profile (FixedResolution=true) if you're doing a custom width or remove the -w 960 and use the max width slider in MCEBuddy
You're getting an EXCELLENT average frame rate of 70fps (you can see in the logs) (86.89 fps, avg 69.12 fps, ETA 00h12m02s). Try removing the -P and then see how it changes, then try adding -U and see how it changes.

You 2 options are -P and -U, play with them (one, both or none, order does not matter) and see which option works best for you (look at the average frame rate).

IMHO, Full HD original recording (1080p), 45 minutes source, 30 minutes to encode - that's pretty decent.
Mar 25, 2014 at 12:56 PM
Thanks very much for the input and your time.
Apr 17, 2014 at 4:51 PM
Edited Jun 5, 2014 at 3:34 AM
For reference, if you're finding that your encoding time suddenly takes a VERY long time (one user reported MCEBuddy saying it'll take 9 hours to complete the encoding with hardware enabled and 20 minutes without). Look at your log file.

Very likely your Intel driver is buggy/old and is causing issues. Try to update to and it should resolve your issue. See the log below for an examples of a buggy driver or if you're running heavy graphics apps/games while using hardware encoding can take the wind out of the Intel driver and causing it to run out of resources.
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.02 %[20:43:36] qsv_enc_init: using 'hardware (1)' implementation, API: 1.3
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Error code -1,    av_qsv_wait_on_sync 642
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Error code -1,    av_qsv_wait_on_sync 642
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Error code -1,    av_qsv_wait_on_sync 642
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Error code -1,    av_qsv_wait_on_sync 642
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Error code -1,    av_qsv_wait_on_sync 642
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Error code -1,    av_qsv_wait_on_sync 642
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Encoding: tasError code -1,   av_qsv_wait_on_sync 642
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> k 1 of 1, 0.05 %
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %not enough to have 10 sync point(s) allocated
2014-04-15T20:43:36 MCEBuddy.AppWrapper.Handbrake --> ERROR: qsv: Not enough resources allocated for QSV encode
2014-04-15T20:43:37 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %
2014-04-15T20:43:37 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %not enough to have 10 sync point(s) allocated
2014-04-15T20:43:37 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %
2014-04-15T20:43:37 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %
2014-04-15T20:43:37 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %not enough to have 10 sync point(s) allocated
2014-04-15T20:43:38 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %
2014-04-15T20:43:38 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, 0.06 %not enough to have 10 sync point(s) allocated
2014-04-15T20:43:38 MCEBuddy.AppWrapper.Handbrake --> ERROR: qsv: Not enough resources allocated for QSV encode
2014-04-15T20:43:38 MCEBuddy.AppWrapper.Handbrake --> ERROR: Last error repeated 2 times
2014-04-15T20:43:38 MCEBuddy.AppWrapper.Handbrake --> ERROR: qsv: Not enough resources allocated for QSV encode
Marked as answer by rboy1 on 4/17/2014 at 8:51 AM
Jun 5, 2014 at 3:34 AM
The most stable Intel Graphics driver tested so far is:
Marked as answer by rboy1 on 6/4/2014 at 7:34 PM
Jun 8, 2014 at 5:08 PM
I see the following in my log file. Is there anything I can do or is my hardware truly not supported?

2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] - Intel microarchitecture Sandy Bridge
2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] - logical processor count: 8
2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] OpenCL device #1: NVIDIA Corporation GeForce GTX 560 Ti
2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] - OpenCL version: 1.1 CUDA
2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] - driver version: 337.88
2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] - device type: GPU
2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] - supported: no
2014-06-08T11:54:15 MCEBuddy.AppWrapper.Handbrake --> [11:54:15] Intel Quick Sync Video support: no
Jun 8, 2014 at 8:30 PM
See if you can enable the intel chipset in your bios otherwise Your hardware does not support quicksync. You can only get opencl benefits

Jul 12, 2014 at 12:49 AM
I just cant wrap my head around all this. I just upgraded to 2.3.15 and while it is quicker, from what I can tell in the file conversion log, Quick Sync is supported but not being used. I have an i5-4670k and a GTX760 GPU. Can quick sync even be used when not using the integrated graphics? Given my hardware, can hardware encoding and GPU acceleration be used in conjuction?
Jul 12, 2014 at 1:06 AM
Upload or Post a link to your conversion log.

Jul 12, 2014 at 5:14 AM
Sure, hopefully this link works: TEXT

Maybe I'm just reading the log file wrong. Like I said it's definitely faster than 2.3.13, I just want to make sure that I'm getting the biggest improvement that I can given my current hardware. Thanks for any help.
Jul 12, 2014 at 2:13 PM
See the FAQ's on how to detect hardware encoding.

INFORMATION> 2014-07-11T11:52:54 MCEBuddy.AppWrapper.Handbrake --> QuickSync encoding supported availble -> False

You Intel card is not being detected. See the FAQ's on how to get it to detect the intel card (attach a monitor).

Sep 1, 2014 at 6:48 PM
Folks who were facing a slow fps issue with hardware encoding (about 30fps), try the new build of mcebuddy it'll speed it up to around 150-200fps with the new 2.4.1 build. This was due to a intermixing of software and hardware deinterlacers which was slowing down the encoder. Now it uses only hardware deinterlacer.
Dec 8, 2014 at 4:08 PM
Edited Dec 8, 2014 at 6:54 PM
I don't know if this is a stupid question or not. I recall back in the days I would crunch data for F@H, albeit I used CPU only, GPU data crunching would require a homemade adapter on the video card. Since I had never used a video card for crunching data I never determined if the way it was done was to use the motherboard video output for one's screen and with the homemade adapter on the video card use the GPU for crunching data. Is this incorrect? Does one disable the onboard video and use something like a AMD Radeon 7800 series display adapter for video conversion as well as the currently used display adapter?

I can see how dedicating the GPU to roles other than the display would work better.


After some more research I see that even older Catalyst drivers won't help the AMD Radeon 7800 series as the older drivers that might work with XP x64 address 5800 series cards. With OpenCL installed I run GPUCapsViewer and see I have no GPU computing available.

So, I suppose this means that even though I am planning to buy an i5-3570k motherboard combo with memory next year and slip it under my 2TB Seagate Hybrid with its WinXP x64, the AMD Radeon GPU might not be available? Wonder if the i5-3570k will be hamstrung with WinXP x64.

Last night's 2 hour The Librarians took 6 hrs 10 minutes on this AMD Athlon 64 X2 dual core 2.00 w/4.00 GB Ram, this for MP4 Normal. I had experimented with both x264 and qsv_h264, they both ran about the same duration but the x264 seemed to produce a cleaner video.
Dec 18, 2014 at 4:21 AM
Interesting. Since I convert both Tivo and HDHR3-cc files to MP4, I generally use MCEBuddy.ServiceCMD.exe and have the service set to Manual. This is because if running as a service automatically started it fails to convert some Tivo files. Now, it runs after I've finished recording at night. If it is still converting files when shows come up to record, I have it sleep and restart after 11PM. If all shows have been converted from the night before I shut it down completely. Now here's a bug. I hit ESC and kill the MCEBuddy.ServiceCMD window and sometimes go to TaskManager and kill MCEBuddy.ServiceCMD. I can see it's gone. Service is set to manual so it shouldn't start. But sometimes, about 15 minutes later I'll see MCEBuddy.ServiceCMD in the TaskManager list and if I had transferred a Tivo file while it was off, the conversion starts and sends the Tivo file to the Failed folder. Now, if I shut down MCEBuddy.ServiceCMD again, and move the Tivo file from failed to the My Tivo recordings, then restart MCEBuddy.ServiceCMD, say after 11PM when all recording are ready to be converted, MCEBuddy will be started, the command box will show, the GUI will show with the list of files to be transcoded including the Tivo file which had been returned from Failed to My Tivo Recordings, and the Tivo file will be successfully transcoded in turn.

So, why does the MCEBuddy restart on its own after being killed?
Dec 18, 2014 at 5:24 AM
When the command line engine shuts down it starts the service engine automatically. Most people don't know how to start the service so to make it easier, when the command line engine starts it disables the service engine and when the command line engine shutsdown it starts the service engine.
Dec 18, 2014 at 5:25 AM
If you don't wait to start the service engine, kill it from the task manager instead of pressing ESC or disable the service.
Dec 18, 2014 at 2:06 PM
Jan 31, 2015 at 4:22 AM
Upgraded to a Haswell 3.1GHz 4 core CPU and mb. So much quicker. With my old AMD 2.0GHz dual core a night's recordings would sometimes take 24 hours to transcode. Now the transcoding is always done by breakfast.
Feb 26, 2015 at 7:21 PM
Awesome program. First..thank you.
Great thread. Everyone's issues are slightly different.

Encoding to WTV...WMC friendly, at 1280 max with multichannel audio. Everything else on default.

My HTPC is an Athlon x2 4000?. (3GHz dual core) with a Nvidia GTX 560 dedicated GPU.
Encoding is taking forever, as you might imagine.
For all other purposes, the HTPC's CPU/GPU power is just fine. It's indeed time to upgrade.
Stuck on 4GB RAM and 2GB HDDs... It's what I had lying around 5 years ago...

Slow. But working like a dang charm!
Yeah, after a heavy day or's like 3-4 days of encoding. Rinse. Repeat.

I'm experimenting with using MCEBuddy on my gaming rig. I have a gig-E between the two.
Rig is I7-4770 at 4.5GHz on water, 32GB ram, NVidia 770. I copied some raw recordings and am processing a batch.
Already, this is much better. However, looking at the log it doesn't appear that it's using hardware encoding.
Which would be better? The 4770K or the 770 at the type of math evolved for the MCEBuddy encoding process?
Should I force an argument somewhere?

It's totally using the i7.. Which is fine if that's the best thing to do.
30 min show was 4 hours... now it's like 20 min to recode. Can I do any better?
Would the dedicated GPU on the HTPC be an alternative? How would I force it to use the GPU?

Otherwise, I'll be utilizing the i7 over the network from now on... anyway I can speed that up as well?

Again. Thanks.
Feb 27, 2015 at 1:23 AM
definitely the i7 is faster, Nvidia GPU will provide opencl support (unless your driver supports quicksync) which is slower. There's another thread comparing speeds of different intel chipsets

Feb 27, 2015 at 3:14 PM
I forgot to mention that not only does the i5 w8GB & Radeon 7850/2GB on a Maximus Hero VI complete a night's recordings in a few hours while it use to most often take 10-14 hours but I'm now transcoding to MP4 High Quality. Only thing is that now there's
a problem with a webpage ( that causes 4 loud beeps from the external speakers. I use hardware encoding.
Feb 27, 2015 at 3:19 PM
Edited Feb 27, 2015 at 3:20 PM
I have seen some discussion on here about using the on board video for the gpu encoding. Have you tried to disable the video card and only use the onboard video when you do your encoding?

I have an I7 4770 and no video card. Using the on board video only and mcebuddy does indeed use the hardware encoding.

To add. I believe there is a faq on here about hardware encoding, including a link to the drivers known to work. It did take a bit of stumbling with the drivers initially, but once it was working, the Microsoft update for drivers hasn't broken it yet.
Feb 27, 2015 at 3:59 PM
Edited Feb 28, 2015 at 10:50 PM

I'll give it a try.

Now I remember. The Maximus Hero VI video doesn't have a VGA connection. Nor does the Radeon 7850. But, the 7850 has a rectangle-like port for which I have a VGA adapter. I use a Dell 17" LCD. So, I must use the Radeon.
Apr 5, 2015 at 8:06 PM


Thanks for your answer on the previous. Still tweaking things here and it’s doing great.

I search the docs before asking. I know you can’t answer every email or post.

I’m using it via the network now, and just today moved the working dir (temp) to my 2TB 2nd drive off my SSD (it was filling up).

Using WTV. Windows Media Center (HTPC) is it’s only function. Multichannel. Not messed with other settings. It’s rockin and rolling.

I’ll be brief.

1. I’ve noticed the quality of the video is a little off. Seems like a lot of things have a sepia tone to them. Diminished or muted colors.

Not new, just the way it’s been. Today I’ve bumped the video quality up 25% to see if that helps. I suppose I could take the slider all the way up. Unsure what impact that would have.

2. I’ve noticed the volume is significantly lower on recorded TV.

3. Commercial detection with Comskip is pretty accurate. Is the donator version MORE accurate or just a little faster?

Any word on ShowAnalyzer for the US customer? No better?

I would think that my 4770K (or whatever transcodes) is the MOST impactful thing to watch.

4. Skipping forward and backward on a converted video takes a long time. 5-6 second delay. Instant on original (larger) video.

Any way to improve this?

5. Is WTV the best method/friendly/file type to use for Media Center?

Thanks a bunch for the great program. I’ve gotten several friends to purchase it based on my experience/demonstration.

Good stuff. Other things I’ve tried in the past were too complicated, bothersome, and finicky for even the tech savvy me to bother with. I tried.


Apr 6, 2015 at 12:42 PM

> Today I’ve bumped the video quality up 25% to see if that helps. I suppose I could take the slider all the way up. Unsure what impact that would have.

If you're changing the video quality using the slider - make sure you're using the updated 2.4.2 BETA, it's broken in 2.4.1 (it' accidentally reverses it in some cases)

> I’ve noticed the volume is significantly lower on recorded TV.

Increase the volume slider or enable the DRC (Volume Leveling) feature

> Commercial detection with Comskip is pretty accurate. Is the donator version MORE accurate or just a little faster?

Just faster

> Any word on ShowAnalyzer for the US customer? No better?

It works fine in the US (I use it)

> Skipping forward and backward on a converted video takes a long time. 5-6 second delay. Instant on original (larger) video. Any way to improve this?

You can try adding B-Frames to your video profile and see if that helps.

> Is WTV the best method/friendly/file type to use for Media Center?

MP4 is better and more compatible with fewer issues but won't work with the Recorded TV section, you'll have to use Videos or Movies section

Apr 6, 2015 at 4:01 PM

Thanks for the feedback.

I’ll try all of those suggestions.

Just downloaded 2.4.2. Thanks.

p.s. The prompt to install showanalyzer did not work. Had to do it manually.


Apr 6, 2015 at 7:38 PM
Thanks for letting me know will check it out

Apr 9, 2015 at 6:51 PM

Showanalyzer install within installer on new beta:

I did it on a second computer (just to install as a backup/test location) and it worked fine on that one. May have been a glitch on my end.

Having to do the manual uninstall before installing a new version may have goofed it up somehow.

On the backup computer, I installed without uninstalling the old first.

Increasing quality and volume has helped. Still testing. Noticed some odd video stuttering/tearing on a few shows…building then a freeze. Audio was ok.

If it happens again, I’ll submit the log file.

You mentioned adding B-Frames and DRC (volume). I’ve looked all over and in the profile.conf and mcebuddy.conf.

Where are the files/parameters for these? Or how to add them to a profile?

I’ll sort this out them try the MP4 instead of WTV.

Any recommendations on that? Which MP4 profile? “High Quality” recommended? Transcoding time about the same as WTV?

Apr 13, 2015 at 6:27 PM

I’m now using WTV Legacy with quality at 100% with showanalyzer.

I’ve got much better control fast forward/reverse/skipping.

Colors are better. I was seeing same issue as another user where everything had a sepia tone to it when on WTV with default quality.

I notice commercial detection is a slight bit better than comskip (for me anyway).

I don’t notice the difference in MPEG v. H. I like the Legacy vs regular WTV.

The choppy/pixilated thing I was getting has gone away for now.

I’m still getting a little freezing for the first 5 seconds of video. I haven’t tried the fixes for that yet.

I did not like the MP4 recordings. Metadata and file placement in WMC. Quality was ok.

May 5, 2015 at 9:22 AM
Installed the latest early donators MCEBUDDY and Comskip but now I get an error from Handbrakecli: Procedure Entry Point Not Found in Msvcrt.dll File

Here's from my Event Viewer:
Event Type: Information
Event Source: Application Popup
Event Category: None
Event ID: 26
Date: 5/5/2015
Time: 1:24:25 AM
User: N/A
Computer: SOYRUN12
Application popup: handbrakecli.exe - Entry Point Not Found : The procedure entry point _wfopen_s could not be located in the dynamic link library msvcrt.dll.

For more information, see Help and Support Center at

This started for the first time after installing the 2.4.2 64bit 20150429
I use the MCEBuddy.ServiceCMD.exe on WinXP x64. I upgraded after a recent TIVO file failed to transcode. This version did the transcode but the error appears after all transcoded files now.
I'd start a new topic but couldn't find the new topic button.

ERROR> --> No response from process for 300 seconds, process likely hung - killing it
ERROR> --> Process hung, killing process
ERROR> 2015-05-05T02:44:40 MCEBuddy.Transcode.ConvertWithHandbrake --> Handbrake conversion failed
2015-05-05T02:44:40 MCEBuddy.Transcode.ConvertWithHandbrake --> Conversion: Percentage Complete 0
2015-05-05T02:44:40 MCEBuddy.Transcode.ConvertWithHandbrake --> Original file size [KB] 1,739,280.00
2015-05-05T02:44:40 MCEBuddy.Transcode.ConvertWithHandbrake --> Finished video conversion, file size [KB] 0.00
ERROR> 2015-05-05T02:44:40 MCEBuddy.Transcode.ConvertWithHandbrake --> Conversion of video failed
ERROR> 2015-05-05T02:44:40 MCEBuddy.Transcode.Convert --> Handbrake did not convert successfully, using fallback if configured
INFORMATION> 2015-05-05T02:44:40 MCEBuddy.Transcode.ConvertWithFfmpeg --> Checking
May 5, 2015 at 1:35 PM
I guess you didn't see the FB and release notes updates. 2.4.1. Is the last build to support windows XP.

If you still want to use windows xp you will need to download handbrake version 0.9.9 and replace it in mcebuddy 2.4.2 or later.

Anyways please start a new thread on this topic.

May 5, 2015 at 3:45 PM
Thanks. Exactly the information I need. Sorry, as I mentioned, I couldn't find the New Thread button on the discussions page and it's a bit confusing, not a unique bbs for MCEBuddy but Codeplex.