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

Quicksync/HW Encoding: Slow FPS

Aug 24, 2014 at 2:08 AM
After upgrading to the new 2.4 release, I was finally able to get MCEBuddy to use hardware; it had always said "Quicksync = True" but by manually editing the profiles.conf file to say "-e qsv_h264," I was able to get hardware encoding to work. It basically increased the framerate tenfold (which obviously isn't everything, but it's a big thing!). It encoded HD movies in the same time it took to transcode a half hour show.

However, I've got some shows--all on the same channel--that simply will not work with the hardware encoding. They continue to go at 30 fps (vs. 300!) and take as long as they did before (checking the graphics card usage also indicates it's being done by software). I'm happy to upload log files, but first is there something I should look for to see if there's a reason these files aren't working through hardware encoding? What's odd is that it DOES say "encoder: H.264 (Intel Media SDK)," which it didn't say before I altered the config file.

I've searched the forum and found it very helpful--particularly in manually changing the conf file--but didn't find anything about potential files that won't go through hardware. I'll note that I didn't tinker very much with the settings on MCEBuddy, so you can probably assume that whatever the setting is, it's default. I'm running a Dell 660s, with an i3-3220, and the graphics driver is only 9.18.10.3257, but unless that seems to be the problem--which I don't think it is--I'd like to leave it.

Thanks for all the help and support here!
Aug 24, 2014 at 3:02 AM
Glad to hear it worked out, but one point to note MCEBuddy automatically enables hardware encoding by change the encoder at runtime to qsv if it finds support.

BUT this ONLY happens if Hardware Encoding is enabled in the options. Open your conversion task click on Expert Settings (conversion task not general settings) and ensure that Hardware Encoding is enabled/checked.

If AFTER checking the box MCEBuddy still isn't enabling the qsv encoder please post your conversion log (zip and upload) and we will check out what's going on.

Regarding your framerate for some shows not increaseing, zip and upload one sample log file to see what's going on.


Aug 25, 2014 at 1:27 AM
I had checked the box, but it was still constantly using software conversion. Not sure why I had to manually fix it. I saw this tip in one of the discussions here:
"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."

For whatever reason, I can't find that page now. The only thing I can think of is that maybe I didn't adequately uninstall an earlier version, but there's a profile.confold from the date of the new installation.

Anyway, this is the log file of one that did not convert with quick sync:
http://1drv.ms/1vCpoKR

and this is one that did:
http://1drv.ms/1vCpmlX


Thanks!

Kevin
Aug 25, 2014 at 2:30 AM
In both the logs you've used custom profiles with -e qsv_h264 already set, so MCEBuddy will do nothing.

Try a clean install and use the stock profiles.conf and it'll work.


Aug 25, 2014 at 3:46 PM
Yes, I manually edited it and added that in, but that was after MCEBuddy didn't make the change. As you said, it may be because I didn't do a clean enough install. I'll be sure to wipe the folders completely.

Do you think that could explain why some files do and some files don't use the hardware?
Aug 25, 2014 at 5:58 PM
The only time MCEBuddy doesn't enable hardware encoding:
1. The system (drivers/hardware) does not support it
2. The target profile codec is not h.264 (e.g. AVI, Divx, WMV etc)
3. Hardware encoder fails, it will fall back to software


Marked as answer by rboy1 on 8/28/2014 at 1:46 PM
Aug 26, 2014 at 12:02 PM
Okay, I clean installed it and without tinkering it went to hardware encode. But the same files--all the Batman reruns on IFC--encode via software at 10% of what other files do (30 fps v. 300).

New log, after the re-encode:
http://1drv.ms/1tEUwZQ

It's not a big deal, as it just seems to be this one show. I should probably record something else on the channel to see if it's the channel or the show. Maybe because it's so old?
Sep 1, 2014 at 2:57 AM
Okay, I'm getting this error on other computers and other files, and I think I can pinpoint part of it. It starts out using hardware encoding (example taken from log in previous file:

2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] + encoder: H.264 (Intel Media SDK)

Now comes a series of errors that I don't quite understand.

2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key me
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: unsupported option trellis
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key subq
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key partitions
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key 8x8dct
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key keyint-min
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key bframes
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key weight-b
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key level-idc
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: unsupported option b-pyramid
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key direct-pred
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key mixed-refs
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key deblock
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key nofast-pskip
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key nodct-decimate
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: unsupported option b-adapt
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: bad key threads
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: hb_qsv_param_parse: unsupported option la-depth
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] mpeg2video: "Chapter 1" (1) at frame 0 time 102101
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> Encoding: task 1 of 1, Searching for start time, 33.37 % (ETA 00h00m00s)[21:01:24] encqsvInit: using encode-only path
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: TargetUsage 2 AsyncDepth 4
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: GopRefDist 3 GopPicSize 25 NumRefFrame 4
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: BFrames on
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: RateControlMethod VBR TargetKbps 1400 MaxKbps 2100 BufferSizeInKB 525 InitialDelayInKB 262
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: CAVLC off
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: ExtBRC off
2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] encqsvInit: H.264 profile High @ level 3.1

And so what happens is that it goes back to using the software to encode:

2014-08-25T21:01:24 MCEBuddy.AppWrapper.Handbrake --> [21:01:24] thread 69cdfb0 started ("H.264/AVC encoder (Intel QSV)")

I'm not sure what to make of those errors or how to correct them, but that happens with almost all of the files that won't convert using hardware.
Sep 1, 2014 at 5:39 AM
Why do you think it's using software encoding? You log says otherwise:

started ("H.264/AVC encoder (Intel QSV)")

It's using the Intel QSV (hardware) encoder.
The messages above it are normal, it just ignores any unsupported options.




Sep 1, 2014 at 11:12 AM
I was basing it off the information in the FAQ about hardware encoding that said you want it to read "encoder: H.264 (Intel Media SDK)." It says that earlier but then went back to QSV immediately before encoding, so I thought that might be a sign of the problem, if not the cause of the problem.

Otherwise, I'm at a loss, as a good number of files across stations and multiple computers don't seem to be using hardware conversion, and I can't figure out why. That log file even says, "qsv_enc_init: using 'hardware (1)' implementation, API: 1.7," but it is converting at about 30 fps, which is what it did before enabling hardware conversion and about 1/10 of the fps rate of other files.

One computer won't update to the new driver, so that may be the cause there; but the other two are updated and one of them converts using hardware some of the time, so I don't know what is going on.
Sep 1, 2014 at 1:58 PM
I think you're confusing time taken to encode v/s hardware encoding. From you statement and log looks like your computer is using hardware encoding but it's processing at around 30fps which is not what you're expecting.

That can happen for a number of reason, mostly like the parameters that are being used, of which the likely issue would be "Interlacing". When using Decombing to supplement deinterlacing the uses some software components which can slow down the processing.

Try this, on the file which is converting at 30fps, try using the MP4 Fast profile to convert. Post back and let us know if that speeds up your conversion (MP4 Fast does not do Decombing).


Marked as answer by rboy1 on 9/1/2014 at 10:41 AM
Sep 1, 2014 at 4:14 PM
That certainly seems to have solved the problem, at least on some files (I haven't checked them all on all systems). I'm a bit surprised: I know fps is an imperfect measurement, but I never even saw the GPU load tick up using the hardware conversion with de-interlacing. I guess it slowed it down sufficiently that the hardware load was minimal.

I guess the next question is what to do about this: Can I turn decombing off in MP4 Normal, and will it make a significant difference? Or is there an easy way to tell which files will require it (obviously, Batman in syndication on the IFC does so)?

Thanks for the help and patience!
Sep 1, 2014 at 6:09 PM
Wait for the next build of MCEBuddy, this problem was fixed over the weekend realted to anohter issue. It'll be there in the next build.


Marked as answer by rboy1 on 9/1/2014 at 10:41 AM
Sep 1, 2014 at 6:50 PM
One sample video went from 30fps to 150fps after this fix.
Sep 1, 2014 at 7:02 PM
Awesome--you guys really keep this up to date!

I tested it on a couple of files, and it showed the same kind of increase as that one, so it'll work perfectly for me. Thanks!