CBR is now always on by default for streaming, so there's no reason to
have a setting for this in particular. Still available in advanced
output settings of course, but simple output mode really should be kept
as simple as possible.
This is mostly just to remove the unnecessary clutter from the output
sections. The reconnect settings are generally rarely modified by users
as it is.
I added stream delay options to advanced settings not just because I
feel it's an advanced option, but also to reduce clutter in the outputs
section and its sub-sections, which already have far too many options as
it is.
This changes the way the advanced output section's FFmpeg output
settings work by allowing the user to select whether they want to output
to a file or output to a URL, and makes it so file names are
automatically generated like other recording outputs.
If they choose to output to a file, it'll only require an output
directory similarly to how other recording outputs work. They can
select a directory to output to rather than being required to type in a
full path and filename; the filename is automatically generated. The
extension is also automatically retrieved from libff depending on the
format selected.
Otherwise if they have Output to URL selected, it'll show a simple edit
box where they can type in the target URL.
Non-NV12 video formats are primarily intended for recording. For
streaming, if the libobs color format is not set to NV12, it's likely
that the video frames will have to be converted to NV12, which will use
extra CPU usage. Due to that fact, it's important to warn the user of
that potential extra increased CPU usage that may be required when
streaming.
This allows using NV12, I420, or RGB output video formats. This option
will set what obs itself outputs frames as.
It's important to note that this is only ideal for specific FFmpeg
encoders that support the desired video format; for example, if you use
RGB and use the huffyuv encoder, huffyuv will now properly output in RGB
instead of YUV NV12/I420.
I420 is useful for eliminating the NV12->I420 conversion for the
AVerMedia encoders, as AVerMedia encoders only support I420 input.
A second even more important note about RGB is that if the encoder does
not support the format you are using, it will be converted on the CPU to
a format that the encoder supports as it's encoded; so for example
setting the obs output format to RGB and then using x264 will be futile
and end up using needless amounts of extra CPU than if you just had obs
set to NV12, which is the most common and ideal format for x264.
In the future, native output of other YUV formats might be implemented
(such as YUV 4:2:2).
OBS will offer the user a list of themes which are .qss files inside
data/obs-studio/themes. If no theme is found in the configuration, it
loads the default theme for the system.
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.
Add a checkbox named "Enforce streaming service encoder settings"
checkbox to advanced output. Disabling this checkbox allows the user to
optionally disable the enforcement of streaming service encoder
settings. I had a user complain that they didn't want to always have
the service's preferred encoder settings forced on them.
clicked() is the wrong signal to use, it only activates on actual user
click, not when the value is changed. toggle() activates whenever the
value itself is changed.
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
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
Add a 'source selection' dialog to replace the 'enter a name' dialog.
This new dialog allows you to make new instances of pre-existing sources
so that you can add a pre-existing source to a different scene, or in to
the same scene more than once.
Also started implementing locale.
Comtemplating switching to JSON-based locale later, so we can add things
like descriptions/disambiguation, and so we can use jansson's built-in
hash table when doing the string lookup.
- Add volume control
These volume controls are basically nothing more than sliders. They
look terrible and hopefully will be as temporary as they are
terrible.
- Allow saving of specific non-user sources via obs_load_source and
obs_save_source functions.
- Save data of desktop/mic audio sources (sync data, volume data, etc),
and load the data on startup.
- Make it so that a scene is created by default if first time using the
application. On certain operating systems where supported, a default
capture will be created. Desktop capture on mac, particularly. Not
sure what to do about windows because monitor capture on windows 7 is
completely terrible and is bad to start users off with.
It didn't really look very nice in most cases and the controls were
always compacted, doing this makes it look a bit better.
Also change it so the properties window shows the properties on the
bottom below the source rather than to the right, seeing as in most
cases the source has a greater width than height, and it feels just a
little bit better to look at (thought that's just my opinion).
Controls still stretch really far sometimes though, I wonder what should
be done about that to be honest. Maybe prevent it from scrolling to the
right?
- 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.
FFmpeg test output wasn't make any attempt to sync data before. Should
be much more accurate now.
Also, added a restart message to audio settings if base audio settings
are changed.
Split off activate to activate and show callbacks, and split off
deactivate to deactivate and hide callbacks. Sources didn't previously
have a means to know whether it was actually being displayed in the main
view or just happened to be visible somewhere. Now, for things like
transition sources, they have a means of knowing when they have actually
been "activated" so they can initiate their sequence.
A source is now only considered "active" when it's being displayed by
the main view. When a source is shown in the main view, the activate
callback/signal is triggered. When it's no longer being displayed by
the main view, deactivate callback/signal is triggered.
When a source is just generally visible to see by any view, the show
callback/signal is triggered. If it's no longer visible by any views,
then the hide callback/signal is triggered.
Presentation volume will now only be active when a source is active in
the main view rather than also in auxilary views.
Also fix a potential bug where parents wouldn't properly increment or
decrement all the activation references of a child source when a child
was added or removed.
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.
This allows the changing of bideo settings without having to completely
reset all graphics data. Will recreate internal output/conversion
buffers and such and reset the main preview.
- 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.
--------------------------------------------------
Notes and details
--------------------------------------------------
Why was this done? Because wxWidgets was just lacking in many areas. I
know wxWidgets is designed to be used with native controls, and that's
great, but wxWidgets just is not a feature-complete toolkit for
multiplatform applications. It lacks in dialog editors, its code is
archaic and outdated, and I just feel frustrated every time I try to do
things with it.
Qt on the other hand.. I had to actually try Qt to realize how much
better it was as a toolkit. They've got everything from dialog editors,
to an IDE, a debugger, build tools, just everything, and it's all
top-notch and highly maintained. The focus of the toolkit is
application development, and they spend their time trying to help
people do exactly that: make programs. Great support, great tools,
and because of that, great toolkit. I just didn't want to alienate any
developers by being stubborn about native widgets.
There *are* some things that are rather lackluster about it and design
choices I disagree with though. For example, I realize that to have an
easy to use toolkit you have to have some level of code generation.
However, in my personal and humble opinion, moc just feels like a
terrible way to approach the problem. Even now I feel like there are a
variety of ways you could handle code generation and automatic
management of things like that. I don't like the idea of circumventing
the language itself like that. It feels like one giant massive hack.
--------------------------------------------------
Things that aren't working properly:
--------------------------------------------------
- Settings dialog is not implemented. The dialog is complete but the
code to handle the dialog hasn't been constructed yet.
- There is a problem with using Qt widgets as a device target on
windows, with at least OpenGL: if I have the preview widget
automatically resize itself, it seems to cause some sort of video
card failure that I don't understand.
- Because of the above, resizing the preview widget has been disabled
until I can figure out what's going on, so it's currently only a
32x32 area.
- Direct3D doesn't seem to render correctly either, seems that the
viewport is messed up or something. I'm sort of confused about
what's going on with it.
- The new main window seems to be triggering more race conditions than
the wxWidgets main window dialog did. I'm not entirely sure what's
going on here, but this may just be existing race conditions within
libobs itself that I just never spotted before (even though I tend to
be very thorough with race conditions any time I use variables
cross-thread)
Palana
jp9000
shousa
kc5nra
Socapex