SETUP request from clients needs to suspend the media to clear the
prerolled buffers. Otherwise it will not affect the prerolled buffer
and the prerolled buffers will be incorrect (for example block-size
from setup request will not affect the prerolled buffer unless the
media is suspended).
https://bugzilla.gnome.org/show_bug.cgi?id=758268
Based on the protocol, create the rtsp stream pipeline. If only TCP or
only UDP is set as the transport protocol, it will not add the extra tee
or queue element to the pipeline. Both these elements will be added, if
it supports both TCP and UDP protocols. This improves the pipeline
performance when one protocol is present.
https://bugzilla.gnome.org/show_bug.cgi?id=758179
Adding them when not needed will start some logic inside rtpbin that might be
problematic. Also if e.g. for a sender media we suddenly receive RTP data, we
would start up a rtpjitterbuffer and behave in weird ways.
We still set up the UDP sources for RTP receiving for a sender media to be
able to receive any packets sent by the client for NAT traversal. They will
all go to a fakesink though.
Having an rtpjitterbuffer in the media pipeline will cause the pipeline to be
NO_PREROLL, which will cause deadlocks when seeking the media as it will never
receive ASYNC_DONE after a seek.
https://bugzilla.gnome.org/show_bug.cgi?id=758319
On POSIX this setting is for sender sockets, on Windows for receiver sockets.
Previously we were only setting this for sender sockets, which caused looped
back packets to be received on Windows if a multicast transport was used.
There's a comment on one of the resources that 'user' and 'admin'
shouldn't even be able to see it, but they can if the default
token is 'admin2', since that gives them access anyway.
When doing a port scan (e.g. with nmap) the call to GST_RTSP_CHECK()
will sometimes fail. This call is made before any context is pushed
resulting in an attempt to pop a NULL context.
https://bugzilla.gnome.org/show_bug.cgi?id=757949
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
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753863
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
