Gstreamer simply mmap()s the DMA buffers. This can be very very slow on
some hardware, so don't ask for it. For gstreamer to support DMA
buffers, it will need to support a proper way of transferring the
buffers from the GPU to the CPU, e.g. using EGL/OpenGL.
The current code has several issues if a pipewiresrc is stopped and deleted
while a buffer is still in use downstream.
- pw_stream_queue_buffer() is never called for the corresponding
pw_buffer. As a result, the busy counter is never decremented and
pw_stream_dequeue_buffer() of the corresponding pipewire output will
return NULL whenever it encounters this buffer.
- The pipewiresrc does not own the buffer reference unless the buffer is
queued in the source, so calling gst_buffer_unref() unconditionally
causes refcount issues for the buffer.
- buffer_recycle() can race with on_remove_buffer() and
gst_pipewire_src_close(). As a result, buffer_recycle() may access pwsrc
when it was already deleted.
The buffer has its own reference to the pool. So the pool object lock can
be used to ensure that the pwsrc, core and stream remain valid in.
buffer_recycle(). If the 'dispose' function pointer was already cleared,
then on_remove_buffer() has already finished, so abort early.
With the pool lock held, it is save to access the pipewire loop. Now the
loop lock can be used to synchronize with on_remove_buffer(). 'dispose'
must be checked again in case on_remove_buffer() was triggered by something
other than gst_pipewire_src_close().
In on_remove_buffer() unref the buffer if it is queued. Otherwise call
pw_stream_queue_buffer() to ensure that the busy counter is decremented
correctly.
When we manually acquire buffers from the pool, we never release them.
But because gst_buffer_pool_acquire_buffer() adds a reference to the pool,
this leaks the pool eventually.
To fix this, just unref the buffer after it has been sent. This releases
it back to the pool and unrefs the pool.
This has no significant effect to the stream, since the underlying
pw buffers are actually pooled in the pw_stream. It just prevents leaking.
When pipewiresink needs to copy data, it has to resize the destination
buffer (to a smaller size) in order to send the correct data size to
pipewire. When this dest buffer is reused later, it will still have
this smaller size as its total size and the copy may discard data
from upstream if the new upstream buffer is bigger than the last one
that was copied on the same dest buffer.
SPA_MEMBER is misleading, all we're doing here is pointer+offset and a
type-casting the result. Rename to SPA_PTROFF which is more expressive (and
has the same number of characters so we don't need to re-indent).
PipeWire does not give DMABUF anymore to clients unless they
explicitly ask for it. This results in v4l2 sending an fd and
the mmapoffset + size fields in the buffer.
GStreamer does not handle the mmapoffset in the fd allocator and
thus runs into mmap problems when using the memory.
Enable DMABuf explicitly to work around the problem until
GStreamer is fixed.
Fixes#1115
With sending and receiving pipelines:
gst-launch videotestsrc ! tee ! pipewiresink mode=provide
gst-launch pipewiresrc path=<node_id> ! videoconvert ! autovideosink
The first pipeline crashes when the other connects.
It happens because SPA_PARAM_BUFFERS_size passed to
pw_stream_update_params() upon pipewiresink's buffer pool activation is
zero. As a consequence, in gst_pipewire_pool_wrap_buffer(), d->type will
be SPA_ID_INVALID and the created GstBuffer will have no memory
appended. This ultimately leads to segfault in do_send_buffer().
If size hasn't been set in GstPipeWirePool's config before the
first buffer is to be rendered by pipewiresink, configure the pool with
the size of that first incoming buffer and activate the pool.
When we destroy the proxy we should either take the thread lock
or stop the thread loop because the destroy might trigger a reply
to remove the object from another thread. This can cause the
refcounting to become invalid and cause double free.
Fixes#286
Don't do any GStreamer data transport from the PipeWire callback
because it might block in preroll and block our communication with
PipeWire. Instead, take the caps and wake up the caller to continue
with negotiation.
Add a property to periodically send the last buffer to keep the
stream alive. Useful for sparse streams that need to keep the
encoder busy every once and a while.
Make all sources in the same process with the same fd share the
connection to the server. This makes it possible to set the same
fd on multiple sources/sinks and have them all use the same
connection, like when capturing multiple monitors from screencast
with the portal.
Fixes#241
Don't use the core info to manage the hiden providers, that info
can't be put there anymore because the session manager manages
the devices now.
Look at the object path instead and hide those with well known
prefixes.
Add an option to resend the last buffer on EOS with an updated
timestamp. This can be used to make sure encoders fill up the
gap between last buffer and EOS, like with sparse streams from
screen capture.
