Linux runners exhibit connectivity issues with some services that are
not present with macOS runners. Switching to macOS thus reduces chances
for false positives.
This changes the return type for getting the filter index from a
size_t to an int. This makes it easier for developers to use,
as an invalid index just returns a -1.
Copy libdatachannel DLL whether it's compiled on MSVC (and named
datachannel.dll) or cross-compiled on MinGW (and named
libdatachannel.dll).
Signed-off-by: pkv <pkv@obsproject.com>
This updates libdatachannel to the commit supporting simulcast [1]
and removes the now unnecessary libdatachannel patching.
[1] 709a663394
Signed-off-by: pkv <pkv@obsproject.com>
This redesigns the status bar to look more modern.
Co-authored-by: Warchamp7 <warchamp2003@hotmail.com>
Co-authored-by: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
Rendezvous mode with SRT protocol is used to punch through firewalls.
Although caller or listener mode are much more widespread, it is
sometimes in use. The rendezvous mode was broken in obs because we
would bind to the remote IP, instead of a local IP. This fixes the bug.
Note that there is also a bug in libsrt preventing our code to work.
But Version 1.5.2+ of libsrt fixes that.
Signed-off-by: pkv <pkv@obsproject.com>
Removes flag guard to enable HDR streaming for HEVC over Enhanced RTMP.
This functionality is currently only supported by YouTube.
See github.com/veovera/enhanced-rtmp for the Enhanced RTMP spec.
Adds a custom User-Agent header to REST requests identifying OBS as the
client.
Randomizes SSRCs to avoid potential issues with servers that do not
rewrite them before forwarding.
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.