In 218b936b1dae, 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.
