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.)
The 6.4 runtime rely on Freedesktop 22.08 which provide a more recent
version of Mesa and PipeWire.
The switch to 22.08 also requires to migrate paths of VST 2 plugins.
These use printf for some reason. Instead of always printing them and
having them clutter the log, blog them with debug level. They don't
appear in log files anyway.
8985c0f - Add ability to mute individual browser docks/panels
c9d1e37 - Don't use app binary directory for logging
7142b21 - Add ability to directly open Dev Tools for Panels
In updated versions of FFmpeg (5.1.x) and SVT-AV1 (1.2.0/1.3.0), the
rate contol mode selection mechanism has changed, causing CBR to throw
an "Invalid Parameter" error and the encoder will fail to start. This
appears to be caused by us specifying rc_max_rate, which will also fail
on FFmpeg CLI. Adjust how we manage rate control methods, appropriately
version-gated, to work with both our current dependency versions and the
versions that we'd like to use.
Starting with macOS 13 the VT hardware encoder has all the capabilities
it needs for both streaming and recording, so we can start recommending
it in AutoConfig.
(Jim note: The missing description of this commit is that basically, the
CAP_MAX_THROUGHPUT value returns a different result based upon what the
other settings are currently set to. It didn't operate the way it was
originally programmed.)
To avoid the user having lookahead enabled with no way to disable it,
change the Simple Output Mode NVENC Preset from P6 to P5.
Follow up to 8806738a04.
In dfccb26bb2, in my haste to fix Windows
CI, I accidentally included a change to disable Windows scripting which
I had been using locally. Reverse that change to re-enable scripting in
Windows builds.
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.
The index is not reliable. The id persists better, so use that.
Also remove matching against the first monitor if the expected monitor
is not available. That feature seems like a good way to get doxxed by
accident.
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.
Jim