The D-Bus signal subscription is a very boring aspect of the
portals infrastructure that shouldn't really matter when reading
the code of pipewire.c.
Move it out to its natural place, portal.c.
Cameras and audio streams will use the async output routines, but
not screencasting. This needs to be handled differently in the
processing callback.
As it is, the code is starting to get a bit messy, as we're now
dealing with two different frame processing approaches. Later on,
this code will be cleaned up and split in more logical pieces.
Co-authored-by: Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>
So far we've been treating format info on a per-connection basis,
but now that a single connection is capable of hosting multiple
streams, and each stream might negotiate a different format, it
is necessary to move format info to each stream individually.
Sorry, this is a painful commit to review :(
Until now, the only consumer of the PipeWire code is the screen
cast portal code. This portal code only ever has one PipeWire
connection, and one PipeWire stream, every time a monitor or a
window is selected. This is reflected on obs_pipewire, which only
handles a single stream for any given connection.
For cameras and audio, however, a single PipeWire connection can
and most likely always will provide multiple streams. For example,
computers with multiple webcams will have one PipeWire connection
reporting multiple PipeWire nodes, one node for each camera.
This commit breaks this one-stream-per-connection assumption, and
makes obs_pipewire_connect_stream() return an independent object
(obs_pipewire_stream) that represents a single stream.
The screencast portal code continues to only ever have one connection
and one stream.
PipeWire supports 10bit colour formats with little endian order.
Adding two new formats required increasing the buffer size for building
PipeWire buffers.
This formats are supported since PipeWire 0.3.41. To allow building
against
older PipeWire versions we will hide those formats. Complications when
running on a host with an older PipeWire version are not expected, since
format negotiation is only done via the numerical values.
Compositors did not agree on how to communicate invalid buffers until
recently, so e0a4d8628d resulted in
regressions on KDE. This restores our old behavior which is too
conservative but mostly works on old and new compositors (which contain
similar workarounds to pass in invalid but non-zero sizes for dma-bufs).
Once all old compositors are out of use we can remove this workaround
and then compositors can remove their random size workaround.
Pipewire desktop portal capture assumes premultiplied alpha, so make
sure to use the right blend equation to make translucent pixels work
correctly.
This is still broken for emissive pixels (alpha < color) since OBS seems
to unpremultiply at some point during blending, but it works properly
for translucent pixels (emissive pixel support requires an end-to-end
premultiplied pipeline).
Use hex for modifiers because they are generally formed from a high byte
and low bytes. This makes it easier to see these bytes and identify
unusual modifiers.
If we receive an empty cursor bitmap - one without valid size - we
should hide the cursor. Do so by clearing the texture.
This fixes visible cursors when recording various games with Wayland
compositors.
Closes https://github.com/obsproject/obs-studio/issues/4895
Some compositors send buffer crop information even when the crop
matches the buffer size. It doesn't really matter in practice,
but it's good hygiene to check for the effective crop instead of
simply checking if crop exists.
Move code into auxiliary functions, to improve the legibility of the
draw function. It also gets rid of these pesky switch fallthroughs.
No functional changes.
In the non-DMA path, we are logging an error message saying that
the DMA format is wrong. That's not the DMA format, it's the raw
buffer format.
Fix the message.
PipeWire allows since 0.3.62 [1] to attach metadata to a buffer
describing a transformation of the buffercontent. Clients should then
undo that transformation to import it correctly.
We can enable this feature using macro guards and runtime server version
checks on supported systems.
[1] https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/1423
Receiving buffers flagged as corrupted, or empty, is a casualty of
how things are implemented in various compositors, and it's not
a critical situation to be afraid of. We can expect a few buffers
to be flagged as corrupted here and there, and that's fine.
Demote these warnings to debug messages, as they're still useful
for debugging.
A trivial cosmetic change. This groups the constructor and
destructor together. Two sides of the same coin, yin and yang,
bound by their nature, and linked by their position in code.
This commit introduces an important distinction in the initialization
process that is essential to future camera and audio work: it splits
creating and connecting to the PipeWire socket, from connecting to
specific PipeWire nodes.
Right now, for the only consumer in existence - the ScreenCast portal
code - this distinction is irrelevant, but from an API perspective it
just makes sense to model it this way.
We don't actually need to restore the node id anymore, since this
is handled by the screencast-portal.c code now.
Remove the pipewire_node field, and just create the stream directly
from the passed file descriptor now.
This separation of obs_pipewire_create() and play_pipewire_stream()
was an artifact of how the original code was written, and there is
no reason to keep this separation anymore. Inlining it will help
future commits too.
And let each portal pass the stream properties relevant to them.
This makes the pipewire.c more independent of the actual portal
by providing a wrapper to create a stream. This will be relevant
later, when linux-pipewire introduces more portals like the Camera
one.
When the linux-pipewire plugin is unloaded, make sure to cleanup
the D-Bus proxy for the ScreenCast portal too. This effectively
doesn't change anything, but it's always good to keep up with the
code hygiene.
PipeWire supports two flags to signal an invalid buffer:
SPA_META_HEADER_FLAG_CORRUPTED signals that the whole buffer is invalid
and should not be used
SPA_CHUNK_FLAG_CORRUPTED signals that one single buffer plane is invalid
Skipping a buffer because of size 0 was moved to only the SHM case.
For DMA-BUFs the size of a single plane is not relevant and should be
ignored [1].
Compatibility note:
GNOME pre 43 sets the chunk size to 0 when a buffer copy failed.
Luckily GNOME doesn't use the META_Header and thus we can detect if we
should use the new or old style of invalid buffer detection.
This workaround should be dropped when reasonable.
[1] https://docs.pipewire.org/page_dma_buf.html
Whe using a software renderer there will be no formats available for
using with dmabufs. We should only consider those formats wrt. to
modifiers and as such move this check after adding general support for
that format.
fixes#7985
This reverts commit 0532a5c1f0.
Ubuntu 21.10 is from OBS 28 onwards not longer supported and as such we
can raise the requirement of the PipeWire dependency to 0.3.33.
