Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

high cpu usage #3

Open
ixlm opened this issue Jun 2, 2020 · 6 comments
Open

high cpu usage #3

ixlm opened this issue Jun 2, 2020 · 6 comments

Comments

@ixlm
Copy link

ixlm commented Jun 2, 2020

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

@WindowsNT
Copy link
Owner

Which encoder?

@ixlm
Copy link
Author

ixlm commented Jun 3, 2020

video : h264
audio : aac

@WindowsNT
Copy link
Owner

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

@pabloko
Copy link

pabloko commented Feb 16, 2021

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

@WindowsNT
Copy link
Owner

Hmm interesting, I 'll take a look.

@pabloko
Copy link

pabloko commented Feb 16, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants