Hardware Accelerated Video?

[etb]

Does LMI Central use hardware acceleration for encoding/decoding the video stream, and is the codec published? 

I can only really speak anecdotally, but I feel like the CPU and GPU usage attributed to a LMI remote control session have increased maybe within the past ~year.  Maybe both CPU and GPU usage on both sides used to be like 8% to 10%, but now they're both 16% to 20%.  I notice this on both the host computer as well as the client computer.  But I haven't knowingly changed any settings (quality, color, resolution, quantity of monitors, OS, activity on the host computer, etc).

So my (perhaps uninformed) hypothesis was that like maybe LMI used to use H.264, but then maybe recently switched to H.265 or AV1?  In my hypothesis, the increased usage I think I'm seeing could be attributed to using a more resource-intensive codec, or a codec which my graphics cards don't support for hardware acceleration.

All of the computers in question are workstation-grade with i7 processor and discrete GPU (and 16GB+ RAM, SSD, 300Mbps+ internet connection, etc).  My client computer is a little old, and probably due for replacement.  So if I should try to target a new computer/GPU which could support hardware acceleration that would work with LMI, then I can look into that.  Likewise, we could target certain GPU hardware as we gradually/normally replace host computers in the office.

[VBGuy]

Hello etb -

I am not sure about the CPU / GPU mix on these machines, but I will work on that aspect.

Thanks for your reply.

[KateG]

Hi @etb  nice to see you around,  

Generally speaking, if you are having an issue the first step is to check for video driver updates from the manufacturer and if there are none or the new driver does not correct the issue then try disabling it.

It can be disabled as mentioned in this article. 

[VBGuy]

Hi KateG-

I disabled the "Use Display Accelerator", but made no difference.

Thanks for your input.

[etb]

Hi @KateG ,

Sorry, I did look into this the same day that you had posted it, but I forgot to post back.

It's not that I have an "issue" per se, but just rather that I'm looking to optimize for the future if possible. 

To try to pose the question in a more straightforward manner:  are there some particular hardware qualities which would be most optimum going forward?  For example, if we made sure to get GPU's that support whatever hardware-accelerated encoding that LMI uses?

In a more dense and specific example, the particular host computer I'm using right now has an Nvidia T1000 GPU, and NVENC with that GPU does support various flavors of H.264 and H.265, but it does not support AV1.  Other host computers have older GPU's, and NVENC on those only supports H.264.

For what it is worth, I did try switching off the "Display Accelerator" as per the link you had posted.  I did then try disconnecting and reconnecting to the host computer, but that didn't seem to change the CPU or GPU load, so I was guessing that perhaps it takes a reboot in order to actually disable the Display Accelerator.

Also for what it is worth, I (anecdotally) notice the increased CPU and GPU usage between multiple different hosts and clients all with different hardware, so I wouldn't think that it is any particular driver.  (We also do keep drivers up to date.)

So I will try to find time to test at some point.  But basically I am asking a general question about optimizing new hardware purchases for hardware-acceleration of LMI.

[etb]

I ended up having a little time to tool around tonight.  Possibly some interesting findings:

On my host computer with the "Blank Screen" option enabled , and the "Display Accelerator" enabled, and nothing running on the host other than task manager (and LMI):

• LMI Remote Control Application process is using about 8-9% CPU and 0% GPU
• Desktop Window Manager process is using ~5-6% CPU and ~18-22% GPU

On my host computer with the "Blank Screen" option disabled , and the "Display Accelerator" enabled, and nothing running on the host other than task manager (and LMI):

• LMI Remote Control Application process is using about 0-3% CPU and 0-8% GPU.  0.3% GPU when fully idling, or up to 8% GPU when there is more motion on the host screen.
• Desktop Window Manager process is using ~0% CPU and ~0% GPU

I tried turning "Display Accelerator" off and rebooting the host and testing again.  The CPU and GPU usage percentages were still the same as above (both when Blank Screen on and Black Screen off).

On my client computer with the "Blank Screen" option enabled , and nothing running on the host other than task manager (and LMI):

• LogMeIn Client process is using about 10-18% CPU and ~0% GPU 
• Client Server Runtime process is using about ~0% CPU and 10-25% GPU (mostly around ~18% GPU, and only momentary spikes to ~25% GPU when there is a lot of motion on the host screen)
• Desktop Window Manager process is using ~2% CPU and ~0% GPU

On my client computer with the "Blank Screen" option disabled , and nothing running on the host other than task manager (and LMI):

• LogMeIn Client process is using about 1-8% CPU and ~0% GPU 
• Client Server Runtime process is using about ~0% CPU and 0-15% GPU (mostly around ~0.5% GPU, and only momentary spikes to ~15% GPU when there is a lot of motion on the host screen)
• Desktop Window Manager process is using ~0% CPU and ~0% GPU

So it seems like it is "Blank Screen" which is comparably very resource-intensive - somehow on both the host and the client.  So are there some hardware properties/specs which would be more optimized for use with "Blank Screen"?

[VBGuy]

Hello etb -

Thanks again for your deep research into this issue.  You have much more knowledge about the CPU / GPU mix than I, and I appreciate your input.

At least one of the laptops is now working properly, probably because of disabling the Display Accelerator AND rebooting.  (I don't think I rebooted in my previous attempt.)

Still waiting to gain access to 3 other laptops to test this theory.

Cheers!

[KateG]

@etb thanks for sharing your input with the Community, as others are finding it helpful. 😊

You can find the minimum requirement for Screen blanking here. Otherwise, could you let me know a bit more about what you are thinking on hardware properties/specs that would be more optimized for use with "Blank Screen"?

[etb]

Hi @KateG ,

Thanks for not giving up on me yet - I know that walls of text can be brutal 🙂

I don't mean to overexplain this, because I'm definitely very far from an expert, and I could be wrong about details.  But basically I'm drawing the parallel to hardware-accelerated video encoding and decoding.

An example with which we might be more familiar is like watching videos from the internet.  If you would pull an old laptop off the shelf and watch a video, you might find that playing the video uses like 25%+ of CPU and kills the battery quickly.  A more modern laptop would have a much easier time playing that same video.  The reasons the modern laptop would be so much more efficient with playing the video are many, but one big reason is that the modern laptop would likely have hardware-accelerated video decoding such as Intel Quick Sync, or Nvidia NVDEC, etc.  As long as the software being used supports using hardware acceleration, and as long as the hardware supports the codec in use, the specialized hardware can be used to very efficiently decode the video (low CPU/GPU usage).

So, tying it back to my question here: is there some particular hardware which can run Screen Blanking notably more efficiently - similar to how hardware with Quick Sync or NVDEC can play videos much more efficiently?  Maybe the GoTo developers might say that LMI is using a certain codec, or that Screen Blanking is most optimized for a certain API, and so therefore a particular generation of graphics cards (or newer) would run things notably more efficiently?

[VBGuy]

Well, Screen Blanking on the Host side seems to have fixed the problem for at least one more laptop. 

Still waiting to gain access to the rest.