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>
The timestamp returned by mHostTime in the AudioTimeStamp structure
is the current timestamp equivalent to mach_absolute_time(), which
is relative to the machine's time base. In order to convert this
to milliseconds, it's necessary to get the host's timebase with
mach_timebase_info() and scale the timestamp accordingly, since
the rest of the timestamp synchronization code expects the timestamp
to be in milliseconds.
This is effectively equivalent to the code which was previously in
libobs/util/platform-coca.m, but must be applied here instead.
gxalpha