Clang 19 has become more strict about mixing different enum types, which
resulted in an error building multimedia/obs-studio on FreeBSD:
/wrkdirs/usr/ports/multimedia/obs-studio/work/obs-studio-30.2.3/plugins
/obs-outputs/flv-mux.c:659:37: error: bitwise operation between
different enumeration types ('enum multitrack_type_t' and 'enum
packet_type_t') [-Werror,-Wenum-enum-conversion]
MbedTLS changed a lot of internals with their LTS version 3.6.0, which
are incompatible with the find module currently shipped with
OBS Studio.
The solution requires several changes to be applied at once:
* Rename the generated target name to MbedTLS::mbedtls to match the
name used by MbedTLS' own CMake package
* Update find module to use the updated target name(s)
* Set CMAKE_FIND_PACKAGE_PREFER_CONFIG to TRUE before trying to find
MbedTLS to ensure that CMake package files are used with priority
(Those are shipped only with MbedTLS 3.6.0 in obs-deps).
* A deprecation warning is emitted if the find module is used with
MbedTLS 3.6.0 available
We check that mids is a nullptr which may not be the case if this
remains uninitialized. Earlier attempt to fix this assumed we faulted on
the response itself.
fixes#11221
At some point NVIDIA started using NV_ENC_ERR_INCOMPATIBLE_CLIENT_KEY
instead of NV_ENC_ERR_OUT_OF_MEMORY to signal that the session limit
has been exceeded.
If speex and rnnoise are disabled but nvafx is enabled, the noise
reduction filter still needs to be built. This fixes the issue.
Co-authored-by: Ryan Foster <ryan@obsproject.com>
Signed-off-by: pkv <pkv@obsproject.com>
Separate the commonly used functions into service-ingest.c/h.
Split the Amazon IVS support out of the Twitch specific files
and into the new amazon-ivs.c/h files. This allows for clean
usage of `struct ingest` between the two services.
Prevents Display capture from capturing the first display on creation.
This issue is due to the properties view combo box automatically
selecting the first item in the list by default, but this needs explicit
text anyway to indicate display, so this adds a "[Select a display]"
item that will prevent that from happening and tell the user to select a
display.
This is due to the property view widget not having an item to select, so
it selects the first one, but we want to have specific text for this
anyway, so changing it here is still appropriate. (I don't want to touch
the properties view widget right now for the sake of my sanity)
Like xcomposite, this was programmed to select the first display by
default. Change it to not capture any display unless explicitly selected
by the user.
There are two situations where xcomposite window capture will capture
random windows: on first creation, and when going to the properties when
the current window is invalid. The first happens because for whatever
reason someone decided to just make it capture the first top-level
window if there is no set value. The second happens because the
properties widget cannot find the value it's looking for and defaults to
the first one when the properties are opened, thus selecting and
capturing the first window in the list (which is probably something we
should fix in the properties view at some point but I don't want to dive
into code that's even *more* cursed than xcomposite code right now)
I think that this was a major oversight and that whoever wrote it
however many countless years ago did not realize that this is something
that maybe users don't want to have happen.
So instead, this diff makes it so that on first creation, it creates a
value that says "[Select a window to capture]" that keeps the capture
inactive until a user actually chooses a window rather than the
top-level window. It also makes it so that if the user has a window that
is no longer valid, it will keep that window in the list and as the
currently selected value, which prevents it from automatically selecting
the first window in the list when properties are opened.
(Have I mentioned xcomposite is cursed? Trying to debug xcomposite code
in a debugger freezes my window compositor and forces me to do a hard
restart of my entire computer, so I was forced to use printf debugging.
Absolute nightmare-inducing code in here.)
This is cursed. Window ID storage for xcomposite capture is absolutely
cursed. It should not be storing the window handle with this. I'm pretty
sure that whoever wrote it at the time decided to store the god-forsaken
window handle (which does not persist after the window closes) as part
of the ID because they were afraid it might capture the wrong window if
they close OBS and open it up again while the window still exists.
Again, xcomposite capture is absolutely cursed.
Moves the window handle/name/class decoding code out of the
xcb_find_window() function and into its own dedicated function so it can
be used elsewhere. This s*** is cursed.
98d94a4 - Enable Qt message loop on Linux
8e2b31f - Set the right Ozone platform on Linux
6451941 - Wait on shutdown for docks to close on Linux
174e6a8 - Remove CMake legacy code path
e4e523d - Update version to 2.24.2
The code prior to this change would never add virtualcam.c to the
win-dshow target, which resulted in the virtualcam_output not being
registered and thus Virtual Camera not working.
Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
This event is only used within destroy_[audio]_screen_stream, and does
not appear to be necessary there. stopCaptureWithCompletionHandler holds
a reference to the SCStream object by itself (and the other objects
being held aren't used afterwards anyways), so there should be no harm
in releasing everything immediately without blocking.
