Checks to make sure that the bframe count is equal to or below the
maximum number of bframes that the encoder for the codec supports.
Fixes a bug where setting bframes higher than what the encoder supports
would cause the encoder to not start up properly.
8dda8d3500 added a few functions to get the last
recording/replay/screenshot path, but it should return allocations
because it's possible for the data to be modified at a later point.
Ubuntu 20.04 and 22.04 both have the same FFmpeg versions, but FFmpeg on
20.04 was built with version 9 of NVENC headers, whereas 22.04 was built
with 11.
Unfortunately, that means we have to revert back to the old presets when
Ubuntu 20.04 is detected. The way this detection is done is a bit hacky,
but it's the only way to preserve startup performance. Otherwise we'd
have to write yet another startup subprocess test program to detect
whether the FFmpeg being used was built with older or newer NVENC, which
is both slow to start up and annoying to write. So instead, just get the
distro name/version strings and detect Ubuntu 20.04 that way.
Things were a bit unoptimal and were squished together, making the code
much more difficult to work with. Instead, separate the code for
processing individual samples into its own function.
Certain programs can start the virtualcam filter, then they may choose
to call `Stop()` on the filter, call `SetFormat()` to change the
resolution, then call `Run()` again to start the filter again. The
Windows virtual camera filter did not account for this, thus if the
resolution was different, it had potential to cause a crash.
To fix this, store the last filter resolution, then check the resolution
every frame, and if it changes, reset the scaling information.
(Author note: This code is unclean. What we need to do with the virtual
camera filter is make it only create the thread on `Run()`, then join
the thread on `Stop()`. It's currently a bit complicated to make it do
that at the moment, so this code is a kind of an annoying stopgap for
now.)
The `cx`/`cy`/`interval` variables specifically specify the
OBS/placeholder resolution/interval. The resolution may not be the same
as the filter's resolution (when scaling is used).
Instead, prefix these variables with `obs_` to improve clarity.
Sending frames on initial pause seems to cause an odd crash on
subsequent frame calls.
(Note by author: I do not know why the crash happened because code
beyond OBS is a proprietary black box. I suspect it's just a bug in
WebRTC or something, but I can't know for sure. This is incredibly
frustrating. But at least this particular crash seems to be fixed.
...for now.)
Due to the timeout detection, we need to factor in the current pause
offset to prevent pause from affecting the timeout.
Closesobsproject/obs-studio#7313
In obsproject/obs-studio#6963, a crash was fixed when retrying NVENC
without psycho aq. Unfortunately, the code forgot to reinitialize the
session, and thus the retry always failed. This reinitializes the
session as it was likely meant to.
vsnprintf is called twice; one call must use args, and one must use
args2 (which is how it was supposed to be from the beginning). Each call
"consumes" its va_list parameter, so they each need to use a separate
copy. Fixes potential corruption and/or crashing when calling vsnprintf.
This reverts commit a36b5bee99.
After this commit was merged, apparently devices were not functioning
correctly for some people. Especially regarding their internal settings.
Just revert it for now.
Apparently this annoying, stupid variable was leaking before the ComPtr
was added, which ironically was necessary to ensure devices worked.
After that ComPtr commit some devices stopped capturing properly.
Basically, it implies that this pointer needs to stick around while the
device is in use.
(Jim note: This was one of the most painful things I've ever had to
debug)
Do to multithreading the update process, files of the same hash can
sometimes collide due to race. Ensure the filenames are all unique by
appending an incremented value for each file.
The original change in obsproject/obs-studio#7200 seems to have been
based upon the idea that if the "selected" parameter has no values, then
the "deselected" parameter must have values, which is clearly an unsafe
assumption to have make given that it causes an assert crash in Qt when
both parameters have 0 values contained within them.
Individual sources cannot be used as vcam outputs (yet) due to the fact
that they cannot currnetly scale. If a source is not exactly the same
dimensions as the canvas, there will be blackness on the right and/or
bottom of the source. It's just not currently usable as-is.
Scenes are a much better fit for this because users can transform
sources within scenes as they please to fit the canvas.
At a later point, we'll likely reintroduce this feature as long as
they're automatically transformed or something.
It's about time to get rid of this being labeled as "(new)".
Also rename the FFmpeg variant. And make it more explicit when the
FFmpeg encoder is being used in the log file.
Seems to solve lag encountered on the new AMF encoder. The SubmitInput
call in the AMF encoder can occasionally stall for quite a long amount
of time, but most take microseconds, so we can compensate by simply
increasing the buffering (3 to 10 textures).
This goes back to a slightly older variant of the
SubmitInput/QueryOutput handling that doesn't use AMF's timeout
property. Older devices do not like it when you change the query timeout
on the fly and will lock up. So instead, wait one millisecond when the
AMF input is full, which appears to fix the issue according to testers.
Also adds a loop timeout in case it goes in an infinite loop (which it
shouldn't anymore, but still)
Big thanks to Flaeri for testing the old code, and Yukari for patiently
testing a whole bunch of builds.
All this does is it uses the same exact code AMD uses with their own
example FFmpeg muxer code. Although instead of adding to the PTS, it
subtracts from the DTS.
This reverts commit 90a409fe58.
Reverts #7077 for now. This really shouldn't be done so close to
release. This crash technically only happens under very niche scenarios,
and the fix seems to have some other potential issues. Prematurely
merged by Jim.
Increment checks for the what's new file were not working as intended;
old stored increments would unintentionally pass to newer versions if
the newer versions did not explicitly start up with a whatsnew.json file
that had their version. The previous attempt to fix made it so that it
used a completely separate global.ini entry when a matching entry was
found. However, this entry did not take into account the beta or release
candidate number of the current build. This fixes it to bake in the
beta/rc number into the entry.
This #if test was intended to not show messages for new users, but
instead just made it so messages wouldn't show at all if the entry
wasn't previously set. Plus the expression was bad anyway.
This was causing betas and release candidates to not show what's new
messages when they should have been.
Just remove this code as it's silly to have at this point anyway. All
users should see what's new messages if they open the program, even if
for the first time.
Allows the user to know what plugins failed to load. This is
particularly useful if we're going to block Qt5 plugins as well, or if
certain plugins can't load because they're incompatible with a newer
version.
obs_find_modules2 allows the ability to get the module name in the
callback, and the change to obs_find_modules2 also adds the ability to
find out whether any modules failed to load or not.
Allows the ability to get additional information about the plugin beyond
just whether it's an OBS plugin. For this case, whether it can load,
which is primarily used on Windows and mostly just determines whether it
has an incompatible Qt version.
There's no reason to expose these to scripting. Additional context: More
functions/structures will be added related to loading all modules, and
there's no reason to expose them to scripting either.
This change makes it so that if you select a service, it will check to
see what codecs that service supports, and only list encoders of those
codecs.
If the service doesn't support a codec and you currently have an
unsupported codec selected in output settings, then it'll prompt you
with a dialog telling the user it will switch to a supported codec, and
if they click yes, then it'll change the codec for the user. If they
click no, then it'll switch back to the previously selected service.
Uses a separate version entry for the "what's new" version check to
ensure that it properly resets whenever a "what's new" entry is ready to
be displayed.
This is more of a safety precaution to ensure that the "what's new"
thread only executes its result function in the UI thread when emitted,
because the result function can read/write config files.
If the API to query the maximum throughput isn't available, it was
intended to fall back to balanced. This code caused it to vall back to
speed instead because if the API isn't available, max_throughput will be
0. This fixes it to make it only fall back to balanced instead.
This feature is meant to reduce maximum audio buffering and turn off
dynamic buffering mode. This allows the lowest possible consistent
latency for audio buffering, which is useful for the decklink and NDI
outputs which cannot rely on audio timestamps for synchronization.
This can have a negative effect of making audio segments (partial or in
full) cut out. So audio glitching or audio loss can occur if this is
enabled.
Certain services have custom server lits handling which I had forgotten
about, so although it would have been nice to have this refactor, we'll
have to live with relying on the plugin properties object directly for a
while.
This also reverts obsproject/obs-studio#6530 and
obsproject/obs-studio#6683 because that change depended on this
problematic refactor code.
This reverts commits:
f2e6122881,
bc80d0ca95,
050a29da1a,
22ffc04f73,
275e510aad,
2fa5ffe4df.
Sometimes when reconnecting the internal RTMP data is not cleared
(particularly the TLS data). This can cause TLS data to carry over from
one connection to another, causing issues with the secondary connection.
Due to a bug in shader parsing, it thinks that because the token
"multiplier" is used here, that the "multiplier" uniform is being used.
This is a workaround for the issue because fixing the parser is probably
going to be much more annoying than just working around the issue for
now.
Jim
