Assistance Understanding Handbrake and NVidia Integration

General Support / Questions Hardware Encoding
1

Unfortunately it would seem I had a conversion fail (after many successful instances), and I am having a little trouble here tracking down exactly what happened, and would greatly appreciate any assistance in figuring this out.

From what I can tell, the NVidia hardware query passes (yay):

--> Checking presence and capabilities of NVidia NVENC Hardware encoder
2019-11-16T17:18:04 MCEBuddy.AppWrapper.NVidiaQuery --> Launching process C:\Program Files\MCEBuddy2x\nvidia\nvidiaQuery.exe
2019-11-16T17:18:04 MCEBuddy.AppWrapper.NVidiaQuery --> Process arguments 
2019-11-16T17:18:04 MCEBuddy.AppWrapper.NVidiaQuery --> UI Session Admin Process : True
2019-11-16T17:18:04 MCEBuddy.AppWrapper.NVidiaQuery --> Starting process as a UISession process with Admin privileges. This requires atleast 1 user to be logged into the system (remote desktop or locally)
2019-11-16T17:18:04 MCEBuddy.AppWrapper.NVidiaQuery --> Setting process priority to Normal
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> C:\Program Files\MCEBuddy2x\nvidia\nvidiaQuery.exe Starting...
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->  CUDA Device Query (Runtime API) version (CUDART static linking)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> Detected 1 CUDA Capable device(s)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> Device 0: "GeForce GTX 1050"
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   CUDA Driver Version / Runtime Version          10.1 / 7.5
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> Detected CUDA Driver version = 10.1
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   CUDA Capability Major/Minor version number:    6.1
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> Detected CUDA Hardware version = 6.1
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Total amount of global memory:                 2048 MBytes (2147483648 bytes)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> MapSMtoCores for SM 6.1 is undefined.  Default to use 128 Cores/SM
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> MapSMtoCores for SM 6.1 is undefined.  Default to use 128 Cores/SM
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   ( 5) Multiprocessors, (128) CUDA Cores/MP:     640 CUDA Cores
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   GPU Max Clock rate:                            1519 MHz (1.52 GHz)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Memory Clock rate:                             3504 Mhz
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Memory Bus Width:                              128-bit
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   L2 Cache Size:                                 1048576 bytes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Maximum Texture Dimension Size (x,y,z)         1D=(131072), 2D=(131072, 65536), 3D=(16384, 16384, 16384)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Maximum Layered 1D Texture Size, (num) layers  1D=(32768), 2048 layers
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Maximum Layered 2D Texture Size, (num) layers  2D=(32768, 32768), 2048 layers
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Total amount of constant memory:               65536 bytes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Total amount of shared memory per block:       49152 bytes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Total number of registers available per block: 65536
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Warp size:                                     32
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Maximum number of threads per multiprocessor:  2048
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Maximum number of threads per block:           1024
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Max dimension size of a grid size    (x,y,z): (2147483647, 65535, 65535)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Maximum memory pitch:                          2147483647 bytes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Texture alignment:                             512 bytes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Concurrent copy and kernel execution:          Yes with 2 copy engine(s)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Run time limit on kernels:                     Yes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Integrated GPU sharing Host Memory:            No
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Support host page-locked memory mapping:       Yes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Alignment requirement for Surfaces:            Yes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Device has ECC support:                        Disabled
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   CUDA Device Driver Mode (TCC or WDDM):         WDDM (Windows Display Driver Model)
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Device supports Unified Addressing (UVA):      Yes
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Device PCI Domain ID / Bus ID / location ID:   0 / 1 / 0
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->   Compute Mode:
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery -->      < Default (multiple host threads can use ::cudaSetDevice() with device simultaneously) >
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> deviceQuery, CUDA Driver = CUDART, CUDA Driver Version = 10.1, CUDA Runtime Version = 7.5, NumDevs = 1, Device0 = GeForce GTX 1050
2019-11-16T17:18:05 MCEBuddy.AppWrapper.NVidiaQuery --> Result = PASS

But then it seems to say that it cannot find hardware after all (boo):

2019-11-16T17:18:09 MCEBuddy.Transcode.ConvertWithHandbrake --> Cannot find supported h264/h265 software/hardware encoder combination in profile, disabling auto hardware encoder adjustments

And then would seem it switches to software and fails after this:

INFORMATION> 2019-11-16T17:18:09 MCEBuddy.Transcode.Convert --> Converting with Handbrake, type: SoftwareOnly, gpu: {
  "hardwareBrand": "Any",
  "codecType": "Undefined",
  "hardwareCodecPresent": false,
  "h265Codec": false,
  "h264Codec": false
}

The only thing I can think of is that the Plex Transcoder.exe was active while this was going on… is that a problem? I was under the impression that the GPU can be used by several applications at once, just like a CPU can. I am wondering if there is another setting somewhere I should consider here.

As always any time and assistance anyone can lend would be greatly appreciated. Attaching full logs.

College Football (2009) - S2019E2580 - Michigan State at Michigan.ts-Default-2019-11-16T17-05-29.9420785-05-00.log (1.4 MB)

2

More reference/context here. I was able to record another game while streaming/transcoding was occurring so it does not appear that this was a result of the GPU being in use.

It could be Plex-related, as well. It is in beta mode, after all. :laughing:

3

It’s actually detecting your Nvidia encoder but your profile is invalid so it disables any automatic adjustments.

If your profile handbrake-video contains encoder nvenc_h264, i.e. your profile is already set to use the hardware encoder. MCEBuddy is looking for either a software encoder, x264, to automatically enable its hardware adjustments or the handbrake-UsingHardwareEncoding=true directive in your profile which tells MCEBuddy that the profile is already optimized for hardware encoding and it shouldn’t change anything, just execute it, so it ends ups being an invalid profile.
Either switch the encoder to the software encoder in the profile or add the handbrake-UsingHardwareEncoding=true directive

1 Like
4

Ok! Awesome… thank you @RBoy your assistance is very much appreciated, as always. :blush:

My only question is… why did it look for (or try to change to) software encoding? It seems like it’s been doing hardware all this time, but perhaps I may be miss understanding something.

FWIW this is what my profile looks like now:

[Handbrake Cli 1.2.0 H265 - Quality 25]
Description=nVidia NVENC HW (H265) Quality Setting 25 + Decomb
order=handbrake
FixedResolution=true
handbrake-general=--loose-anamorphic --comb-detect=fast --decomb=mode=7 --verbose=2 --format av_mp4 --subtitle-lang-list eng,spa --all-subtitles --subtitle-default=1 --native-language eng --native-dub
handbrake-video=--start-at duration:0 --encoder nvenc_h264 --encoder-preset slow --quality 25 --vfr
handbrake-audio=--aencoder copy:aac --audio-lang-list eng --all-audio
handbrake-audioac3=--aencoder copy:ac3 --audio-lang-list eng --all-audio
handbrake-ext=.m4v
handbrake-audiodelay=skip
handbrake-UsingHardwareEncoding=true
PreConversionCommercialRemover=true

Let’s see how this does. :+1:

(BTW, I know it’s named H265 and it actually looks for h264 – I keep forgetting to change it! :laughing:)

5

It doens’t change it to software, by default all profiles that ship with mcebuddy have only software encoders. It looks for graphics cards and then changes them to hardware encoders at runtime if supported. If you’re creating a custom profile which is optimized for hardware encoding, then you need to let mcebuddy know now to start looking.

We’re going to change this in future and it mcebuddy detects that the profile has a hardware encoder then it’ll automatically set the hardware optimized flag <encoder>-UsingHardwareEncoding=true

1 Like
6

So, unfortunately, after configuring the above, I am still getting intermittent issues. Please see the attached.

It looks like Handbrake fails with a non-zero return code, so it would seem it’s in Handbrake’s court.

I will open an issue with Handbrake but wanted to verify here first to make sure there aren’t any further MCEBuddy settings to consider before doing so.

Log attached here: NFL Football - S2019E2191 - Chicago Bears at Detroit Lions.ts-Football-2019-11-28T16-35-04.5332992-05-00.log (1.3 MB)

7

Looks like your graphics driver is failing:

MCEBuddy.AppWrapper.Handbrake → Encoding: task 1 of 1, 0.00 %[h264_nvenc @ 000000000716bbc0] OpenEncodeSessionEx failed: out of memory (10)

1 Like
8

Dang… that would do it. :laughing: My video card has 2GB of memory on it, too. Again it’s intermittent and only occurs infrequently.

The video card drivers were a bit dated so I’ve updated them. Not sure if there’s not much to do here except get a bigger video card.

Thanks for your assistance, @RBoy. :+1:

9

That error is from the graphics driver, most likely a software memory leak than hardware issue.

10

OK thank you @RBoy… let’s see if the latest version attends to this issue, if not I am thinking there might be something with Plex that is causing this. :sweat:

11

If you’re using more than 2 concurrent conversions, NVidia graphics drivers will not let you do it as they have a hard limit of 2 simultaneous transcodes, see this post for more details:

1 Like
12

AH… I bet you that is what is going on! We have 3 Rokus in our household now and before I got the GPU one transcode stream was taking up 50-85% of the CPU.

So, I then put all streams to “original” so that there would be no transcoding.

Since getting the GPU, however, it turns out that running a transcode stream is peanuts (and what I would expect): around 5-10% of the CPU. Actually it was about 15% with two concurrent streams.

I haven’t tried it with 3 concurrent streams from our Rokus, but of course if there is a transcode that is occurring for post-processing that would put us in the scenario you describe. What a limitation. :stuck_out_tongue:

I will have to put more thought into how we want to handle this… thank you for the additional information and context. :+1: