Using UUIDs to store display references in obs-studio's settings file
allows us to "rediscover" devices even between restarts
(as CGDirectDisplayID changes between those) and select the same device.
Xcode 14.3 and the macOS 13.3 platform SDK introduced a few breaking
changes:
* Updated AppleClang emits warnings about unqualified std cast calls
when using C++ - as `move` is too broad a word, developers are to use
`std::move` to make this explicit. Alas this is exactly what `json11`
uses and because that library is archived, there is no possibility
of an upstream update.
* Apple guarded calls to old screen capture APIs as "available but
deprecated", but seems to have chosen the wrong lower version
boundary: The calls are flagged as being available for macOS 13 and
macOS 14 only.
To fix this, the existing macOS platform SDK header is replaced by a
local copy that uses macOS 11 as the lower boundary (the oldest macOS
version supported by obs-studio anyway)
The current method would enum though all devices looking for a matching
uid instead of directly asking for kAudioHardwarePropertyDeviceForUID.
Asking directly instead would also enable finding hidden devices that
can only be found directly via uid and not via enumerating (were we ever
to need to find such a device).
SCK has too many open issues on macOS 12 to enable full functionality
on that version. Window Capture has the biggest performance uplift and
so far the least amount of quirks, so leave this variant (with the
"Beta" qualifier) for macOS versions before Ventura.
Per OBS API documentation, `get_properties` can be used to get the
properties of a source, but also of a source type. The latter would
pass a NULL pointer for a given source.
This adds the necessary change to avoid crashing OBS by passing such
a null pointer.
SCK has too many bugs on macOS 12 that don't like they will get fixed or
backported for it to be the recommended capture source.
This commit removes the "Deprecated" flag from traditional capture
source if the user is on macOS 12 (even if SCK is available) and marks
SCK as Beta.
This was necessary since the default background color was meant to be
clear, but wasn't set properly. The bug is fixed in macOS 13 Beta 6, so
we can remove this statement.
Adding all windows manually means that any windows opened after the
session was started won't appear. This instead excludes the Control
Center from Display Capture. While unfortunate, it seems to be the only
thing on the display that can't be disabled.
When the ScreenCaptureKit-based source is generated, the window ID
read from the settings will be empty and interpreted as window ID "0".
This window ID doesn't represent a valid window, but the capture stream
is nevertheless successfully initialized with that value, but will not
generate any output.
Worse, the activated stream should be destroyed when a new stream is
created, but creation will throw an error.
This commit ensures that a valid window ID is used if no good default
value is available, ensuring a working (and destroyable) stream.
Also removes any remaining usage of the old window-utils.
Initializing a display stream with a content filter which excludes an
empty list of windows leads to a broken stream. Initializing with a list
of all available windows as a workaround re-enables functionality.
Reduces the amount of calls to the update callback (also reduces amount
of calls to check for available capture content).
Also moves some code to only update data for currently selected capture
type.
Whereas the `availability` checks will correctly detect macOS 12.5,
the `__MAC_OS_X_VERSION_MAX_ALLOWED` macro is dependent on the platform
SDK. The most current platform SDK is 12.3, hence why this version
needs to be checked for.
SCK's application list has one entry with empty name and bundle ID which
belongs to WindowServer. This is not worth exposing since an empty entry
would confuse users and nothing would get captured if selected.
Marking a source as deprecated will make it harder for users to find
when creating a new source. We don't currently plan on removing
traditional display and window capture, however ScreenCaptureKit will be
the preferred capture method going forward.
on the capabilities of audio capture refer to the documentation https://developer.apple.com/documentation/screencapturekit/ or watch the session "Meet ScreenCaptureKit".
Currently audio capture typically happens via virtual devices set up with 3rd party products. This requires additional installation and configuration by users.
Including the audio with the existing CMBuffers will make it easier to manage audio sync with video frames. Additionally, you can capture distinct audio tracks from multiple apps at once,
like a call with friends + screen content.
macOS 13 on a 2019 16" MacBook Pro
macOS 13 on a 2022 M1 Pro Macbook Pro
Tested with multiple games + Discord, FaceTime, Apple Music and Safari tabs playing audio content.
* Bug fix (non-breaking change which fixes an issue)
* Performance enhancement (non-breaking change which improves efficiency)
* Additional control over what audio content to capture
* Logic to manage audio & frame sync
Replaces the current implementation of Window Capture, which uses Core
Graphics to render a bitmap raster, with one that accesses the window's
CGImage bitmap directly, blits it, and hands that off as a frame to OBS
instead.
Co-Authored-By: Sebastian Beckmann <beckmann.sebastian@outlook.de>
