For install_external_plugin_bin_to_data and
install_external_plugin_bin_to_arch_data, they were using the
'plugin_target' variable instead of just 'target' for the plugin
directory output location, and they were using 'target' instead of
'additional_target' for the data/binaries they were supposed to be
installing.
Removing this union fixes the internal compile error that would occur on
visual studio 2015 update 2 and above when these variables were all in a
union.
The new cutoff timing fix means that streaming/recording has to remain
active for bit until the stream/recording has reached the expecting stop
timestamp. This means that the buttons would continue to say "Stop
streaming/recording" while waiting for the output to stop itself at the
appropriate timing.
So instead of letting it do that and confusing the user, the buttons
will now say "stopping" when the button is pressed to indicate to the
user that the stream/recording is in the process of stopping.
It wouldn't properly clear the reconnect information when the user
forcibly stops the stream while reconnecting, so when the user starts a
new stream after that it would erroneously display a lingering reconnect
message on the status bar.
This fixes an design flaw where a delayed output would schedule a
stop even while in the process of reconnecting instead of just shutting
down right away.
When obs_output_actual_stop is called on shutdown, it should wait for
the output to fully stop before doing anything, and then it should wait
for the data capture to end. The service should not be removed until
after the output has stopped, otherwise it could result in a possible
memory leak on stop. Packets should be freed last.
(Note: This commit also modifies obs-ffmpeg and obs-outputs)
API Changed:
obs_output_info::void (*stop)(void *data);
To:
obs_output_info::void (*stop)(void *data, uint64_t ts);
This fixes the long-time design flaw where obs_output_stop and the
output 'stop' callback would just shut down the output without
considering the timing of when obs_output_stop was used, discarding any
possible buffering and causing the output to get cut off at an
unexpected timing.
The 'stop' callback of obs_output_info now takes a timestamp with the
expectation that the output will use that timestamp to stop output data
in accordance to that timing. obs_output_stop now records the timestamp
at the time that the function is called and calls the 'stop' callback
with that timestamp. If needed, obs_output_force_stop will still stop
the output immediately without buffering.
Because output stop timing has been fixed, there is no need to send the
remaining packets in the queue because it now just waits for the stop
timing anyway.
Fixes a bug where if a D3D9 program recreates its device the capture
would become invalid. Certain games (especially blizzard games) will
completely recreate their Direct3D device if a critical D3D9 error
occurs.
Fixes an issue where the audio meter/fader would call an obs function
and lock another mutex, potentially causing a mutual inverted lock in
another thread.
Adds the ability to add video playlists via libvlc instead of via the
media source. This is mostly just being added as a secondary option to
the media source to reduce maintenance costs and save time. Currently
libff cannot pause/unpause/seek, and isn't programmed to handle
playlists yet.
If VLC is installed on the computer (with the same architecture) it will
allow video playback via libVLC. In the future, users should be able to
optionally download VLC libraries via the installer as well if they
don't want to necessarily install VLC to get the plugin working.
This plugin performs runtime linking instead of compile-time linking;
compiling VLC is not required, only its headers are required. To
compile, clone the VLC repository and set the VLCPath cmake variable to
point to the VLC repository directory.
When using GPU conversion for 4:2:0 frames on async video sources, it
would create a texture bigger than necessary and try to copy too much
data from the frame, resulting in a crash.
The internal data of a property value would be converted to QString and
Qt would inevitably try to convert the characters to another encoding,
causing the internal data to possibly become invalid. Instead, use
QByteArray to treat it as nothing more than a byte array.
The xcomposite window capture crashes were due to a few factors:
-------------------------------
1.) The source's X error handler was possibly being overwritten by
another part of the program despite us locking the display, presumably
something in Qt which isn't locking the display when pushing/popping its
own error handler (though this is not yet certain). The source's calls
to X functions happen in the graphics thread, which is separate from the
UI thread, and it was noticed that somehow the error handler would be
overwritten almost seemingly at random, indicating that something else
in the program outside of OBS code was not locking the display while
pushing/popping the error handler.
To replicate this, make it so that the source cannot find the target
window and so it continually searches for it each video_tick call, then
resize the main OBS window continually (which causes Qt to push/pop its
own error handlers). A crash will almost always occur due to BadWindow
despite our error handling.
2.) Calling X functions with a window ID that no longer exists,
particularly XGetWindowAttributes, in conjunction the unknown error
handler set in case #1 would cause the program to outright crash because
that error handler is programmed to crash on BadWindow for whatever
reason. The source would call X functions without even checking if
'win' was 0.
3.) The source stored window IDs (in JSON, even if they've long since
become invalid/pointless, such as system restarts). This is a bad
practice and will result in more cases of BadWindow.
Fixing the problem (reducing the possibility of getting BadWindow):
-------------------------------
Step 1.) Deprecate and ignore window IDs in stored settings. Instead of
using window IDs to find the window, we now must always search the
windows and find the target window via the window name exclusively.
This helps ensure that we actually consistently have a working window
ID.
Step 2.) Do not call any X functions if the window ID is 0.
Step 3.) Reset the window ID to 0 any time the window has updated, and
make the source find the window again to ensure it still exists before
attempting to use any X functions on the window ID again.
Add checks to make sure the pulseaudio operation objects are actually
valid and the request did not fail right away. Other pulseaudio
functions dealing with the objects expect them not to be NULL,
otherwise they will kill the application with a failing assert.
For some reason in the FFmpeg output, this AVCodecContext variable is
being set to 1 by FFmpeg itself somewhere, and it's causing a massive
slowdown when encoding with FFmpeg directly. This should be set to 0 to
specify to use as many threads as necessary.
jp9000
Kilian von Pflugk
Kazuki Oishi
nd
fryshorts
hwdro