A bug which was technically introduced in df446c3f6e: the author
assigned video mixes to the virtual camera and did not realize you have
to wait for full capture stop with the "deactivate" signal rather than
the "stop" signal. This situation is understandable because these
signals are likely confusing and need more documentation.
The way an output works when it stops is it has three stages:
- "stopping", which is the moment the user themselves stop the output
- "stop", when the output's implementation has stopped and returns
success or an error code
- "deactivate", when the output inself (not the implementation) has
fully stopped capturing encoded or raw frame data after the
implementation has stopped. This is done in a separate thread,
end_data_capture_thread(), for performance and data race reasons, and
is when it's "actually fully stopped for real this time"
(Lain note: I sincerely apologize for this confusing signal design)
The author of df446c3f6e was likely confused as to why they could not
destroy the video mix in the "stop" signal without triggering a race
condition in end_data_capture_thread(), and instead decided to make a
workaround to clear the video mix set to the output before destroying
the video mix. Unsetting the video mix I'm guessing *seemed* to fix the
problem for them at the time, and destroying the video mix separately
after that automatically stops capture, so it *technically* worked
because the deactivate thread cannot be called until the
implementation's stop signal has executed. However, it was still the
incorrect way to handle the problem, because it circumvents the output's
mechanism for deactivating the frame data capture by destroying the view
instead.
The reason this was the incorrect way to handle the problem became
exposed in 7cd7ca80f8, when tytan made it so it uses the main video mix
under certain circumstances. The main view is special and cannot be
destroyed, so the mechanism to stop frame data capture that the
virtualcam was using before failed, and raw frame data capture continued
perpetually until the end of the program erroneously.
This fix solves the bug by using the "deactivate" signal rather than the
"stop" signal, thus allowing the output to fully end its data capture
and *then* destroy the video mix.
Fixesobsproject/obs-studio#9153
Allows the use of OAuth credentials set up via environment variables
(as used on CI) without the need for extra plumbing via build scripts.
Also sets GPU_PRIORITY_VAL via preset on Windows.
This cleans up the fairly arbitrary Windows includes and types and
unused functions from the common code and replaces them with platform
independent equivalents, or platform specific implementations in
common_utils.
This removes the Windows 8 support to avoid adding an additional
platform function to query this. OBS only supports Windows 10
officially, so it's about time we removed it.
Replace the checks based on D3D11 and D3D9 to check a more informative
variable aptly named UseTexAlloc for which memory allocator should be
used within the encoder.
The query being done will ovewrite ALL invalid parameters. This results
in invalid parameters that are not LowPower settings being overwritten
with 0 either introducing different errors or possibly different
behavior.
This log line was introduced in 239e9273d and looks like it was for
debugging purposes. It always prints an error message when an SCK audio
capture source was successfully created.
Generated post build action batch scripts retained an empty token to
the copy command with the used generator expression (as PDBs are only
generated for Debug and RelWithDebInfo configurations).
Moving their copy step into its own command (and using the `true`
CMake command, which is a no-op) ensures that builds in Release and
MinSizeRel correctly finish this step.
To avoid passing `struct darray *` type, which cannot hold the type
information, this commit defines array types and uses that types on the
function parameters.
To avoid passing `struct darray *` type, which cannot hold the type
information, this commit defines array types and uses that types on the
function parameters.
To avoid passing `struct darray *` type, which cannot hold the type
information, this commit defines array types and uses that types on the
function parameters.
Passing struct darray type will loose the actual type of the contents.
Uses a defined type of `DARRAY(struct encoder_packet)` to carry the
type when crossing functions.
To avoid passing `struct darray *` type, which cannot hold the type
information of the array element, use defined array types on the
function parameter lists.
Passing DARRAY with an operator such as dereference (`*`) sometimes
caused a compile error. To avoid the error, introduced parentheses
inside the macros.
Unobfuscated secrets require the hash values to be set to 0, by default
CMake will treat 0 as a falsy value. This commit adds support for
_either_ 0 _or_ a valid hexadecimal hash.