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.
So that we can expand the number of construct-time connection
properties without changing the function signature every time.
This is mostly an ergonomic change for now, but it'll be very
useful when introducing the Camera portal code.
We use a size_t that can be 64bit while EGL uses 32bit for the
underlying value. Writes from our graphics function can leave high bits
uninitialized and cause iteration of the format list to overlfow.
fixes#9844
We were passing the core pipewire pointer where renegotiation expected
the stream pointer. Somehow this worked, probably because the two are
very close.
fixes#9733
After the cmake 3.0 rebuild glad was transitioned to a static library.
This lead to the glad symbols being uninitialized and crashes when they
are used in some cases.
tytan652