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.
(Note: This commit also modifies the UI)
The editable list only had two types: A type that allows both files and
URLS, and a type that only allows strings.
This changes it so the editable list can have a "files only" type, a
"files and URLs" type, and a "strings only" type.
When a transition is a sub-source of another source, it would not call
the transition's active source enum function, meaning that any sources
the transition had would not increment their active/showing refs (it
would only be called when activating the transition directly before).
That would result in negative/invalid active/showing refs on its
sub-sources, causing them to become permanently active/inactive and/or
permanently showing/hidden.
Under certain circumstances it's necessary to seek, but if the frame
isn't loaded for the position that's being seeked to, it won't update
the texture. This just ensures the texture will update when seeking.
If custom transforms were used, the very first frame after starting
would always render with the previous transform before calculating the
new transform.
If a transition had a fixed size, it would not render itself or its
sub-sources according to that fixed size. The fixed size value was
essentially being ignored.
This fixes a bug where the sub-sources on a transition wouldn't render
with the expected size when the transition had a different size from its
sub-sources
This reverts commit 8d520b970d.
This can actually cause a hard lock due to the windows API when
destroying window capture. When the graphics thread locks the source
list for doing tick or render, and then the UI thread tries to destroy a
source, the UI thread will wait for the graphics thread to complete
rendering/ticking of sources. The video_tick of window capture would
then check windows in the same process and try to query the window's
name via GetWindowText. However, GetWindowText is synchronous, and will
not return until the window event has been processed by the UI thread,
so it will perpetually lock because the two threads are waiting for each
other to finish.
On windows, if you were saving a file name or directory with characters
that are not of the current windows character set, it could cause the
file saving process to fail. This fixes it so that on windows it uses
wmain and converts the unicode command line to a UTF-8 command line,
which works with FFmpeg.
