Commit 53955301a2 introduced a async source texture copy bug due to
creating a new case in a switch without adding a break to the one above
it, causing it to execute both cases by mistake.
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.
When rebuilding the graphics subsystem, it's possible a shared texture
may no longer be available. In this case, just soft fail and allow the
texture to be rebuilt rather than crash the entire program over it.
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
This commit adds the ability to copy a scene item's transform and crop
settings and paste those settings onto another scene item in any scene
or scene collection. It also changes the menu shortcut key for the
Transform action "Center to screen" from "C" to "n" because "C" is the
standard shortcut key for "Copy" in most other applications.
Closesjp9000/obs-studio#719
This enables use of the dedicated GPUs for AMD PowerXpress systems.
Especially important for Adapter selection, as usually the dedicated GPU
is hidden/inactive until needed.
Closesjp9000/obs-studio#706
Because D3D11 specifically does not support an L8 texture format (you
have to use a shader swizzle), manually convert Y800 signals to RGBX
instead. This also fixes a bug where Y800 signals will render red.
Closesjp9000/obs-studio#718
In the filters dialog, when the properties are being updated due to
filters being added/removed/switched, using deleteLater on the previous
view would cause it to linger in the view until the deleteLater is
processed by the Qt queue, displaying two views instead of one.
Additionally because of that, this would also cause the display in the
filters dialog to resize as well, causing the reorder mutex hard lock
which was fixed by the parent commit.
Closesjp9000/obs-studio#714
For displays, instead of using the draw_callbacks_mutex and risk a
reverse mutual lock scenario, use a separate mutex to lock display size
data.
This bug was exposed when trying to reorder filters in the UI module.
The UI thread would try to reorder the filters, locking the filter mutex
of the source, and then the reorder would signal the UI to resize the
display, so the display would lock its draw_callbacks_mutex. Then, in
the graphics thread, it would lock the display's draw_callbacks_mutex,
try to draw the source, and then the source would try to lock that same
filter mutex.
A mutex trace:
UI thread -> lock source filter mutex -> waiting on display mutex
graphics thread -> lock display mutex -> waiting on source filter mutex
Closesjp9000/obs-studio#714
This commit fixes a bug that would cause the frontend API function
obs_frontend_set_current_scene_collection to never be successful. Due
to the bug, the following null pointer check would always fail, so the
action would never be triggered.
Modification by Jim: Instead of fixing the typo that caused this to
occur, make it so both scene collection menus and profile menus both use
"file_name" consistently.
Closesjp9000/obs-studio#712
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.
All named objects (including file mapped shared memory) need to be
created within the hook itself due to the fact that UWP programs cannot
access named objects outside of the UWP process.
Because shared memory needs to be created within the hook, the capture
loop cannot start until the shared memory has been filled with valid
data. Creating an additional "initialize" event fixes this issue.
Additionally, changed the way that named kernel objects are
opened/created. Before, there were functions that would first try to
open named objects and then implicitly create them if opening failed
(assuming that if the hook didn't create it first, game capture would),
now it's been changed so that you can only either explicitly open or
create.
To check to make sure game capture is still active in the capture
program, it currently uses a named event, and then it checks to see if
that named event exists. However with UWP programs, you can't open a
named event outside of the UWP process. FindWindow on the other hand
does work, so instead of checking to see if a named kernel object
exists, create a window and check to see if that window exists.
The "main" windows detected for UWP programs are basically to help
sandbox the programs -- they run in the ApplicationFrameHost process and
help reduce the possibility of other programs trying to access the
actual process window, which is a child window.
To bypass this, go through the list of child windows for the
ApplicationFrameHost window, and then find the one that's attached to
a different process; that different process will always be the target,
and will allows us to open the actual process of the UWP program.
Instead of calling OpenThread, use DuplicateHandle with the minimal
access rights (SYNCHRONIZE) to be able to get the current thread handle
within a UWP program.
jp9000
Cephas Reis
Michael Fabian Dirks
cg2121
Ryan Foster
SuslikV
Autumin
shiina424
vic