The server can send multiple crypto sessions, one for each SSRC with its
own rollover counter. We parse this information and pass it to the SRTP
decoder via the "request-key" signal.
https://bugzilla.gnome.org/show_bug.cgi?id=730540
Leverage response from gst_rtsp_connection_connect_with_response to
determine if the connection should be retried using authentication. If
so, add the appropriate authentication headers based upon the response
and retry the connection.
https://bugzilla.gnome.org/show_bug.cgi?id=749596
The string could exist but with a wrong format, in that case we still want
to reset the values of client_port_range.min and max like we do if there is
no string.
CID 1139593
In parse_keymgmt(), don't mutate the input string that's been passed
as const, especially since we might need the original value again if
the same key info applies to multiple streams (RTX, for example).
When a resource is 404, and we have auth info - retry with the auth
info the same as if we had receive unauthorised, in case the resource
isn't even visible until credentials are supplied.
Fix a memory leak handling Mikey data.
When generating a random keystring, don't overrun the 30 byte
buffer by generating 32 bytes into it.
Sometimes it is useful to know this information on the
server side. Other popular implementations (vlc, ffmpeg, ...)
also send this header on every message.
This includes a new "user-agent" property that the user
can set to use a custom User-Agent string. The default
is "GStreamer/<version>"
https://bugzilla.gnome.org/show_bug.cgi?id=750101
In media to caps function, reserved_keys array is being used for variable i,
leading to GLib-CRITICAL **: g_ascii_strcasecmp: assertion 's1 != NULL' failed
changed it to variable j
https://bugzilla.gnome.org/show_bug.cgi?id=753009
Skip keys from the fmtp, which we already use ourselves for the
caps. Some software is adding random things like clock-rate into
the fmtp, and we would otherwise here set a string-typed clock-rate
in the caps... and thus fail to create valid RTP caps
https://bugzilla.gnome.org/show_bug.cgi?id=753009
It is expected that buffers are time-stamped with running time. Set
a segment accordingly. In this case we pick 0,-1 as this is what udpsrc
would do. Depayloaders will update the segment to reflect the playback
position.
https://bugzilla.gnome.org/show_bug.cgi?id=635701
The segment start/stop in the query is meant to represent the seekable
portion of the stream. It does not match the segment start/stop. Instead
export 0 to duration.
We need to set up the transport in any case, not just if we have a container
stream or a non-interleaved stream. Only if we have an interleaved stream and
are retrying, we should not set up the stream again.
https://bugzilla.gnome.org/show_bug.cgi?id=745599
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
