Otherwise we will get not-negotiated later from rtpbin, and will never be able
to send RTCP packets back to the server. Note that error flow returns from the
RTCP pads are ignored, that's why it didn't fail more visible before.
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
