Audio ids were being stored in a map with const char pointers, thus they
were destroyed when call_once finished. To fix this, store std::strings
instead.
Having both a "callback" and "cb" doesn't make sense. One is
specifically for visual updates only, the other is for actual updates,
so use an appropriate name for both
We'll need flip model swap chains in the future for HDR, and we don't
want to limit HDR to WIndows 11. The new test is the existence of
IDXGIFactory5, which was introduced in Windows 10 1607. This should be
enough for HDR, for which we use APIs in Windows 10 1703.
Hopefully having SetMaximumFrameLatency(40) this time will make enough
of a difference to not bring back reports of degraded performance when
using flip model on Windows 10.
Similar to the Windows counter part. Check the PCI bus for
installed cards. When found at least one VGA compatible adapter
from NVIDIA that is not in the blacklist we pass the check.
Fixes overriding of macOS dock icon behavior.
macOS sets the icon on launch based on:
- The Information PLIST
- A user provided icon by Finder
setWindowIcon overrides this behavior.
Therefore, this commit resolves this issue,
by doing nothing if target is macOS.
When we added undo/redo in 86eb7aeb a distinction between Updates and
Visual updates was made, presumably for filters which need special
handling of the update case. These functions were also added to regular
source properties, but didnt use any special code instead calling
obs_source_update an additional time after a short time.
Instead lets remove the 2nd delayed call and only call obs_source_update
once per settings change.
Remove a bit of duplicated code, and fix non-Windows compilation. This
is a bit of a workaround to not have to modify cmake, but might as well
reuse a function that already exists anyway rather than duplicate the
code.
When you add an audio capture source and use the "use existing" feature
in the source selection dialog, and then recreate the same audio source
again in audio settings, it will result in two sources using identical
names, which although relatively harmless can cause issues when doing
things such as trying to find sources by their name.
Fixesobsproject/obs-studio#5621Closesobsproject/obs-studio#5947
Apparently the testing that was done was not sufficient enough or did
not check all test cases, so resolution/fps does not get set properly on
the virtualcam.
Makes the callback variable "removed" atomic, and on script unload,
first sets all callbacks to removed before actually unloading the script
out of a safety precaution. (See note at the bottom for further details)
This minimizes the possibility of a race condition where the script
callback could be called while those callbacks were being removed.
Big note for this change, this change should eventually be replaced with
a reference counting ownership method where script callbacks can hold a
reference and share ownership of the script if it's still alive while
the script callback is being called. That way the script callbacks can
safely execute. May require a fair amount of reworking of the script
object.
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.