jp9000
/
obs-studio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
obs-studio/obs/window-basic-main-outputs.hpp

43 lines
1.2 KiB
C++
Raw Normal View History

UI: Refactor output handling To accommodate multiple types of outputs, there has to be some level of abstraction. The BasicOutputHandler structure will give us a way that we can switch between different output configurations.
2015-02-06 03:17:33 -08:00
#pragma once
class OBSBasic;
struct BasicOutputHandler {
OBSOutput fileOutput;
OBSOutput streamOutput;
UI: Don't use activeRefs to determine if active Due to certain design changes for delay, it's better to simply determine whether outputs are active via booleans rather than an activeRefs variable, which could get decremented more than once if say, the signal for stopping the stream gets called more than once for whatever reason (which may happen in the case of delay due to the way delay works)
2015-09-06 16:07:45 -07:00
bool streamingActive = false;
bool recordingActive = false;
UI: Implement stream delay When stream delay is active, the "Start/Stop Streaming" button is changed in to a menu button, which allows the user to select either the option to stop the stream (which causes it to count down), or forcibly stop the stream (which immediately stops the stream and cuts off all delayed data). If the user decides they want to start the stream again while in the process of counting down, they can safely do so without having to wait for it to stop, and it will schedule it to start up again with the same delay after the stop. On the status bar, it will now show whether delay is active, and its duration. If the stream is in the process of stopping/starting, it will count down to the stop/start. If the option to preserve stream cutoff point on unexpected disconnections/reconnections is enabled, it will update the current delay duration accordingly.
2015-09-06 16:19:53 -07:00
bool delayActive = false;
UI: Refactor output handling To accommodate multiple types of outputs, there has to be some level of abstraction. The BasicOutputHandler structure will give us a way that we can switch between different output configurations.
2015-02-06 03:17:33 -08:00
OBSBasic *main;
UI: Release recording/streaming signals before outputs
2015-07-03 23:00:21 -07:00
OBSSignal startRecording;
OBSSignal stopRecording;
OBSSignal startStreaming;
OBSSignal stopStreaming;
UI: Implement stream delay When stream delay is active, the "Start/Stop Streaming" button is changed in to a menu button, which allows the user to select either the option to stop the stream (which causes it to count down), or forcibly stop the stream (which immediately stops the stream and cuts off all delayed data). If the user decides they want to start the stream again while in the process of counting down, they can safely do so without having to wait for it to stop, and it will schedule it to start up again with the same delay after the stop. On the status bar, it will now show whether delay is active, and its duration. If the stream is in the process of stopping/starting, it will count down to the stop/start. If the option to preserve stream cutoff point on unexpected disconnections/reconnections is enabled, it will update the current delay duration accordingly.
2015-09-06 16:19:53 -07:00
OBSSignal streamDelayStarting;
UI: Show "stopping" text on buttons when waiting for stop The new cutoff timing fix means that streaming/recording has to remain active for bit until the stream/recording has reached the expecting stop timestamp. This means that the buttons would continue to say "Stop streaming/recording" while waiting for the output to stop itself at the appropriate timing. So instead of letting it do that and confusing the user, the buttons will now say "stopping" when the button is pressed to indicate to the user that the stream/recording is in the process of stopping.
2016-06-22 01:47:08 -07:00
OBSSignal streamStopping;
OBSSignal recordStopping;
UI: Release recording/streaming signals before outputs
2015-07-03 23:00:21 -07:00
UI: Refactor output handling To accommodate multiple types of outputs, there has to be some level of abstraction. The BasicOutputHandler structure will give us a way that we can switch between different output configurations.
2015-02-06 03:17:33 -08:00
inline BasicOutputHandler(OBSBasic *main_) : main(main_) {}
virtual ~BasicOutputHandler() {};
virtual bool StartStreaming(obs_service_t *service) = 0;
virtual bool StartRecording() = 0;
virtual void StopStreaming() = 0;
UI: Implement stream delay When stream delay is active, the "Start/Stop Streaming" button is changed in to a menu button, which allows the user to select either the option to stop the stream (which causes it to count down), or forcibly stop the stream (which immediately stops the stream and cuts off all delayed data). If the user decides they want to start the stream again while in the process of counting down, they can safely do so without having to wait for it to stop, and it will schedule it to start up again with the same delay after the stop. On the status bar, it will now show whether delay is active, and its duration. If the stream is in the process of stopping/starting, it will count down to the stop/start. If the option to preserve stream cutoff point on unexpected disconnections/reconnections is enabled, it will update the current delay duration accordingly.
2015-09-06 16:19:53 -07:00
virtual void ForceStopStreaming() = 0;
UI: Refactor output handling To accommodate multiple types of outputs, there has to be some level of abstraction. The BasicOutputHandler structure will give us a way that we can switch between different output configurations.
2015-02-06 03:17:33 -08:00
virtual void StopRecording() = 0;
virtual bool StreamingActive() const = 0;
virtual bool RecordingActive() const = 0;
virtual void Update() = 0;
UI: Don't use activeRefs to determine if active Due to certain design changes for delay, it's better to simply determine whether outputs are active via booleans rather than an activeRefs variable, which could get decremented more than once if say, the signal for stopping the stream gets called more than once for whatever reason (which may happen in the case of delay due to the way delay works)
2015-09-06 16:07:45 -07:00
inline bool Active() const
{
UI: Implement stream delay When stream delay is active, the "Start/Stop Streaming" button is changed in to a menu button, which allows the user to select either the option to stop the stream (which causes it to count down), or forcibly stop the stream (which immediately stops the stream and cuts off all delayed data). If the user decides they want to start the stream again while in the process of counting down, they can safely do so without having to wait for it to stop, and it will schedule it to start up again with the same delay after the stop. On the status bar, it will now show whether delay is active, and its duration. If the stream is in the process of stopping/starting, it will count down to the stop/start. If the option to preserve stream cutoff point on unexpected disconnections/reconnections is enabled, it will update the current delay duration accordingly.
2015-09-06 16:19:53 -07:00
return streamingActive || recordingActive || delayActive;
UI: Don't use activeRefs to determine if active Due to certain design changes for delay, it's better to simply determine whether outputs are active via booleans rather than an activeRefs variable, which could get decremented more than once if say, the signal for stopping the stream gets called more than once for whatever reason (which may happen in the case of delay due to the way delay works)
2015-09-06 16:07:45 -07:00
}
UI: Refactor output handling To accommodate multiple types of outputs, there has to be some level of abstraction. The BasicOutputHandler structure will give us a way that we can switch between different output configurations.
2015-02-06 03:17:33 -08:00
};
BasicOutputHandler *CreateSimpleOutputHandler(OBSBasic *main);
UI: Add advanced output settings Adds an 'advanced' mode to the output settings to allow more powerful and complex streaming and recording options: - Optionally use a different encoder for recording than for streaming to allow the recording to use a different encoder or encoder settings if desired (though at the cost if increased CPU usage depending on the encoders being used) - Use encoders other than x264 - Rescale the recording or streaming encoders in case the user wishes to stream and record at different resolutions - Select the specific mixer to use for recording and for streaming, allowing the stream and recording to use separate mixers (to for example allow a user to stream the game/mic audio but only record the game audio) - Use FFmpeg output for the recording button instead of only recording h264/aac to FLV, allowing the user to output to various different types of file formats or remote URLs, as well as allowing the user to select and use different encoders and encoder settings that are available in the FFmpeg library - Optionally allow the use of multiple audio tracks in a single output if the file formats or stream services support it
2015-01-26 13:41:22 -08:00
BasicOutputHandler *CreateAdvancedOutputHandler(OBSBasic *main);