When a source file contains an explicit include with a filename
following the "moc_<actual-filename>.cpp" pattern, then CMake's
AUTOMOC generation tool will recognize the matching pair and generate
the replacement header file and add the required include directory
entries.
For all files which do contain Q_OBJECT or similar declarations but do
not have an explicit include directive, the global mocs_compilation.cpp
file will still be generated (which groups all "missing" generated
headers).
The larger this global file is, the more expensive incremental
compilation will be as this file (and all its contained generated
headers) will be re-generated regardless of whether actual changes
occurred.
The ComPtr, WinHandle, and obfuscate source files are shared with
multiple sub-projects and thus need to be moved into the shared
directory to uncouple their availability from libobs itself.
The same applies to d3d8-api, inject-library, and hook-config
(from win-capture), as well as comutils (from the virtualcam-module).
List widgets are currently used as playlists in source properties,
but only contain the file paths and no other identifying information.
This can lead to files being added multiple times, so when changes to
list order occurs, plugins cannot uniquely identify which duplicate
item was actually changed (because they're only identified by the path).
By adding a UUID to the user data role of a list item, an additional
unique information is added that allows plugins to de-duplicate list
items.
On Windows, shutdown() will not interrupt a blocking connect() call, so
happy_eyeballs_destroy could block until the remaining candidates timed
out. As happy_eyeballs_destroy is called in the RTMP connect path, this
would stall the RTMP connection and cause the winning candidate's socket
to be disconnected due to a timeout.
The code currently assumes that the array does not change during
execution, this assumption is violated when the darray resizes causing
previous pointers to point to invalid memory and cause undefined
behavior and crashes.
This may need refactoring in the future, this commit simply fixes the
issue for now.
By not performing an unref on sw_frame before using it again, a memory
"leak" was being created if the frame had side data. This removes a
previously-added check that optionally unrefs sw_frame, and just does
it every tick.
Co-authored-by: pkviet <pkv@obsproject.com>
