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
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
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.
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.
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
We need to set session medias to NULL without the client lock otherwise
we can end up in a deadlock if another thread is waiting for the lock
and media unprepare is also waiting for that thread to end.
https://bugzilla.gnome.org/show_bug.cgi?id=737690
If the backlog limit is kept two cases of deadlocks may be
encountered when streaming over TCP. Without the backlog
limit this deadlocks can not happen, at the expence of
memory usage.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=737631
As long as gst-rtsp-server can successfully send RTP/RTCP data to
clients then the client must be reading. This change makes the server
timeout the connection if the client stops reading.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=736647
Allow the send backlog in the RTSP watch to grow to unlimited size while
attempting to bring the media pipeline to NULL due to a session
expiring. Without this change the appsink element cannot change state
because it is blocked while rendering data in the new_sample callback.
This callback will block until it has successfully put the data into the
send backlog. There is a chance that the send backlog is full at this
point which means that the callback may block for a long time, possibly
forever. Therefore the media pipeline may also be prevented from
changing state for a long time.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=736647
rtsp-client.c:2553:50: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
Just in case that guint8 doesn't fit in a pointer. Just in case ...
We need to raise the backlog limits before pausing the pipeline or else
the appsink might be blocking in the render method in wait_backlog() and
we would deadlock waiting for paused.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=736322
link/unlink of the transport in a session was done to keep track of all
TCP transports and to send RTP/RTCP data to the streams. We can simplify
that by putting all the TCP transports in a hashtable indexed with the
channel number.
We also don't need to link/unlink the transports when we pause/resume
the streams. The same effect is already achieved when we pause/play the
media. Indeed, when we pause the media, the transport is removed from
the media and the callbacks will not be called anymore.
See https://bugzilla.gnome.org/show_bug.cgi?id=736041
Fixes a crash when close() is called while merging clients
in handle_tunnel(). In that case close() would destroy the
watch while it is still being used in handle_tunnel().
https://bugzilla.gnome.org/show_bug.cgi?id=735570
Release the object lock before calling the filter functions. We need to
keep a cookie to detect when the list changed during the filter
callback. We also keep a hashtable to make sure we only call the filter
function once for each object in case of concurrent modification.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732950
This extra ref will be dropped when all client sessions have been
removed. A session is removed when a client sends teardown, closes its
endpoint of the TCP connection or the sessions expires.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732226
Once we manage a media in a session, we can't unmanage it anymore
without destroying it. Therefore, first check everything before we
manage the media, otherwise if something is wrong we have no way to
unmanage the media.
If we created a new session and something went wrong, remove the session
again. Fixes a leak in the unit test.
Don't just keep a weak ref to the session objects but use a hard ref. We
will be notified when a session is removed from the pool (expired) with
the new session-removed signal.
Don't automatically close the RTSP connection when all the sessions of
a client are removed, a client can continue to operate and it can create
a new session if it wants. If you want to remove the client from the
server, you have to use gst_rtsp_server_client_filter() now.
Based on patch from Ognyan Tonchev <ognyan.tonchev at axis.com>
See https://bugzilla.gnome.org/show_bug.cgi?id=732226
Add encryption and authentication key length parameters to MIKEY. For
the encoders, the key lengths are obtained from the cipher and auth
algorithms set in the caps. For the decoders, they are obtained while
parsing the key management from the client.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=730472
