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
This reverts commit 4b0767741ab7f3c10d95c96c17a9ac0c0f726ca3,
3f3f9ed7e60a8dbe8c904b234a8b715841df880f,
0e7c17bd6e2f17a6002556ef8229f0b7e2124e91, and
865eecb7396841ccf4b4154b79253f5c8f1a1b76.
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.
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.
For some reason, the combination of QPlainTextEdit and a HTML block
seems to treat spaces as HTML shoult (only display one, no tabs, etc)
rather than how QTextEdit + HTML does, which is strange. As we don't
need HTML for existing log lines, insert them as plaintext, but for
new entries wrap non-error non-warning messages in a <font> tag and
format that with white-space: pre
Replace fixed Arial, 7 px meter scale font with the font used
for VolumeMeter/QWidget. Add qproperties for meter bar thickness and
a scaling factor for the meter scale numbers. If not specified in a
QSS, defaults are 3 pixel bar width and 80% of base font size.
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
Update the in-tree nv-codec-header files (nvEncodeAPI.h and
dynlink_cuda.h) to n11.1.5.1, which is the version currently used in the
OBS Studio dependencies, to keep the in-tree version in sync with the
version in our dependencies.
This commit includes two big changes, alongside other smaller tweaks.
1) Update the internal QTextDocument of the text component directly
2) Use QPlainTextEdit, which supports HTML & is designed for long text
3) Use QString's arg function for formatting strings
Fix 1 significantly improves realtime performance when adding lines
individually, to the point that the UI no longer freezes if the viewer
is open and the log is being spammed. It also improves initial launch
speed when there's a large amount of text already in the file.
Reference: https://stackoverflow.com/a/54501760/2763321
Fix 2 completely eliminates delay when opening the viewer, regardless
of how many lines are already in the log file. For a standard log
after OBS launch, this cuts opening time from about 2 seconds to half a
second. For anything longer than 1,000 lines, the UI no longer freezes,
and the viewer (& its contents) open within half a second.
Reference: https://stackoverflow.com/a/17466240/2763321
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.
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.
Commit 7a5bffc0a66980113c32dbed123b3928d38abe8b 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.
Our version fixes the system freeze issue, reduces resource usage, and
improves performance back to 3770 levels.
See obsproject/cef@36fdac16a7 for detailed information.
