ScreenCapture icon indicating copy to clipboard operation
ScreenCapture copied to clipboard

high cpu usage

Open ixlm opened this issue 5 years ago • 6 comments

up to 80% cpu usages(4 cores cpu) for running it. anybody the same as me? how to resolve it?

ixlm avatar Jun 02 '20 02:06 ixlm

Which encoder?

WindowsNT avatar Jun 02 '20 11:06 WindowsNT

video : h264 audio : aac

ixlm avatar Jun 03 '20 01:06 ixlm

I see, probably a need for upgrading the Nvidia/AMD driver then or even the hardware.

WindowsNT avatar Jun 03 '20 04:06 WindowsNT

Great work @WindowsNT, following this issue, i'm a bit profane on dx11 but to me it seems like theres unnecessary copy of the video texture in CAPTURE class, the desktopdupl texture is being copied to a texture with CPU access, blend the mouse pointer and mapped again to the gpu, do you think this is the case?

I'd rather keep the texture always on the gpu and create the IMFMediaBuffer by using MFCreateDXGISurfaceBuffer instead MFCreateMemoryBuffer

pabloko avatar Feb 16 '21 01:02 pabloko

Hmm interesting, I 'll take a look.

WindowsNT avatar Feb 16 '21 10:02 WindowsNT

I've just tried it by copiying CAPTURE::Get to ::Get2 and trimming it where lGDIImage (which im using as surface) is complete.

So the part of DesktopCapture looks like this:

            if ( lDesktopResource && !cap.Get2 (lDesktopResource, dp.Cursor, dp.rx.right && dp.rx.bottom ? &dp.rx : 0) )
                break;

            if ( !pVideoBuffer )
            {
                hr = MFCreateDXGISurfaceBuffer (IID_ID3D11Texture2D, cap.lGDIImage, 0, 0, &pVideoBuffer);
                if ( FAILED (hr) ) break;
            }

            hr = pVideoBuffer->SetCurrentLength (VideoBufferSize);
            if ( FAILED (hr) ) break;

            CComPtr<IMFSample> pVideoSample = NULL;

It seems the call to SetCurrentLength must be done or framesink->write will fail with INVALIDARG, apart from that, lock-memcpy-unlock can be removed, and also all the mapping of the image to a memory buffer (cropping should be reimplemented at dxgi level)

Also related to this issue i've noticed that my cpu usage is 5% without audio and 25% with it, so maybe theres some spinlock on that code path, ill try to review later.

Best regards

edit: Checked that silence generator thread had a spinlock, Sleep (1); at init of loop solved it

pabloko avatar Feb 16 '21 13:02 pabloko