Goto error label checks stream to see if it needs to be unreferenced before
returning, but this goto jumps happens before the stream is ever set, so it
will always be NULL in this error label.
CID #1352034
Coverity demands for fallthrough statements to be clearly commented,
to distinguish from accidental fall throughs. And it also needs all
cases to finish with a break, even if the break is never going to be
executed like in the case of a continue jump.
CID #1352039
CID #1352040
Add an rtspclientsink element that accepts streams for which
there is a registered payloader and sends them to
an RTSP server using RECORD.
Sending is synchronised to the pipeline clock. Payload-types
are automatically selected. The 'new-payloader' signal is fired
for custom configuration of payloaders when they are created.
Can now stream a movie like this:
receiver:
./test-record "( decodebin name=depay0 ! videoconvert ! autovideosink \
decodebin name=depay1 ! audioconvert ! autoaudiosink )"
sender:
gst-launch-1.0 filesrc location=file-with-aac-and-h264.mp4 ! qtdemux name=d ! \
queue ! aacparse ! rtspclientsink location=rtsp://127.0.0.1:8554/test name=s \
https://bugzilla.gnome.org/show_bug.cgi?id=758180
Add a boolean to indicate that the rtsp-stream is running on the
'client' side of an RTSP connection, for sending streams via
RECORD. In that case, the roles of the client/server ports
in transport setup are swapped.
https://bugzilla.gnome.org/show_bug.cgi?id=758180
When RTSP server trying update transport during multicast, it throws an
assert. The assert is thrown because it is trying to get the parent of
an non-existing funnel element.
https://bugzilla.gnome.org/show_bug.cgi?id=760150
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
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.
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
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
Add "check-requirements" signal and vfunc to allow application
(and subclasses) to check the requirements.
Based on patch from Hyunjun Ko <zzoon.ko@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749417
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
When calling gst_rtsp_watch_write_data in gstrtspconnection.c and
backlog is empty it can happen that just a part of a message will be
sent and rest is in backlog queue. If then flush during teardown
just a part of message will be sent.This can lead to client miss
teardown response since it expect to get the last part of message.
The flushing during teardown was introduced to fix a deadlock that now
is fixed more generally in handle_request by temporary setting backlog
size to unlimited.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=749845
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>
The sdp framesize attribute is desribed in RFC6064. It is specified
for payloading of H263 and has the following form
a=framesize:<payload type> <width>-<height>. The <width>-<height> part
should be added to the caps in a payloader and the <payload type> should
be added by the rtsp-server.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=725334
Allow specifying the GType of a GstRtspMedia subclass to create
as a simpler way to get the factory to create a custom
GstRtspMedia sub-class, without subclassing GstRtspMediaFactory.
Changed RTSP session timeout handling to monotonic time
and deprecating the API for current system time.
This fixes timeouts when the system time changes.
https://bugzilla.gnome.org/show_bug.cgi?id=743346
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.
RTCP packets were not sent because the same tr_cache_cookie was used for
both RTP and RTCP. So only one of the tr_cache lists were populated
depending on which one was sent first. If the tr_cache list is not
populated then no packets can be sent. Most often this happened to be
RTCP. Now seperate RTCP and RTP transport cache cookies are added which
resulted in both the tr_cache_lists to be populated regardless of which
one was sent first.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=743734
RFC4566 Section 5.2 says that it should make the username, session id,
nettype, addrtype and unicast address tuple globally unique. Always using
1188340656180883 is not going to guarantee that: https://xkcd.com/221/
Instead let's create a 64 bit random number, which at least brings us
closer to the goal of global uniqueness.
https://tools.ietf.org/html/rfc4566#section-5.2
We add a trailing \0 in GstRTSPConnection to make parsing of
string message bodies easier (e.g. the SDP from DESCRIBE) but
for actual data this means we have to drop it or otherwise
create invalid data.
Fixes crash when two threads access handle_new_sample() at the same
time, one for RTP, one for RTCP.
Otherwise, when iterating over the transports cache, it might be modified by
another thread at the same time if the transports cookie has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=742954
This reverts commit 935e8f852d.
RFC 2326 states that session IDs may consist of alphanumeric as well as
the safe characters $-_.+ -- N.B. the percent character is not allowed.
Previously the session ID was URI-escaped, this meant that any character
which was not alphanumeric or any of the characters +-._~ would be
percent encoded. While the RFC (surprisingly) mentions that linear white
space in session IDs should be URI-escaped, it does not say anything
about other characters. Moreover no white space is allowed in the
session ID. Finally the percent character which is the result of
URI-escaping is not allowed in a session ID.
So there is no reason to do any URI-escaping, and now it is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=742869
rtsp-stream.c:1351:3: error: non-void function 'gst_rtsp_stream_get_retransmission_time' should return a value [-Wreturn-type]
g_return_if_fail (GST_IS_RTSP_STREAM (stream));
^
rtsp-stream.c:1384:3: error: non-void function 'gst_rtsp_stream_get_retransmission_pt' should return a value [-Wreturn-type]
g_return_if_fail (GST_IS_RTSP_STREAM (stream));
^
The default implementation of configure_client_transport() in
rtsp-client uses the session media when it chooses channels for
interleaved traffic.
https://bugzilla.gnome.org/show_bug.cgi?id=739112
If the media has been managed by a session media, it should not be
cached in the client any longer. The GstRTSPSessionMedia object is now
responsible for unpreparing the GstRTSPMedia object using
gst_rtsp_media_unprepare(). Unprepare the media when finalizing the
session media.
https://bugzilla.gnome.org/show_bug.cgi?id=739112
