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()
The error_full callback is similar to the error callback, but allows for
better error handling. For read errors a partial message is provided to
help an RTSP server generate a more correct error response, and for write
errors the write queue id of the failed message is returned.
Rewrote read_line() to support LWS (Line White Space), the method used by
RTSP (and HTTP) to break long lines. Also added support for \r and \n as
line endings (in addition to the official \r\n).
From RFC 2068 section 4.2: "Multiple message-header fields with the same
field-name may be present in a message if and only if the entire
field-value for that header field is defined as a comma-separated list
[i.e., #(values)]." This means that we should not split other headers which
may contain a comma, e.g., Range and Date.
Due to the odd syntax for WWW-Authenticate (and Proxy-Authenticate) which
allows commas both to separate between multiple challenges, and within the
challenges themself, we need to take some extra care to split these headers
correctly.
Do not abort message parsing as soon as there is an error. Instead parse
as much as possible to allow a server to return as meaningful an error as
possible.
Revert previous 'fix' for bug #588717 and fix it properly, whilst
maintaining the streamheader field on the output caps. Also make
sure we don't leak header buffers we couldn't push when downstream
is unlinked. Add unit test for the presence of the streamheader
field on the output caps and for the issue from bug #588717.
Remove any existing Session and Date headers before adding new ones
when sending a request. This may happen if the user of this code reuses
a request (rtspsrc does this when resending after authorization fails).
Do not use sizeof() on an array passed as an argument to a function and
expect to get anything but the size of a pointer. As a result only the
first 4 (or 8) bytes of the response buffer were initialized to 0 in
auth_digest_compute_response() which caused it to return a string which
was not NUL-terminated...
Before, SEEK events would be sent to the video sink, which wouldn't
be linked in any way to the subtitle part of the pipeline and
subparse would never see the SEEK event. This would then seek
the audio/video but the subtitles would continue from the old
position instead.
Fixes bug #591664.
The problem with an error message is, that it will stop playback completely
while it could be that only a audio decoder plugin is missing and the video
could be played with the available plugins.
See bug #591677.
Before we had STREAM/WRONG_TYPE but it's really CORE/MISSING_PLUGIN
because a plugin is missing and nothing else is wrong.
Also make it an error instead of a warning.
Really fixes bug #591677.
