Stingers -- and especially track matte stingers -- are currently subject
to real time decoding, which can be detrimental in a production
environment where a stinger video may not be able to decode in a timely
fashion.
To remedy this, this change adds an option to fully decode stingers
immediately and cache the decoded video/audio in RAM for playback to
greatly improve stinger performance.
On systems with multiple graphics adapters, one card can be configured
as power saving, and another card can be configured as performance.
Sometimes, OBS and the encoder test subprocesses will not be configured
the same way, so it's necessary to provide adapter order to the encoder
test subprocesses.
This change ensures the adapter order by passing the LUIDs to the test
subprocesses. The adapter indexes will then be updated accordingly.
This call will fail on multi-adapter systems, and isn't used anyway, so
just remove it. Not sure why it was called in the first place; pretty
sure it was unintended and was likely just copied over from the D3D11
subsystem code.
When this detection helper was originally written, it incorrectly set
the hardware implementation value. This fixes it to use the correct one
based upon the index.
Neither the mfxExtMasteringDisplayColourVolumme and
mfxExtContentLightLevelInfo structures appear to be supported when using
AV1, so if using AV1, do not include these structures.
It's unknown as to why AV1 fails to initialize when using either of
these extended structures as part of its configuration parameters.
Either they're completely unsupported or there's a member variable that
causes initialization to fail.
This simplifies encoder initialization and prevents it from requiring
any sort of unnecessary Direct3D or encoder initiazation tests while OBS
is actually running.
Because Intel has wonderful code which forces it to run on the iGPU if
there are both an Intel iGPU and an Intel dGPU on the same system, the
adapter index OBS is set to internally will no longer be valid, thus if
anyone calls `obs_get_video_info()` to try to find out what adapter
index OBS is running on, it will be invalid on those computers.
Wonderful.
So, basically, this code here just fixe it so if you want to call
`obs_get_video_info()`, it'll actually have a valid adapter index now,
that way we can reference the adapter index when determining what GPU
we're actually running on without having to like, do anything super
complicated and silly like comparing adapter GUIDs just to figure out
what adapter OBS is actually runing on. I don't want the code to be a
mess anymore.
(I like how in any other situation on the face of the planet, there's no
need to force OBS to run on an integrated adapter. *Normally* OBS
*should* run on the dedicated adapter, that way it can actually capture
games properly. You can probably guess as to why they're forcing it to
run on the integrated adapter rather than the dedicated adapter. But you
know what? Whatever. I don't really care anymore I guess. Just...
whatever. Here we are I guess. Also I was in a bad mood while writing
this just as a disclaimer.)
(I hate that this commit exist. I hate that the commit c83eaaa51c exists
even more.)
P6 seems to invoke lookahead, which causes lag for some older GPUs and
interferes with game performance. So let's just use P5 by default for
now. Shouldn't really affect recording anyway.
This reverts commit bcb73cb599.
Annoyingly, this breaks WebEx, likely due to their own bug. This only
breaks Discord under very specific circumstances due to their own bug,
so if I'm going to choose between Discord breaking under very specific
circumstances that rarely occur versus choosing WebEx not working at
all, I'm going to just let Discord be broken under specific/rare
circumstances.
I hate DirectShow.
The dynamic increment timeout does not need to be 30 seconds. Change it
to 4 seconds instead to make dynamic bitrate something that people
actually want to use.
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.
Jim
