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 feature allows a user to delay an output (as long as the output
itself supports it). Needless to say this intended for live streams,
where users may want to delay their streams to prevent stream sniping,
cheating, and other such things.
The design this time was a bit more elaborate, but still simple in
design: the user can now schedule stops/starts without having to wait
for the stream itself to stop before being able to take any action.
Optionally, they can also forcibly stop stream (and delay) in case
something happens which they might not want to be streamed.
Additionally, a new option was added to preserve stream cutoff point on
disconnections/reconnections, so that if you get disconnected while
streaming, when it reconnects, it will reconnect right at the point
where it left off. This will probably be quite useful for a number of
applications in addition to regular delay, such as setting the delay to
1 second and then using this feature to minimize, for example, a
critical stream such as a tournament stream from getting any of its
stream data cut off. However, using this feature will of course cause
the stream data to buffer and increase delay (and memory usage) while
it's in the process of reconnecting.
This reverts commit a508c17f0a7048a5592d91c0a6587bfb59c28e84.
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.
For both cases the cur_level calculations were "wrong". For one channel
case, I assume that was only an oversight, as for two channels case
cur_level "calculation", getting the level from downmixing to mono will
result in an attenuated level than expected. One solution is to use the
highest level of both channels to drive the gate.
This was broken in cd222f8ce03a65815ef6474cce89f069c1d49f8c which had a
horrible commit message that makes replicating the issue impossible if
there weren't others who reported similar visual studio issues when
using a Japanese locale
Limits similar log entries (determined by a simple hash function that
sums the characters) to certain number of lines in a row. When a
different log entry occurs, it resets the repeat check and logs how many
times the last message was repeated.
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)
..This is rather embarrassing. I used the parameter variable and the
actual variable that I wanted to used went completely unused. Would
static analysis catch something like this, I wonder? Would probably
have to be really good static analysis.
This improves logging for when audio data insertion is way out of bounds
or is getting cut off in the front due to a bad negative sync offset.
Instead of throwing out a log message for every time this happens with
each piece of data, it now states when the out of bounds or cutoff has
started and stopped only.
This fixes a case where an insertion of audio data would pass
valid_timestamp_range yet the insert position would cause a negative
integer position and thus an unsigned integer overflow.
YouTube Gaming is live since today (26 August 2015) and people will ask
for it.
This makes it a bit clearer that YouTube and YouTube Gaming
(which share the same ingestion system) work with OBS MP.
Replaces all the json/config loading/saving functions with safe
variants to reduce the chance of potential file corruption as much as
possible.
Also does a minor refactor of json writing by using
obs_data_save_json_safe for writing json files instead of manually using
obs_data_get_json and os_quick_write_utf8 each time.
obs_data_create_from_json_file_safe: Attempts to create an obs_data
object from a file, and if that fails and a backup file exists, deletes
the old file and tries to open it again.
obs_data_save_json_safe: Saves json data to a temporary file first,
optionally backs up the target file if the file exists and backup_ext is
valid (otherwise deletes it), and then renames the temporary file to the
target file. This helps reduce the chance of json corruption on save.
This helper function saves to a temporary file first, (optionally) backs
up the original file, then renames the temporary file to the actual file
name. This helps reduce the chance of file corruption under various
circumstances (such as shutdown or crash while the file is being written
to disk).
This will use the services.json file present in the cache, or if it has
the wrong format version or is corrupted for whatever reason, uses the
local version instead.
Also a minor refactor, makes it so that you call the open_services_file
function to get the services array, rather than having to get the file
name each time.
This allows plugins to update and cache data files from a remote source.
Here are the steps that occur when the API initiates an update check:
1.) It checks to see if the local files are greater than the cached
files. If the local version is newer (for whatever reason), it
replaces the cached version(s) with the local version.
2.) A packages.json file is downloaded from the specified URL. That
packages.json file contains a version number and a list of files to
be updated.
3.) If the downloaded package version is greater than the cached
version, executes step 4-5 on each file.
4.) Checks the version for the file to update in packages.json, and if
the version is greater than the cached version, proceeds to step 5,
otherwise repeat step 4-5 for other files.
5.) Calls the callback given to the update function (if any) with the
file information (file name, buffer, etc), and if the callback
returns true, allows the cached file to be updated and replaced,
otherwise goes back to step 4-6 for the rest of the files.
NOTE: Files are never modified directly. All file saving/modification
is performed in a temporary directory, and then files are moved to their
destination. This should eliminate any possibility of file corruption
(or at least dramatically reduce the possibility).
API Changed:
---------------------------
From:
- bool obs_startup(const char *locale, profiler_name_store_t *store);
To:
- bool obs_startup(const char *locale, const char *module_config_path,
profiler_name_store_t *store);
Summary:
---------------------------
This allows plugin modules to store plugin-specific configuration data
(rather than only allowing objects to store configuration data). This
will be useful for things like caching data, for example looking up and
storing ingests from remote (rather than storing locally), or caching
font data (so it doesn't have to build a font cache each time), among
other things.
Also adds a module-specific directory for the UI
If a user was using FFmpeg output before pathc 0.12.0, they had to type
in the full file name to the FFmpeg output URL/Path box, which isn't
exactly compatible with the new settings.
This changes each profile's config file so that the FFmpeg output
detects whether files are used, and then extracts the file's directory
and extension and sets them accordingly to make it compatible with the
new FFmpeg file output handling.
