Add a limit to the amount of queued bytes or messages we allow on the watch.
API: GstRTSPConnection::gst_rtsp_watch_set_send_backlog()
API: GstRTSPConnection::gst_rtsp_watch_get_send_backlog()
return false from dispatch () if the read and write sockets have been
unset in tunnel_complete ()
Setting up HTTP tunnels causes segfaults since the watch for the second
connection is not destroyed anymore in tunnel_complete () and the connection
will still be used even though it is not valid anymore.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=686276
When closing the connection, unref the currently used sockets. This should close
them when not in use. We need to do this because else we cannot reconnect
anymore after a close, the connect function requires that the sockets are NULL.
Clear the GError after g_socket_connect tells us that the connection is pending.
If we don't do this, glib complains when we try to reuse the non-NULL GError
variable a little below.
Even if watch->messages->length is 0 there may still be some
data from a message that was only written partially at the
previous attempt stored in watch->write_data, so check for
that as well. We don't want to write data into the middle
of another message, which could happen when there wasn't
enough bandwidth.
https://bugzilla.gnome.org/show_bug.cgi?id=669039
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
Replace g_thread_create() with g_thread_try_new().
Unlike linux, OSX wakes up select with POLLOUT (instead of POLLERR) when
connect() is done async and the connection is refused. Therefore always check
for the socket error state using getsockopt (..., SO_ERROR, ...) after a
connection attempt.
When closing rtspsrc the state change blocks until the polling in the
connection timeouts. This is because the second time we loop to read a
full message controllable is set to FALSE in the poll group, even though no
message is half read.
This can be avoided by not setting controllable to FALSE the poll group
unless we had begin to read a message.
Fixes#610916
We want to send the keealive message a little earlier than the timeout value
specifies. Scale this based on the value of the timeout instead of just assuming
5 seconds.
Because we should act before the rtsp server does a timeout, we
reduce the timeout-time with 5 seconds, this should be safe to always
keep te rtsp connection alive.
https://bugzilla.gnome.org/show_bug.cgi?id=633455
Catch more socket errors.
Rework how sockets are managed in the GSource, wake up the maincontext instead
of adding/removing the sockets from the source.
Add callback for when the tunnel connection is lost. Some clients (Quicktime
Player) close the POST connection in tunneled mode and reopen the socket when
needed.
See #612915
Be careful when allocating the amount of bytes specified in the Content-Length
because it can be an insanely huge value. Try to allocate the memory but fail
gracefully with a nice error when the allocation failed.
Use send() instead of write() so that we can pass the MSG_NOSIGNAL flags to
avoid crashing with SIGPIPE when the remote end is not listening to us anymore.
Fixes#601772
gstrtspconnection.c:gst_rtsp_connection_receive() can hang when an error occured
on a socekt. Fix this problem by checking for error on 'other' socket after poll
return.
Fixes#596159
The new API to send messages using GstRTSPWatch will first try to send the
message immediately. Then, if that failed (or the message was not sent
fully), it will queue the remaining message for later delivery. This avoids
unnecessary context switches, and makes it possible to keep track of
whether the connection is blocked (the unblocking of the connection is
indicated by the reception of the message_sent signal).
This also deprecates the old API (gst_rtsp_watch_queue_data() and
gst_rtsp_watch_queue_message().)
API: gst_rtsp_watch_write_data()
API: gst_rtsp_watch_send_message()
With gst_rtsp_connection_set_http_mode() it is possible to tell the
connection whether to allow HTTP messages to be supported. By enabling HTTP
support the automatic HTTP tunnel support will also be disabled.
API: gst_rtsp_connection_set_http_mode()