Apply recording path/format changes to a running output - #183
Open
r-bart wants to merge 1 commit into
Open
Conversation
…adjacent) A live Source Record recording ignored changes to its recording path, format or filename pattern until the filter was disabled/re-enabled: source_record_filter_update only (re)started the file output when the record state changed, never when the settings changed while already recording. Users saw new recordings keep going to the old path (reported on the OBS forum: "file format and path revert unless the filter is disabled/re-enabled between changes"). Cache the path/rec_format/filename_formatting the output was started with, and on an update while recording, if any changed, restart the output the same way a replay-duration change already does (disconnecting the remove-after-record "stop" handler first). A live ffmpeg muxer can't change its file mid-write, so this splits the recording: the current file finalizes (moov written, playable) and a new one starts with the new settings. Only fires while recording; an idle filter already picks up new settings on its next start. Validated over obs-websocket (tests/repro_settings_restart.py): record into dir A, change the filter path to dir B while recording -> a new growing file appears in B and the file in A is finalized with its moov atom. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A live Source Record recording ignores changes to its recording path, format or filename pattern until the filter is disabled/re-enabled.
source_record_filter_updateonly (re)starts the file output when the record state changes, never when the settings change while the output is already recording, so new recordings keep going to the old path. (Reported on the OBS forum: "file format and path revert unless the filter is disabled/re-enabled between changes.")Fix
Cache the
path/rec_format/filename_formattingthe output was started with, and on an update while recording, if any of them changed, restart the output the same way a replay-duration change already does (disconnecting the remove-after-record"stop"handler first so the restart doesn't tear the filter down).A live ffmpeg muxer can't change its file mid-write, so this splits the recording: the current file finalizes (its
moovatom is written, so it stays playable) and a new one starts with the new settings. It only fires while recording; an idle filter already picks up new settings on its next start.Testing
Validated over obs-websocket (
tests/repro_settings_restart.py): record into dir A, change the filterpathto dir B while recording → a new growing file appears in B and the file in A is finalized with itsmoovatom.Developed with AI assistance (Claude); the analysis, diff and test were produced collaboratively and verified against the libobs source. Happy to adjust anything to match your conventions.