We don't initially have the SAP socket open, so we can't generate an SDP
(because we don't have the interface address). So in addition to the
regular flow, also trigger SDP creation after opening the SAP socket, so
we can have a valid SDP for the announcement.
The sending was broken in commit a44afd84. We delay the SAP fd openeing
for reasons explained in commit f2f204d6).
When both node and port are given, check that the port belongs to the
node. If it doesn't, it could be that we found a Port using the
object.id but we should have used the port.id of the node.
The transport update is set in the node properties. If one client tries
to start and another tries to stop we have two conflicting desired states
in the nodes.
Fix this by making the state update a one time property and remove it
from the sever and client properties after updating it. We then need to
keep the new state around and apply it once.
Keep the node driver state as it is unless there was a transport state
update.
Fixes#4543
Deprecate the `always-copy` property in pipewiresrc and use the new
property `use-bufferpool` in both pipewiresrc and pipewiresink to
specify whether to use the gstpipewirepool or not.
The gstpipewirepool is used for video by default unless `use-bufferpool`
is set to `false` and it is not used for audio by default unless
`use-bufferpool` is set to `true`
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
