When receiving an sctp message for a stream that not yet has an
sctpdec pad associated with it means we end up in
_on_sctpdec_pad_added. At this point we're holding the sctpassocation
lock. Then it's not possible to take the pc_lock because then code
executing under the pc_lock (which means anything in the webrtc
thread) may not take the sctpassociation lock. For example, running
the data channel close procedure from the webrtc thread means we
eventually end up sending a SCTP_RESET_STREAMS packet which needs to
grab the sctpassociation lock.
This means _on_sctpdec_pad_added simply cannot take the pc_lock and
also it is not possible to postpone the channel creation as we need to
link the pads right there. The solution is to introduce a more
granular dc_lock that protects only the things that needs to be done
to create the datachannel.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2186>
Support for closing WebRTC data channels as described in RFC
8831 (section 6.7) now fully supported. This means that we can now
reuse data channels that have been closed properly. Previously, an
application that created a lot of short-lived on-demand data channels
would quickly exhaust resources held by lingering non-closed data
channels.
We now use a one-to-one style socket interface to SCTP just like the
Google implementation (i.e. SOCK_STREAM instead of SOCK_SEQPACKET, see
RFC 6458). For some reason the socket interface to use was made
optional through a property "use-sock-stream" even though code wasn't
written to handle the SOCK_SEQPACKET style. Specifically the
SCTP_RESET_STREAMS command wouldn't work without passing the correct
assocation id. Changing the default interface to use from
SOCK_SEQPACKET to SOCK_STREAM now means we don't have to bother about
the association id as there is only one association per socket. For
the SCTP_RESET_STREAMS command we set it to SCTP_ALL_ASSOC just to
match the Google implementation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2186>
openaptx has recently changed its license to explicitly exclude
'Freedesktop projects' from using it, which would include GStreamer, as
well as shifting to base terms of GPLv3:
811bc18586
This unilateral license change is legally dubious in many ways.
The original work came from ffmpeg under the LGPL v2.1, to which third
parties may not add additional restrictions (per sections 2 and 7 of the
LGPL v2.1), so LGPLv2.1 + may-not-use restrictions are not permissible
without the explicit consent of the original copyright holder.
The upgrade to LGPL v3.0 without explicit consent from the original
copyright holder is in itself permissible through the upgrade terms of
the LGPL, however the additional restrictions imposed again conflict
with sections 7 and 10 of the GPLv3 (as the base of the LGPLv3, with
those sections not being invalidated by the additional LGPLv3 text).
Though it does not impact the legal validity of the redeclaration of
licensing, the claims that freedesktop.org has violated the terms of the
openaptx license in the past are false; the work was contributed to the
PulseAudio project with an explicit open license, with the original
contributor later attempting to revoke permission for its use, despite
the explicit terms of the license giving no ability to do so as they
lack a change-of-heart provision.
The claims that Collabora violated the license are even more baseless;
they are based on an assertion that when I (acting on behalf of
freedesktop.org rather than Collabora, in my own unpaid time) banned
users from freedesktop.org's GitLab instance due to sustained violations
of the Code of Conduct users agree to when creating an account on that
platform, this somehow constituted a violation of the license. Even if
Collabora were somehow involved in this - which they were not at all -
there is no requirement under open licenses that users be given
unlimited access under all terms to any platform on the internet. Such
terms would mean that open development could only be conducted on
completely unmoderated platforms, which does not stand up to any
scrutiny.
Regardless of the declared license having no legal validity, the LGPL's
explicit provision in both v2.1 and v3.0 for such additional
restrictions to be stripped, and the low likelihood of it ever being
used together with GStreamer as its licensing terms would not be
acceptable to any distribution, enforcing a version check seems like the
safest way to ensure complete legal clarity, not put users or
downstreams in any jeopardy, and comply with the author's stated wishes
for v0.2.1 and above to not be used by GStreamer.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2235>
Use the object lock for the following fields:
- `bytes`: Written by the `load-bytes` signal unless running; consumed
on start.
- `draw_background`: Read and written by the `draw-background`
property.
- `location`: Read and written by the `location` property and the URI
handler.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2222>
This MR provides a transform element that leverage ONNX runtime
to run AI inference on a broad range of neural network toolkits, running
on either CPU or GPU. ONNX supports 16 different providers at the
moment, so with ONNX we immediately get support for Nvidia, AMD, Xilinx
and many others.
For the first release, this plugin adds a gstonnxobjectdetector element to
detect objects in video frames. Meta data generated by the model is
attached to the video buffer as a custom GstObjectDetectorMeta meta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1997>
First fail the offer creation if the mid of an existing offer doesn't
match a forced m-mline.
Then, for all newly added mlines, first look for a transceiver that
forces this m-line, then add a "floating" one, then the data channel.
And repeat this until we're out of transceivers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2104>
The simple case where this breaks is if you add a
datachannel and want to add a new pad (a new media) after). Another
case where this is broken is if the order of the media is forced to
something different by the peer.
It's more simple to just split both things completely. In practice, the
pads will be named in the order in which they are allocated, so it
shouldn't change the current behaviour, just enable new ones.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2104>
