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.
Previously we assumed mjpeg was always decoded to 422 but it seems some
cameras provide frames that decode to different pixel formats such as
420.
This change delays setting the obs frame pixel format until after we
have decoded the v4l2 frame.
fixes#5821
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.
Bundles libraries are available via their specific versioned filename
as well as SOVERSION and versionless symlinks. Dylibbundler does _not_
include these symlinks when copying linked libraries into the bundle.
This change ensures that all libraries and their SOVERSION symlinks
exist in the created App Bundle.
Prior version was linked against libxcb, because it was present on
Github Actions macOS runners. Consequently builds on CI will succeed
as the library is always present, will fail on user's machines though.
More accurate and cheaper.
This is a breaking change because Amount is also now computed as linear,
but most users are probably using 1.0, so v2 isn't worthwhile.
Intel UHD Graphics 750: 980 µs -> 860 µs
This fixes crashes in media Source when :
- the user forgets to set the input format for srt or rist URLs;
- disabling / enabling / disabling etc Media source with a rist URL.
Signed-off-by: pkv <pkv@obsproject.com>
