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.
The sequence number is not monotonic for RTP packets after pause. The
reason is basepayloader generates a randon sequence number when the
pipeline goes from ready to pause. With this fix generation of sequence
number will be monotonic when going from pause to play request.
https://bugzilla.gnome.org/show_bug.cgi?id=736017
The RTCP parts, in specific the RTCP udpsinks, are not flushed when
seeking and will always continue counting the time. This leads to
the NPT after a backwards seek to be something completely different
to the actual seek position.
https://bugzilla.gnome.org/show_bug.cgi?id=732644
When we have too many messages queued for a client (currently hardcoded
to 100) we overflow and drop the messages. Add a drop-backlog property
to control this behaviour. Setting this property to FALSE will retry
to send the messages to the client by waiting for more room in the
backlog.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=725898
Set our state to UNPREPARING and release the state-lock before
setting the pipeline to the NULL state. This way, any pad-added
callback will be able to take the state-lock and check that we are now
unpreparing instead of deadlocking.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727102
If client supplied a range check if the range specifies the start point.
If not, then do an accurate seek to the current position. If a start
point was specified do do a key unit seek to make sure the streaming
starts with decodeable frames.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724611
in gst_rtsp_media_prepare() the thread is not used if media is already
prepared (e.g. media shared) so we want to stop the thread. otherwise, a
leak occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=724182
Only set the keyframe flag when we modify the start position. The
keyframe flag should probably be ignored when no change is requested but
until we can claim this is all documented properly and all demuxer
implement this, avoid setting the flag.
See also https://bugzilla.gnome.org/show_bug.cgi?id=723075
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
Start live streams in the blocked state and make them preroll using the
messages. This ensure that no data is played by the sink until we explicitly
unblock the stream right before going to PLAYING.
See https://bugzilla.gnome.org/show_bug.cgi?id=711257
* gst/rtsp-server/rtsp-media.c (gst_rtsp_media_set_state): if we are
trying to change to GST_STATE_NULL and media is in error status, we
remove all transports.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=712776
* gst/rtsp-server/rtsp-stream.c: add new method gst_rtsp_stream_get_pt.
* gst/rtsp-server/rtsp-media.c (pad_added_cb): find real payloader
element and create the stream with this one instead of the dynpay%d
element.
https://bugzilla.gnome.org/show_bug.cgi?id=712396
We should not depend on whether or not the pipeline state change
returned NO_PREROLL or not. A media could dynamically change its
element and switch from seekable to non seekable so it's best to test
the seekable nature of the pipeline dynamically when we try to do a seek.
Start the media pipeline in the provided context (or our default one
when NULL). This makes sure that we run the bus thread in this context and that
all media threads are children of this context.
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
