We detect a container correctly now so we need to revert the weird
check there was before.
Use gst_rtspsrc_stream_push_event() to push the caps event on the
right pad.
See https://bugzilla.gnome.org/show_bug.cgi?id=739391
We set to PLAYING after we have configured the caps, otherwise we
might end up calling request_key (with SRTP) while caps are still
being configured, ending in a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=740505
gstrtspsrc.c:7939:11: error: implicit conversion from enumeration type 'GstSDPResult' to different enumeration type
'GstRTSPResult' [-Werror,-Wenum-conversion]
res = gst_sdp_message_new (&sdp);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstrtspsrc.c:7944:11: error: implicit conversion from enumeration type 'GstSDPResult' to different enumeration type
'GstRTSPResult' [-Werror,-Wenum-conversion]
res = gst_sdp_message_parse_uri (uri, sdp);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This patch adds supports for the incoming key management parameters for
encryption and authentication key lengths.
It also adds a new signal request-rtcp-key that allows the user to
provide the crypto parameters and key for the RTCP stream.
https://bugzilla.gnome.org/show_bug.cgi?id=730473
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Create and make a key for encrypting the RTCP packets back to the server
and wrap this in a MIKEY message that we send as a header in the SETUP
request.
Try to avoid using the request-pt-map to get caps but set them directly
on the udpsrc element. That way, the caps get nicely transformed as they
pass through the different elements in the rtpbin, including the AUX and
decoder/encoder elements.
Keep track of what streams we did the SETUP for. We only need to
configure caps, wait for pads and push events on setup streams. We can
remove the disabled state of the stream and simplify some checks.
After we setup a stream, skip the other streams that have the same
control url. Use a skipped flag to mark streams that should be skipped.
Call gst_rtspsrc_connection_flush (src, FALSE) to reset connections as
non-flushing before sending PAUSE and PLAY with the new npt range. Without this
patch, those commands would fail with EINTR as the connections were still
flushing.
A media stream can have multiple payload types. Parse all the payload
types and collect the caps information. We then have to store the
pt<->caps mapping instead of 1 pt and 1 caps.
Parse the profile from the SDP and use that to negotiate the transport
instead of always using AVP.
Rework how we do some tweaks for ASF and Realmedia.
Add support for a new property: tls-database. If the property is set,
the certificate database will be given to the rtsp connection if TLS
protocol is being used. If the server certificate can't be verified with
the default database, this additional database will be used.
https://bugzilla.gnome.org/show_bug.cgi?id=724396
This reverts commit 9f7b1128b1.
This should be handled automatically be rtspsrc if the AVPF profile
is used, and manual enabling of it can be done with the new-manager
signal.
Call reset-sync on the rtpbin before we go to playing. This makes us require SR
packets for all streams again before we attempt to sync them. If we don't reset,
it might be that we combine SR packets from before and after the PAUSE/PLAYING
state change and end up with huge bogus offsets.
When we go to paused, we first flush the connection and then send the pause
command. As a result of the flushing, the scheduled paused command can get
lost. Wait until the connection is completely flushed and the rtsp task is
waiting before issuing the paused or playing request.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702705
Lock the state of the all our elements and manage their states
outselves. Because we are working async, we can't rely on the state
change function to set the state at the right time or to return the
right return value from the state change function.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702046
It is not needed to do a state change from the _play() function on
ourselves. The state change function already did that and we don't want to
interfere with that (or use hacks to avoid interference).
For receiving video data via RTSP when the video is sent via
multicast there is no way to specify the udpsrc buffer-size.
On windows the native network buffer is not large and with video
i-frames being huge the buffer is to small and you get i-frame corruption,
it looks terrible, and there is no (easy) way to set the udpsrc buffer-size.
https://bugs.freedesktop.org/show_bug.cgi?id=52264
When the server suggests a GstNetTimeProvider in the SDP, set up a
GstNetClientClock that slaves to the remote clock and suggest this clock in
provide_clock.
Ignore other commands when reconnecting, otherwise the loop function would pause
and the reconnection would not happen. Continue looping after doing a reconnect
so that we have a chance to actually read the new data.
* gst/rtsp/gstrtspsrc.c (gst_rtspsrc_play): state change might be
happening in the application thread, so we don't change the state to
PLAYING in the gstrtspsrc thread unless it is safe.
A specific case is when chaning the state to NULL from the application
thread. This will synchronously try to stop the task (with the element
state lock acquired), but we will try a gst_element_set_state from
gstrtspsrc thread which will block on the element state lock causing a
deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=684312
Make a segment event when we send a new range header to a client (first PLAY
request or after a seek). Send the segment event in interleaved mode.
Clean the segment event on cleanup
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=688382
* gst/rtsp/gstrtspsrc.[ch]: added new "udp-reconnect" property. Before,
rtspsrc always tried to reconnect to the server when the RTSP
connection was closed by the server. This property lets the user
decide whether it wants rtspsrc to reconnect or not.
https://bugzilla.gnome.org/show_bug.cgi?id=683912
When the user configured a port-range, propose ports from this range
as the multicast ports. The server is free to ignore this request but if it
honours it, increment our ports so that we suggest the next port pair for the
next stream.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=639420
When we have a PLAY request, go into the LOOP function next. When we are
looping, keep on looping until we are told otherwise.
This fixed rtsp and TCP connections.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=680551
Don't reset the time in flush-stop. Live sources can do this flush in the
playing state and so the pipeline will never have a chance to update the
base_time of the elements, which only happens when going from paused to
playing.
Always send the flushing events to the udp elements now that basesrc supports
this. This makes sure a segment event is sent correctly after a flush.
Keep track of the currently executing command and make it possible to specify
what command you want to cancel when starting a new async command.
See https://bugzilla.gnome.org/show_bug.cgi?id=677905
Setting GST_SEEK_FLAG_SKIP when sending a seek event in rtspsrc should
set the "Scale" field in the rtsp PLAY header.
Because the boolean "src->skip" is set after the call, "Speed" instead
of "Scale" is always set. Move the assignment before issuing the _play
request.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676618
Some encoders (Arecont) do not like the long OPTIONS sent at startup as sent by
GStreamer, but do accept the short header as sent by Live555.
This patch makes the extending the request optional by adding a property
(short-header).
Fixes#655805.
API: GstRTSPSrc:short-header
... introduced when shuffling around code for the async implementation
by setting state of source (and udp sources) in _play before downstream
flushing is undone.
... since the TEARDOWN sequence might not have had a chance to even start,
but at least connections should be closed (synchronously) and state cleaned up.
See #632504.
Simplify the command handling; passing a command to thread means we really
want it to get the message, which means to always flush provided the command
can handle being interrupted. Command thread indicates whether command
allows interruption and ensure non-flushing connection as it subsequently
needs it.
In particular, this also makes the TEARDOWN sequence interruptable
and also prevents races where _loop_ could miss a command and would
continue receiving (or at least trying to).
See #632504.
With the async state changes, it is possible that we need to open the stream
before play and pause.
Also make sure we remember a previous open failure so that we don't keep trying
again.
Simplify the command handling, only continue looping when we have not received
another command or when the previous loop was successfull.
Avoid looping on a disconnected socket.
Parse session control attributes when no media control attribute is
present. Threat * control attributes as an empty string, just like the
spec says.
Fixes#646800
... by forcing a state changed to PLAYING, which should otherwise be a
no-op as elements should already be in that state.
In particular, jitterbuffer needs new base_time as soon as possible to perform
proper timing (e.g. eos timeout handling) and can't wait for the new base_time
that will be distributed when the whole pipeline returns to PLAYING.
See bug #646397.
