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.
