ScreenRecorderLib
ScreenRecorderLib copied to clipboard
Error: The sample allocator is currently empty, due to outstanding requests.
Hello, I am getting a strange error the screenrecorder is failing from time to time with this error:
2023-09-18 15:47:00.433 [ERROR] [OutputManager.cpp | RenderFrame: 194] >> Writing of video frame with start pos 64702 ms failed: The sample allocator is currently empty, due to outstanding requests. 2023-09-18 15:47:00.434 [ERROR] [RecordingManager.cpp | operator (): 515] >> RETURN_ON_BAD_HR: hr=0xc00d4a3e, error is: The sample allocator is currently empty, due to outstanding requests. 2023-09-18 15:47:00.434 [ERROR] [RecordingManager.cpp | StartRecorderLoop: 744] >> RETURN_RESULT_ON_BAD_HR: hr=0xc00d4a3e, error is: The sample allocator is currently empty, due to outstanding requests. 2023-09-18 15:47:00.435 [DEBUG] [ScreenCaptureManager.cpp | CaptureThreadProc: 849] >> Exiting CaptureThreadProc
Do you have any idea what is happening here?
Best regards
What version are you using?
I'm able to provoke the error by removing the code that releases the IMFSample after it is written to the sink writer. It could be a case of samples not being properly released somewhere, the system running out of memory, or if you have disabled throttling in video encoder options, this could cause memory usage to grow until errors.
I was using the 5.2.0 version.
I have set the IsThrottlingDisabled property to false.
I will try to upgrade to latest version to see if that changes anything.
I updated the version to 5.3.1 and did some testing and it worked a couple of times but then it failed like this:
I never get the event OnRecordingComplete and the file is hold by the program and if i kill it the file is corrupt.
Any tips would be appreciated
Best regards
Can you try with this self contained test app, to rule out any differences in the .net versions, implementations, etc.
I did some testing and got this result:
I was running 10 runs, 10min recording.
Does it give you any clue?
The "access is denied" is caused by losing prileges to the desktop image, it happens for example when on the login screen, or when you get an UAC popup. Did you do a similar thing when it crashed?
It would help if you can log a crash with Trace and attach the entire log here.
Hmm not sure that I got a UAC pop or that I logged out, but did a new run with trace as debug option: Log_638308819328152179.txt
I have added the log file as you wanted.
Best regards
2023-09-21 08:36:30.860 [TRACE] [ScreenCaptureManager.cpp | CaptureThreadProc: 880] >> CaptureThreadProc waited for busy shared surface for 600 ms
2023-09-21 08:36:31.881 [TRACE] [OutputManager.cpp | RenderFrame: 227] >> Wrote video sample with duration 1020.68 ms
2023-09-21 08:36:31.882 [DEBUG] [ScreenCaptureManager.cpp | CaptureThreadProc: 877] >> Dropped DesktopDuplicationCapture frame because wait time exceeded limit
2023-09-21 08:36:32.904 [TRACE] [OutputManager.cpp | RenderFrame: 227] >> Wrote video sample with duration 1022.63 ms
2023-09-21 08:36:32.905 [TRACE] [ScreenCaptureManager.cpp | CaptureThreadProc: 880] >> CaptureThreadProc waited for busy shared surface for 954 ms
This is very interesting. Code is being triggered that should normally only happen when a recording is paused. Which means the IDXGIKeyedMutex is either not responding internally or executing excrutiatingly slow. Normally the max length for a frame is 500ms. I'm guessing it's the result of whatever causes the eventual MF_E_SAMPLEALLOCATOR_EMPTY error.
I've never seen this particular issue before, but it looks perhaps like a graphics driver or hardware fault to me. If you can't replicate it on another machine at least. Reinstalling drivers and updating Windows can help.
I have pretty much run the same test on another computer without any problem. I will try to update windows and the drivers. And run the test again.