Currently, this allows the setting of values such as:
- Audio buffering time
- Color format (still somewhat unsupported)
- YUV color space (if a YUV format)
= YUV color range (if a YUV format)
More color formats will be added in the future, such as RGB and YUV
4:2:2 formats.
The 'rescale' values in advanced output section are supposed to be based
upon the output resolution of the program. Meaning they should not be
used for scaling up, because the resolution downloaded from the graphics
processor is the output resolution set in video settings; thus any
resolution you set for the 'rescale' values is scaled from that.
Currently service settings are updated in real time via the properties
view, which means that OK/Cancel/Apply have no effect. This fixes that
by using the new type of properties view that operates only on settings
data, not an object.
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
Typedef pointers are unsafe. If you do:
typedef struct bla *bla_t;
then you cannot use it as a constant, such as: const bla_t, because
that constant will be to the pointer itself rather than to the
underlying data. I admit this was a fundamental mistake that must
be corrected.
All typedefs that were pointer types will now have their pointers
removed from the type itself, and the pointers will be used when they
are actually used as variables/parameters/returns instead.
This does not break ABI though, which is pretty nice.
Currently, if a user presses 'OK' or 'Apply' on the settings window, it
will save all data from all controls on a settings pane, regardless of
whether of not they were changed. The major issue with this is that
setting the data will overwrite all default values, making it impossible
for default values to be used if a user didn't actually change a value.
(Thanks to palana for pointing this fact out)
So instead, mark a control as 'changed' using QObject::property() and
QObject::sender(), and add a few helper functions to controls to ensure
that they are checked to see whether they were actually changed directly
by the user before saving the value to the config.
Implement the 'file path' in output settings, and implement the 'start
recording' button, though for the time being I'm just going to make it
use a directory rather than allow custom file names.
This file output will actually share the video and audio encoder with
the stream.
I don't really know what to do about MP4 -- I don't really like the idea
of saving directly in the program, if you do and the program crashes,
that MP4 file is lost. I'm contemplating making some sort of mp4 output
process stub. So no MP4 file output for the time being.
If you need MP4, just remux it with FFmpeg:
ffmpeg -i flv_file.flv -acodec copy -vcodec copy mp4_file.mp4
- 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.
- Add some temporary streaming code using FFmpeg. FFmpeg itself is not
very ideal for streaming; lack of direct control of the sockets and
no framedrop handling means that FFmpeg is definitely not something
you want to use without wrapper code. I'd prefer writing my own
network framework in this particular case just because you give away
so much control of the network interface. Wasted an entire day
trying to go through FFmpeg issues.
There's just no way FFmpeg should be used for real streaming (at
least without being patched or submitting some sort of patch, but I'm
sort of feeling "meh" on that idea)
I had to end up writing multiple threads just to handle both
connecting and writing, because av_interleaved_write_frame blocks
every call, stalling the main encoder thread, and thus also stalling
draw signals.
- Add some temporary user interface for streaming settings. This is
just temporary for the time being. It's in the outputs section of
the basic-mode settings
- Make it so that dynamic arrays do not free all their data when the
size just happens to be reduced to 0. This prevents constant
reallocation when an array keeps going from 1 item to 0 items. Also,
it was bad to become dependent upon that functionality. You must now
always explicitly call "free" on it to ensure the data is free, and
that's how it should be. Implicit functionality can lead to
confusion and maintainability issues.
Having everything in global.ini meant that if you wanted different
settings for studio mode, that it would also overwrite it for basic
mode. This way, the settings for each mode are separate, and you can
use different settings for each mode.
Implement a few audio options in to the user interface as well as a few
inline audio functions in audio-io.h.
Make it so ffmpeg plugin automatically converts to the desired format.
Use regular interleaved float internally for audio instead of planar
float.
- Move over the last of the original settings dialog code to QT. It was
actually a bit easier to write in the QT version. wxWidgets was
definitely not ideal for that because the pages would fully
create/destroy every time.
- [Win32] Fix os_dlopen so that it only appends .dll if not present
- [MacOS] Fix name dialog text edit widget issue (it would be better if
we could just use the list widget for editing labels, will have to
look in to that in the future)
- Tweak the settings UI a bit more and make 30 FPS default
- Add a macro to convert a QString to a UTF-8 const char * string
- Rename build/plugins to build/obs-plugins
- Remove the last of the wxWidgets code
- Had the wrong names set for the up/down widgets for sources/scenes
- Updated the settings dialog and gave most of the widgets actual object
names
- Added code for the settings window. Settings window should now at
least display.
