When #5169 implemented deferred encoder updates, it did not account for
the case when the encoder hadn't started yet. This means the encoder would
start and then immediately call update with the same settings it was
started with, which in the case of some hardware encoders would trigger
a reconfiguration request to the driver.
- Set standard to c++17 (Cpp11 is an alias for "Latest")
- Update comments to clang-format 13
- Uncomment options that have previously been commented out due to not
being available at the time the file was written.
Linux QSV drivers have varying capabilities depending on if the
free/non-free Intel drivers are installed. This means we cannot safely
expose QSV in simple mode as users may be unable stream without changing
to advanced mode.
This moves the existing adapter checking into the platform layer and
moves the Windows implementation to its platform implementation and adds
a Linux implementation based on directly querying VA-API.
Unlike Windows, this check takes ~1ms so we have no need to spin out
another thread to perform the work. This also fixes up some of the CPP/C
mixing going on in common_utils."h" to allow us to call common functions
from C files.
Reset frame_rate_divisor_counter to 0 on encoder shutdown.
After starting and stopping a GPU encoder session, obs_encoder_shutdown
would set frame_rate_divisor_counter to 1. When the next GPU encoder
session was started, in libobs/obs-video-gpu-encode.c, gpu_encode_thread
would set skip to this value (1), and increment
frame_rate_divisor_counter to 2. This causes the next check to fail, as
frame_rate_divisor is 1 by default (2 == 1 is false), so
frame_rate_divisor_counter retains its value. Since skip is non-zero,
the next check, if(skip), passes, and skip to the next loop iteration.
This will continue forever, because frame_rate_divisor_counter will
continue to increment, so it will never hold the same value as
frame_rate_divisor. This means that send_off_encoder_packet is never
called, so the muxer never receives encoded packets.
To the end-user, this manifests as their second encoder session being
impossible to stop. They then have to force quit OBS and the
obs-ffmpeg-mux process. This change prevents that from occurring and
allows multiple back-to-back GPU encoder sessions to be completed.
The CMake 3.0 path used the old syntax for logging if the module was
disabled. Update this to use target_disable to match the syntax in other
CMake 3.0 paths.
The macros `YOUTUBE_ENABLED`, `RESTREAM_ENABLED`, and `TWITCH_ENABLED`
are not defined when the associated features are not enabled.
When the code was originally implemented, there were definitions to set
`0` if the feature is disabled. However a later commit 349372b removes
the definition. Now, the use of `#ifdef` is better than just `#if`.
Instead of actually removing the file, simply rename it to the .bak
version which OBS ignores in most cases. That allows users to recover
accidentally deleted collections more easily, while only taking up a
few kilobytes of disk space at most.
Default ffmpeg initial buffer fullness (75%) is too low
and results in significantly lower video quality on AMD cards.
Changing it to 100% fixes the quality and also matches what
AMF encoder is doing.
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
