Instead of lettings the hotkey thread handle bindings triggered by Qt,
call the callback directly.
By this point, Qt has resolved the modifier state (so no need for the
hotkey thread to do the same), the pressed state is set as well,
the branch takes care of matching the pressed keys.
This also fixes the issue with the hotkey changes introduced by #3914,
which only inject key events when OBS is _not_ in focus (and as such
modifier states are never updated).
Replaces the current implementation of Window Capture, which uses Core
Graphics to render a bitmap raster, with one that accesses the window's
CGImage bitmap directly, blits it, and hands that off as a frame to OBS
instead.
Co-Authored-By: Sebastian Beckmann <beckmann.sebastian@outlook.de>
This replaces direct OpenGL calls to error handling helpers. Previously
this would cause errors to be misattributed to the next OpenGL functions
called.
Fixes DMA-BUF importing returning a texture on failure on KDE+NVIDIA.
This sets the aac bitstream to ADTS for the mpegts output.
This fixes a bug with mpegts ouput where the avformat muxer issues
an error with fdk-aac encoder.
Signed-off-by: pkv <pkv@obsproject.com>
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
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.
This causes the thread to only start when the IMediaFilter::Run/Pause
calls have been made, and stop whenever either the IMediaFilter::Stop
call has been made, or on destruction, whichever comes first.
This potentially will work around a suspected race condition that
appears to be in the WebRTC library where the filter's library will be
released while the filter is in the process of being destroyed, which
can take longer than usual if the join takes too long. Basically, fixes
a reported crash (that doesn't appear to technically be our fault) when
the filter is used with browsers when the virtualcam is deactivating in
web browsers.
This may have been the issue behind the reported firefox crashes, but
strangely, the thread should always be joinable here because it's
explicitly always created in the constructor and joined in the
destructor.
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.
Sort video device entries with `alphasort` on non-Linux platforms,
as opposed to `versionsort` on Linux.
(`versionsort` is a GNU extension, unavailable on e.g. FreeBSD.)
UI: Fix call to `to_string` on FreeBSD
Previously the switch did not catch all cases issuing a quite large
warning. Also there was a const-ness warning for codecs on ffmpeg 5.0
that this addresses.
Commit 7a5bffc0a6 applied a fix to the
macOS build script. This applies the same fix to the GitHub Actions
workflow that is actually currently used on CI.
