ScreenCapture
ScreenCapture copied to clipboard
high cpu usage
up to 80% cpu usages(4 cores cpu) for running it. anybody the same as me? how to resolve it?
Which encoder?
video : h264 audio : aac
I see, probably a need for upgrading the Nvidia/AMD driver then or even the hardware.
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
Hmm interesting, I 'll take a look.
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