Without this we can easily run into a race condition with async state changes:
- the pipeline is doing an async state change
- we set the internal bins to PLAYING but that's ignored because an
async state change is currently pending
- the async state change finishes but does not change the state of the
internal bins because of locked_state==TRUE
- the internal bins stay in PAUSED forever
Otherwise it will never try to send us the next one: it tries to keep
exactly one message in-flight all the time.
In gst-rtsp-server this is done asynchronously via the GstRTSPWatch but
in the client sink we always write data out synchronously.
This adds new functions for passing buffer lists through the different
layers without breaking API/ABI, and enables the appsink to actually
provide buffer lists.
This should already reduce CPU usage and potentially context switches a
bit by passing a whole buffer list from the appsink instead of
individual buffers. As a next step it would be necessary to
a) Add support for a vector of data for the GstRTSPMessage body
b) Add support for sending multiple messages at once to the
GstRTSPWatch and let it be handled internally
c) Adding API to GOutputStream that works like writev()
Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/29
We were previously only ever waiting for a single stream to notify it's
blocked status through GstRTSPStreamBlocking. Actually count streams to
wait for.
Fixes rtspclientsink sending SDP's without out some of the input
streams.
https://bugzilla.gnome.org/show_bug.cgi?id=796624
Set transport string to NULL after freeing it, so that
at worst we get a NULL pointer if constructing a new
transport string fails (which shouldn't really fail here).
Also check return value of that, just in case.
CID 1433768.
This was broken since the work for delayed transport creation
was merged: the creation of the transports string depends on
calling stream_get_server_port, which only starts returning
something meaningful after a call to stream_allocate_udp_sockets
has been made, this function expects a transport that we parse
from the transport string ...
Significant refactoring is in order, but does not look entirely
trivial, for now we put a band aid on and create a second transport
string after the stream has been completed, to pass it in
the request headers instead of the previous, incomplete one.
https://bugzilla.gnome.org/show_bug.cgi?id=794789
As READY_TO_PAUSED can no longer return async, the RECORD
command will be queued before the OPEN command fails
(for example in case the server could not be connected),
and record then waits for ever.
https://bugzilla.gnome.org/show_bug.cgi?id=793896
Goto error label checks stream to see if it needs to be unreferenced before
returning, but this goto jumps happens before the stream is ever set, so it
will always be NULL in this error label.
CID #1352034
Coverity demands for fallthrough statements to be clearly commented,
to distinguish from accidental fall throughs. And it also needs all
cases to finish with a break, even if the break is never going to be
executed like in the case of a continue jump.
CID #1352039
CID #1352040
Add an rtspclientsink element that accepts streams for which
there is a registered payloader and sends them to
an RTSP server using RECORD.
Sending is synchronised to the pipeline clock. Payload-types
are automatically selected. The 'new-payloader' signal is fired
for custom configuration of payloaders when they are created.
Can now stream a movie like this:
receiver:
./test-record "( decodebin name=depay0 ! videoconvert ! autovideosink \
decodebin name=depay1 ! audioconvert ! autoaudiosink )"
sender:
gst-launch-1.0 filesrc location=file-with-aac-and-h264.mp4 ! qtdemux name=d ! \
queue ! aacparse ! rtspclientsink location=rtsp://127.0.0.1:8554/test name=s \
https://bugzilla.gnome.org/show_bug.cgi?id=758180
