During negotiation, ensure that possible_caps exists before calling
gst_caps_intersect_full(). Sometimes possible_caps seem to be NULL which
cause the GST_IS_CAPS assert to fail.
The reason for the occasional NULL possible_caps during initial
negotiation is unknown, but this is also possible during renegotiation.
The handle_format_change() may be triggered before the next create(),
win which case we have not yet discovered in the streaming thread that
we are in the NOT_NEGOTIATED state. We should guard against this
possibility as well.
Because we don't know the stream state at the start of streaming, if
clients are deciding to connect on the basis of this flag, they will
never connect if we default to true. So let's be optimistic by default
and we'll find out on timeout if there actually isn't data to receive.
Some of the tools would like to connect to the manager socket first
because they are manager style apps. They however completely ignore any
of the configured sockets in the config and assume everything is the
default.
Fix this by adding a remote.intention = "manager" to those apps. This
instructs the protocol to first try to connect to a socket with the
-manager extension before attempting the regular configured socket.
This makes things work when you have sockets configured in /tmp
and have remote.name = /tmp/pipewire-0 in the config.
We use the remote name as a suffix for the default server address and so
it should not contain any slashes. Take everything after the last slash
if there is one.
We keep on calling the drain event for as long as we are drained. The
application is supposed to inactivate the stream or provide more data
at some point.
Because we do this from the data thread, we use a non-blocking invoke.
If for some reason the event callback takes a long time we might place a
lot of these invoke calls into the invoke queue, which will then be
dispatched one after another (and cause more blocking or a burst of
useless invoke calls).
Avoid this by only placing one drain invoke call into the queue at a
time.
Fixes#4529
If a provider uses the stream API and pushes a buffer to the stream
after the stream is set to paused, the buffer_id of the last buffer
remains in the io.
If a consumer starts streaming in this state, the buffer_id of the old
buffer is still in the io. The consumer receives a stale buffer_id and
may discard the buffer. Now the buffer is lost, since it is still marked
as busy on the producer.
This can be reproduced by starting Weston with the PipeWire backend and
repeatedly restarting a GStreamer pipeline that connects to the Weston
output. Eventually Weston won't be able to dequeue buffers since the
lost buffer is still busy.
Clear the buffers in the io when the buffers are cleared to avoid
sending an old buffer_id to the consumer.
If the rate is 0/0, converting nsec to ticks doesn't work and will
result in 0 ticks, and it is not possible to convert ticks back to a
timestamp.
This can be reproduced by connecting a GStreamer pipewiresrc to a
libcamera node. The libcamera-utils has a rate of 0/0 and the
pipewireclock won't be able to determine a correct time with that. This
error was caused by Commit 89993a3cc6 ("gst: enable the pipewire ticks
as a clock source").
Fix this by using the nsec as ticks and setting the appropriate rate.
Idle the source when no packets are received and resume when new packets
arrive.
Add a stream.may-pause property to pause the stream when no packets are
received during the timeout window.
Make sure the rtp.streaming property is updated correctly and as soon as
we get the first packet.
Fixes#4456
Reorganize some code to separate the creation and sending of the SAP
message.
Check if when the node changed, we have an actual change in the SDP
before we send BYE and the new SAP message. It's possible that nothing
changed, for example when the node simply changed state or an unrelated
property.
When we do any other blocking in the render function, we should unblock
and call _wait_preroll() when we go to PAUSED.
We can have this situation when all the buffers are queued in the
pw_stream and we get a new _render() call. We can't get more buffers
from the pool and so we must block and wait. When we go to PAUSED we
need to unlock and go to _wait_preroll(). Implement this by setting a
pool paused flag that is set when the sink goes to paused, we can then
return a special value that does the wait_preroll().
See !2248
Setting bufferpool to flushing state in PAUSED state is preventing the
buffer flow if there is a seek/flush event.
Instead, set the bufferpool to flushing during the `flush-start` event
and clear it during the `flush-stop`
Deactivate/activate the stream during flush event only if the sink is
in the PLAYING state. In the PAUSED or READY state, the stream would be
inactive and we do not want to alter that
When we write samples, check if we make a jump in the ringbuffer and
clear the samples we jumped over.
If we don't do this, the reader side might pick up old samples that we
didn't write or clear but that are now available for reading after we
made a jump in the ringbuffer.
This migh not be exactly what pulseaudio does but it is good for now.
Fixes#4464
flush the pw buffers to the stream's queue during a FLUSH_START event
and return the unqueued pw buffers, if they are dropped/released without
being rendered, so they can be available to be dequeued for the subsequent
`acquire` calls
We now automatically move non-rt clients into non-rt threads so the
client-rt.conf is obsolete.
Move the module-rt in client.conf and add conditions to disable modules.
Transparently load client.conf in case applications still specify
client-rt.conf.
Custon configuration in the client-rt.conf.d/ should be moved to
client.conf.d/
Wireplumber and other system services use local real time timestamps in
logging, so it's more convenient if also PW uses them.
Add env var for selecting the timestamp type, default to "local".
Copy the server value to the context so that the locally allocated
buffers match the server quantum-limit and we don't cause xruns because
of too small buffers.
See #4490
