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.
This makes sure we first nicely remove the stream from the server
and then close the socket.
If we don't do this, the disconnect might not have flushed out our
disconnect and the server is left with a non-responsive node,
especially if the disconnect on the core was done with a socket from
the portal that is still open.
Pipewire might update buffers that have not been recycled by GStreamer,
because they are still used downstream. There is nothing we can do about
it in the pipewiresrc.
If a buffer is sent downstream more than once, take an additional
reference to make sure that we don't queue a buffer that is still used
and print a warning.
By default, the pipewiresrc tries to negotiate 16 buffers. This value is
hard coded in the pipewiresrc. If the buffers are large, this could lead
to an undesirably high memory usage. Applications that know about the
buffer size and that fewer buffers are sufficient should be able to
configure the limits for the number of buffers that are negotiated.
Therefore, add the min-buffers and max-buffers properties to the
pipewiresrc to enable applications to configure limits for the number of
negotiated buffers.
If the video format cannot be detected, GStreamer will return the
UNKNOWN format, which is translated into the Id 0 in the
Spa:Interface:TypeMap, which is added to the pod.
When the pipewire server receives the pod and tries to unmarshal the
pod, it will detect the Id 0. Unable to distinguish Id 0 from a missing
id, the server discards the message as invalid and closes the
connection.
Use the following gstreamer pipeline to reproduce (note the wrong nv12
instead of a correct NV12 format):
gst-launch-1.0 pipewiresrc ! video/x-raw,format=nv12 ! fakesink
The gstdeviceprovider segfaults when listing the available devices,
because it the pointer to GList * is initialized with NULL instead of
the GList * itself. Don't use a pointer, but use the GList * directly.
Messages that are printed for every buffer should use the LOG debug
level, while messages that happen during setup and tear down should use
the DEBUG debug level.
Therefore, use LOG in on_process and when popping buffers and DEBUG when
Pipewire adds or removes buffers.
This is more in line with wayland and it allows us to create new
interfaces in modules without having to add anything to the type
enum. It also removes some lookups to map type_id to readable
name in debug.
Make the thread_loop alloc its own loop by default to simplify
some core. Add extra new_full method to pass a custom pw_loop.
Make other loop implementations ready to support custom loops
if we want that later.
