The use of `SPA_POD_OPT_Rectangle()` means that if the rectangle cannot be
parsed, then no error will be returned. In that case uninitialized variables
will be used. This can happen if the pod object contains e.g. a list of
resolutions (`SPA_CHOICE_Enum`).
Fix that by using `SPA_POD_Rectangle()`, which enforces successful parsing.
The SPA format (pixelformat) was compared with a libobs video format
value.
Also removes the SPA format support check since at this point it already
has been done while listing formats.
The resolution and aspect ration should be added to the description of
the format even if there are no available frame rates.
The code is restructured a bit to avoid having to call `dstr_free()`
before each `continue`.
Fixes: 4cfcfc8c35 ("linux-pipewire: Make camera framerate non-mandatory")
Since video rendering happens on a separate thread from PipeWire buffer
ingestion, it may happen that two buffers are ingested in quick
succession without the rendering thread ever getting to them. Since,
prior to this commit, the release sync point is only "primed" (set to
signal in the future) only on the video rendering thread, this results
in the buffer being returned to PipeWire's pool without anything ever
signaling the release point, effectively blocking it from ever getting
reused in the future. This quickly clogs up the buffer pool and leaves
only one buffer to circulate between the screencast source and OBS.
This commit adds a flag tracking whether the release point had been
primed. If, when ingesting a new PW buffer, the old buffer's release
point hadn't been primed, that means the video rendering thread never
got to that buffer, so the release point is immediately signaled,
marking the buffer reusable by the screencast source.
PipeWire format renegotiation runs in parallel with video rendering.
When the stream format is renegotiated, PipeWire removes the existing
buffers and closes the syncobj file descriptors. At the same time, the
video rendering thread may try to import the (already closed) syncobj
acquire fd, and hang on waiting for the fence to become available.
This is not a problem for the dmabuf fd because it's imported into a
texture right away, which doesn't disappear when PipeWire closes the fd.
This commit adds duping to the syncobj fds so that they too remain open
as long as the rendering thread may access them.
It is possible for OBS to receive incomplete frames from the compositor
if the graphics drivers in use do not support implicit synchronization.
The compositors usually try to workaround this issue by waiting all
render operations to complete before sharing frames with OBS. However,
this has performance implications for the compositors. Similarly, OBS
should also make sure that all the rendering operations sourcing the
received buffer are complete before returning the respective pw_buffer
back to the compositor, or it would risk the image it is working on
getting overwritten without some type of synchronization.
This change leverages PipeWire's ability to share DRM syncobj fds to
implement an explicit synchronization solution to solve the problem
described above. The usage of these DRM syncobjs is negotiated with the
compositor that OBS is running on. So OBS can still work even if the
compositor does not support explicit synchronization.
Signed-off-by: Doğukan Korkmaztürk <dkorkmazturk@nvidia.com>
Allow to select both main type of ScreenCast (monitor, window)
with only one source type rather than adding a source type per
ScreenCast type.
This change is made as a new Screen Capture source type which
obsoletes the use of the previous Screen Capture (monitor-only)
and Window Capture.
This will allow consumers of obs_pipewire to handle the device
registry themselves. This is not useful for the screencast code
since there's always only one node in the registry, but it will
be used by the camera and audio code to list hardware devices.
This commit adds the screencast-specific 'cursor_visible' field
in an anonymous struct within the constructor struct.
This slightly improves the connection code by properly treating
construction-time information in a constructor struct. It allows
removing the extra function call that sets cursor visibility from
the Screencast portal code.
Admittedly that's not much, but again, this will be an important
distinction when introducing the Camera portal code, since some
camera properties will need to trigger renegotiation.
