It seems more intuitive if the recording paths for the Simple
Output, Advanced Default Output and Advanced FFmpeg Output are
linked together, so that the user does not have to manage three
paths if switching between the different options.
The UI elements are also connected so that a change to one
signals a change to the others with the corresponding config
setting.
When a source window was not available, a red background was shown
instead. This was undesirable, and expected behavior would be for the
background to be transparent, enabling what exists behind the source
to be shown.
These functions were mistakenly not marked as static. They are not used
outside of their compiled object module files, therefore there's no
reason for them not to be static.
The default buffering time for audio was always 1 second before the
audio subsystem was changed, and it was always more than sufficient for
max audio buffering time
Under certain circumstances, the timing_adjust variable would cause line
1161 to continually trigger over and over again. The "loop detection"
code incorrectly made it so that any timestamp that was just simply
below the expected value would be seen as a jump. After that, the
timing_adjust variable would be set for the frame again, and then the
audio would see it as a jump again after that, and those two things
would continue endlessly. This would cause stuttering particularly with
certain devices (particularly elgato/lgp/hdpvr) where the audio/video
data are decoded and sent at varying/different/unpredictable times.
To fix this issue, it should not detect values below as jumps, but
instead should only do it for values that exceed the MAX_TS_VAR (maximum
timestamp variance) value.
Originally there was an issue using FLAC for audio in AVI files, AVI
files wouldn't play back with some players. Because FLAC doesn't work,
and lossless should be lossless, instead just used uncompressed WAV
data for the lossless audio, which is always supported.
This reverts commit 6e20310945.
FLAC doesn't work properly in AVI files, and MKV files don't work in
vegas. So, sadly the only solution is to use lossless audio at a super
high bitrate for the time being.
Apple wants to get people to move over to their own crypto APIs instead
of using OpenSSL, so disable the warning in the files where OpenSSL is
used for the time being.
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.
If the media source is set to restart on activation, it also shuts down
when not active. However, it would *always* start regardless of
active/inactive when the source is first created. It shouldn't do that,
it should start up only when it becomes active.
If scene duplication mode is disabled and studio mode is turned on, it
would always initially duplicate scene regardless of whether scene
duplication mode was activated or not.
If obs_source::audio_ts is set to 0 (such as by discard_if_stopped in
obs-audio.c), but the push_back variable in the source_output_audio_data
function in obs-source.c was being set to true (meaning it's within the
seamless audio smoothing threshold), it would cause it to never reset
the obs_source::audio_ts value, and thus all audio data from the source
would become perpetually ignored by the audio subsystem until there was
finally some sort of timestamp jump that caused it to call
source_output_audio_place, and thus reset obs_source::audio_ts.
obs_source::audio_ts is only reset in source_output_audio_place, not in
source_output_audio_push_back, so the most simple solution is to just
call source_output_audio_push_back is obs_source::audio_ts is 0.
This code causes audio data in general to be reset (and subsequently
deleted). It should just be marked as pending and ignored until the
data is ready. The discard_if_stopped function will serve the same
purpose if the source's audio has actually stopped.
There's technically no need to clear the audio data here, nor is there
any need to try to trick the timestamp in to a different position. It
can simple just reset the audio timing.
Prevents a possible case where audio data might be deleted when it's not
necessary to delete any.
Fixes a bug introduced in 6407707a04 where if you open the settings
window the settings would always think there were new changes. It was
marking a control as changed when it shouldn't be
This variable is used to detect whether audio has stopped -- if audio
stops, it detects that no new data is coming in, and resets the audio
position so that it eliminates the chance of causing the audio buffering
to go haywire if audio starts up again. However, this variable was not
being reset every time the value changes, which it should.
Sometimes the A and B sources of a transition would a large difference
in their timestamps, and the calculation of where to start the audio
data for one of the sources could be above the tick size, which could
cause a crash.
If the circular audio buffer of the source has data remaining that's
less than the audio frame tick count (1024 frames), it would just leave
that audio data on the source without discarding it. However, this
could cause audio buffering to increase unnecessarily under certain
circumstances (when the next audio timestamp is within the timestamp
jump window), so it would append data to that circular buffer despite
the audio stopping that long ago, causing audio buffering to have to
increase to compensate.
Instead, just discard pending audio if it hasn't been written to. In
other words, if the audio has stopped and there's insufficient audio
left to continue processing.
jp9000
Gol-D-Ace
Charles Ray Shisler III
Radzaquiel
partouf
yogpstop
dodgepong