-
-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI: Add frontend event and output signal for replay buffer saving #8955
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the hotkey
member of struct ffmpeg_muxer
used anywhere at all now? Should it be removed?
the |
d42ccea
to
9ce55aa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the changes here all dependent on each other? If not, it might make sense to split them into multiple PRs.
It might also make sense to combine "UI: Register the replay buffer save hotkey in the frontend" and "obs-ffmpeg: Clean up now-redundant hotkey registering code" into one commit, given that otherwise you’d have two replay buffer hotkeys at the same time if you only have one of the commits.
Would also like a @Warchamp7 review on the fact that the save replay buffer hotkey is now always available, even if replay buffer is disabled.
The two parts ("add signal and event" and "move hotkey registration") are not technically dependent on each other. However, if the hotkey isn't moved, saving by pressing the hotkey will not trigger the firing of the frontend event (unless you can access the frontend api from within ffmpeg-mux). Event will only be sent when pressing the UI button, which does not feel to me like wishable behaviour. |
I am okay with this change |
ee12061
to
c9192f5
Compare
c9192f5
to
d02938b
Compare
(from what I can see the failed checks are just a result of temporary changes to the CI when this was last pushed, not of the changes introduced by this PR) |
d02938b
to
a34b683
Compare
I just wanted to selfishly poke over here and see what's up. It'd be nice to have this functionality for using plugins with the replay buffer in the main branch instead of having to build with these changes pulled or use custom build artifacts. @gxalpha is the only concern with this change right now (other than merge conflicts) that the two commits for moving the hotkey should be squashed into one? |
Existing registering of the save hotkey in obs-ffmpeg makes it impossible for it to trigger a frontend event, and is inconsistent with other existing output hotkeys. This registers the save hotkey in the frontend and removes the registration in obs-ffmpeg, and adds a "due to hotkey" log message, like other output hotkeys.
a34b683
to
bc616ca
Compare
Description
This adds a frontend event and a signal on the replay buffer's signal
handler that trigger when the replay buffer is saving (i.e. when a save
has been requested, but before it saves).
The frontend event triggers the moment the frontend requests a save
(either through hotkey or the button), whereas the signal triggers when
the replay buffer actually starts saving (separated by the encoding delay).
N.B.: Allowing the save hotkey to trigger a frontend event required
moving its registration from obs-ffmpeg (in the definition of the replay
buffer output) to the UI (with all the frontend hotkeys for outputs).
This actually constitutes the biggest change in this PR.
Motivation and Context
Motivation is mainly to bring replay buffer save to feature parity with
other output events, which almost all have both "before" and "after" events.
A specific usecase envisionned was to allow the dynamic changing of
replay buffer saving path/filename rather than having one set-in-stone
save formatting for the whole session, but many other usecases could be
possible.
Moving over the hotkey registration also has the added benefit of moving
its location next to the other replay buffer hotkeys in the settings UI,
which creates a more consistent UX.
How Has This Been Tested?
This has been tested on Ubuntu 22.04.
Changes to hotkey registration seem to not have affected its behaviour.
Event and signal trigger correctly from hotkey and button.
Types of changes
Checklist: