obs-studio
obs-studio copied to clipboard
obsproject
macOS application capture shows blank output
Operating System Info
macOS 14
Other OS
No response
OBS Studio Version
30.0.2
OBS Studio Version (Other)
No response
OBS Studio Log URL
https://obsproject.com/logs/18B7IX8RLz4pzc6u
OBS Studio Crash Log URL
No response
Expected Behavior
The source that I have for "Godot app capture" should actually be rendering the Godot application.
Current Behavior
The "Godot app capture" source has blank output.
Steps to Reproduce
The way this bug happens naturally seems to be shutting down my computer and then opening OBS from a fresh state. Application captures and even other sources like my webcam need to be updated. However, I have a consistent repro in the form of the following steps:
Prerequisites:
- Add a new macOS Screen Capture source to a scene.
- Set it up like this so that it's capturing Godot:
Steps:
- Open the properties for the source
- Open Godot
- Change the Application to Finder. Do not click "OK" to close the dialog yet, that way "Godot" will still show in the Application dropdown.
- Quit Godot completely
- Change the screen capture to Godot
- Open Godot
At this point, you'll see a blank window despite Godot being open.
Anything else we should know?
Here's a video repro of this happening.
The workaround is to toggle to a different application and then toggle back.
At least given the reproduction steps that is entirely expected behaviour:
- The list of available applications is not automatically refreshed in the background, it is generated when the property window is opened or when the capture type is changed
- When you close Godot with the property window open, it will only hold the old reference to the running application which is obviously invalid when you close the app
- If you reopen the app it will not automatically be inserted/replaced in the dropdown
- By re-selecting Godot you configure the source to use a non-existing application instance
It should be noted that if the property is not changed, the capture will automatically pick up the application if it's relaunched (at least all applications I tested with did so).
(The important distinction being that to configure an SCK capture one has to pass a SCRunningApplication array which contains process IDs. Once configured, SCK will be able to automatically capture re-opened applications with the same bundle ID, but the SCRunningApplication reference we still hold is invalid (as the process ID is invalid and even if it would collide with an existing ID, the bundle identifier wouldn't match), so we cannot reconfigure the capture with the old entry).
Hey Pat, thank you for the response! The repro steps aren't exactly real; I end up reproing this somehow just by rebooting my computer. Based on your response, it sounds like OBS shouldn't be "forgetting" windows though—is that right? Are there any logs I can capture when I see that happening? I tend not to even notice that some source isn't showing until I switch to the scene and see chunks of the scene missing.
Hi! Although about every user will dislike that's actually a feature. It seems Mac OBS saves process ID as source so as you close and open the application again or restart the computer, it captures no longer.
Hey Pat, thank you for the response! The repro steps aren't exactly real; I end up reproing this somehow just by rebooting my computer. Based on your response, it sounds like OBS shouldn't be "forgetting" windows though—is that right? Are there any logs I can capture when I see that happening? I tend not to even notice that some source isn't showing until I switch to the scene and see chunks of the scene missing.
OBS will store one of three things for a SCK capture source:
- The display UUID (for display capture)
- The app bundle (for application capture)
- The window ID (for window capture)
The display UUID and app bundle ID are both pretty stable and will allow OBS to restore a capture after restarting the computer, the window ID is ephemeral though and will obviously change between restarts. As such, if you restart your computer, the window ID will not necessarily match and as such we cannot re-initialize the same capture.
When just relaunching OBS, those values obviously won't change, so everything is restored just fine.
When you close the lid of your Macbook however, you suspend the OS and the capture is suspended as well and macOS does not automatically restore terminated capture sessions. OBS is also not programmed to be aware of this kind of suspend (it's uncommon for Windows-based desktop PCs and that's OBS' main platform).
So what we'd need to do on OBS' side is detect when the application awakes from sleep and re-initialise the captures automatically. That would solve only the "closing the lid" use case, but it's also something we haven't implemented any code for.
So for the time being, consider "closing and re-opening the lid while OBS is running" an unsupported use case.
It should be noted that the Deprecated Window Capture source works as expected - the capture persists through app restarts, system reboots, and the app destroying and respawning its window (as in Keynote switching between edit and present modes). So it is possible to capture the window in a persistent manner.
It should be noted that the Deprecated Window Capture source works as expected - the capture persists through app restarts, system reboots, and the app destroying and respawning its window (as in Keynote switching between edit and present modes). So it is possible to capture the window in a persistent manner.
The deprecated source just creates screenshots of a window on a timer (hence why it's performance scales negatively with the size of the captured window) and uses the window title to find a capture target.
The modern capture source uses the SCK framework and works entirely differently as we request macOS to capture a display/app/window for us and send us the captured frames. It's an entirely different implementation using different technologies.
We also opted to work with a consent model closer to macOS' own, namely that consent needs to be unambiguous for privacy reasons and for windows this means the specific instance of a window identified by its ID.
With the screen sharing picker introduced in Sonoma it's also obvious that the intended flow on macOS is for applications like OBS to offer themselves as targets for screen sharing and users actively selecting windows to share from within the windows and not the other way around (OBS picking which windows to capture):
Once this is implemented, I can see an evolution of the current capture source to allow for more advanced use cases again that properly communicate the risk of features like "follow the window title" and require users to actively confirm that they understand that it can mean stuff automatically appears on stream that they'd rather not.
Hey, thank you for the responses! I just wanted to add some clarifications that are probably already understood:
- I'm not on a laptop, so "closing the lid" is just rebooting my computer in this case.
- This also happens with video captures. E.g. I have a webcam that is plugged in through USB, and occasionally, I need to select it again in OBS for OBS to capture anything.
- I don't think I had problems with rebooting back when I was on Windows.
(again, maybe none of that is news, in which case please ignore it 😅)
I totally understand that my scenario may be unsupported, but I'd be remiss if I didn't ask: are there any workarounds? I have a scene that captures:
- Specific Chrome window X
- Specific Chrome window Y
- Specific Discord window Z
- My camera (not the webcam that I mentioned earlier)
The camera never has any issues, but it takes me time to select each of the three specific windows, and I can only do it while live-streaming since those windows aren't actually open until I need them (one of them is a Discord video call). Could I maybe make a plug-in that sets the scene source through Python based on window titles...?
I'm going to close this issue since it sounds like everything is working as intended. Thank you again for the discussion. 🙏