obs-ffmpeg, UI: Implement flush replay buffer after save
Description
Adds simple/advanced output replay buffer setting to allow flushing the replay buffer after the save button or hotkey is pressed.
Separately, fixes an issue with the save button not re-enabling after pressing stop on a paused recording.
Motivation and Context
To cut down on duplicate footage in saved replay clips.
- https://ideas.obsproject.com/posts/246/add-replay-buffer-option-to-clear-on-save
- https://obsproject.com/forum/threads/smarter-replay-buffer-options.156347/
- Etc.
How Has This Been Tested?
Tested on Windows 11. Both the hotkey and the UI save button reset the buffer after save. I've also tested alongside recording.
Types of changes
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [ ] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
I definitely welcome help, suggestions, ideas, criticism, etc. This has been a bit of a learning project for me as I'm basically new to the language. 😅 As you can see above I've been back and forth with ideas, and I'm still not sure if I'm on the best path...
I definitely welcome help, suggestions, ideas, criticism, etc. This has been a bit of a learning project for me as I'm basically new to the language. 😅 As you can see above I've been back and forth with ideas, and I'm still not sure if I'm on the best path...
PRs are reviewed as time allows. We're in the middle of the beta phase of a release cycle, so efforts are understandably focused on pure bug fixes rather than new features. It may be some time before someone is able to dig into this. Thank you for your understanding.
No rush at all.
After discussion, we don't want this as a checkbox, but we would be fine adding a separate hotkey that allows the user to save the replay buffer and flush it.
As a separate matter, it would be more expedient to get the bug fix in if it were submitted separately from a feature PR.
Good ideas. Will create a new PR for the bug fix and add as a separate hotkey here ASAP.
Note to self: Keep this in mind: https://github.com/elgatosf/streamdeck-obs-plugin2
On Mon, Jan 23, 2023 at 2:23 PM Ryan Foster @.***> wrote:
After discussion, we don't want this as a checkbox, but we would be fine adding a separate hotkey that allows the user to save the replay buffer and flush it.
As a separate matter, it would be more expedient to get the bug fix in if it were submitted separately from a feature PR.
— Reply to this email directly, view it on GitHub https://github.com/obsproject/obs-studio/pull/7940#issuecomment-1401088163, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPORXSDBIKRS5CQEQSLY5DWT4AG7ANCNFSM6AAAAAATCJN5HA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Been using this pull request for a few hours of clips, and it seems to work great. Would be perfect if the second clip started exactly where the first output ended, as it would not require syncing when editing. Currently the second clip starts a bit before the first one ends (around 3 seconds of overlapping footage on my machine)
Thanks for this nice feature, been searching for it and found this PR luckily.
After discussion, we don't want this as a checkbox, but we would be fine adding a separate hotkey that allows the user to save the replay buffer and flush it.
As a separate matter, it would be more expedient to get the bug fix in if it were submitted separately from a feature PR.
Finally working on implementing this as a hotkey... Will update the above description and take care of the save button (051b4fec5667a52bad471ede38247a0508c2b75b) in a separate PR.
And, RE:
Currently the second clip starts a bit before the first one ends (around 3 seconds of overlapping footage on my machine)
I believe that is a symptom of only flushing down to two keyframes. IIRC, I ran into issues otherwise. e.g.,
if (flushing(stream)) {
while (stream->keyframes >= 2)
purge(stream);
os_atomic_set_bool(&stream->flushing, false);
return;
}
Will see what I can figure out... May need some help on that one.