Release 1.15.2

rtsp-media: Fix multicast use case with common media

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

rtsp-server: remove recursive behavior

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

rtsp-client: Only allow to set either a send_func or send_messages_func but not both

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

We otherwise break backwards compatibility.

rtsp-client: Add support for sending buffer lists directly

Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/29

rtsp-server: Add support for buffer lists

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 https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/29

client: Fix crash in close handler

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.

rtsp-stream: Use cached address when allocating sockets

If an address/port was previously decided upon (ex: multicast in the
SDP), then use that instead of re-creating another one

Fixes https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/57

rtsp-media: Fix race codition in finish_unprepare

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 https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/59

Release 1.15.1

Add source elements to the pipeline before activation

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 https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/53

Automatic update of common submodule

From ed78bee to 59cb678

examples: test-appsrc: fix coding style error

examples: test-appsrc: fix buffer leak

rtsp-media: Update priv->blocked when linked streams are unblocked.

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.

rtsp-media: Don't block streams before seeking

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.

tests: rtspserver: Add shared media test case for TCP

rtsp-stream: Use seqnum-offset for rtpinfo

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

rtsp-stream: Plug memory leak

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.

Add Gitlab CI configuration

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 https://gitlab.freedesktop.org/gstreamer/gstreamer-project/issues/29

Update git locations to gitlab

meson: add new onvif types

Add ONVIF subclass headers to the installed headers in meson.build too

rtsp-server: Declare GstRTSPServer struct before anything else

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

Mark all ONVIF-specific subclasses as Since 1.14

Include ONVIF types from single-include rtsp-server.h

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

rtsp-stream: use idle source in on_message_sent

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

rtsp-client: Remove timeout GSource on cleanup

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

autotools: fix distcheck

onvif: encapsulate onvif part into a bin

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

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

tests: client: Avoid bind() failures in tests

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

New property for socket binding to mcast addresses

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

libs: fix API export/import and 'inconsistent linkage' on MSVC

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

rtsp-media-factory: Add missing break statements

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

CID #1439515
CID #1439523

meson: add gobject-cast-checks, glib-asserts, glib-checks options

meson: add option to disable build of rtspclientsink plugin

meson: re-arrange options

meson: Use feature option for tests option

This was somehow missed the last time around.

meson: Maintain macOS ABI through dylib versioning

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

meson: add pkg-config file for the rtspclientsink plugin

rtsp-client: Avoid reuse of channel numbers for interleaved

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

rtsp-client: Add unit test of SETUP for RTSP/RTP/TCP

Allow regex for matching transport header against expected pattern.

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

meson: There is no gstreamer-plugins-good-1.0.pc

There is no installed version of that, only an uninstalled version.

Fix indentation again

stream: Added a list of multicast client addresses

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

stream: Choose the maximum ttl value provided by multicast clients

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

rtsp-stream: Don't require address pool in the transport specific case

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

client: Don't reserve multicast address in the client setting case

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

Add new API for setting/getting maximum multicast ttl value

Change-Id: I5ef4758188c14785e17fb8fbf42a3dc0cb054233

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

rtsp-stream: avoid duplicating the first multicast client

In dcb4533fedae3ac62bc25a916eb95927b7d69aec , 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

Revert "rtsp-stream: avoid duplicating the first multicast client"

This reverts commit 33570944401747f44d8ebfec535350651413fb92.

Commits where accidentially squashed together

Revert "Add new API for setting/getting maximum multicast ttl value"

This reverts commit 7f0ae77e400fb8a0462a76a5dd2e63e12c4a2e52.

Commits where accidentially squashed together

Revert "rtsp-stream: Don't require address pool in the transport specific case"

This reverts commit a9db3e7f092cfeb5475e9aa24b1e91906c141d52.

Commits where accidentially squashed together

Revert "stream: Choose the maximum ttl value provided by multicast clients"

This reverts commit 499e437e501215849d24cdaa157e0edf4de097d0.

Commits where accidentially squashed together

examples: Fix indentation

stream: Choose the maximum ttl value provided by multicast clients

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

rtsp-stream: Don't require address pool in the transport specific case

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

Add new API for setting/getting maximum multicast ttl value

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

rtsp-stream: avoid duplicating the first multicast client

In dcb4533fedae3ac62bc25a916eb95927b7d69aec , 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

rtsp-server: Add gstreamer-base gir dir in autotools

rtsp-client: always allocate both IPV4 and IPV6 sockets

multiudpsink does not support setting the socket* properties
after it has started, which meant that rtsp-server could no
longer serve on both IPV4 and IPV6 sockets since the patches
from https://bugzilla.gnome.org/show_bug.cgi?id=757488 were
merged.

When first connecting an IPV6 client then an IPV4 client,
multiudpsink fell back to using the IPV6 socket.

When first connecting an IPV4 client, then an IPV6 client,
multiudpsink errored out, released the IPV4 socket, then
crashed when trying to send a message on NULL nevertheless,
that is however a separate issue.

This could probably be fixed by handling the setting of
sockets in multiudpsink after it has started, that will
however be a much more significant effort.

For now, this commit simply partially reverts the behaviour
of rtsp-stream: it will continue to only create the udpsinks
when needed, as was the case since the patches were merged,
it will however when creating them, always allocate both
sockets and set them on the sink before it starts, as was
the case prior to the patches.

Transport configuration will only error out if the allocation
of UDP sockets fails for the actual client's family, this
also downgrades the GST_ERRORs in alloc_ports_one_family
to GST_WARNINGs, as failing to allocate is no longer
necessarily fatal.

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

meson: Convert common options to feature options

These are necessary for gst-build to set options correctly. The
remaining automagic option is cgroup support in examples.

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

rtsp-stream: Slightly simplify locking

Limit queued TCP data messages to one per stream

Before, the watch backlog size in GstRTSPClient was changed
dynamically between unlimited and a fixed size, trying to avoid both
unlimited memory usage and deadlocks while waiting for place in the
queue. (Some of the deadlocks were described in a long comment in
handle_request().)

In the previous commit, we changed to a fixed backlog size of 100.
This is possible, because we now handle RTP/RTCP data messages differently
from RTSP request/response messages.

The data messages are messages tunneled over TCP. We allow at most one
queued data message per stream in GstRTSPClient at a time, and
successfully sent data messages are acked by sending a "message-sent"
callback from the GstStreamTransport. Until that ack comes, the
GstRTSPStream does not call pull_sample() on its appsink, and
therefore the streaming thread in the pipeline will not be blocked
inside GstRTSPClient, waiting for a place in the queue.

pull_sample() is called when we have both an ack and a "new-sample"
signal from the appsink. Then, we know there is a buffer to write.

RTSP request/response messages are not acked in the same way as data
messages. The rest of the 100 places in the queue are used for
them. If the queue becomes full of request/response messages, we
return an error and close the connection to the client.

Change-Id: I275310bc90a219ceb2473c098261acc78be84c97

rtsp-client: Use fixed backlog size

Change to using a fixed backlog size WATCH_BACKLOG_SIZE.

Preparation for the next commit, which changes to a different way of
avoiding both deadlocks and unlimited memory usage with the watch
backlog.

rtsp-media: unref clock (if set) when finalizing

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

rtsp-media: add gst_rtsp_media_*_set_clock to docs

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

media-factory: unref old clock when setting new clock

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

media-factory: unref clock in finalize

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

rtsp-onvif-media: fix g-ir-scanner warnings

.gitignore: add another example binary

meson: add new test-appsrc2 example to meson build

examples: fix build of new test-appsrc2 example

Need to link against libgstapp-1.0.

examples: Add test-appsrc2

Add an example of feeding both audio and video into an RTSP
pipeline via appsrc.

client: Strip transport parts as whitespaces could be around commas

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

rtsp-stream: avoid pushing data on unlinked udpsrc pad during setup

Fix race when setting up source elements.

Since we set the source element(s) to PLAYING state before hooking
them up to the downstream funnel, it's possible for the source element
to receive packets before we actually get to linking it to the funnel,
in which case buffers would be pushed out on an unlinked pad, causing
it to error out and stop receiving more data.

We fix this by blocking the source's srcpad until we have linked it.

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

rtsp-stream: Fix mismatch between allowed and configured protocols

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

rtsp-stream: Emit a signal when the SRTP decoder is created

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

rtsp-stream: Don't require presence of sinks in _get_*_socket()

Transport specific sink elements are added to the pipeline
in PLAY request and sockets are already created in SETUP so
it's actually wrong to require the presence of sinks in
_get_*_socket() functions.

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

rtsp-stream: Update transport for multicast clients as well

If a multicast client requests different transport settings
than the existing one make sure that this new transport
configuruation is propagated to the multicast udp sink.

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

rtsp-stream: Set the multicast TTL parameter on multicast udp sinks

And not on unicast udp sinks

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

Update for g_type_class_add_private() deprecation in recent GLib

Fix indentation

examples: Add test-video-disconnect example

Simple example which cuts off all clients 10 seconds
after the first one connects.

rtsp-auth: Add support for parsing .htdigest files

Passwords are usually not stored in clear text, but instead
stored already hashed in a .htdigest file.

Add support for parsing such files, add API to allow setting
a custom realm in RTSPAuth, and update the digest example.

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

rtspclientsink: fix waiting for multiple streams

We were previously only ever waiting for a single stream to notify it's
blocked status through GstRTSPStreamBlocking.  Actually count streams to
wait for.

Fixes rtspclientsink sending SDP's without out some of the input
streams.

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

docs: add missing auth methods

rtsp-stream: only create funnel if it didn't exist already.

This precented using multiple protocols for the same stream.

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

meson: build auth-digest example

Get payloader stats only for the sending streams

Get/set payloader properties only for streams that actually
contain a payloader element.

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

Makefile: Don't hardcode libtool for g-i build

Similar to the other commits in core/base/bad

rtsp-onvif-media-factory: export gst_rtsp_onvif_media_factory_requires_backchannel

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

rtspclientsink: Don't deadlock in preroll on early close

If the connection is closed very early, the flushing
marker might not get set and rtspclientsink can get
deadlocked waiting for preroll forever.

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

meson: Update option names to omit disable_ and with- prefixes

Also yield common options to the outer project (gst-build in our case)
so that they don't have to be set manually.

meson: use -Wl,-Bsymbolic-functions where supported

Just like the autotools build.

configure: check for -good and -bad plugins only in uninstalled setup

Avoids confusing configure messages looking or a -good .pc file
that doesn't exist.

Also use plugindir variables that common macros set while at it.

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

rtsp-client: Fix session timeout

When streaming data over TCP then is not the keep-alive
functionality working.

The reason is that the function do_send_data have changed
to boolean but the code is still checking the received result
from send_func with GST_RTSP_OK.

The result is that a successful send_func will always lead to
that do_send_data is returning false and the keep-alive will
not be updated.

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

Implement support for ULP Forward Error Correction

In this initial commit, interface is only exposed for RECORD,
further work will be needed in rtspsrc to support this for
PLAY.

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

Revert "rtsp-server: Switch around sendonly/recvonly attributes"

This reverts commit 3d275b1345b76151418e3f56ed014d9089ac1a57.

While RFC 3264 (SDP) says that sendonly/recvonly are from the point of view of
the requester, the actual RTSP RFCs (RFC 2326 / 7826) disagree and say
the opposite, just like the ONVIF standard.

Let's follow those RFCs as we're doing RTSP here, and add a property at
a later time if needed to switch to the SDP RFC behaviour.

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

Automatic update of common submodule

From 3fa2c9e to ed78bee