Allows the user to specify custom formatting for their recording file
names with many formatting options, viewed via tooltip. The options
have been added to the advanced settings section.
Closesjp9000/obs-studio#507
(Note: This commit also changes the UI)
Changed:
-------------------
void obs_load_sources(obs_data_array_t *sources_list);
To:
-------------------
void obs_load_sources(obs_data_array_t *sources_list,
obs_source_load_cb callback, void *private_data);
Signals should really never be required to use to make some function
work properly. The "source_load" signal was required for the
obs_load_sources function, but it's meant more for loading private data
in the settings, not for general loading of sources.
This changes it so that a callback is explicitly required to load the
sources.
A lot of people had the problem where they'd initialize video settings
with 0 width or height on their output resolution value. This just
changes it so that the user always has a valid resolution so video
initialization doesn't just outright fail.
Implements transitions, and introduces "Studio Mode" which allows live
editing of the same or different scenes while preserving what's
currently being displayed.
Studio Mode offers a number of new features:
- The ability to edit different scenes or the same scene without
modifying what's currently being displayed (of course)
- The ability to set up "quick transitions" with a desired transition
and duration that can be assigned hotkeys
- The option to create full copies of all sources in the program scene
to allow editing of source properties of the same scene live without
modifying the output, or (by default) just use references. (Note
however that certain sources cannot be duplicated, such as capture
sources, media sources, and device sources)
- Swap Mode (enabled by default) which swaps the program scene with
the preview scene when a transition completes
Currently, only non-configurable transitions (transitions without
properties) are listed, and the only transitions available as of this
writing are fade and cut. In future versions more transitions will be
added, such as swipe, stingers, and many other various sort of
transitions, and the UI will support being able to add/configure/remove
those sort of configurable transitions.
(Note: This commit also modifies the UI)
Allows the ability to duplicate sources fully copied, and/or have the
scene and its duplicates be private sources
(Note: test and UI are also modified by this commit)
API Changed (removed "enum obs_source_type type" parameter):
-------------------------
obs_source_get_display_name
obs_source_create
obs_get_source_output_flags
obs_get_source_defaults
obs_get_source_properties
Removes the "type" parameter from these functions. The "type" parameter
really doesn't serve much of a purpose being a parameter in any of these
cases, the type is just to indicate what it's used for.
When right-clicking items in the preview window and getting context
menus for them, it would often make the wrong scene item be associated
with the context menu because of the fact that it was using
QListWidget::currentItem instead of querying the actual selected list.
You must query the actual selection list via QListWidget::selectedItems
because QListWidget::currentItem does not work properly for
multi-selection list widgets.
Some streamers would accidentally hit start/stop streaming, which on
certain services would send out mass emails to all their followers.
This just adds options to general settings to optionally enable dialogs
that confirm whether to actually start/stop streaming when the button is
clicked.
Prunes code used to workaround libobs "user sources" (such as
sourceSceneRefs) and instead simply holds its own references and saves
sources it chooses with obs_save_sources_filtered.
(Note: This commit breaks UI compilation. Skip if bisecting)
Ensures that a reference is kept until the signals associated with that
reference are disconnected.
Having sleep or screensavers inhibited at all times was causing some
annoyances for people. Sleep/screensavers are now only inhibited when
the program is active or when a projector is open.
Currently creating new sources can cause a deadlock:
OBSBasicSourceSelect locks the scene mutex when adding a new source
(required to add invisible sources), and later OBSBasic tries to
lock the graphics mutex (via CreatePropertiesWindow); meanwhile the
graphics thread is holding the graphics mutex and tries to lock each
scene as it renders them, resulting in a (non-obvious from the code)
lock ordering conflict.
Moving the CreatePropertiesWindow call out of the locked scene mutex
restores the previous lock ordering; in addition, the requirement
for keeping sourceSceneRefs for opening that initial properties
window is removed
API removed:
--------------------
gs_effect_t *obs_get_default_effect(void);
gs_effect_t *obs_get_default_rect_effect(void);
gs_effect_t *obs_get_opaque_effect(void);
gs_effect_t *obs_get_solid_effect(void);
gs_effect_t *obs_get_bicubic_effect(void);
gs_effect_t *obs_get_lanczos_effect(void);
gs_effect_t *obs_get_bilinear_lowres_effect(void);
API added:
--------------------
gs_effect_t *obs_get_base_effect(enum obs_base_effect effect);
Summary:
--------------------
Combines multiple near-identical functions into a single function with
an enum parameter.
RemoveScene would always remove the currently selected item from the
scenes list, even if that item didn't reference the actual scene being
removed; finding the proper item via its OBSRef fixes this issue.
How to reproduce the original issue:
Create two scenes "a" and "b", set a hotkey for switching to scene "a",
select scene "b" and press the remove scene button, then while the
confirmation dialog is up press the hotkey while the UI is out of focus.
The active scene should have switched to "a", while the dialog still
displays "b" as its target; now confirm the removal of "b". Note how "a"
was removed from the scenes list instead.
Reported at https://obsproject.com/mantis/view.php?id=333
This reverts commit 35b2ce565a.
There is far too much potential for issues to occur if the first-time
start creates a display capture by default on linux and windows.
Display capture on windows laptops will not be guaranteed to capture
properly, leaving the user with a blank screen. Display capture on
linux downloads its image off the graphics processor, so it's quite
inefficient to have on by default.
So certain high-profile individuals were complaining that it was
difficult to configure recording settings for quality in OBS. So, I
decided to add a very easy-to-use auto-configuration for high quality
encoding -- including lossless encoding. This feature will
automatically configure ideal recording settings based upon a specified
quality level.
Recording quality presets added to simple output:
- Same as stream: Copies the encoded streaming data with no extra usage
hit.
- High quality: uses a higher CRF value (starting at 23) if using x264.
- Indistinguishable quality: uses a low CRF value (starting at 16) if
using x264.
- Lossless will spawn an FFmpeg output that uses huffyuv encoding. If a
user tries to select lossless, they will be warned both via a dialog
prompt and a warning message in the settings window to ensure they
understand that it requires tremendous amounts of free space. It will
always use the AVI file format.
Extra Notes:
- When High/Indistinguishable quality is set, it will allow you to
select the recording encoder. Currently, it just allows you to select
x264 (at either veryfast or ultrafast). Later on, it'll be useful to
be able to set up pre-configured presets for hardware encoders once
more are implemented and tested.
- I decided to allow the use of x264 at both veryfast or ultrafast
presets. The reasoning is two-fold:
1.) ultrafast is perfectly viable even for near indistinguishable
quality as long as it has the appropriate CRF value. It's nice if you
want to record but would like to or need to reduce the impact of
encoding on the CPU. It will automatically compensate for the preset at
the cost of larger file size.
2.) It was suggested to just always use ultrafast, but ultrafast
requires 2-4x as much disk space for the same CRF (most likely due to
x264 compensating for the preset). Providing veryfast is important if
you really want to reduce file size and/or reduce blocking at lower
quality levels.
- When a recording preset is used, a secondary audio encoder is also
spawned at 192 bitrate to ensure high quality audio. I chose 192
because that's the limit of the media foundation aac encoder on
windows, which I want to make sure is used if available due to its
high performance.
- The CRF calculation is based upon resolution, quality, and whether
it's set to ultrafast. First, quality sets the base CRF, 23 for
"good" quality, 16 for "very high" quality. If set to ultrafast,
it'll subtract 2 points from the CRF value to help compensate. Lower
resolutions will also lower the CRF value to help improve higher
details with a smaller pixel ratio.
The user may not want their audio or their display to be captured when
creating a new scene collection. Make new scene collections default to
fully empty.
For the sake of consistency, always create a display capture source on
the very first run of the program, just to have something displayed.
(NOTE: The only exception here is on windows 7/vista, which isn't ideal
for display capture, so it'll continue to be left blank)
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.
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.
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 reverts commit a508c17f0a.
I realized that this would become more of an annoyance for most people
rather than anything helpful. This has only happened only twice that I
am aware of in all the years that the program has been around.
jp9000
bl
Palana