SDP are now provided *before* the pipeline is fully complete. In order
to know whether a media is seekable or not therefore requires asking
the invididual streams.
API: gst_rtsp_stream_seekable
https://bugzilla.gnome.org/show_bug.cgi?id=790674
There is not need of adding fakesink elements to the media
pipeline in the dynamic-payloader case.
The media pipeline itself is dynamically updated with
the receiver and sender parts that are based on the client
transport information known after SETUP has been received.
Change-Id: I4e88c9b500c04030669822f0d03b1842913f6cb9
https://bugzilla.gnome.org/show_bug.cgi?id=790674
Media is complete when all the transport based parts are
added to the media pipeline. At this point ASYNC_DONE is
posted by the media pipeline and media is ready to enter
the PREPARED state.
Change-Id: I50fb8dfed88ebaf057d9a35fca2d7f0a70e9d1fa
https://bugzilla.gnome.org/show_bug.cgi?id=790674
If we still have some dynamic paylaoders which haven't posted
no-more-pads yet, don't go to PREPARED if one of the streams
blocked.
The risk was that we would end up not exposing/using all specified
streams.
The downside is that if you have _multiple_ _live_ _dynamic_ payloaders
then it will take a bit more time to start. But only if those 3
conditions are present.
https://bugzilla.gnome.org/show_bug.cgi?id=769521
If we have more than one dynamic payloader in the pipeline, we need
to wait until the *last* one emits 'no-more-pads' before switching
to PREPARED.
Failure to do so would result in a race where some of the streams
wouldn't properly be prepared
https://bugzilla.gnome.org/show_bug.cgi?id=769521
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
Deferred calls to start_prepare() can be deferred past the point until
which wait_preroll() and by proxy gst_rtsp_media_get_status() is
prepared to wait. Previously there was no lock and no check for this
situation. This meant that a media could be prepared and unprepared
simultaneously by two different threads. Now a lock is in place and a
suitable check is done.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=759773
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
default_prepare() takes a transfer-none reference GstRTSPMedia object.
Later on a g_idle_source_new() is created and a pointer to the media
object is passed as user data. If the media is freed before the idle
source is dispatched the media object pointer is invalid, but the idle
source callback expects it to still be valid. To fix this a reference to
the media object is taken when registering the source callback function
and a corresponding release of the reference is done when the souce is
destroyed.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=755748
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).
https://bugzilla.gnome.org/show_bug.cgi?id=754753
Add gst_rtsp_stream_(get|set)_buffer_size and use it to configure the
UDP TX buffer size.
Incorporates a patch by Hyunjun Ko <zzoon.ko@samsung.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=749095
The intention is to prevent going PLAYING state before pads are created.
If there was mutilple dynamic payload, it would leak few fakesink and
actually prevent from ever reaching playing state.
https://bugzilla.gnome.org/show_bug.cgi?id=753385
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
A bin that contains the real payloader might be used as payloader. In this
case we have to get the real payloader for the various properties it provides.
Example use cases for this are bins that payload some media and then have
additional elements that add metadata or RTP extension headers to the stream.
https://bugzilla.gnome.org/show_bug.cgi?id=750800
Because of duplicated g_signal_connect for request-aux-sender signal,
wrong stream pointer is passed to the signal handler.
Instead of passing each stream, pass stream array and get the relevant stream.
https://bugzilla.gnome.org/show_bug.cgi?id=747839
When the sdp media attribute framesize are converted to caps
the <payload> should not be included.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=725335
Based on the patch for rtspsrc by Linus Svensson <linussn@axis.com>
If the media was just not seekable, we continue from whatever position we are
and let the client decide if that is what is wanted or not.
Only if the actual seek failed, we can't really recover and should error out.
Fix the logic of gst_rtsp_media_collect_streams() so after looping collecting
all streams it knows if it got any, and can check if the transport mode is OK.
CID #1268400
Just print a warning if the one that was set before disagrees with what
elements we found. It must already be set to something before as this
function is called after we received the SDP from ANNOUNCE in RECORD mode,
and we would reject ANNOUNCE if the RECORD flag was not set.
