The remuxer thread was only started if there was an actual remux job,
which resulted in the remuxer thread not being able to call the worker's
destructor (because it wasn't running)
OBS Sparkle feeds have two extensions to vanilla Sparkle feeds:
- There can be two kinds of items per feed: (zipped) .app and .mpkg
via <ce:packageType>app|mpkg</ce:packageType> (default is mpkg)
- Feed items can be disabled via <ce:deployed>false</ce:deployed>; these
items will not be considered for updates unless
"[General] UpdateToUndeployed=1" is set the global config
Unlike other Sparkle implementations the FeedURL cannot be updated via user
preferences because we support multiple app packages with the same package
identifier but different FeedURL settings on the same machine
Due to a small error in the timestamp smoothing code the timestamp of
audio packages that were too early was always set to the next expected
timestamp, even if the difference was bigger than the smoothing threshold.
This would cause obs to simply append all audio data to the buffer even if
the real timestamp was way smaller than the next that was expected.
This should reduce corruption problems with for example the pulseaudio
plugin, which resends data under certain conditions.
If the sample format used by PulseAudio can not be converted into an
OBS audio format it will be handled as AUDIO_FORMAT_UNKNOWN which will
not result in a proper audio recording. So instead we request a format
that OBS supports from PulseAudio and let it do the format conversion.
The format PA_SAMPLE_S24_32LE is a 24 bit audio format in 32 bit integers
and not a 32 bit audio format and so it should no be mapped to
AUDIO_FORMAT_32BIT.
Before it was giving timestamps based upon system time for each new
segment of audio data. Also, it was subtracting pulse latency from the
audio timestamp, which seems like it was really meant for use with the
pulse audio time rather than system time.
Now, it just uses system time for timestamps. Still might not be
totally perfect, but seems to be much better than it was.
This also removes the latency calculation. Latency is no longer used
because we're not using pulseaudio timing.
As stated in the sysinfo manpage the totalram field in the sysinfo
structure is in mem_unit sizes since Linux 2.3.23. To get the actual
memory in the system the totalram value has to be multiplied with the
mem_unit size.
Allows adding Syphon servers as sources, and provides game-capture if
used with SyphonInject (specifically the scripting additions have to be
installed for SyphonInject to work from within OBS)
I do not want the D3D11 library to depend on a specific compiler
version. This way, I do not have to distribute D3D Compiler libraries
with the program (proprietary binary blobs). Any particular version
works because the API for the D3DCompiler function appears to be the
same; the only things that change are other features and additions
mostly (at least as far as I can tell). Using any version available on
the system should be more than sufficient rather than depending on some
specific D3D compiler version.
If the user doesn't have it, a download of the latest D3D distributables
should be fine, though it should work with the ones that come with
windows 7+ as well.
obs_source_update_properties should be called by sources when property
values change, e.g. a capture device source would use this when it
detects a new capture device (in case its properties contain a list of
available capture devices or similar)
This allows for easier comparison between two obs_data_t and it will make
const char *json1 = obs_data_get_json(data);
obs_data_t *data_ = obs_data_create_from_json(json1);
const char *json2 = obs_data_get_json(data_);
produce the same string in json1 and json2
This Fixes a minor flaw with the API where data had to always be mutable
to be usable by the API.
Functions that do not modify the fundamental underlying data of a
structure should be marked as constant, both for safety and to signify
that the parameter is input only and will not be modified by the
function using it.