obs-studio
obs-studio copied to clipboard
obsproject
[MacOS] OBS28 mac-screencapture intermittently freezes
Operating System Info
macOS 12
Other OS
No response
OBS Studio Version
28.0.0-rc2
OBS Studio Version (Other)
28.0.0-rc1 + rc2
OBS Studio Log URL
https://obsproject.com/logs/JHu75GvfsNg7w-h0
OBS Studio Crash Log URL
No response
Expected Behavior
Expected:
Application/Screen/Display capture should not stop unless requested.
Current Behavior
Intermittently, with no user input, the MacOS Screen Capture source (in any mode) will emit an error:
14:43:49.470: [ mac-screencapture ]: destroy_screen_stream: Failed to stop stream with error (null)
and stop updating the video capture in OBS.
Changing the "captured window/application" to another window and back will restart the capture successfully
Steps to Reproduce
- Capture a window/application/screen
- Wait long enough.
Anything else we should know?
Log file is from RC1, but have repro'd on RC2 as well.
Turns out it occurs without emitting the log entry. When I toggle "show cursor" (or any other property update) to resynchronize the video, I get the log message to emit.
After some digging - it looks like Jetsam is killing replayd when there is a low amount of memory pressure on the machine.
With launchd relaunching replayd, this explains why changing any property causes recovery.
This also explains the log message that is emitted when OBS attempts to teardown the current capture.
To me, this implies that we're getting caught somewhere in our application flow with an inadvertently blocking call (or mutex/semaphore/etc deadlock) in a case where we're no longer talking to the same replayd that has our ScreenCapture session.
A few likely leads appear to be:
https://github.com/obsproject/obs-studio/blob/1d8bfb833a62d273a37eac4e602f5b42a904c34d/plugins/mac-capture/mac-screen-capture.m#L334
and
https://github.com/obsproject/obs-studio/blob/1d8bfb833a62d273a37eac4e602f5b42a904c34d/plugins/mac-capture/mac-screen-capture.m#L530
In the latter case, we know that the event is being fired from the completion handler - so if the call at: https://github.com/obsproject/obs-studio/blob/1d8bfb833a62d273a37eac4e602f5b42a904c34d/plugins/mac-capture/mac-screen-capture.m#L515 hangs, we'll be stuck waiting for the event.
Dug in a lot more - this doesn't actually look like a deadlock.
We instantiate a Stream, and we get delivered frames to our CaptureDelegate. If replayd goes away underneath, OBS is unaware anything has changed, and simply isn't getting frames delivered. I've poked at a couple ways to detect this, but the underlying error handler is based on issues creating the stream.
This might necessitate something out of band (potentially via tick?) to detect the absence of delivered frames into the buffer, tear down our current StreamCapture, and re-init.
We are indeed investigating some unexplained behaviour of ReplayKit in relation to ScreenCaptureKit with Apple at this moment (there is another issue where starting a capture session leads to an unhandled error in ReplayKit which leads to locks never being released).
What could help us is if you could run log stream --system | grep "replayd" in a Terminal window while using OBS and trying to trigger the issue - the log stream should give us a bit more info about the state of replayd when the issue occurs.
replayd.log Here's a tee'd log from the above.
Jetsam OOM at 17:24:46. I noticed it around a minute later (17:25:30), and toggled "show cursor", which brought the capture back live.
It freezes when the apple menu hides! then goes back to normal if the menu becomes visible
is my problem here https://obsproject.com/forum/threads/obs-stop-record-the-image-after-sometime.160200/ related to this bugs ?
I also just experienced this. I'm not technical enough with OBS to help with the technical side, but I will watch out while using it for apparent triggers. What's also interesting is that this did not occur with my OBS version (28.0.3) for several hours of use (over several days) and then started doing it frequently today.
Mine doesn't freeze video, but it ceases to capture audio with the following log entries:
20:22:59.082: coreaudio: device 'Elgato Wave:3' disconnected or changed. attempting to reconnect 20:22:59.365: coreaudio: device 'BlackHole 2ch' disconnected or changed. attempting to reconnect 20:22:59.662: coreaudio: device 'MacBook Pro Microphone' disconnected or changed. attempting to reconnect 20:23:01.085: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS. 20:23:01.366: bmalloc: Allocating 0 bytes is broken behavior, please fix your code! This will crash in future versions of OBS. 20:23:01.818: coreaudio: Device 'MacBook Pro Microphone' [48000 Hz] initialized 20:23:03.166: coreaudio: Device 'Elgato Wave:3' [96000 Hz] initialized 20:23:03.407: coreaudio: Device 'BlackHole 2ch' [48000 Hz] initialized
Please provide the full log file when posting logs, snippets cut out potentially important information logged elsewhere in the file.
@jeremydk Are you using a dock / hub? I think my issue is related to an incompability between my SD5700T and Ventura since I have noticing audio cutouts that result in the OBS Mac Screen Capture audio ceasing. i.e., I no longer believe that my issue is related to OBS.
EDIT: Nevermind, further troubleshooting shows this happens when the dock is not connected as well. Continuing investigation...
OK, pretty sure I found and fixed my problem. I've been without any issues for the past 6 hours, whereas this issue was happening every 1-30 minutes before
I have an Elgato Wave Microphone, for which you can use Elgato Wave Link software for extra features. I do not use WaveLink, but I did have it installed. I noticed that when I run it, the problem happens way more often - every 3-5 seconds. My problem, as it turns out, is with the WaveLink audio driver plugin. Unninstalling WaveLink does not remove the plugin, it must be deleted manually from /Library/Audio/Plug-Ins/HAL.
While others may not have WaveLink installed, if you are experiencing similar problems I would recommend navigating to /Library/Audio/Plug-Ins/HAL, moving all the plugins out, and then moving them back one by one until you find which is/are problematic.
EDIT: OK, one more bit of crucial info - this seems to be related to anything that uses Rogue Amoeba's ACE audio driver (WaveLink uses it, along with Discord if you have set it up and most/all rogue amoeba products). That's right... ACE does not work with Ventura.
I was trying to reproduce this with logs, but at the end the obs process was ended unexpectedly
Here is last log line:
2022-11-22 22:19:53.497015+0200 0x5f5 Default 0x0 0 0 kernel: memorystatus: killing_idle_process pid 5609 [replayd] jetsam_reason->osr_code: 9
Here is log file: replayd.log
As a note here, we believe this is the same issue as #7663. Said issue is an issue with macOS that should be fixed with an upcoming beta version of macOS 13.1.
As I said, an upcoming beta version. This is not fixed in 22C5050e (Beta 3).
As I said, an upcoming beta version. This is not fixed in 22C5050e (Beta 3).
@gxalpha Why are you sure that the issue should be fixed with an upcoming beta version ? What version ?
Because we reported the issue to Apple and are in regular conversation with them.
Closing as a duplicate of #7663, as that other issue has more actionable information and less unrelated messages.