Instead of capturing compressed video, you may use the 'Framer' callback. This returns a raw RGBA upside down array of your requested resolution as long as you return S_FALSE. Once you return S_OK, then the function returns.
I downloaded and ran the sample project you provided. Really very cool, so thank you. I must be missing some step because it doesn't record audio. The sample project is set to record audio, but when the application runs through to this line
dp.HasAudio = 0;
ains is empty and HasAudio is set to 0. The computer has working audio and when I have started the sample application, I have had music playing in an attempt to have something to record... But I have yet to capture audio. I have yet to have ains populated with anything...
Any thoughts? Pointers on troubleshooting? Thanks for your time.
Hi, great library! Your test program worked very well (VS2019 on Win 10), then I tried to encapsulate it in a class to embed in my MFC application. On MFC I have to manually declare the libs to link with, I investigated to find that they are:
Basically the class creates a thread which in turn calls DesktopCapture, so the main UI thread does not get blocked. Whenever I call it, it returns error -10 "The data specified for the media type is invalid, inconsistent, or not supported by this object." I suppose I'm missing something but can't find it, any ideas? Thanks!
Michael, thanks for responding. What I did basically was to create a C++ class CScreenRecorder that creates a worker thread, which is the one that calls DesktopCapture. Yes, I call CoInitializeEx() and MFStartup() both in the main thread and in the actual ScreenRecorder worker thread. I had to separate the definition of DESKTOPCAPTUREPARAMS to ScreenRecorder.h so it was known in my class without having to include capture.hpp more than once. ScreenRecorder.h is the file that also #includes all the files that appear in your stdafx.h. Other than that, the only change to capture.hpp was to enclose the DESKTOPCAPTUREPARAMS definition inside the classic
That means, I am using exactly the same capture.hpp that runs in your solution, didn't change the encoder nor anything. When I don't call MFStartup(), it would return error -3. It happens both in 32- and 64-bit compilations. Since your solution works perfectly in the same PC, I was wondering whether I was linking with the right libraries, or whether some obscure setting of Visual Studio for MFC projects affects its behavior... I could not find in your solution how or where do you specify the MF libraries, since it links correctly although they are not mentioned in the project. The error that appears in the output window is "Exception thrown at 0x00007FF892ECA839 (KernelBase.dll) in BCGTest.exe: WinRT originate error - 0xC00D36B4 : 'Media type MF_MT_FRAME_SIZE(Height) is not compatible with the format MF_MT_SUBTYPE'." which matches the line that generates error -10 (lines 1360 to 1366 in capture.hpp):
hr = pSinkWriter->SetInputMediaType(OutVideoStreamIndex, pMediaTypeVideoIn, NULL);
if (FAILED(hr)) return -10;
The "WinRT" part of the error confuses me because I don't use Windows RT at all, this is a standard AMD Ryzen PC. Thanks again!
must be an even number. Sending and odd number causes it to fail and return -10.
It also seems like it also doesn't like when a monitor has negative X coordinates, I will try to do something to automatically convert negative coordinates to the proper monitor number. But does that mean then that it is not possible to record a region that covers more than one monitor?
Thanks for the info about the rect, I will check. There is the output parameter in the structure that allows to choose which monitor is to be captured, but I don't think it can capture both monitors at the same time.