Use case
client 1: SETUP
client 1: PLAY
client 2: SETUP
client 1: TEARDOWN
client 2: PLAY
client 2: TEARDOWN

Göran Jönsson authored 5 years ago and Sebastian Dröge committed 5 years ago

Introduce a threadpool to send rtp and rtcp to avoid recursive behavior.

And route all messages through the send_func if no send_messages_func
was provided.

We otherwise break backwards compatibility.

Fixes gst-rtsp-server#29

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

Benjamin Berg authored 6 years ago and Tim-Philipp Müller committed 5 years ago

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.

Edward Hervey authored 5 years ago and Edward Hervey committed 5 years ago

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

Lars Wireen authored 6 years ago and Sebastian Dröge committed 5 years ago

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

Patricia Muscalu authored 6 years ago and Sebastian Dröge committed 6 years ago

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

From ed78bee to 59cb678

Patricia Muscalu authored 6 years ago and Sebastian Dröge committed 6 years ago

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.

Patricia Muscalu authored 6 years ago and Sebastian Dröge committed 6 years ago

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.

Linus Svensson authored 6 years ago and Sebastian Dröge committed 6 years ago

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

Linus Svensson authored 6 years ago and Sebastian Dröge committed 6 years ago

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.

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

It's needed by all kinds of other headers, including the ones that are
required for defining the GstRTSPServer struct itself and its API.

... 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

Göran Jönsson authored 6 years ago and Sebastian Dröge committed 6 years ago

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

Edward Hervey authored 6 years ago and Edward Hervey committed 6 years ago

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).

Ognyan Tonchev authored 6 years ago and Sebastian Dröge committed 6 years ago

...and thus do not let onvif affect pipelines latency

https://bugzilla.gnome.org/show_bug.cgi?id=797174

Patricia Muscalu authored 6 years ago and Sebastian Dröge committed 6 years ago

https://bugzilla.gnome.org/show_bug.cgi?id=797059

Patricia Muscalu authored 6 years ago and Sebastian Dröge committed 6 years ago

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

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

Edward Hervey authored 6 years ago and Edward Hervey committed 6 years ago

This resulted in warnings/assertions whenever one accessed the
max-mcast-ttl property.

CID #1439515
CID #1439523

This was somehow missed the last time around.

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