- Oct 21, 2020
-
-
Tim-Philipp Müller authored
-
- Oct 20, 2020
-
-
Tim-Philipp Müller authored
For some reason libtool would pull in the wrong libgstapp version from the system if we don't specify this rtsp-server internal dep explicitly. Unclear why this happens, but should be fine to brute force it. Also fix some ordering issues. Part-of: <gstreamer/gst-rtsp-server!165>
-
Tim-Philipp Müller authored
From 59cb678 to a825d27
-
- Sep 25, 2020
-
-
This causes them to send caps events before data flow, which is usually a pretty correct thing to do! Not doing so manifested in a bug where ssrcdemux wouldn't forward the caps it had received with an extra ssrc field, as it hadn't received any caps event. Fixes #85 Part-of: <gstreamer/gst-rtsp-server!153>
-
- Sep 24, 2020
-
-
Otherwise no sink is found for multicast sreams and the less accurate fallback is used to determine the current sequence number and timestamp. Part-of: <gstreamer/gst-rtsp-server!152>
-
- Sep 21, 2020
-
-
Sebastian Dröge authored
Without this we can easily run into a race condition with async state changes: - the pipeline is doing an async state change - we set the internal bins to PLAYING but that's ignored because an async state change is currently pending - the async state change finishes but does not change the state of the internal bins because of locked_state==TRUE - the internal bins stay in PAUSED forever Part-of: <gstreamer/gst-rtsp-server!151>
-
- Jun 06, 2020
-
-
When using the basic authentication scheme, we wouldn't validate that the authorization field of the credentials is not NULL and pass it on to g_hash_table_lookup(). g_str_hash() however is not NULL-safe and will dereference the NULL pointer and crash. A specially crafted (read: invalid) RTSP header can cause this to happen. As a solution, check for the authorization to be not NULL before continuing processing it and if it is simply fail authentication. This fixes CVE-2020-6095 and TALOS-2020-1018. Discovered by Peter Wang of Cisco ASIG.
-
- Feb 04, 2020
-
-
from glib ``` Deprecated: 2.58: Use %G_ADD_PRIVATE and the generated `your_type_get_instance_private()` function instead ```
-
- Dec 13, 2019
-
-
- Dec 03, 2019
-
-
Tim-Philipp Müller authored
-
- Nov 12, 2019
-
-
(cherry picked from commit f1d2a0ca)
-
- Nov 11, 2019
-
-
Change condition that should be fulfilled regarding RTPInfo. Replace !gst_rtsp_media_is_receive_only with gst_rtsp_media_has_completed_sender. It is more correct to actually look for a sender pipeline that is complete. Only then a RTPInfo should exist. gst_rtsp_media_is_receive_only gives different answears depending on state of server. If Describe is called wth URL+options for backchannel SDP will give only audio and only backchannel a=sendonly If Describe is called on URL+options that gives both audio and video direction from server to client, pipelines are created. Thus receive_only will return false, even though Setup only would setup backchannel. RTP-Info is only for outgoing streams. Thus one should look if outgoing streams are complete.
-
- Oct 17, 2019
-
-
Instead of hardcoding the URI, take the actual URI (and especially the correct port) from the RTSP context. Fixes #84
-
- Sep 23, 2019
-
-
Tim-Philipp Müller authored
-
- Sep 08, 2019
-
-
If RTP Info is missing. Then return GST_RTSP_STS_INTERNAL_SERVER_ERROR Fixes #76
-
- Aug 06, 2019
-
-
Tim-Philipp Müller authored
-
-
-
-
- May 02, 2019
-
-
Tim-Philipp Müller authored
-
- Apr 18, 2019
-
-
Tim-Philipp Müller authored
-
- Apr 15, 2019
-
-
Otherwise it will never try to send us the next one: it tries to keep exactly one message in-flight all the time. In gst-rtsp-server this is done asynchronously via the GstRTSPWatch but in the client sink we always write data out synchronously.
-
- Apr 11, 2019
-
-
Göran Jönsson authored
If not waiting for free thread pool before clean transport caches, there can be a crash if a thread is executing in transport list loop in function send_tcp_message. Also add a check if priv->send_pool in on_message_sent to avoid that a new thread is pushed during wait of free thread pool. This is possible since when waiting for free thread pool mutex have to be unlocked.
-
- Apr 10, 2019
-
-
Follow-up to !198
- Mar 27, 2019
-
-
Erlend Eriksen authored
-
- Mar 23, 2019
-
-
Tim-Philipp Müller authored
This suppresses the annoying 'g-ir-scanner: link: cc ..' output that we get even if everything works just fine. We still get g-ir-scanner warnings and compiler warnings if we pass this option.
-
Tim-Philipp Müller authored
We need a nested extern in our init section for the scanner binary so we can call gst_init to make sure GStreamer types are initialised (they are not all lazy init via get_type functions, but some are in exported variables). There doesn't seem to be any other mechanism to achieve this, so just remove that warning, it's not important at all.
-
- Mar 21, 2019
-
-
Tim-Philipp Müller authored
-
- Mar 20, 2019
-
-
Göran Jönsson authored
Handle the situation when a call to gst_rtsp_media_set_state is done when media status is preparing. Also add unit test for this scenario. The unit test simulate on a media level when two clients share a (live) media. Both clients have done SETUP and got responses. Now client 1 is doing play and client 2 is just closing the connection. Then without patch there are a problem when client1 is calling gst_rtsp_media_unsuspend in handle_play_request. And client2 is doing closing connection we can end up in a call to gst_rtsp_media_set_state when priv->status == GST_RTSP_MEDIA_STATUS_PREPARING and all the logic for shut down media is jumped over . With this patch and this scenario we wait until priv->status == GST_RTSP_MEDIA_STATUS_PREPARED and then continue to execute after that and now we will execute the logic for shut down media.
-
- Mar 04, 2019
-
-
Tim-Philipp Müller authored
-
- Feb 26, 2019
-
-
Tim-Philipp Müller authored
-
- Feb 19, 2019
-
-
Göran Jönsson authored
Use case client 1: SETUP client 1: PLAY client 2: SETUP client 1: TEARDOWN client 2: PLAY client 2: TEARDOWN
-
- Feb 02, 2019
-
-
Introduce a threadpool to send rtp and rtcp to avoid recursive behavior.
-
- Jan 30, 2019
-
-
Sebastian Dröge authored
And route all messages through the send_func if no send_messages_func was provided. We otherwise break backwards compatibility.
-
Sebastian Dröge authored
Fixes gstreamer/gst-rtsp-server#29
-
Sebastian Dröge authored
This adds new functions for passing buffer lists through the different layers without breaking API/ABI, and enables the appsink to actually provide buffer lists. This should already reduce CPU usage and potentially context switches a bit by passing a whole buffer list from the appsink instead of individual buffers. As a next step it would be necessary to a) Add support for a vector of data for the GstRTSPMessage body b) Add support for sending multiple messages at once to the GstRTSPWatch and let it be handled internally c) Adding API to GOutputStream that works like writev() Fixes gstreamer/gst-rtsp-server#29
-
- Jan 29, 2019
-
-
The close handler could trigger a crash because it invalidated the watch_context while still leaving a source attached to it which would be cleaned up at a later point.
-
If an address/port was previously decided upon (ex: multicast in the SDP), then use that instead of re-creating another one Fixes gstreamer/gst-rtsp-server#57
-
- Jan 25, 2019
-
-
The previous fix for race condition around finish_unprepare where the function could be called twice assumed that the status wouldn't change during execution of the function. This assumption is incorrect as the state may change, for example if an error message arrives from the pipeline bus. Instead a flag keeping track on whether the finish_unprepare function is currently executing is introduced and checked. Fixes gstreamer/gst-rtsp-server#59
-