We then pass those to adjust_play_mode, which needs to operate
on the "final" seek flags, as previously the code in rtsp-media
was assuming that accuracy seek flags (accurate / key_unit) should
not be set if the flags passed to the seek method were already set.
First try "pay", then "pay_%s" (where %s == pad name). And only then
fall back to the code that simply takes the first payloader that is
found.
The current code usually works (but is racy) because it will always take
the payloader that was last added (due to g_list_prepend() when adding
elements) in pad-added and that's usually the correct one. But if a new
payloader is added between pad-added and us trying to get it, we would
get the wrong payloader.
Without this patch there are problem pre-rolling when using audio back
channel.
Without this patch a probe will be created for all streams including
the stream for audio backchannel. To pre-roll all this pads have to
receive data. Since the stream for audio backchannel is a receiver this
will never happen.
The solution is to never create any probes for streams that are for
incomming data and instead set them as blocking already from beginning.
The recent ONVIF work exposed a race condition when dealing with
multiple streams: one of the sinks may preroll before other streams
have started flushing. This led to the pipeline posting async-done
prematurely, when some streams were actually still in the middle
of performing a flushing seek. The newly-added code looks up a
sticky segment event on the first stream in order to respond to
the PLAY request with accurate Scale and Speed headers. In the
failure condition, the first stream was flushing, and thus had
no sticky segment event, leading to the PLAY request failing,
and in turn the test.
This will be used in the onvif tests in order to validate the
data transmitted over TCP: for streaming to continue after a
data message has been provided to client->send_func, the client
is responsible for marking the message as sent on the relevant
stream transport.
GStreamer plays segment from stop to start when doing reverse playback.
RTSP implies that media should be played from start of Range header to
its stop. Hence we swap start and stop times before passing them to
gst_element_seek.
Also make gst_rtsp_stream_query_stop always return value that can be
used as stop time of Range header.
Add support for the RTSP Scale and Speed headers by setting the rate in
the seek to (scale*speed). We then check the resulting segment for rate
and applied rate, and use them as values for the Speed and Scale headers
respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=754575
Adds a new virtual function, adjust_play_mode(), that allows
sub classes to adjust the seek done on the media. The sub class can
modify the values of the the seek flags and the rate.
https://bugzilla.gnome.org/show_bug.cgi?id=754575
Add new function gst_rtsp_media_seek_full_with_rate() which allows the
caller to specify the rate for the seek. Also added functions in
rtsp-stream and rtsp-media for retreiving current rate and applied rate.
https://bugzilla.gnome.org/show_bug.cgi?id=754575
This means we can use some newer features and get rid of some
boilerplate code using the G_DECLARE_* macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
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
Add functionality to limit the Content-Length.
API addition, Enhancement.
Define an appropriate request size limit and reject requests
exceeding the limit with response status 413 Request Entity Too Large
Related to !182
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.
If not waiting for free thread pool before clean transport caches, there
can be a crash if a thread is executing in transport list loop in
function send_tcp_message.
Also add a check if priv->send_pool in on_message_sent to avoid that a
new thread is pushed during wait of free thread pool. This is possible
since when waiting for free thread pool mutex have to be unlocked.
This suppresses the annoying 'g-ir-scanner: link: cc ..' output
that we get even if everything works just fine.
We still get g-ir-scanner warnings and compiler warnings if
we pass this option.
We need a nested extern in our init section for the scanner binary
so we can call gst_init to make sure GStreamer types are initialised
(they are not all lazy init via get_type functions, but some are in
exported variables). There doesn't seem to be any other mechanism to
achieve this, so just remove that warning, it's not important at all.
Handle the situation when a call to gst_rtsp_media_set_state is done
when media status is preparing.
Also add unit test for this scenario.
The unit test simulate on a media level when two clients share a (live)
media.
Both clients have done SETUP and got responses. Now client 1 is doing
play and client 2 is just closing the connection.
Then without patch there are a problem when
client1 is calling gst_rtsp_media_unsuspend in handle_play_request.
And client2 is doing closing connection we can end up in a call
to gst_rtsp_media_set_state when
priv->status == GST_RTSP_MEDIA_STATUS_PREPARING and all the logic for
shut down media is jumped over .
With this patch and this scenario we wait until
priv->status == GST_RTSP_MEDIA_STATUS_PREPARED and then continue to
execute after that and now we will execute the logic for
shut down media.
