When receiving a seek event, check whether we can actually seek based
on the information the server provided.
Also add more documentation on what the seekable field means
- Handle version negotation:
Added a `default-version` property so that the user can configure
what to use in case the server does not support version negotation
(which actually exist)
- Handle pipelined requests, which allow avoiding full round trip to
setup the RTP streams (request are sent in a raw, and response are
handled as they arrive).
- Handle the new Media-Properties header
- Handle the new Seek-Style header
- Handle the new Accept-Ranges header
Handling of IPV6 should already be OK.
We are still missing (at least) the following features (which do not
seem really mandatory as they require a "persistent connection between
server and client"):
- Server to Client TEARDOWN command (Not so usefull fmpov)
- PLAY_NOTIFY (not needed for our server yet)
- Support for the new REDIRECT features
and probably some more protocol changes might not be handled yet.
https://bugzilla.gnome.org/show_bug.cgi?id=781446
Timestamp offsets needs to be checked to detect unrealistic values
caused for example by NTP clocks not in sync. The new parameter
max-ts-offset lets the user decide an upper offset limit. There
are two different cases for checking the offset based on if
ntp-sync is used or not:
1) ntp-sync enabled
Only negative offsest are allowed since a positive offset would
mean that the sender and receiver clocks are not in sync.
Default vaule of max-ts-offset = 0 (disabled)
2) ntp-sync disabled
Both positive and negative offsets are allowed.
Default vaule of max-ts-offset = 3000000000
The reason for different default values is to be backwards
compatible.
https://bugzilla.gnome.org/show_bug.cgi?id=785733
Instant large changes to ts_offset may cause timestamps to move
backwards and also cause visible effects in media playback. The new
option max-ts-offset-adjustment lets the application control the rate to
apply changes to ts_offset.
https://bugzilla.gnome.org/show_bug.cgi?id=784002
We currently send data to the RTSP connection from multiple threads:
whenever a command is to be handled and whenever RTCP is generated. This
can cause data corruption or worse if both happen at the same time.
As such, protect gst_rtsp_connection_send() and gst_rtsp_connection_receive()
calls with a mutex. While this means that we hold a mutex during the IO
operation, this is not actually a problem as the IO operation can be
interrupted (gst_rtsp_connection_flush()) at any time and is blocking by
itself anyway.
We only changed them for UDP so far, which caused the wrong seqnum-base and
other information to be passed to rtpjitterbuffer/etc when seeking. This
usually wasn't that much of a problem as the code there is robust enough, but
every now and then it causes us to drop up to 32756 packets before we
continue doing anything meaningful.
https://bugzilla.gnome.org/show_bug.cgi?id=765689
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
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
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
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
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.
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.
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.
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.
* 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
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
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
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.
