Removes all callbacks in use on sources right when a source is about to
be destroyed.
Fixes a crash where callbacks would still be executed while in a
destroyed state (particularly sidechain filters). Could also just mark
the source as being in a destroyed state and not accept anymore
obs_source_output_[audio/video] calls.
The *AutoRelease helpers should not take references from OBSRef objects.
Instead, make an OBSRefAutoRelease base class, and OBSRef a subclass of
that to allow moves, and then perform moves from those objects.
This fixes an issue where *AutoRelease OBSRef objects would cause an
unintended double release of objects after having been assigned values
from non-*AutoRelease OBSRef objects.
When sharing DMA-BUFs it is required the announce the underlying
hardware capabilities via supported modifiers.
Add new device_query_dmabuf_capabilities vfunc to gs_exports and connect it
to the egl implementation stubs in the supported render platforms. Add a new
public method gs_query_dmabuf_capabilities() that calls the vfunc above.
Add new device_query_dmabuf_modifiers vfunc to gs_exports and connect it
to the egl implementation in the supported render platforms. Add a new
public method gs_query_dmabuf_modifiers() that calls the vfunc above.
(This also modifies the UI)
The purpose of deferring destruction of sources is to ensure that:
1.) Hard locks from enumeration cannot occur with source destruction.
For example, if the browser source is destroyed while in the graphics
thread, the browser thread would wait for the graphics thread, but the
graphics thread would still be waiting for the browser thread, causing
a hard lock.
2.) When destroys occur during source enumeration, that the integrity of
the context's next pointer in the linked list can no longer be
compromised
3.) Source releases are fully asynchronous rather than having the risk
of stalling the calling thread
4.) We can wait for source destruction when switching scene collections
or when shutting down rather than hoping for threads to be finished
with sources.
This introduces a new requirement when cleaning up scene/source data:
the obs_wait_for_destroy_queue() function. It is highly recommended that
this function be called after cleaning up sources. It will return true
if at least one or more sources were destroyed. Otherwise it will return
false. Forks are highly advised to call this function manually on source
cleanup -- preferably in a loop, in conjunction with processing
outstanding OBS signals and UI events.
Holds an active reference to a source during signaling of the
`source_remove` signal, to prevent receivers from being given an
already-destroyed source.
- Call obs_source_remove(source)
- Receiver 1 gets signal, calls `obs_source_release(source)`
- Receiver 2 gets signal, calls `obs_source_release(source)`,
refs == -1, source destroyed
- Receiver 3 gets signal, source already destroyed, is forced to ignore
signal due to invalid source
This is a theoretical situation which is currently possible in
obs-websocket.
Users on Wayland are displeased that they cannot see their hotkey
bindings. This enables key reporting like X11, and has the infrastructure
in place in case Wayland ever decides to allow for capturing input.
obs_source_release should not be called while iterating through the
global sources linked list, otherwise the linked list will be
compromised. Annoying.
Basically the same fix as obsproject/obs-studio#5600, but should be
slightly more optimal and a bit more explicit.
Fixes an issue pointed out in obsproject/obs-browser#333 where a source
may destroy the next source in obs_source_video_tick(), thus
invalidating the next source in the linked list. Get the next source in
the list *after* calling obs_source_video_tick() rather than before.
Closesobsproject/obs-studio#5600
When pushing to the front of an empty circular buffer, it would not
update the end_pos, so end_pos would be left on 0, and it would break
when trying to push to the back after that. The reason why this bug was
never discovered until now is because breakage only happens when pushing
to the front of an empty buffer, then pushing to the back right after
that.
These AutoRelease versions of the C++ OBSRef types do not add a ref on
construction, which is useful when accepting the result of a function
that turns a raw C pointer type that has had a reference added.
Not having these types has resulted in multiple awkward anti-patterns.
Such as immediately releasing after construction to account for the
extra addref, or avoiding using the C++ type entirely and manually
releasing it later.
Example:
```
OBSSource source = obs_get_source_by_name(name.c_str());
obs_source_release(source);
```
The whole point of these types is to avoid the need for manual releases,
and rely on the RAII mechanisms inside of C++. Additionally, the
immediate release isn't commented anywhere, resulting in confusion for
other developers looking at the code as to why things are being
immediately released.
The AutoRelease types and names are taken from obs-websocket.
When sources output NULL frames, it is generally used to disable the
source and prevent the last frame from being left on screen. However,
when the source begins outputting video again, the last frame is
still in the async cache.
Depending on the stability of the source's frame output, this still
frame can end up being shown for 5+ output frames.
By freeing the async cache when a NULL frame is submitted, we avoid
the issue of old frames being re-displayed.
Currently, ifdefs are used to determine if monitoring is supported.
This is difficult to maintain and restricts plugins from knowing if
monitoring is supported by OBS. This adds a runtime function to fix
that issue.
Adds support for using shared textures that were made with the
D3D11_RESOURCE_MISC_SHARED_NTHANDLE flag.
This increases the minimum required Windows version to Windows 8 or the
Platform Update for Windows 7. As official support is only for Win 8+
this does not change official support.
Previously we would wait for pulse to attempt to read from the monitor
source and obs buffered at least 5ms of audio data before we tried to
fill the buffer. In some cases this resulted in consistently triggering
underruns in pulse.
Instead we try to fill the buffer immediately as obs outputs audio data
and while the pa buffer is not full. We also stop trying to grow the
buffer to prevent underruns after we reach 1s of latency.
