2013-12-11 20:50:10 -08:00
|
|
|
/******************************************************************************
|
|
|
|
Copyright (C) 2013 by Hugh Bailey <obs.jim@gmail.com>
|
|
|
|
|
|
|
|
This program is free software: you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation, either version 2 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
******************************************************************************/
|
|
|
|
|
2013-12-10 20:14:20 -08:00
|
|
|
#pragma once
|
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
#include <util/util.hpp>
|
2014-01-24 20:19:50 -08:00
|
|
|
#include <QDialog>
|
2013-12-12 20:47:42 -08:00
|
|
|
#include <memory>
|
2013-12-10 20:14:20 -08:00
|
|
|
|
2014-03-07 11:56:31 -08:00
|
|
|
#include <obs.h>
|
|
|
|
|
2014-03-06 20:08:12 -08:00
|
|
|
class OBSBasic;
|
2014-01-24 20:19:50 -08:00
|
|
|
class QAbstractButton;
|
2014-03-07 11:56:31 -08:00
|
|
|
class QComboBox;
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
class OBSPropertiesView;
|
2014-01-24 20:19:50 -08:00
|
|
|
|
|
|
|
#include "ui_OBSBasicSettings.h"
|
2013-12-10 20:14:20 -08:00
|
|
|
|
2014-01-24 20:19:50 -08:00
|
|
|
class OBSBasicSettings : public QDialog {
|
|
|
|
Q_OBJECT
|
2013-12-11 20:50:10 -08:00
|
|
|
|
2014-01-24 20:19:50 -08:00
|
|
|
private:
|
2014-03-06 20:08:12 -08:00
|
|
|
OBSBasic *main;
|
|
|
|
|
2014-01-24 20:19:50 -08:00
|
|
|
std::unique_ptr<Ui::OBSBasicSettings> ui;
|
2015-02-03 20:19:48 -08:00
|
|
|
bool generalChanged = false;
|
|
|
|
bool outputsChanged = false;
|
|
|
|
bool audioChanged = false;
|
|
|
|
bool videoChanged = false;
|
|
|
|
int pageIndex = 0;
|
|
|
|
bool loading = true;
|
|
|
|
|
|
|
|
OBSPropertiesView *streamProperties = nullptr;
|
2015-01-26 13:41:22 -08:00
|
|
|
OBSPropertiesView *streamEncoderProps = nullptr;
|
|
|
|
OBSPropertiesView *recordEncoderProps = nullptr;
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
|
2014-06-23 19:54:20 -07:00
|
|
|
void SaveCombo(QComboBox *widget, const char *section,
|
|
|
|
const char *value);
|
|
|
|
void SaveComboData(QComboBox *widget, const char *section,
|
|
|
|
const char *value);
|
2015-01-26 13:41:22 -08:00
|
|
|
void SaveCheckBox(QAbstractButton *widget, const char *section,
|
|
|
|
const char *value, bool invert = false);
|
2014-06-23 19:54:20 -07:00
|
|
|
void SaveEdit(QLineEdit *widget, const char *section,
|
|
|
|
const char *value);
|
|
|
|
void SaveSpinBox(QSpinBox *widget, const char *section,
|
|
|
|
const char *value);
|
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
inline bool Changed() const
|
|
|
|
{
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
return generalChanged || outputsChanged ||
|
|
|
|
audioChanged || videoChanged;
|
2014-01-26 14:36:15 -08:00
|
|
|
}
|
|
|
|
|
2014-05-09 15:04:39 -07:00
|
|
|
inline void EnableApplyButton(bool en)
|
|
|
|
{
|
|
|
|
ui->buttonBox->button(QDialogButtonBox::Apply)->setEnabled(en);
|
|
|
|
}
|
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
inline void ClearChanged()
|
|
|
|
{
|
|
|
|
generalChanged = false;
|
|
|
|
outputsChanged = false;
|
|
|
|
audioChanged = false;
|
|
|
|
videoChanged = false;
|
2014-05-09 15:04:39 -07:00
|
|
|
EnableApplyButton(false);
|
2014-01-26 14:36:15 -08:00
|
|
|
}
|
|
|
|
|
2014-03-07 11:56:31 -08:00
|
|
|
void HookWidget(QWidget *widget, const char *signal, const char *slot);
|
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
bool QueryChanges();
|
|
|
|
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
void LoadServiceTypes();
|
|
|
|
void LoadServiceInfo();
|
2015-01-26 13:41:22 -08:00
|
|
|
void LoadEncoderTypes();
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
void LoadGeneralSettings();
|
2014-03-10 13:10:35 -07:00
|
|
|
void LoadOutputSettings();
|
2014-02-23 15:27:19 -08:00
|
|
|
void LoadAudioSettings();
|
2014-01-26 14:36:15 -08:00
|
|
|
void LoadVideoSettings();
|
2014-02-23 15:27:19 -08:00
|
|
|
void LoadSettings(bool changedOnly);
|
2014-01-26 14:36:15 -08:00
|
|
|
|
2015-01-26 13:41:22 -08:00
|
|
|
OBSPropertiesView *CreateEncoderPropertyView(const char *encoder,
|
|
|
|
const char *path, bool changed = false);
|
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
/* general */
|
|
|
|
void LoadLanguageList();
|
|
|
|
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
/* output */
|
|
|
|
void LoadSimpleOutputSettings();
|
2015-01-26 13:41:22 -08:00
|
|
|
void LoadAdvOutputStreamingSettings();
|
|
|
|
void LoadAdvOutputStreamingEncoderProperties();
|
|
|
|
void LoadAdvOutputRecordingSettings();
|
|
|
|
void LoadAdvOutputRecordingEncoderProperties();
|
|
|
|
void LoadAdvOutputFFmpegSettings();
|
|
|
|
void LoadAdvOutputAudioSettings();
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
|
2014-03-06 06:02:25 -08:00
|
|
|
/* audio */
|
2014-09-25 17:44:05 -07:00
|
|
|
void LoadListValues(QComboBox *widget, obs_property_t *prop,
|
2014-03-07 11:56:31 -08:00
|
|
|
const char *configName);
|
2014-03-06 06:02:25 -08:00
|
|
|
void LoadAudioDevices();
|
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
/* video */
|
|
|
|
void LoadRendererList();
|
|
|
|
void ResetDownscales(uint32_t cx, uint32_t cy);
|
2014-12-15 01:08:46 -08:00
|
|
|
void LoadDownscaleFilters();
|
2014-01-26 14:36:15 -08:00
|
|
|
void LoadResolutionLists();
|
|
|
|
void LoadFPSData();
|
|
|
|
|
|
|
|
void SaveGeneralSettings();
|
2014-03-10 13:10:35 -07:00
|
|
|
void SaveOutputSettings();
|
2014-02-23 15:27:19 -08:00
|
|
|
void SaveAudioSettings();
|
2014-01-26 14:36:15 -08:00
|
|
|
void SaveVideoSettings();
|
|
|
|
void SaveSettings();
|
2013-12-17 12:56:58 -08:00
|
|
|
|
2014-01-24 20:19:50 -08:00
|
|
|
private slots:
|
2015-02-06 03:56:19 -08:00
|
|
|
void on_simpleOutUseBufsize_toggled(bool checked);
|
|
|
|
void on_simpleOutputVBitrate_valueChanged(int val);
|
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
void on_listWidget_itemSelectionChanged();
|
2014-01-24 20:19:50 -08:00
|
|
|
void on_buttonBox_clicked(QAbstractButton *button);
|
|
|
|
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
void on_streamType_currentIndexChanged(int idx);
|
2014-05-20 23:27:27 -07:00
|
|
|
void on_simpleOutputBrowse_clicked();
|
2015-01-26 13:41:22 -08:00
|
|
|
void on_advOutRecPathBrowse_clicked();
|
|
|
|
void on_advOutFFPathBrowse_clicked();
|
|
|
|
void on_advOutEncoder_currentIndexChanged(int idx);
|
|
|
|
void on_advOutRecEncoder_currentIndexChanged(int idx);
|
obs-studio UI: Implement stream settings UI
- Updated the services API so that it links up with an output and
the output gets data from that service rather than via settings.
This allows the service context to have control over how an output is
used, and makes it so that the URL/key/etc isn't necessarily some
static setting.
Also, if the service is attached to an output, it will stick around
until the output is destroyed.
- The settings interface has been updated so that it can allow the
usage of service plugins. What this means is that now you can create
a service plugin that can control aspects of the stream, and it
allows each service to create their own user interface if they create
a service plugin module.
- Testing out saving of current service information. Saves/loads from
JSON in to obs_data_t, seems to be working quite nicely, and the
service object information is saved/preserved on exit, and loaded
again on startup.
- I agonized over the settings user interface for days, and eventually
I just decided that the only way that users weren't going to be
fumbling over options was to split up the settings in to simple/basic
output, pre-configured, and then advanced for advanced use (such as
multiple outputs or services, which I'll implement later).
This was particularly painful to really design right, I wanted more
features and wanted to include everything in one interface but
ultimately just realized from experience that users are just not
technically knowledgable about it and will end up fumbling with the
settings rather than getting things done.
Basically, what this means is that casual users only have to enter in
about 3 things to configure their stream: Stream key, audio bitrate,
and video bitrate. I am really happy with this interface for those
types of users, but it definitely won't be sufficient for advanced
usage or for custom outputs, so that stuff will have to be separated.
- Improved the JSON usage for the 'common streaming services' context,
I realized that JSON arrays are there to ensure sorting, while
forgetting that general items are optimized for hashing. So
basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
|
|
|
|
2014-01-26 14:36:15 -08:00
|
|
|
void on_baseResolution_editTextChanged(const QString &text);
|
2014-03-07 11:56:31 -08:00
|
|
|
|
|
|
|
void GeneralChanged();
|
|
|
|
void AudioChanged();
|
|
|
|
void AudioChangedRestart();
|
2014-03-10 13:10:35 -07:00
|
|
|
void OutputsChanged();
|
2014-03-07 11:56:31 -08:00
|
|
|
void VideoChanged();
|
|
|
|
void VideoChangedResolution();
|
|
|
|
void VideoChangedRestart();
|
2014-01-26 14:36:15 -08:00
|
|
|
|
2014-01-24 20:19:50 -08:00
|
|
|
protected:
|
|
|
|
virtual void closeEvent(QCloseEvent *event);
|
2013-12-17 12:56:58 -08:00
|
|
|
|
2013-12-10 20:14:20 -08:00
|
|
|
public:
|
2014-01-24 20:19:50 -08:00
|
|
|
OBSBasicSettings(QWidget *parent);
|
2013-12-10 20:14:20 -08:00
|
|
|
};
|