- Nov 05, 2018
-
-
Matthew Waters authored
-
- Nov 01, 2018
-
-
Mathieu Duponchelle authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
It's needed by all kinds of other headers, including the ones that are required for defining the GstRTSPServer struct itself and its API.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
... by actually making it a single-include header and moving everything related to the GstRTSPServer type to rtsp-server-object.h instead. Otherwise there are too many circular includes. https://bugzilla.gnome.org/show_bug.cgi?id=797361
-
- Oct 23, 2018
-
-
When the underlying layers are running on_message_sent, this sometimes causes the underlying layer to send more data, which will cause the underlying layer to run callback on_message_sent again. This can go on and on. To break this chain, we introduce an idle source that takes care of sending data if there are more to send when running callback https://bugzilla.gnome.org/show_bug.cgi?id=797289
-
- Oct 22, 2018
-
-
Avoids ending up with races where a timeout would still be around *after* a client was gone. This could happen rather easily in RTSP-over-HTTP mode on a local connection, where each RTSP message would be sent as a different HTTP connection with the same tunnelid. If not properly removed, that timeout would then try to free again a client (and its contents).
-
- Oct 04, 2018
-
-
Tim-Philipp Müller authored
-
- Oct 03, 2018
-
-
...and thus do not let onvif affect pipelines latency https://bugzilla.gnome.org/show_bug.cgi?id=797174
-
- Sep 28, 2018
-
-
By default the multicast sockets are bound to INADDR_ANY, as it's not allowed to bind sockets to multicast addresses in Windows. This default behaviour can be changed by setting bind-mcast-address property on the media-factory object. https://bugzilla.gnome.org/show_bug.cgi?id=797059
- Sep 24, 2018
-
-
Tim-Philipp Müller authored
Export rtsp-server library API in headers when we're building the library itself, otherwise import the API from the headers. This fixes linker warnings on Windows when building with MSVC. Fix up some missing config.h includes when building the lib which is needed to get the export api define from config.h https://bugzilla.gnome.org/show_bug.cgi?id=797185
-
- Sep 19, 2018
-
-
This resulted in warnings/assertions whenever one accessed the max-mcast-ttl property. CID #1439515 CID #1439523
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Sep 01, 2018
-
-
Nirbheek Chauhan authored
This was somehow missed the last time around.
-
- Aug 31, 2018
-
-
Nirbheek Chauhan authored
Requires Meson 0.48, but the feature will be ignored on older versions so it's safe to add it without bumping the requirement. Documentation: https://github.com/mesonbuild/meson/blob/master/docs/markdown/Reference-manual.md#shared_library
-
Matthew Waters authored
-
- Aug 29, 2018
-
-
If a (strange) client would reuse interleaved channel numbers in multiple SETUP requests, we should not accept them. The channel numbers are used for looking up stream transports in the priv->transports hash table, and transports disappear from the table if channel numbers are reused. RFC 7826 (RTSP 2.0), Section 18.54, clarifies that it is OK for the server to change the channel numbers suggested by the client. https://bugzilla.gnome.org/show_bug.cgi?id=796988
-
Allow regex for matching transport header against expected pattern. https://bugzilla.gnome.org/show_bug.cgi?id=796988
-
- Aug 15, 2018
-
-
Nirbheek Chauhan authored
There is no installed version of that, only an uninstalled version.
-
- Aug 14, 2018
-
-
Sebastian Dröge authored
-
When media is shared, the same media stream can be sent to multiple multicast groups. Currently, there is no API to retrieve multicast addresses from the stream. When calling gst_rtsp_stream_get_multicast_address() function, only the first multicast address is returned. With this patch, each multicast destination requested in SETUP will be stored in an internal list (call to gst_rtsp_stream_add_multicast_client_address()). The list of multicast groups requested by the clients can be retrieved by calling gst_rtsp_stream_get_multicast_client_addresses(). There still exist some problems with the current implementation in the multicast case: 1) The receiving part is currently only configured with regard to the first multicast client (see https://bugzilla.gnome.org/show_bug.cgi?id=796917). 2) Secondly, of security reasons, some constraints should be put on the requested multicast destinations (see https://bugzilla.gnome.org/show_bug.cgi?id=796916). Change-Id: I6b060746e472a0734cc2fd828ffe4ea2956733ea https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
The maximum ttl value provided so far by the multicast clients will be chosen and reported in the response to the current client request. Change-Id: I5408646e3b5a0a224d907ae215bdea60c4f1905f https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
If "transport.client-settings" parameter is set to true, the client is allowed to specify destination, ports and ttl. There is no need for pre-configured address pool. Change-Id: I6ae578fb5164d78e8ec1e2ee82dc4eaacd0912d1 https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
When two multicast clients request specific transport configurations, and "transport.client-settings" parameter is set to true, it's wrong to actually require that these two clients request the same multicast group. Removed test_client_multicast_invalid_transport_specific test cases as they wrongly require that the requested destination address is supposed to be present in the address pool, also in the case when "transport.client-settings" parameter is set to true. Change-Id: I4580182ef35996caf644686d6139f72ec599c9fa https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
Change-Id: I5ef4758188c14785e17fb8fbf42a3dc0cb054233 https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
In dcb4533f , we made it so clients were dynamically added and removed to the multicast udp sinks, as such we should no longer add a first client in set_multicast_socket_for_udpsink https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
Sebastian Dröge authored
This reverts commit 33570944. Commits where accidentially squashed together
-
Sebastian Dröge authored
This reverts commit 7f0ae77e. Commits where accidentially squashed together
-
Sebastian Dröge authored
This reverts commit a9db3e7f. Commits where accidentially squashed together
-
Sebastian Dröge authored
This reverts commit 499e437e. Commits where accidentially squashed together
-
Sebastian Dröge authored
-
The maximum ttl value provided so far by the multicast clients will be chosen and reported in the response to the current client request. https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
If "transport.client-settings" parameter is set to true, the client is allowed to specify destination, ports and ttl. There is no need for pre-configured address pool. https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
In dcb4533f , we made it so clients were dynamically added and removed to the multicast udp sinks, as such we should no longer add a first client in set_multicast_socket_for_udpsink https://bugzilla.gnome.org/show_bug.cgi?id=793441
-
- Aug 06, 2018
-
-
Thibault Saunier authored
-