Otherwise when changing the target caps (e.g. for reducing quality)
there is a race condition between buffers between the converter elements
and renegotiation.
For example, videoconvertscale might've output a 1920x1080 buffer, then
the capsfilter is configured to 1280x720, the buffer arrives in
videorate, videorate notices that renegotiation is pending, tries to
renegotiate and ends up with EMPTY caps because it can only change the
framerate but not the resolution.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1949>
It is possible that in unprepare(), waiting for a task to complete while
holding the state lock, that task may be waiting to acquire the state lock and
result in a deadlock.
This is quick to reproduce when starting and stopping webrtcsink in very quick
succession.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1931>
The InPlace/Taken logic was introduced to avoid using an extra lock
around the session, but it places expectations that are not always
obvious to meet around when a session is expected to be taken or not.
Any code that expects to have access to the sessions at all times thus
needs either extra logic in the session wrapper, or to maintain the
state of the session outside of the session (eg mids).
This commit removes the logic, and wraps sessions in Arc<Mutex>>.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1852>
Since 6a23ae168f, the chain function
of webrtcsink adds a custom meta on input buffers.
That custom meta was registered only by the class_init of the subclasses
of BaseWebRTCSink, but the custom signaller example uses
BaseWebRTCSink::with_signaller() directly.
Fix by registering the meta in BaseWebRTCSink::class_init()
Fixes: #610
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1854>
When congestion control is used for a session with multiple encoders,
the default implementation simply divides the overall bitrate equally
between encoders.
This is not always desirable, and this patch exposes a new signal
that users can register to, with two arguments:
* The overall bitrate to allocate
* A structure with an encoder.stream_name -> bitrate mapping
Handlers should return a similar structure with a custom mapping.
An example is also provided.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1792>
RFC7273 related attributes are set in the SDP offer by passing them via the
transceiver `codec-preferences` signal. These attributes are intended to be set
at the media level so they must be prefixed by `a-` in the `Caps` argument to
the signal. Otherwise they end up under `a=fmtp`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1810>
It may be desirable for the frontend to receive ancillary information
over the control channel.
Such information includes but is not limited to time code metas, support
for other metas (eg custom meta) might be implemented in the future, as
well as downstream events.
This patch implements a new info message, probes buffers that arrive at
nicesink to look up timecode metas and potentially forwards them to the
consumer when the `forward-metas` property is set appropriately.
Internally, a "dye" meta is used to trace the media identifier the
packet we are about to send over relates to, as rtpfunnel bundles all
packets together.
The example frontend code also gets a minor update and now logs info
messages to the console.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1749>
1c48d7065d was mistakenly merged too
early, and there were concerns about the implementation and API design:
The fact that the frontend had to expose a text area specifically for
sending over a mix matrix, and had to manually edit in floats into the
stringified JSON was suboptimal.
Said text area was always present even when remote control was not
enabled.
The sendControlRequest API was made more complex than needed by
accepting an optional stringifier callback.
This patch addresses all those concerns:
The deserialization code in webrtcsink is now made more clever and
robust by first having it pick a numerical type to coerce to when
deserializing arrays with numbers, then making sure it doesn't allow
mixed types in arrays (or arrays of arrays as those too must share
the same inner value type).
The frontend side simply sends over strings wrapped with a request
message envelope to the backend.
The request text area is only shown when remote control is enabled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1725>
webrtcsink was starting the negotiation process on Ready and concurrently
moving the consumer pipeline to Playing, but when answering the remote
description was set so fast that input streams were connected (and the time
format set on appsrc) before the state change to Paused had completed.
This meant gst_base_src_start was happening after that and setting the format
back to bytes, the time segment that was next coming in then caused:
basesrc gstbasesrc.c:4255:gst_base_src_push_segment:<video_0> segment format mismatched, ignore
And the consumer pipeline errored out.
The same issue existed in theory when webrtcsink was creating the offer,
but was much harder to trigger as it required that the remote answer
came in before the state change to Paused had completed.
This commit fixes the issue by simply waiting for the state to have
changed to Paused before negotiating.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1730>
This is one example of how a consumer might send over custom upstream
event requests to the producer.
As webrtcsink will deserialize numbers in priority as integers, we need
a custom stringifying function to ensure members of the matrix array are
indeed serialized with the floating point.
An optional stringifier parameter is thus added to the
sendControlRequest API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1711>
.. and deprecate data channel navigation in favor of it.
A new property, "enable-data-channel-control" is exposed, when set to
TRUE a control data channel is offered, over which can be sent typed
upstream events.
This means further upstream events will be usable, for now only
navigation and custom upstream events are handled.
In addition, send response messages to notify the consumer of whether
its requests have been handled.
In the future this can also be extended to allow the consumer to send
queries, or seek events ..
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1711>
