A bug which was technically introduced in df446c3f6e: the author
assigned video mixes to the virtual camera and did not realize you have
to wait for full capture stop with the "deactivate" signal rather than
the "stop" signal. This situation is understandable because these
signals are likely confusing and need more documentation.
The way an output works when it stops is it has three stages:
- "stopping", which is the moment the user themselves stop the output
- "stop", when the output's implementation has stopped and returns
success or an error code
- "deactivate", when the output inself (not the implementation) has
fully stopped capturing encoded or raw frame data after the
implementation has stopped. This is done in a separate thread,
end_data_capture_thread(), for performance and data race reasons, and
is when it's "actually fully stopped for real this time"
(Lain note: I sincerely apologize for this confusing signal design)
The author of df446c3f6e was likely confused as to why they could not
destroy the video mix in the "stop" signal without triggering a race
condition in end_data_capture_thread(), and instead decided to make a
workaround to clear the video mix set to the output before destroying
the video mix. Unsetting the video mix I'm guessing *seemed* to fix the
problem for them at the time, and destroying the video mix separately
after that automatically stops capture, so it *technically* worked
because the deactivate thread cannot be called until the
implementation's stop signal has executed. However, it was still the
incorrect way to handle the problem, because it circumvents the output's
mechanism for deactivating the frame data capture by destroying the view
instead.
The reason this was the incorrect way to handle the problem became
exposed in 7cd7ca80f8, when tytan made it so it uses the main video mix
under certain circumstances. The main view is special and cannot be
destroyed, so the mechanism to stop frame data capture that the
virtualcam was using before failed, and raw frame data capture continued
perpetually until the end of the program erroneously.
This fix solves the bug by using the "deactivate" signal rather than the
"stop" signal, thus allowing the output to fully end its data capture
and *then* destroy the video mix.
Fixesobsproject/obs-studio#9153
This reverts commit 02f3495b72.
Multiple issues have come up with this commit. One issue is that
suddenly replays are overwriting themselves despite the option being
disabled. Second issue is that slashes to separate files into
subdirectories no longer work properly with replay buffers.
I'm just reverting it. I do not care enough about this feature to try to
fix it or wait on a fix. If someone wants to fix it they can create a
new PR for it.
This commit implements a new feature to split recordings in split files
in Advanced output mode.
These basic settings are implemented.
- Enable/disable the feature. Default is disabled.
- Select a type of the limit, time or size.
- Specifies the limit in seconds or MiB.
This shows notifications in the status bar with the following:
- When screenshot is saved
- When replay buffer is saved
- When recording is saved
- When recording is auto remuxed
The frontend API event OBS_FRONTEND_EVENT_REPLAY_BUFFER_SAVED was not
being triggered when hotkeys were used because it was only set to
trigger when the replay buffer button was clicked, not when a hotkey was
used. This fixes it so that the frontend event sends a signal to the
frontend so that hotkeys will actually work.
Due to the fact that a global was used on GenerateSpecifiedFilename to
save the remux file name, when a screenshot was made, it would overwrite
the filename being remuxed, because screenshots use the same function to
generate filenames as well.
This solves that problem by removing the global and the changes to
GeneratedSpecifiedFilename, and isolating that to the output handler.
Coincidentally, this bug probably also happened with replay buffers
under certain circumstances.
Fixesobsproject/obs-studio#3497Closesobsproject/obs-studio#3498
In 218b936b1d, the virtual camera was ignored when checking the active
state, which is kind of a lackluster solution. Instead, this makes
SetupOutputs() a virtual function, and calls it before starting the
virtual camera to be more consistent with the rest of the outputs.
The BasicOutputHandler::Active() function was used for checking whether
outputs had started or not. However, the virtual camera is not used in
the subclasses; instead it's a part of the base class. Because of that
fact, when the virtual camera is started, the procedures used to start
up the other outputs are never called, causing outputs to crash because
they hadn't been initialized properly. For example, starting the
virtual camera, then starting stream/recording would crash.
So, as a simple fix to this, when checking the active status in the
derived classes, do not factor in the virtual camera.
Adds a virtual camera button to the main user interface. If virtual
camera is not installed, it will not add the button. On Windows, it
detects whether the virtual camera filters are properly registered, and
will only add the button if the virtual camera filter is confirmed
registered.
Also adds a virtual camera option to the auto-configuration wizard,
which will just simply set the user's resolution/scale to 1920x1080 at
30 FPS.
Code submissions have continually suffered from formatting
inconsistencies that constantly have to be addressed. Using
clang-format simplifies this by making code formatting more consistent,
and allows automation of the code formatting so that maintainers can
focus more on the code itself instead of code formatting.
Allows a service to specify the output it needs in order to function as
configured.
NOTE: This functionality should be considered temporary as a seamless
means of implementing support for different output types within the same
service. Ideally, different services should be used for this
functionality.
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.
If the user hits the "stop stream" button it'll transition in to
"stopping stream..." and will continue to output until the stream
reaches the timing in which "stop" was pressed.
However, if there is significant congestion, stopping the stream can
take far longer than the user may like. So there needs to be an option
to forcibly stop the stream in that case; pushing the "stop" button a
second time should allow the user to tell the stream/recording to stop
right away instead of waiting for the precise stop timing.
