The initial pipeline does not contain specific transport
elements. The receiver and the sender parts are added
after PLAY.
If the media is shared, the streams are dynamically
reconfigured after each PLAY.
https://bugzilla.gnome.org/show_bug.cgi?id=788340
This adds basic support for new 2.0 features, though the protocol is
subposdely backward incompatible, most semantics are the sames.
This commit adds:
- features:
* version negotiation
* pipelined requests support
* Media-Properties support
* Accept-Ranges support
- APIs:
* gst_rtsp_media_seekable
The RTSP methods that have been removed when using 2.0 now return
BAD_REQUEST.
https://bugzilla.gnome.org/show_bug.cgi?id=781446
For NTP and PTP clocks we signal the actual clock that is used and signal
the direct media clock offset.
For all other clocks we at least signal that it's the local sender clock.
This allows receivers to know which clock was used to generate the media and
its RTP timestamps. Receivers can then implement network synchronization,
either absolute or at least relative by getting the sender clock rate directly
via NTP/PTP instead of estimating it from RTP timestamps and packet receive
times.
https://bugzilla.gnome.org/show_bug.cgi?id=760005
Without TEARDOWN it might be desireable to keep the media running and continue
sending data to the client, even if the RTSP connection itself is
disconnected.
Only do this for session medias that have only UDP transports. If there's at
least on TCP transport, it will stop working and cause problems when the
connection is disconnected.
https://bugzilla.gnome.org/show_bug.cgi?id=758999
Add support for different suspend modes. The stream is suspended right after
producing the SDP and after PAUSE. Different suspend modes are available that
affect the state of the pipeline. NONE leaves the pipeline state unchanged and
is the current and old behaviour, PAUSE will set the pipeline to the PAUSED
state and RESET will bring the pipeline to the NULL state.
A stream is also unsuspended when it goes back to PLAYING, for RESET streams,
this means that the pipeline needs to be prerolled again.
Base on patches by Ognyan Tonchev <ognyan@axis.com>
See https://bugzilla.gnome.org/show_bug.cgi?id=711257
Remove the auth object from media and factory. We want to have the RTSPClient
authenticate and authorize resources, there is no need to place another auth
manager on the media/factory.
get_range_times worked for handling UTC ranges for seeks, but we also
need to convert back from NPT to the requested unit in
get_range_string. convert_range is now used for both.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702084
Make it possible to override the conversion from GstRTSPTimeRange to
GstClockTimes, that is done before seeking on the media
pipeline. Overriding can be useful for UTC ranges, where the default
conversion gives nanoseconds since 1900.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701191
Listen to the pad-removed signal and remove the stream associated with the
removed pad.
Add signal to be notified of the removed pad.
Remove the fakesink in unprepare()
Fix signatures of the signal methods
Together with a shared clock, this base-time could eventually be sent to
the client so that it can reconstruct the exact running-time of the clock
on the server.
Add a property to let the media provide a GstNetTimeProvider for its clock.
Make methods to get the clock and nettimeprovider
Add a x-gst-clock property to the SDP with the IP and port number of the nettime
provider and also the current time of the clock. This should make it possible
for (GStreamer) clients to slave their clock to the server clock.
