Regular SDR/HDR stingers, and SDR track matte should work. HDR track
matte might work, but would take a carefully crafted video that takes
the SDR white level into account, and this hasn't been tested.
On Windows, All Files was added by default with (*), but on macOS and
Linux this appeared as an empty option in the dropdown and treated as a
Video Files filter rather than All Files.
This also adds proper translation handling for 'Video Files', matching
the obs-ffmpeg-source.
Fixes#5870
Although obs_source_add_active_child indicates to a child source that a
child source needs to activate, sources will not activate until the next
tick. However, because the transition start call is made from within the
UI thread, the time in which the media source renders is not guaranteed
to be activated by the time the stinger renders due to a potential race.
Thus he media source of a stinger is not guaranteed to be activated,
causing a brief flash. This also applies when stopping a stinger.
This problem normally doesn't really affect normal stingers; instead, it
affects track matte stingers because it is critical for them to be on
time in order to have the mask data.
In order to solve this, check to see if the underlying media source is
actually active and able to render when performing the masking.
Because it's not currently possible to guarantee synchronization between
two separate media files (yet), disable separated track matte media
files for now. It'll just result in support requests that can't be
solved.
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.
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.
This fixes an issue with Track Matte Stingers applied as visibility
transitions, where the side-by-side or stacked matte file mode would
result in the matte part of the video to "overflow" outside of the
transition's zone
