obs_module_unload was never properly documented, so some plugins use it
to free resources, some use it to save data, etc. While libobs tries to
ensure all objects are shut down and destroyed before calling unload, if
another plugin is holding a strong reference, or if a reference leak has
occurred, libobs may need to call back into a plugin-provided object's
destroy function even after obs_module_unload has returned. If the
plugin has freed memory or other resources needed for the callback then
this likely results in a crash.
Going forward, we should document that obs_module_unload is now intended
only for saving data and releasing references, and that calling libobs
after it returns is not allowed. For cases where resource cleanup is
actually needed (for example, an external out of process helper needs to
be shut down or a release call to a hardware driver), a new
obs_module_destroy callback is intended to be added in a future version.
With v1 of this function, it's unclear where exactly the data pointer
comes from or what it is. In fact, this is not determined by libobs, but
the consumer. libobs assumes that the caller of
obs_property_button_clicked passes an obs_context_data pointer, and then
passes the data pointer of that obs_context_data as the data pointer to
the callback.
In OBS Studio, this is always the private data of the associated object.
However, this assumes that there even is such an object (source/encoder/
etc), even though properties are meant to be free-standing. This is not
just philosophical, because with obs_get_source_properties you can
actually get an obs_properties_t that isn't associated with any specific
source, at which point you have no idea what the data pointer will be.
For this reason, obs_properties_add_button v1 needs to go.
obs_properties_add_button2 can be used as a drop-in replacement.
With v2, it's well-defined that the pointer you're passing as priv is
the pointer you get back in the callback as data. If you don't care
about it, simply pass NULL/nullptr.
Once v1 is removed in the future, obs_property_button_clicked should be
replaced with a variant that doesn't take a second argument, as that
argument will no longer be used anywhere.
The important point here is that "data" from the callback isn't defined
by libobs, but rather by the API consumer.
Additionally, it's not entirely clear from the documentation whether the
callback would still be called for button of type OBS_BUTTON_URL. There
should be no negatives to always calling it and the OBS Studio frontend
already behaves that way, so let's document that in libobs.
obs_get_transition_by_name is very problematic because transitions are
always private and their names aren't unique. This means that the method
iterates over all private sources and then takes the first that both is
a transition and matches the name we're looking for. However, this could
be from anywhere - it could be a frontend transition, but also a source
transition, quick transition, or even one from third-party plugins. This
is always never what is intended.
As such, this method (which should never have been added in the first
place) needs to go. In its place, obs_frontend_get_transitions returns a
list of all frontend transitions (which is usually what people are
looking for), and alternatively obs_get_source_by_uuid also provides
access to private sources.
While we're at it, obs_get_transition_by_uuid is basically a wrapper for
obs_get_source_by_uuid and not really necessary. UUID's are unique and
a source doesn't suddenly change its type, so if you have a transition's
UUID you can be pretty sure that when you do obs_get_source_by_uuid, it
will still be a transition.
This change adds a new type named gs_sync_t and related functions to X11
and Wayland EGL backends to abstract DRM syncobjs and their various
uses.
Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
Revert "docs: Add new relative positioning scene functions"
This partially reverts commit 366cfdb963.
The addition of obs_sceneitem_(get/set)_info2 was not removed as that is
still valid.
obs_scene_sceneitem_from_source is problematic because there can be
multiple items of the same source in a scene, which the function doesn't
account for. In such a case, it would return the first item it finds,
which often might not be what a developer expects.
It was originally added for the undo/redo-operation of "Add New Source"
where the UI guarantees that the item is unique, but for a general case
it's not suitable.
Packet callbacks are invoked in `send_interleaved()` and
are useful for any plugin to extend functionality at the
packet processing level without needing to modify code in
libobs. Closed caption support is one candidate that is
suitable for migration to a packet callback.
The packet callback also supports the new encoder packet
timing feature. This means a registered callback will have
access to both the compressed encoder packet and the associated
encoder packet timing information.
Deprecated in 28.0, documentation erroneously states 27.2.
The following functions were erroneously not marked as deprecated in
the header:
- obs_sceneitem_set_show_transition()
- obs_sceneitem_set_show_transition_duration()
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.
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.
Warchamp7