When the #include directive in in the C lexer preprocessor is
encountered, the files being included need to be relative to the
directory of the file that the include was used in.
Originally this on by default, but then was changed to being off by
default because it was thought that there were permission issues, but it
turned out that the permission issues were a separate bug, so it's safe
to have this be default to on again.
This is a fast/immediate solution to a possible bug with caching the DLL
versions for game capture hook addresses - may as well just reload game
capture hook addresses each time the program is run for the time being
just to be safe. Load time will increase a little for the time being
but it's worth it to prevent any issues with game capture.
(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.
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.
jp9000
Gol-D-Ace
TotalCaesar659
Charles Ray Shisler III
Radzaquiel
partouf