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
