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.)
Fixes a bug where script properties would not update correctly after the
Undo/Redo changes in the properties view. The properties view was using
the wrong callback, and had a bad cast.
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.
(Additional note by Jim: Apparently, dacast doesn't use "stream key" for
whatever reason on its website, so this commit apparently changes the
text "Stream Key" to "Encoder Key" or whatever for whatever reason I'll
never know. I guess we need arbitrary names for things these days
because services can't get their names in order or something. Whatever.
I'm seriously tired of dealing with this sort of stuff. Seriously, this
is just dumb. This is dumb, and I wish I wasn't merging it, but at this
point, I'm like, whatever. I don't care. I've stopped caring. Why should
I care anymore? I'm losing it. I am absolutely losing it.)
If the fade to black was active and the user switched scene collections,
or exited studio mode, the source wouldn't be cleared, causing the
transition not to work properly when used again.
These files have been superseded by files in CI/scripts/macos. They are
no longer used, and keeping them around creates confusion and makes
people think they are still used. Let's remove them to prevent further
confusion.
This commit also removes the CMake function `obs_finish_bundle` that was
only used with the osxbundle resources and removes calls to that
function.
This reverts commit c370692773.
The PR that introduced this commit was opened before the browser plugin
was enabled, and when the browser was effectively enabled, this change
was already in place and didn't conflict, leaving us with both a
-DBUILD_BROWSER=ON *and* -DBUILD_BROWSER=OFF in place.
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.
Settings would not update properly because obs_source_update() can only
apply the settings value to the existing settings, so it could not
remove values. This change fully erases existing settings and replaces
it with the target settings instead.
jpark37
jp9000
Developer
Clayton Groeneveld
Ryan Foster
Georges Basile Stavracas Neto
iamflorencejay
geekenmd
Exeldro
Sebastian Beckmann
Matt Gajownik
Kurt Kartaltepe