- 18 12月, 2016 7 次提交
-
-
由 jp9000 提交于
-
由 jp9000 提交于
With the previous Y800 fix a bug was introduced where the format for the destination frame wouldn't be set if it wasn't Y800, causing a crash.
-
由 Michael Fabian Dirks 提交于
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. Closes jp9000/obs-studio#706
-
由 jp9000 提交于
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. Closes jp9000/obs-studio#718
-
由 Jim 提交于
UI: Fix frontend-api event call for adding scenes
-
由 jp9000 提交于
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. Closes jp9000/obs-studio#714
-
由 jp9000 提交于
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 Closes jp9000/obs-studio#714
-
- 17 12月, 2016 14 次提交
-
-
由 vic 提交于
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. Closes jp9000/obs-studio#712
-
由 Jim 提交于
libff: Allow custom demuxer options
-
由 jp9000 提交于
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).
-
由 jp9000 提交于
These are helpful for debugging UWP capture issues.
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
The ApplicationFrameHost process is a sandbox process, and should not be hooked.
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
Remote threads in suspended processes will also start up suspended, so do not attempt to hook suspended processes.
-
由 jp9000 提交于
-
由 jp9000 提交于
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
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.
-
- 16 12月, 2016 8 次提交
-
-
由 jp9000 提交于
Prevents from having to mix ansi/wide string usage for opening UWP programs.
-
由 jp9000 提交于
This function now already exists elsewhere -- open_event_plus_id.
-
由 jp9000 提交于
The "Local\" prefix effectively does nothing.
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
Named pipes cannot be used within UWP programs, so make them optional.
-
由 jp9000 提交于
This prevents issues with opening handles to objects within UWP programs, which have increased security limitations.
-
- 13 12月, 2016 1 次提交
-
-
由 jp9000 提交于
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.
-
- 12 12月, 2016 1 次提交
-
-
由 jp9000 提交于
-
- 10 12月, 2016 3 次提交
-
-
由 jp9000 提交于
Adds the ability to use a specific prefix and/or suffix on replay buffer filenames to distinguish them from normal recordings. Defaults to having the prefix "Replay".
-
由 jp9000 提交于
Replay buffer and recording should be separate in case the user wants to start recording from a specific point rather being forced to reconfigure for regular recording. Creates a new button on the main window below the recording button for turning on/off the replay buffer.
-
由 jp9000 提交于
It should specify that the user specifically needs to set the "save" hotkey, not just "the replay buffer hotkey".
-
- 08 12月, 2016 6 次提交
-
-
由 jp9000 提交于
-
由 jp9000 提交于
-
由 jp9000 提交于
This output allows buffering the encoded data, and then muxing the current buffer to a file on the spot via a hotkey the user sets.
-
由 jp9000 提交于
Prevents reallocation of encoded packet data. Deprecates: obs_duplicate_encoder_packet obs_free_encoder_packet Replaces those functions with: obs_encoder_packet_ref obs_encoder_packet_release
-
由 jp9000 提交于
On MSVC, deprecated types/functions were being completely ignored by the compiler due to this pragma. Any plugins/programs that depended on this would also have this warning disabled due to it being in this file. This pragma was most likely originally done due to the MSVC warnings for C-standard functions, which are now ignored via _CRT_SECURE_NO_WARNINGS on all projects instead.
-
由 jp9000 提交于
There's no need to have two separate macros to declare something as deprecated.
-