Adds a switch to distinguish between the possible results that could
occur. While we expect to received RequestCompleted for our camera
extension (RequestWillCompleteAfterReboot is usually more of a network
extension thing), we can't be sure that this always is what we receive
unless we check it.
OSSystemExtensionErrorRequestCanceled is called when the activation
delegate returns OSSystemExtensionReplacementActionCancel on request
actionForReplacingExtension withExtension. As per the previous (parent)
commit we no longer request cancellation, so we can be sure that
receiving a "cancelled" error is an actual error and not something that
is supposed to happen.
This commit also removes the "error" from the log prefix, as the message
sent may also be a warning instead, and the LOG_LEVEL conveys the
severity of the log line anyways.
Current code assumes that a newer version of the extension is always
better. However that's not true - when the user installs an old version
of OBS, we should also install the old version of the camera extension
to have a version compatible with the installed OBS.
For normal users this method is only called when the versions in the
Info.plist do not match. In system extensions developer mode it's called
every time an installation is requested (meaning on every start), which
is probably desired as well; and by never returning
"ReplacementActionCancel" we can now always treat "ErrorRequestCanceled"
as an error and not something that we requested to happen.
Creation of Info.plist files through Xcode is more canonical and
future-proof, as it will automatically pick up changes/updates
introduced by Apple. Non-standard keys can still be added via a
template file, which will then be extended by Xcode with the default
keys.
Compiler extensions are disabled before the first `project` call to
force CMake into considering compilers to not support GNU extensions
(even though clang and gcc do).
Also sets common clang compiler options so they can be used across all
supported platforms.
`openmp-simd` support is enabled by default as there is no performance
penalty on x86_64 systems and intrinsics are enabled on arm64.
Also implements CMake's `CMAKE_COMPILE_WARNING_AS_ERROR` flag to
enable the desired behavior and configuration time.
Effectively reverting parts of d314d47, this commit removes the new
functions that got added to remove the flags parameter. Instead, it just
marks the parameter as unused and documents this. Having what is
effectively an API break just to remove a parameter is a bit overkill.
The other parts of d314d47 which cleaned up the usage of the flags
parameter are untouched here.
The pixel buffer pool is used to create pixel buffers with both the CMIO
extension and the DAL plugin. As such, it is created independent of
which camera type is used, and should be released independent of it as
well.
This deprecates the following functions, replacing them with new
versions:
- `obs_output_can_begin_data_capture()` - now `*capture2()`
- `obs_output_initialize_encoders()` - now `*encoders2()`
- `obs_output_begin_data_capture()` - now `*capture2()`
The flags parameter was initially designed to support audio-only or
video-only operation of an output which had the `OBS_OUTPUT_AV` flag,
however, full support for that was never implemented, and there are
likely fundamental issues with an implementation, mainly that most
outputs are programmed assuming that there will always be at least one
audio and one video track. This requires new flags specifying support
for optional audio/video, among other things.
An implementation to allow audio/video to be optional is best done
using the flag technique above, with audio/video enablement specified
by whether media (raw, `video_t/audio_t`) or encoder (`obs_encoder_t`)
objects are specified.
Since every implementation I could find always specifies `flags` as 0,
I was able to safely conclude that immediately removing the parameter's
functionality is safe to do.
Camera Extensions require specific entitlements for the hosting app,
which also require a provisioning profile. To avoid breaking local
builds that do not require the camera extension, an additional
entitlements file that will not trigger the provisioning profile
requirement will be used if the virtualcam (but not the Camera
Extension) is configured.
With the recent change to enforce C17 standard for compilers, default
visibility was also enforced to be hidden. This also automatically hid
the `PlugInMain` symbol required for DAL plugins. Adding the
`__exported` decorator makes the symbol explicitly visible.
All presentation time stamps are rounded to whole seconds during the
conversion from nanoseconds to seconds, because of the immediate cast
to `int64_t`. This results in the same presentation time stamp being
send to consumers for a whole second.
In previews/live streams this isn't super visible as last frame is
often assumed to be the newest and the stream is updated. It's more
problematic when recording since APIs like Apple's AVFoundation don't
allow duplicate presentation time stamps or it can look like frames are
produced in huge bursts once per second.
In this PR `CMTimeMakeWithSeconds` is used instead of `CMTimeMake` to
make sure the conversion is done correctly and simplify the calculation
we have to do a little.
The `fillFrame` method of the mac-virtualcam plugin is creating samples
directly using the value from `mach_absolute_time()` as `hostTime`.
This assumes this value is in nanoseconds, while it is in fact in mach
tick units. On Intel Macs mach tick units will be exactly 1 nanosecond
resulting in valid values, but on Apple Silicon macs this is no longer
the case.
This results in sample buffers with the placeholder image that have
much lower presentation time stamps than the samples containing content
produced by OBS. In previews/live streams this shows due to the last
content sample being shown frozen until the whole buffer is filled with
samples containing the placeholder image. Applications recording the
video stream are even more confused and crash or record videos with
wildly incorrect lengths.
In this PR `clock_gettime_nsec_np` is used to convert from mach tick units
to nanoseconds. This will make sure the `hostTime` value is correct on
both Apple Silicon and Intel macs. Making sure we produce stable
presentation time stamps from the virtual camera plugin at all times.
CMake build framework 3.0 introduces more strict typing checks, which
require additional code fixes to silence.
* Fixes warnings about implicit casts
* Fixes warnings about weak references used multiple times inside
blocks
The DAL plugin-based virtualcamera shares data between OBS and the
plugin using an IOSurface. IOSurface locks are necessary to ensure
race conditions between data generation (OBS side) and consumption
(virtual camera side) and also that an IOSurface is not offloaded to
GPU memory when it is indeed needed in CPU memory.
Also moves the invalidation of the NSMachPort for the frames to after
the IOSurface data has been converted into a pixelbuffer and added to
the frame queue of the virtual camera, as an early invalidation will
cut off access to the pixel data shared with the DAL plugin.
IOSurface locks are only necessary when any processing with the data
contained in the surface is done and an explicit copy of data from GPU
memory back to CPU memory is needed.
Apple Silicon-based Macs have a unified memory architecture, as such
an IOSurface will always be available in memory accessible to the CPU
and GPU (and an off-load of the IOSurface will not take place).
eGPUs are not supported on Apple Silicon-based Macs either, so an
IOSurface lock to ensure data is copied back to CPU memory is not
necessary.
Without invalidating the mach port used for sharing the IOSurface
between OBS and the application displaying the virtual camera output,
IOKit seems to run into the issue of receiving "shared" mach ports,
possibly because of port exhaustion. IOKit requires a "new" port
however and crashes upon that error otherwise.
Co-authored-by: Steven Michaud <smichaud@pobox.com>
The root cause of the issue is `swscale` dropping the second plane of
biplanar pixel data, resulting in an "incomplete" frame being fed to the
CVPixelBuffer.
As CVPixelBuffers have dedicated support for full range colour, use
these directly, which improves performance even further (as any
conversion for full range data is avoided as well).
To ensure that OBS does not implicitly enable conversion via `swscale`
a video conversion struct needs to be set in any case, ensuring that the
output range and colourspace match the output configuration.
This issue primarily seems to affect Intel-based Macs without unified
memory: While an IOSurface is supposed to be shared via a mach port
with other processes, each process needs to lock the surface during
access (as is common with other shared resources).
Apple Silicon-based Macs seem to be less affected as a switch between
GPU and CPU memory (which can happen dynamically for IOSurfaces) would
still point to the same unified memory.
