The proposed way to handle plugin distribution
through Flatpak depends on these directories to
be read. It goes as follows:
1. Flatpak's extension point merges the 'lib'
and 'share' directories at /app/plugin
2. Plugins prefix their install paths in the
Flatpak manifest to /app/plugins/<plugin name>
3. OBS Studio lists /app/plugin as one of the
search paths in OBS Studio code
This commit implements the third step of this
process, which is the only one that actually
involves OBS Studio itself.
With that, it is possible to distribute plugins
as Flatpak extensions, which in turn allows them
to be listed at app stores such as GNOME Software,
elementary's app store, and KDE's Discover.
Related: https://github.com/flathub/com.obsproject.Studio/issues/135
The gs_draw_sprite_subregion() function is used when a cropping
rectangle is received from PipeWire. It is usually used by
compositors to implement window screencast - where a large and
mostly empty frame is sent, the window contents are only a small
part of it, and the crop rectangle tells us that.
Recently the wlroots implementation of portals started to use it
to implement cropping, and it exposed a bug in the PipeWire code
in OBS Studio. The gs_draw_sprite_subregion() function takes a pair
of integers representing position (x, y) and a pair of integers
representing size (width, height). The PipeWire code, however,
passes a second pair of positions (x2, y2) instead of sizes, and
it causes overrendering the crop area.
This bug wasn't hit yet because both GNOME and KDE implementations
always send (0, 0) as position, which practically never trigger
this condition.
Pass only width and height to gs_draw_sprite_subregion(), instead
of adding x and y to them.
Fixes https://github.com/obsproject/obs-studio/issues/4982
When size of source_info_t is larger then current structure, memcpy
overruns. Size check is moved before the memcpy.
HANDLE_ERROR macro copies info to data but data is not used. When
calling free_type_data and type_data, the member of data should be used
to ensure the free_type_data is not out of bounds.
When changing a source's audio mixers/tracks or sync offset with
obs_source_set_audio_mixers or obs_source_set_sync_offset
from a non UI thread while the advanced audio properties panel is open
the UI fields will not update until closed and reopened.
It just shows an error on stderr for the failed invokeMethod calls
that would do the update. For mixers and sync offset respectively:
QMetaMethod::invoke: Unable to handle unregistered datatype 'uint32_t'
QMetaMethod::invoke: Unable to handle unregistered datatype 'int64_t'
Added needed Qt registrations in window-basic-main as that's where
all the needed ones for the frontend UI seem to be put.
Adds support for 1080p streams, adds support for 60 FPS streams,
implements bitrate matrix to restrict bitrates depending on the user's
resolution and framerate combination, and removes 480x360, as it was the
incorrect resolution (the correct resolution was supposed to be
640x360).
The bitrate matrix allows specifying maximum bitrate values based upon
resolution and framerate values. This allows more fine-tuned enforcement
of bitrate to prevent users from setting a bitrate that is less ideal
for their particular framerate and resolution combination.
Intead of creating one pair of GDBusConnection + GDBusProxy objects
for each PipeWire capture, be it window or desktop, use the global
ones managed by portal.c.
Even if g_bus_get_sync() ends up reusing the same object under the
hood, it's still a net gain, since it has to perform some thread
synchronization routines that aren't necessary here. Creating the
proxy object was a worse offender, because despite being asynchronous,
it would still incur in a few socket messages + a cancellable fd +
thread synchronization.
Reuse these objects from portal.c. The biggest code change here is
that create_proxy() and on_proxy_created_cb() were merged into
init_obs_pipewire().
Right now we just assume that every compositor and portal implementation
exposes both window and monitor captures, but that's not true, and in fact
the Desktop portal provides a simple mechanism to check which source types
are available: a D-Bus property called "AvailableSourceTypes".
Read this D-Bus property, and use it to conditionally register the desktop
and the window captures.
Related: https://github.com/obsproject/obs-studio/issues/4815
When obs_get_source_properties is called, it calls the property modified
callbacks without a source instantiation. The callbacks set in
.get_properties for display capture and window capture would then result
in exceptions when anything is dereferenced on the source, such as
wgc_supported or update_mutex, because the source itself is null. Let's
make the callbacks return early if the property param is null.
We shouldn't have to check WGC support for every display capture or
window capture source. Either the system supports it or it doesn't.
Check when the plugin loads and use that result.
The device type (OBS renderer) cannot change without restarting OBS, so
we should only have to check if we're using D3D11 once instead of
checking every time a new display capture or window capture source is
created.
Among the systems we officially support, the oldest Qt version is Qt 5.9
on Ubuntu 18.04. Fractional scaling is supported in Qt 5.6 and newer. We
should be able to safely remove these ifdefs.
Follow up to PR #3988 and commit
5cdd084c7f.
Without this change, displays listed as projector targets on systems
using a fractional scaling factor (e.g., 125%, 150%, 175%) will show an
incorrect width and height for their size. For a display with 125%
scaling, OBS would show 1536x864 instead of 1920x1080. With this change,
it will show 1920x1080.
The cursor bitmap is centered on the hotspot, so not accounting
for it means PipeWire captures were positioning the cursor sprite
slightly off.
Properly account for the hotspot by subtracting it from the cursor
position.
Related: https://github.com/obsproject/obs-studio/issues/4766
The Windows uninstaller was not deleting the desktop shortcut because
the shell context was incorrectly set to "current" for it, causing it to
try to delete in the incorrect location.
This crash was caused by the fact that the SourceToolbar::oldData member
variable was not being released correctly. To release an OBSData object,
it must be either destructed, set to a new value, or set to a null
value.
Before OBS Studio 27, we used our own hard-coded internal encoder IDs on
for the mac-vth264 plugin: vt_h264_hw and vt_h264_sw. As of OBS Studio
27, we changed to using the encoder IDs that Apple's API reports.
Specifically, this behavior occurs due to PR #4105 and commit
6a9f25c8ea.
Unfortunately, this change in encoder IDs failed to take into account
existing user configurations, resulting in users with broken encoder
settings. This change attempts to gracefully upgrade user configurations
to handle the changed encoder IDs.
Fixes#4799.
Only use lossless encode if the capability is supported.
Set qpPrimeYZeroTransformBypassFlag to 1 for lossless.
Do not set profileGUID for lossless.
For both NVENC implementations, retry with a heavier reset because both
are unable to recover from failure lightly.
For new NVENC, warn if PVT is requested, but unsupported by the GPU.
Also retry without PVT on failure to try to catch bad cominbations.
For old NVENC, if PVT is enabled when FFmpeg failure occurs, retry
without PVT.
