If a serialized query arrives (e.g. allocation) and the jitterbuffer has never
received a packet, then jitterbuffer would never forward the serialized query
resulting in a hang.
Fix by forwarding queries/events before the conditions that require the first
packet to arrive.
Also update unit test to check for this scenario.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1846>
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>
The base receive time should not be the monotonic system clock time, but
the monotonic system clock time adjusted by the current clock calibration.
For the first time this is equivalent as the clock calibration is the default,
but for further discontinuities it is not and would cause a
discontinuity in the clock times at this point.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1766>
When we receive a new alternative we want to avoid iterating out of
bounds, but the comparison between the current index and the length of
the alternative should not log an error when partial_index == length, as
Vec::drain(length..) is valid, and it is completely valid for AWS to
send us a new alternative with as many items as we have already
dequeued.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1751>
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>
Allows you to switch output between folders without having to state change to READY to close the current playlist.
Closes the current playlist immediately and starts a new one at the currently set location.
Should be used after changing the relevant location properties.
Makes use of the send-headers signal in cmafmux.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1692>
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>
Posts a simple 'hls-segment-added' message with the segment location, start running time and duration.
With hlssink2, it was possible to catch 'splitmuxsink-fragment-closed', but since hlssink3 doesn't forward that message
(and hlscmafsink doesn't even use that mux), the new one was added to allow for listening for new fragments being added.
I extended the existing tests to check whether this message is posted correctly.
They theoretically only cover hlssink3, but hlscmafsink uses the same base class so it should be alright for now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1677>
