When connecting to an RTSP server in tunnled mode (HTTP) the server
usually replies with a x-server header. This contains the address
of the intended streaming server. However some servers return an
"invalid" address. Here follows two examples when it might happen.
1. A server use Apache combined with a separate RTSP process to handle
Https request on port 443. In this case Apache handle TLS and
connects to the local RTSP server, which results in a local
address 127.0.0.1 or ::1 in the x-server reply. This address is
returned to the actual RTSP client in the x-server header.
The client will receive this address and try to connect to it
and fail.
2. The client use a ipv6 link local address with a specified scope id
fe80::aaaa:bbbb:cccc:dddd%eth0 and connects via Http on port 80.
The RTSP server receives the connection and returns the address
in the x-server header. The client will receive this address and
try to connect to it "as is" without the scope id and fail.
In the case of streaming data from RTSP servers like 1. and 2. it's
useful to have the option to simply ignore the x-server header reply
and continue using the original address.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1007>
Seek events are sent upstream on each sink, so if we receive multiple
seeks with the same seqnum, we must only perform one seek, not N seeks
where N = the number of sinks in the pipeline connected to rtspsrc.
This is the same thing done by demuxers like qtdemux or matrsokademux.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/938>
Since glib 2.62, the accumulated return values in RUN_CLEANUP override the
accumulated return values in RUN_FIRST. Since:
1. We have a default handler that always returns TRUE, and
2. User handlers are only run in RUN_FIRST, and
3. Our accumulator just takes the latest return value
We were discarding the return value from the user handler and always
sending messages even if the user handler said not to. See
https://gitlab.gnome.org/GNOME/glib/-/issues/2352 for more details.
This signal does not need RUN_CLEANUP or RUN_FIRST, so just change it
to RUN_LAST so that it's emitted exactly once and accumulated once.
With this fix, this signal can now be used to intercept PAUSE when
going to GST_STATE_NULL so that the server does a TEARDOWN (if
necessary) and not a PAUSE, which will confuse other RTSP clients when
playing shared media.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/909>
Directly setting rtspsrc to the NULL state before putting the pipeline
in the NULL state usually works, but it can cause a deadlock in some
cases, so it's not a reliable mechanism to fix this.
This reverts commit f37afdafff:
"rtspsrc: Fix state changes from PAUSED to PLAYING"
and commit 76d624b2df:
"rtspsrc: Do not send PAUSE command when going to GST_STATE_NULL"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/908>
This usually doesn't matter, but it is disruptive when streaming from
a shared media since it will pause all other clients when any client
exits.
This new behaviour is opt-in and should be safe because you need to
set the NULL state on rtspsrc directly, instead of just on the
pipeline. See the updated documentation for an explanation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/901>
Some cameras (e.g. HikVision DS-2CD2732F-IS) return "551 Option
not supported" when a command is sent that is not implemented
(e.g. PAUSE). Instead; it should return "501 Not Implemented".
This is wrong, as previously, the camera did announce support for PAUSE
in the OPTIONS.
In this case, handle the 551 as if it was 501 to avoid throwing errors
to application level. */
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/885>
Due to the may_cancel flag in GstRTSPConnection, receiving might not get
cancelled when supposed to. In this case, gst_rtsp_src_receive_response
will have to wait until timeout instead but if busy receiving RTP
data, this timeout will never occur.
With this patch, gst_rtsp_src_receive_response returns GST_RTSP_EINTR
if flushing is set to TRUE instead of continuing to receive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/831>
Comparing gst_rtspsrc_loop_interleaved and gst_rtspsrc_loop_udp, and investigating on timeout issues, it sounds like a piece of code has been originally copied from udp to the interleaved one. The timeout variable is never used inside the interleaved one. No side effect has been seen in the removed function calls.
The debug message removed is pointless as the timeout used is "src->tcp_timeout" that is fixed.
The presence of the two timeout drove my team in investigating if the reference to the tcp_timeout was correct (it is). Hence we removed the misleading reference to the local timeout variable.
When the server replies with a range "now-", it is presumed to
be a "live" stream and we should request a similar range.
This was the case prior to my refactoring to make use of
gst_rtsp_range_to_string in 5f1a732bc7,
this commit restores the behaviour for that case.
gstrtspsrc uses a queue, set_get_param_q, to store set param and get
param requests. The requests are put on the queue by calling
get_parameters() and set_parameter(). A thread which executs in
gst_rtspsrc_thread() then pops requests from the queue and processes
them. The crash occured because the queue became empty and a NULL
request object was then used. The reason that the queue became empty
is that it was popped even when the thread was NOT processing a get
parameter or set parameter command. The fix is to make sure that the
queue is ONLY popped when the command being processed is a set
parameter or get parameter command.
By passing `NULL` to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
The output segment is only used in ONVIF mode.
The previous behaviour was to output a segment computed from
the Range response sent by the server.
In ONVIF mode, servers will start serving from the appropriate
synchronization point (keyframe), and the Range in response will
start at that position.
This means rtspsrc can now perform truly accurate seeks in that
mode, by clipping the output segment to the values requested in
the seek. The decoder will then discard out of segment buffers
and playback will start without artefacts at the exact requested
position, similar to the behaviour of a demuxer when an accurate
seek is requested.
This is useful to support the ONVIF case: when is-live is set to
FALSE and onvif-rate-control is no, the client can control the
rate of delivery and arrange for the server to block and still
keep sending when unblocked, without requiring back and forth
PAUSE / PLAY requests. This enables, amongst other things, fast
frame stepping on the client side.
When is-live is FALSE, we don't use a manager at all. This case
was actually already pretty well handled by the current code. The
standard manager, rtpbin, is simply no longer needed in this case.
Applications can instantiate a downloadbuffer after rtspsrc if
needed.
Refactor the code for parsing and generating the Range, taking
advantage of existing API in GstRtspTimeRange.
Only use the TCP protocol in that mode, as per the specification.
Generate an accurate segment when in that mode, and signal to the
depayloader that it should not generate its own segment, through
the "onvif-mode" field in the caps, see
<https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/328>
for more information.
Translate trickmode seek flags to their ONVIF representation
Expose an onvif-rate-control property
