By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
Body_offset mean that so much data have been written.
Without this patch n_vectors somtimes becomes one more than it should
and then there will be an vector that have a random size causing
writev_bytes to cause a "Bad address" error.
RFC 7826 recommends (but does not require) starting at 0,
but at least one known server implementation fails to copy
request sequence numbers <1 into responses due to an
incorrect null check.
The server known to exhibit this behavior is the Parrot
Streaming Server, serving video from their UAV devices.
A fix has been submitted upstream as well:
https://github.com/Parrot-Developers/librtsp/pull/2
The Parrot developers are known to have tested with LibVLC.
In WireShark debugging, LibVLC appears to start with a CSeq
of 2, which is likely why this bug went unnoticed.
This reverts 487595a7d6, which set this to 0 citing the
RFC. The switch to 0 was thus a recent one; it's therefore
possible server implementors relied on the previous
GStreamer client behavior in their tests as well.
Fixes#624.
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means we
no longer need the macro there, but for most types in base/gst-libs we
don't want to break ABI, which means it's better to just keep it like it
is (and use the `#ifdef` instead).
Add the possible to limit the Content-Length
Define an appropriate request size limit and reject requests exceeding
the limit (413 Request Entity Too Large)
Make rtspconnection a little more strict to RFC2326.
Make sure that CSeq is in every RTSP message and that CSeq is valid.
Also break the build_next loop if any parsing fails, By acting on
the builder->status code.
The former code allowed an attacker to create a heap overflow by
sending a longer than allowed session id in a response and including a
semicolon to change the maximum length. With this change, the parser
will never go beyond 512 bytes.
The function fill_bytes could sometimes return a value greater than zero
and in the same time set the GError.
Function read_bytes calls fill_bytes in a while loop. In the special
case above it would call fill_bytes with error already set.
Thus resulting in "GError set over the top of a previous GError".
Solved this by clearing GError when return value is greater than zero.
Actions are taken depending on error type by caller of read_bytes. Eg.
with EWOULDBLOCK gst_rtsp_source_dispatch_read will try to read the
missing bytes again (GST_RTSP_EINTR )
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/445
gstrtspconnection.c: In function ‘writev_bytes’:
gstrtspconnection.c:1348:10: error: ‘res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return res;
^
Otherwise we would return EOF if nothing was written in any case, even
if this was actually a case of TIMEOUT or EWOULDBLOCK for example.
Thanks to Edward Hervey for debugging and finding this issue.
Fixes 2 problems:
1) Number of unmapped memories does not always match number of mmaped ones in
dispatch_write().
2) When dispatch_write() is dispatched second time after an incomplete write,
already set offsets will not be taken into account, thus corrupt RTP data will
be sent.
This makes it unnecessary for callers to first merge together all
memories, and it allows API like GstRTSPConnection to write them out
without first copying all memories together or using writev()-style API
to write multiple memories out in one go.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/370
gst_rtsp_connection_send() adds the Authorization header to the request.
If this function is being called multiple times with the same request
it will add one more Authorization header every time.
To fix to this issue do not append a new Authorization header on
top of an existing ones. Remove any existing Authorization headers first
and then add the new one.
Fixes gst-plugins-good#425
rtsp_connection_send takes care of adding those already,
and some reverse proxies such as nginx will reject the request
altogether if the Authorization header is present twice,
even with the same value.
https://bugzilla.gnome.org/show_bug.cgi?id=797272
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
While we're at it, add new GST_API_EXPORT in config.h and use
that for GST_*_API decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
Function body must only be removed if compiling with
GST_REMOVE_DEPRECATED. Function declaration must not
be skipped if GST_DISABLE_DEPRECATED is defined, since
it contains our export decorator and we wouldn't export
the symbol as public API any more then since we compile
with GST_DISABLE_DEPRECATED.
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
When the GstRTSPConnection class sends a RTSP over HTTP tunnelling
request, the HTTP Content-Type header is missing from the HTTP POST
request.
This isn't a problem with most servers, but there are servers that
rejects the request without there also being a Content-Type header.
RFC 1945:
Any HTTP/1.0 message containing an entity body should include a
Content-Type header field defining the media type of that body.
Apple Dispatch 28:
QuickTime Streaming uses the "application/x-rtsp-tunnelled" MIME
type in both the Content-Type and Accept headers. This reflects
the data type that is expected and delivered by the client and server.
https://bugzilla.gnome.org/show_bug.cgi?id=793110
Registering GstRTSPMessage as a boxed type allows it to be conveniently
used as an argument to signals, a-la GstSDPMessage, and general usage
from bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=762884
Properly handle protocol version in the connection
Add the following headers types:
* Pipelined-Request
* Media-Properties
* Seek-Style
* Accept-Ranges
https://bugzilla.gnome.org/show_bug.cgi?id=781446
