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 channel_layout API was overhauled by FFmpeg [1-5]. The previous
bitmask channel_layout is replaced by a struct ch_layout which combines
the number of channels, a bitmask and other infos.
The resampler needs to be updated whenever using swresample > 4.5.100.
This commit makes the necessary changes.
[1] Bump minor versions after the channel layout changes
FFmpeg/FFmpeg@cdba98b
[2] lavc: switch to the new channel layout API
FFmpeg/FFmpeg@548aeb9
[3] avutil/channel_layout: Add a new channel layout API
FFmpeg/FFmpeg@086a804
[4] avframe: switch to the new channel layout API db6efa18
FFmpeg/FFmpeg@db6efa1
[5] swresample: convert to new channel layout API
FFmpeg/FFmpeg@8a5896e
Signed-off-by: pkv <pkv@obsproject.com>
Since obs-studio switched to Qt6, old plugins linking Qt5 should be
rejected. On Linux system, OBS and it's plugins link the system
libraries so that obs could be crashed by such plugins that links Qt5
when Qt5 functions are called.
Co-authored-by: Norihiro Kamae <norihiro@nagater.net>
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).
Using a relative path for the pthread.h header by w32-pthreads breaks
compilation of plugins which include threading.h from libobs (as
w32-pthreads will exist at a different location relative to the
libobs header).
As w32-pthreads (and its include directory) is added to the libobs
target by CMake, the pthread.h header will be found even when using
system header notation.
Fixes https://github.com/obsproject/obs-studio/issues/7155
It seems that the older key still exists on Win 11 and 10 but is always
set to 0, so use the newer to start with and fall back to the old one if
necessary.
Additionally, if the key for HAGS and GameMode do not exist assume
they're on as this is the default on Win 11. On Windows 10 game mode is
also on by default in recent versions.
Also changes "10" to "10/11" just for correctness.
Laptops that render OBS displays on NVIDIA, and display through Intel
have been seen flickering, and we think the driver is not properly
handling swap chain buffers that have been cleared but not drawn to. To
work around this, we use a draw to simulate a render target clear. This
is not as efficient, so hopefully NVIDIA will fix this soon.
