Fixes warning introduced by d7848f3cb7 that pops up in GCC:
warning: comparison of unsigned expression < 0 is always false
[-Wtype-limits]
The proper solution was to use the 64bit integer values with the clamp,
and then convert to a 32bit unsigned integer.
Fixes the following warning:
warning C4505: 'operator ==' : unreferenced local function has been
removed
This function actually is used despite this warning, so the only way to
get rid of the warning is to disable the warning itself in this
particular case.
Accessing objects inside obs_datas after obs_data_clear was called on the
parent obs_data causes a NULL dereference.
Reproduce with:
obs_data_t *data = obs_data_create();
obs_data_set_obj(data, "foo", NULL);
obs_data_clear(data);
obs_data_get_obj(data, "foo");
Not calling recv when data is received will accumulate data in the
internal recveive buffer until it's full, in which case is will stop
acknowledging. This can lead to unjustified disconnections.
SetThreadExecutionState with ES_DISPLAY_REQUIRED has the same effect of preventing the screensaver from activating. Using SPI_SETSCREENSAVEACTIVE leaves the screensaver disabled system-wide if OBS crashes before it can re-enable it.
If there was an attempt to destroy the rtmp-stream output while it was
already connecting and stopping at the same time, it would try to join
with the stop thread rather than with the connect thread. The connect
thread would then continue past destruction.
Sometimes stopping a connection can lock up due to data that still
remains to be sent, and this would lock up the thread requesting the
stop (typically the UI thread). So instead of locking up the calling
thread, spawn a new thread specifically for stopping so the calling
thread can continue uninterrupted. If the user attempts to reconnect,
it will wait for the stop thread to complete in the connect thread
before attempting to connect.
Currently creating new sources can cause a deadlock:
OBSBasicSourceSelect locks the scene mutex when adding a new source
(required to add invisible sources), and later OBSBasic tries to
lock the graphics mutex (via CreatePropertiesWindow); meanwhile the
graphics thread is holding the graphics mutex and tries to lock each
scene as it renders them, resulting in a (non-obvious from the code)
lock ordering conflict.
Moving the CreatePropertiesWindow call out of the locked scene mutex
restores the previous lock ordering; in addition, the requirement
for keeping sourceSceneRefs for opening that initial properties
window is removed
When an async video source is about to be rendered, the async texture
should be updated before any effect filtering occurs, rather than right
when it's about to render.
Fixes a few bugs:
- If the async texture hadn't drawn for its first time, and the source
has an effect filter, it would never end up rendering the first
frame due to the fact that it would fail on obs-source.c:2434 for the
first filter, causing it to never actually render the source, and thus
never get to a point in which it could call set_async_texture_size to
establish the async texture width/height for the first time.
- Any time the async texture size changed, it would only update the
async texture size at the end of the filter loop, which means that the
first frame after a size change would use the old size for the filters
rather than update to the new size right away.
Passing 0,0 texture size should be considered legal, and safely return
false to indicate that rendering can't begin. Also there's no need to
try to use the current swap chain's width/height if either of the sizes
are 0, there's no need try try to "force" success here anymore.
jp9000
Palana
Richard Stanway