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.
The `OBS_ENCODER_CAP_DYN_BITRATE` flag indicates if an encoder is
capable of supporting dynamic bitrate changes without disturbing
the stream. In the case of multitrack video, dynamic bitrate changes
are also possible, however the encoder must be able to change bitrates
for multiple renditions and multiple codecs and maintain IDR alignment.
Add the `OBS_ENCODER_CAP_MULTITRACK_DYN_BITRATE` to specify this
capability for the encoder.
This aligns obs_canvas_get_video_info() and obs_get_video_info() and
ensures the frame-rate is correct rather than returning the
potentially stale data stored in the canvas itself.
These calls introduce pipeline stalls in OpenGL on low end machines
which can contribute to a fairly significant 10-30% of total rendering
time.
The driver already needs to synchronize events within the context so
these calls are not needed for correctness for OpenGL.
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.
When an Audio Output Capture source (AOC) like 'Desktop Audio' has
monitoring_type == OBS_MONITORING_TYPE_MONITOR_ONLY, deduplication
should not be triggered. this is an edge case which may not cover a
reasonable use case, but for the sake of completeness, we deal with it.
Signed-off-by: pkv <pkv@obsproject.com>
The sequence should be the same for every fd:
- Close the parent end of the pipe
- If the child end of the pipe is not the intended fd already,
- Dup it over
- And close the old fd
This fixes a double-close() in the read path (which is fairly harmless
since it happens in the child, but sticks out in strace), some fd
leakage, and the stderr-already-is-2 case.
The default device retrieved was the one used for system sounds.
This fixes it by retrieving the one used to output audio.
It seems the bug has been there since the initial writing of this bit of
code (so 2017).
The monitoring deduplication was previously checking at each audio tick
the whole audio tree for Audio Output Capture (AOC) devices used for
monitoring. The profiling did not show any big impact on the audio
callback. But due to reports of a significant slowdown for scenes with
numerous audio sources, we have moved the check on AOC from the audio
thread to the UI thread.
So we implemented obs_source_audio_output_capture_device_changed which
is triggered whenever:
- a monitoring device is changed in Settings > Audio,
- an Audio Output Capture source changes its device or on startup.
This function compares the AOC device with the monitoring device in UI
thread. If they are identical, a signal is sent to the audio thread to
add an audio task updating the AOC duplicating source pointer at the end
of an audio tick.
This triggers monitoring deduplication if the ptr is not NULL.
The calls in the AOC are implemented in next commits.
The rest of the logic in obs-audio.c is the same except on one count,
which is that we check against the muted state of the AOC rather than
its user_muted; with the new logic, muted works better.
Signed-off-by: pkv <pkv@obsproject.com>
This adds the devices_match function to null monitor to fix linking
issues on linux when pulse audio is disabled.
Fixes#12810
Signed-off-by: pkv <pkv@obsproject.com>
This adds comparison to default devices to the monitoring deduplication.
When a user picks a default device, the device_id setting is 'default',
which prevents any comparison.
The comparison is done by leveraging the libobs/audio-monitoring
devices_match function.
For macOS, some special care is taken because the devices list differ
for 'Desktop Audio' and 'monitoring' since coreaudio sdk has no pure
audio capture; so 'default' in the two lists do not match in general.
One then retrieves the device_id for the default desktop audio for macOS
through get_desktop_default_id function.
Signed-off-by: pkv <pkv@obsproject.com>
Richard StanwayandRyan Foster
LainandRyan Foster
Norihiro KamaeandRyan Foster
PenwywernandRyan Foster
FiniteSingularityandRyan Foster
derrodandRyan Foster
Warchamp7andRyan Foster
PatTheMavandRyan Foster
Alex LuccisanoandRyan Foster
Ruwen HahnandRyan Foster
Dennis SädtlerandRyan Foster
Sebastian BeckmannandRyan Foster
ansh1406andRyan Foster
cg2121andRyan Foster
Kurt KartaltepeandRyan Foster
ExeldroandRyan Foster
pkvandRyan Foster
Hoshino LinaandRyan Foster
Anton KesyandRyan Foster