os_sleepto_ns() can occasionally return false on times that the
processor may not have reached yet. The reason is because the
count_target, which converts time_target into a QPC counter, is subject
to a rounding error.
Using numbers I generated from an actual clock cycle on my own CPU, I
can show an example of this occurring: if the clock frequency value is
10000000.0, and you call os_sleepto_ns(42164590320600), it will convert
that number first to a double floating point of its QPC value:
421645903205.99994. Then, because it converts that to a LONGLONG
integer, it of course strips off the decimal point. If you convert
421645903205 *back* to a time value, the new value will be
42164590320500, which is lower than the original value by approximately
100 nanoseconds. While this may seem insignificant, it was apparently
enough to cause the os_sleepto_ns() call in video_sleep() to sometimes
return false despite the current time being lower than the target time,
which would cause it to incorrectly calculate how many frames were
duplicated by subtracting the frame time from the current system time,
divide that by the current frame interval, set the vframe_info.count
value to 0, and thus cause an infinite loop in the encode_gpu()
function because queue_frame now starts returning negative numbers in
perpetuity.
This change fixes some rare reports of users having their video lock up
and disconnect, forcing the user to have to forcibly shut down the
program.
Thanks to Twitch user SNLabat for having the patience to kindly provide
us with a dump file from the freeze, and to Matt for coordinating with
that user to obtain it from them.
The current path would prevent the browser source from loading if OBS
itself is in the "Application Support" folder, where it might end up
when being installed via certain distribution platforms.
This adjusts the existing hack to specifically check for the obs-studio
subfolder where the old browser source library would reside.
With this, you can now cast normal obs objects (services, outputs,
sources, encoders) to an obs_object_t, and then use obs_object_*
functions to get references, release references, and similar for weak
object references as well. This allows the ability for the frontend to
use an object of any of those types interchangeably in certain
situations without having to handle each specific type individually.
This is useful because the properties view in particular doesn't care
what type of object it uses, it just needs to be able to hold weak
references to abstract OBS objects.
Currently if a module fails its load callback, it remains loaded and OBS
continues to call additional exports such as obs_module_post_load. This
goes against the documented behavior, which states that a module that
fails its load callback is unloaded.
This commit releases locale resources and frees the module's
information, preventing further callbacks from libobs. The module itself
(the DLL) is not yet unloaded from memory as os_dlclose is commented out
for causing unspecified issues - this should be revisited in the future.
The audio capture callback's mute parameter internally respects the
push to talk/mute state, whereas obs_source_muted() and the "mute"
signal don't. This resulted in meters looking entirely unmuted even
though both monitoring and output were not receiving audio.
Deprecates:
obs_source_addref()
obs_output_addref()
obs_encoder_addref()
obs_service_addref()
obs_scene_addref()
These functions should be considered unsafe and not used. Instead, use:
obs_source_get_ref()
obs_output_get_ref()
obs_encoder_get_ref()
obs_service_get_ref()
obs_scene_get_ref()
These functions return a pointer to the incremented object only if the
object is still valid, otherwise they will return null, indicating that
the object is no longer valid or is unsafe to use.
The reason why this is being done is because certain third party plugins
seem to be using addref, and are somehow managing to call addref on
sources that have already been fully released. For the sake of safety,
almost all usage of these functions within OBS have also been replaced
as well.
This prevents double destroys from happening on sources and causing
crashes. If someone's doing a double destroy it'll probably crash anyway
but at least we'll know what happened if it does. (Jim note: I suspect
third party plugins are calling addref on sources when they shouldn't
be. Either that or we're missing something ourselves, but I suppose
we'll see.)
These were operated on by atomic functions but were not marked as
volatile or loaded with os_atomic_load_long, potentially introducing
subtle race conditions. Detected by ThreadSanitizer.
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.
(This commit also modifies UI)
This makes it more trivial for encoder plugins to communicate to users
why specifically an encoder error might have occurred mid-stream.
When signed 32-bit audio arrived to pulseaudio-output and volume was
lowered, audio data was broken. In the function `process_volume`, the
type of the data is switched by `bytes_per_channel`. However the size of
signed 32-bit integer and the size of float are same so that the signed
32-bit integer is processed as float.
This commit changes these items.
- Use `format` instead of `bytes_per_channel` so that all the sample
types can be differentiated.
- Change `short` to `int16_t` and renames existing function
`process_short` to `process_s16` to clarify the function is
processing signed 16-bit.
