Here is what I see in the logs. It looks like HW (nVidia) GPU is detected, but later on it looks like it is not using the GPU.
WARNING> 2020-03-13T22:27:03 MCEBuddy.AppWrapper.NVidiaQuery --> Checking if Hardware is nvENC compatible
INFORMATION> --> NVidia nvENC encoding supported -> True
WARNING> 2020-03-13T22:27:08 MCEBuddy.AppWrapper.AMDQuery --> AMD driver not detected or driver is not compatible
INFORMATION> --> AMD AMF encoding support available -> False
INFORMATION> 2020-03-13T22:27:08 MCEBuddy.Engine.ConversionJob --> Converting
INFORMATION> 2020-03-13T22:27:08 MCEBuddy.Transcode.ConvertWithHandbrake --> Checking for Unsupported profile for container / codec combination
INFORMATION> 2020-03-13T22:27:08 MCEBuddy.Transcode.ConvertWithFfmpeg --> Checking for Unsupported profile for container / codec combination
INFORMATION> 2020-03-13T22:27:08 MCEBuddy.Transcode.ConvertWithHandbrake --> Checking for Unsupported profile for container / codec combination
INFORMATION> 2020-03-13T22:27:08 MCEBuddy.Transcode.Convert --> Converting with Handbrake, type: SoftwareOnly, gpu: {
"hardwareBrand": "Any",
"codecType": "Undefined",
"hardwareCodecPresent": false,
"h265Codec": false,
"h264Codec": false
}
BTW, this profile is to convert to H.265, so I’m not sure why the h265codec is flagged as false.
Clues in above: INFORMATION> --> NVidia nvENC encoding supported -> True
and Converting with Handbrake, type: SoftwareOnly,
Am I mis-interpreting the above, or is there a setting I need to make somewhere to enable/force GPU conversions?
Yes it’s using software, either because the Use Hardware Encoding option is not checked in the conversion task -> Expert Settings or your profile is telling MCEBuddy to not use hardware encoding. No way to tell without the logs
This may be a red herring, but MCEBuddy is running as a service, and I read (see below) that services start under Process 0 in Windows, and because of that they cannot access kernel drivers, and I don’t know if that’s an issue with MCEBuddy as a service and GPU drivers. It would explain why it works if run from the CLI (i.e. with user credentials) and not from the service (with system credentials from Process 0) - if that is the issue (I installed MCEBuddy to run for “Everyone”).
Services run in session 0. Session 0 does not have access to the video driver so hardware acceleration is unavailable to PMS as a service.
My bad. I didn’t check the details on already having that recording already processed.
Here is a new one, and it is from a TiVo (pulled via KMTTG with mpg output) for bonus points.
This one is much bigger (6MB) so I zipped it. I see some testing but lots of disabling and “unable to find H.264/H.265 profile” type messages so I’m not sure what that is about. The CPU is an i5 4330 (4th gen).
And your profile is converting to h.265 (HEVC) so it can’t use the hardware:
→ Profile being used : HEVC MKV
Profile entries →
→ Description=HEVC in MKV (H.265/AC3) conversion. Creates a smaller file (50% smaller than H.264) with comparable quality but very slow.
So it falls back to software encoding
2020-03-17T14:46:38 MCEBuddy.Transcode.ConvertWithHandbrake → Cannot find supported h264/h265 software/hardware encoder combination in profile, disabling auto hardware encoder adjustments
Running Handbrake 1.3.1 (2020010400) it looks like they support H.265 NVENC encoding.
I’m running a GTX-750ti using nVidia drivers 442.59 03/10/2020 on Win10x64 1909 release.
The current handbrakeCLI in MCEBuddy says nvenc_h265 is supported.
So what am I missing? Is it that MCEBuddy is running as a service (i.e. process 0) and can’t access the video drivers from the kernel? Do I need to re-install and not pick “everyone” during the install?
Just adding that H.265 doesn’t get support on nVidia until the Pascal GPUs (GTX-1050 and above/newer). My (ancient) 750ti is a Maxwell GPU. It is in a dedicated HTPC, which has plenty of spare time to use, so HW transcoding isn’t urgent enough to get an upgrade (yet). I also don’t have 4K content or a 4K TV, so the H.265 is just for the space savings and to be future-ready.