I'm not getting HW transcoding with my J4105 NUC

[nmkaufman 43]

I did some testing today, and I'm not getting HW transcoding with my J4105 NUC, either. It has DX12 capable UHD 600 on the die.

 

I'd been writing it off for months as having to do with me not having a monitor attached, but I hooked up a monitor, mouse and keyboard, and it's still not working.

 

I'll backtrack for instructions, and upload logs.

[nmkaufman 43]

I was about to try installing the beta, but I'm using a Windows portable install (x64) and don't know where to find a link.

 

The installer won't do.

 

 

Found it. Trying now.

Edited January 30, 2020 by nmkaufman

[nmkaufman 43]

4.4.0.10 fixed it for me, and that hardware transcode is good stuff. Transcoded a 7 minute 1080P video to 360P in ~30 seconds.

 

Suspicions are confirmed that a monitor needs to be connected, and a local user session may even need to be logged in.

 

Is there a way for me to test whether or not it's working without logging into the machine? I'd be curious to know if it's working when running as a service, after a fresh reboot.

 

If there's a way to test that, I'll see if you even need a monitor plugged in, or if it's truly just RDP that breaks it.

[Happy2Play 7747]

4.4.0.10 fixed it for me, and that hardware transcode is good stuff. Transcoded a 7 minute 1080P video to 360P in ~30 seconds.

 

Suspicions are confirmed that a monitor needs to be connected, and a local user session may even need to be logged in.

 

Is there a way for me to test whether or not it's working without logging into the machine? I'd be curious to know if it's working when running as a service, after a fresh reboot.

 

If there's a way to test that, I'll see if you even need a monitor plugged in, or if it's truly just RDP that breaks it.

All you can do is test those variables.

 

Restart Emby and perform tests without a monitor connected, and don't have a RDP session.

 

You may have to set HWA to Advanced and only select the specific decoders and encoders that that work in your setup.

[softworkz 2619]

@@nmkaufman - I slit your posts into a separate topic.

[softworkz 2619]

4.4.0.10 fixed it for me, and that hardware transcode is good stuff. Transcoded a 7 minute 1080P video to 360P in ~30 seconds.

 

Suspicions are confirmed that a monitor needs to be connected, and a local user session may even need to be logged in.

 

Is there a way for me to test whether or not it's working without logging into the machine? I'd be curious to know if it's working when running as a service, after a fresh reboot.

 

If there's a way to test that, I'll see if you even need a monitor plugged in, or if it's truly just RDP that breaks it.

 

It's not always that RDP breaks it. We haven't found out under which conditions that happens.

 

D3D11 hardware acceleration should normally work always without a display, without a logged-in user and inside a service.

[nmkaufman 43]

I'll play around with it tomorrow, if I get a chance.

 

For now, I'm pretty content knowing I can get it working if I need it.

[nmkaufman 43]

I've determined that (with my setup, at least) no monitor is required.

 

I can log into the box with Google Remote Desktop without breaking quicksync transcoding.

 

Logging into the machine with RDP breaks quicksync until I log back in, either locally or with Google Remote Desktop (which emulates a local user.)

 

Nvidia users will want to do their own testing, because on my desktop machine I absolutely need a monitor connected in order to use the Nvidia Hardware (for Gamestream.)

 

The NVENC transcoding may still work, without a monitor, but I have no plans to test it at this time.

Edited January 30, 2020 by nmkaufman

[softworkz 2619]

For Nvidia hw acceleration, there's no connected display required. Never. And with no exceptions.

(Gamestream is probably a different story)

 

For QuickSync: The D3D11 variants don't need a display, neither a user session and they work from inside a Windows service. For the 'normal' QuickSync variants, the opposite is true.

 

 

For RDP, there's something you could try:

 

Open Group Policy Editor > Local Computer Policy and navigate in the tree as you can see in the title bar:

 

 

 

Go through all settings about "hardware" and "RemoteFX" and disable everything that seems to be related to hardware acceleration.

 

Reboot.

 

Let us know if that makes a change!

[nmkaufman 43]

Nice! That worked.

 

All I had to disable is the option you have highlighted in your post, and transcoding no longer breaks while / after signing into an RDP session.

 

No reboot even required.

[Luke 33666]

@@cayars can help add this to the hardware acceleration setup guide. Thanks.

[softworkz 2619]

@@cayars can help add this to the hardware acceleration setup guide. Thanks.

 

A separate article would be better. Then I could link to it.

[Carlo 4219]

Nice! That worked.

 

All I had to disable is the option you have highlighted in your post, and transcoding no longer breaks while / after signing into an RDP session.

 

No reboot even required.

So you set the option highlighted above to DISABLED and it worked for you?

[nmkaufman 43]

Correct, I disabled using the graphics card for hosting RDP sessions, and it no longer breaks HW transcoding / Quicksync.

 

It might make hosting an RDP session more taxing on the CPU, if that's a concern.

[Carlo 4219]

Thanks for the feedback nmkaufman.

I've update the hardware acceleration page for windows article with this information on connected monitors.