A recent obs-deps change removed all non-essential x86 deps. This caused
the x86 subproject(s) on Windows to fail to configure due to being
unable to find x86 dependencies that do not exist.
Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
Adds a new encoder cap which tells libobs that rather than scaling
video frames in software, the encoder is capable of scaling them via
its own (presumably more efficient) means.
An encoder may implement this cap by comparing the VOI of its assigned
`video_t` and the results of `obs_encoder_get_width/height()`. If the
width/height values differ, then the encoder is being asked by libobs
to self-scale, and the resolution in VOI will be the raw frame size,
with the `...get_width/height()` being the intended output resolution
of the encoder.
It is important to note that GPU rescaling mode will take priority
over self-scaling. If GPU rescaling is enabled, the encoder will never
be asked to self-scale.
This is useful for discrete hardware encoders, where they might have
fixed-function video scaling logic that is highly efficient and fast.
Additionally, this feature allows a hardware device which is encoding
a full ABR ladder of tracks to be smart and only copy a video frame
from GPU -> Host -> Device once for the entire ladder, rather than
once for every track.
This logic would previously have written any changed scale resolution
set by the encoder in the `.get_video_info` callback back to the
encoder, however this functionality was "broken" by
20d8779d30. In reality, this would have
never worked with texture encoders or with GPU rescaling enabled, and
probably would have had odd side effects for CPU rescaling, too. It's
best just to remove this functionality.
I forgot to update this before tagging 30.2.1, so the updater won't stop
telling people there's an update available, even after updating.
Update this for real now to 30.2.2.
Fixes a crash when the following steps occur:
- Encoder group created and then started with encoders, only the group
owning encoder refs
- Encoder group destroy called: group has `destroy_on_stop` set
without actual destroy
- Outputs holding encoders from stopping are stopped
- `remove_connection()` function destroys encoder group, releasing
encoders and causing the currently processed encoder to be destroyed
early
- parent scopes try to access destroyed encoder pointer and crash
This change moves some logic around to improve the release/destruct
order of `obs_encoder_stop()` to fix the race above.
Note: Cases of encoder errors will not destruct the group if it has
`destroy_on_stop` set, as the encoder is also not destroyed if it also
is set to destroy on stop. This part of the code should be revisited
at a later date and fixed up to prevent memory leaks.
Modifies the encoder group API added previously to better follow the
existing libobs API naming paradigms. This also produces much more
readable code, and allows a few small benefits like only needing to
hold a reference to the encoder group, instead of every encoder.
Adds global signals for when a filter is added to or removed from a
source. These will be helpful for listening for changes to a sources
filters without having to attach and detach a signal handler, which
would be annoying in the context of for example context menus which
change sources rapidly.
derrodandRyan Foster
tytan652andRyan Foster
tt2468andRyan Foster
qhy040404andLain
jcmandMatt Gajownik
Norihiro KamaeandRyan Foster
Florian ZwochandLain
ExeldroandRyan Foster
Kurt Kartaltepeandtt2468
gxalphaandRyan Foster
jcmandRodney
Warchamp7
