- Apr 10, 2019
-
-
Tim-Philipp Müller authored
-
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 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
-
- Jan 17, 2019
-
-
Tim-Philipp Müller authored
-
- Dec 06, 2018
-
-
In plug_src we changed the element state before adding it to the owner container. This prevented the pipeline from intercepting a GST_STREAM_STATUS_TYPE_CREATE message from the pad in order to assign a custom task pool. Fixes gstreamer/gst-rtsp-server#53
-
- Dec 05, 2018
-
-
Thibault Saunier authored
From ed78bee to 59cb678
-
- Nov 20, 2018
-
-
Ingo Randolf authored
-
-
- Nov 19, 2018
-
-
Media is considered to be blocked when all streams that belong to that media are blocked. This patch solves the problem of inconsistent updates of priv->blocked that are not synchronized with the media state.
-
Before the seek operation is performed on media, it's required that its pipeline is prepared <=> the pipeline is in the PAUSED state. At this stage, all transport parts (transport sinks) have been successfully added to the pipeline and there is no need for blocking the streams.
-
- Nov 17, 2018
-
-
Patricia Muscalu authored
-
- Nov 14, 2018
-
-
The sequence number in the rtpinfo is supposed to be the first RTP sequence number. The "seqnum" property on a payloader is supposed to be the number from the last processed RTP packet. The sequence number for payloaders that inherit gstrtpbasepayload will not be correct in case of buffer lists. In order to fix the seqnum property on the payloaders gst-rtsp-server must get the sequence number for rtpinfo elsewhere and "seqnum-offset" from the "stats" property contains the value of the very first RTP packet in a stream. The server will, however, try to look at the last simple in the sink element and only use properties on the payloader in case there no sink elements yet, and by looking at the last sample of the sink gives the server full control of which RTP packet it looks at. If the payloader does not have the "stats" property, "seqnum" is still used since "seqnum-offset" is only present in as part of "stats" and this is still an issue not solved with this patch. Needed for gst-plugins-base!17
-
Attaching a GSource to a context will increase the refcount. The idle source will never be free'd since the initial reference is never dropped.
-
- Nov 12, 2018
-
-
Jordan Petridіs authored
This commit adds a .gitlab-ci.yml file, which uses a feature to fetch the config from a centralized repository. The intent is to have all the gstreamer modules use the same configuration. The configuration is currently hosted at the gst-ci repository under the gitlab/ci_template.yml path. Part of gstreamer/gstreamer-project#29
-
- 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