Previously would always end up with OBS_MEDIA_STATE_ENDED whether the
video reaches the end or the user stops the source (state is set to
STOPPED, but becomes ENDED right after). This fixes it so that if the
user stops the source, it will remain stopped.
The frontend API was never explicitly cleaned up which has lead to
several crashes from plugins continuing to call it even after OBS itself
has been destroyed. We now destroy the API after the exit event, so
further calls by plugins will be no-ops instead of potentially accessing
destroyed OBS state.
This also required some changes to our own use of the API, as we relied
on the OBSBasic destructor to clean up some callbacks, by which point
the API should have already been destroyed.
The D-Bus signal subscription is a very boring aspect of the
portals infrastructure that shouldn't really matter when reading
the code of pipewire.c.
Move it out to its natural place, portal.c.
Cameras and audio streams will use the async output routines, but
not screencasting. This needs to be handled differently in the
processing callback.
As it is, the code is starting to get a bit messy, as we're now
dealing with two different frame processing approaches. Later on,
this code will be cleaned up and split in more logical pieces.
Co-authored-by: Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>
So far we've been treating format info on a per-connection basis,
but now that a single connection is capable of hosting multiple
streams, and each stream might negotiate a different format, it
is necessary to move format info to each stream individually.
Sorry, this is a painful commit to review :(
Until now, the only consumer of the PipeWire code is the screen
cast portal code. This portal code only ever has one PipeWire
connection, and one PipeWire stream, every time a monitor or a
window is selected. This is reflected on obs_pipewire, which only
handles a single stream for any given connection.
For cameras and audio, however, a single PipeWire connection can
and most likely always will provide multiple streams. For example,
computers with multiple webcams will have one PipeWire connection
reporting multiple PipeWire nodes, one node for each camera.
This commit breaks this one-stream-per-connection assumption, and
makes obs_pipewire_connect_stream() return an independent object
(obs_pipewire_stream) that represents a single stream.
The screencast portal code continues to only ever have one connection
and one stream.
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.