Fixes a memory leak with stinger texrender objects. These functions must
be called while the graphics context is locked. Caught via warnings
generated by the destroy functions.
The actual crash is caused because obs_module_unload() is called before
the decklink outputs are stopped. In obs_module_unload(), the deviceEnum
pointer is freed. During decklink_output_stop(), the removed code tries
to retrieve a reference of the decklink device from the deviceEnum and
crashes because it has already been freed. This code appears to serve no
purpose anyway, so we remove it.
This ensures correct texture filtering, simplifies the render callback,
and allows us to remove the custom draw flag, restoring the direct
rendering optimization for filters against image sources.
When using a stacked track matte stinger transition with a visibility
transition, the matte portion of video would also be visible on the
right side or below the source. This fixes it by first rendering the
video to a texrender object in order to filter out the unwanted portion.
(Jim note: So basically, track matte stingers now use two texrenders. I
really don't like this. Texrender objects can already cause stalling as
it is.)
When using track matte stingers as visibility transitions, it would
render the matte portion at the incorrect size. This was due to the fact
that texrender render code blocks do not set the projection matrix.
You're supposed to do that manually. Thus, it was using whatever the
current projection matrix was, which was usually the canvas projection
matrix.
(Jim note: There were reasons why I didn't make texrender objects do
this automatically, mostly scaling and performance reasons, but I
realize now I should have at least provided an option for it instead to
prevent this "gotcha" situation from happening. Bad design on my part. I
do not blame Palakis for falling for this.)
This would cause a null pointer check log message because matte_source
only exists when using an explicit separate video for track matte
stingers. Instead, explicitly set matte_ph to null if matt_source is
null to avoid the null pointer check logging.
This causes the track matte render target to only be reset once per
frame, rather than potentially multiple times per frame. Palakis most
likely did not know that you're supposed to reset only once per frame in
order to prevent the render target from being rendered more than once
per frame.
(Jim note: I probably should have made texrender objects automatically
detect new frames internally so it wouldn't require this. Not Palakis'
fault.)
Color mismatch is apparent when using source transitions, which lerps
against transparent black and blends into the canvas nonlinearly. When
the transition is done, the blend switches to linear, leading to a pop.
Fix the issue by blending into the canvas in linear space. The lerp is
still nonlinear by design.
A user has reported that toggling the cursor can cause exceptions.
Propagate that information upward, so we can reset the capture.
Display capture never needed to call the function in the first place.
Shuffle around window capture code to make a common reset function.
Builds on PR #4663.
Add support for applying alpha in linear space to match Photoshop
behavior in linear mode, and for just overall correctness. The default
setting is still nonlinear to match common user expectation though.
Add OBS_SOURCE_SRGB to indicate sources that support SRGB rendering. We
can use this flag to know which sources do not know how to handle SRGB,
and disable accordingly inside obs_source_main_render().
We can also use this flag to clean up the filter interface and remove
the SRGB-specific functions. We also need to disable direct rendering if
the filter source wants to render SRGB, but the parent source does not
support it.
Scenes and groups are marked as having SRGB support, and those are
internal sources that we control.
For v2 filters, switch Opacity settings from integer [0, 100] to
floating-point [0.0, 1.0] with four decimal places for granular blacks.
Also multiply alpha in shader to maintain precision.
The feature name is "Noise Removal" with that exact capitalization.
"NVIDIA Noise Removal" or "Noise Removal, powered by NVIDIA Broadcast"
are the two valid options for displaying this feature name in the UI.
Initializing NVAFX is slow as it has to load large models and can cause
significant impact to OBS' startup time. This moves NVAFX initialization
into a separate thread. NVAFX does not appear to be reentrant across
threads, hence a global mutex is also used to avoid reentrancy issues.
The downside of this change is that the first few seconds of audio after
adding the filter or starting OBS will not be filtered, but this is
unlikely to cause any real-world issues.
