The Saturation option was unbalanced, giving more weight to the color
red and a TON more weight to the color blue. This patch balances the
colors to provide a more even increase in saturation across the RGB
channels.
Closesjp9000/obs-studio#739
When using this filter in/on OpenGL situations can cause crashes with an
"int to vec4" cast. This fix should resolve that issue.
Closesjp9000/obs-studio#739
This reverts commit bd67c18c022f6a01ba054ecd77ba176359f33f73.
Causes performance issues when the window isn't found. The situation it
fixes is also very rare anyway.
Using and creating a window can use issues in game capture if multiple
game captures are active, so revert back to using a mutex, and just
ignore the keepalive check failure if injected inside a UWP program
(only check to see if GetLastError reports that it's not found -- if it
returns access denied or any other error, assume it's in a UWP program,
and ignore the keepalive check).
If the backbuffer count is larger than 3, it could still try to assign
backbuffers to pointers beyond the variable's array size when calling
swap->GetBuffer.
Use a d3d9 device and allocator to encode in QSV.
This fixes a random crash that could only happen on Windows 7. The QSV
Deviced returned a DEVICE_FAILURE after a random amount of time with the
old method.
This fix is totally based on Shinck's QSVHelper.exe patch for OBS
Classic (see
https://obsproject.com/forum/threads/0-633b-qsvhelper-exe-was-killed-encode-failed.19230/page-3#post-161984
for more information)
This is more like a proof of concept, but that fix is currently stable
and tested more than 50 hours, with a single session of +14 hours.
That commit doesn't respect all OBS Guidelines. It is currently
recommended to wait for a more "cleaner" implementation.
Due to using FindWindowEx to search for certain windows, certain windows
will show up that aren't usable/capturable. Prevent these windows from
showing up in the window lists.
For some unknown reason, GetWindow will not traverse the entire window
tree. It could be due to Microsoft purposely hiding certain UWP
windows, though the reason is unknown. For some equally unknown reason
FindWindowEx does work in its place.
This fixes the issue of not being able to find/capture certain windows,
such as halo 5: forge.
D3D12 capture does not take in to account when multiple backbuffers are
in used. With previous versions of Direct3D there was no need to do
this, but with D3D12 you must explicitly capture each specific
backbuffer currently in use.
The encoder name was changed from "nvenc_h264" to "h264_nvenc", and will
throw a warning in the log file if you use the former, so try the latter
first, then the former.
Similar to the parent commit, do not reset the blend state if the source
is not marked as a custom drawn source. Filters applied won't have the
correct blend state and the alpha edges of the text will be partially
black.
The blend state does not need to (and should not) be changed. This
fixes an issue where if filters are applied to an image source, the
image source will paint incorrectly.
Replaces the "Color Correction" filter with a newer version that uses a
matrix, adds hue and saturation, and improves the contrast option.
Closesjp9000/obs-studio#708
If capturing a UWP window, do not fall back to matching windows with the
same window class if the exact window is not found, as this will get any
other UWP window on the system (due to the fact that they all have the
same window class name).
Because the hook cannot get the window handle of UWP windows, fall back
to using the window handle stored in the game capture source itself if
it's unavailable from the hook.
Under certain circumstances, the program may not be able to acquire the
window thread ID for a UWP process, but will be able to acquire the
process ID. In this case, it should soft fail and retry, rather than
assume it's unacquirable and stop trying to reacquire.
The "attempting to hook [executable]" message would not display the
correct executable if it's fallen back to a different window with the
same window class.
Now that the game capture hook creates and controls all the
synchronization objects, it's no longer possible to expect that the hook
is fully loaded by the time game capture tries to initialize it. In
that case, allow game capture to retry the hook for a few frames before
assuming something failed.
This detects whether the target process is a UWP process, and then uses
the open_app_* functions for mutexes/events/mapping. Also slightly
refactors named object open functions.
The only way to open named kernel objects within a UWP "app" is to get
the AppContainer SID, and then open the objects with their full
system namespace names via undocumented NT functions.
