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>
We have only one copy of gst_va_base_dec_parent_class inside the
vabasedec, so it can not handle the case when there are multi va
decoders inside one pipeline. The pipeline:
gst-launch-1.0 filesrc location=xxx.h264 ! h264parse \
! vah264dec ! msdkh265enc ! vah265dec ! fakesink
generates a assertion of
"invalid cast from 'GstVaH264Dec' to 'GstH265Decoder"
and gets a crash.
We should keep the parent_class for each decoder type.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2231>
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>
VADecPictureParameterBufferAV1.mode_control_fields.bits were filled
twice, overwriting to zeros the first assignation. This patch unifies
both assignations.
Also it makes explicit an enum casting between libva and gstreamer; it
removes the assignation to zero a deprecated parameter; and use an
appropriate assertion.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2223>
The previous test was preventing the pad to be in EOS
when the segment position was greater than segment stop.
It ended up consuming all the data before getting in EOS.
Regarding GST_SEEK_FLAG_SEGMENT it seems to be
correctly handled later in the method.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2173>
Do not carry over segmentation flags from previous frames. The spec
says in 7.2.10 that the feature data carry over from previous frames
if not updated, but the flags do not.
Consider what would happen if a flag B is to depend on a flag A, and
B carries over as set from another frame. Further consider that A is
now not set in this particular frame. This leads to the invalid state
in which flag B is set but flag A isn't.
This might cause the bitstream to be rejected by accelerators down
the line.
Fix it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2203>
Before creating output duplication interface, call SetThreadDesktop()
with HDESK of the current input desktop in case a desktop switch has
occurred.
This allows d3d11desktopdupsrc to capture Windows User Account Control
(UAC) prompts, which appear on a separate secure desktop. Otherwise
IDXGIOutput1::DuplicateOutput() will return E_ACCESSDENIED and the
element won't produce any frames as long as the UAC screen is active.
Note that in order to access secure desktop the application still has to
run at LOCAL_SYSTEM privileges. For GStreamer applications running with
regular user privileges this change has no effect.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2209>
IDXGIOutputDuplication can become invalid for example when there's
desktop switch, resolution change or Windows User Account Control prompt
appears on screen.
When that happens, try to re-create the duplication interface for the
changed output. Note that in the case of UAC prompt this operation will
fail if the GStreamer process doesn't run at LOCAL_SYSTEM privileges. In
such situation the source element won't create any frames as long as the
output is occupied by UAC screen.
In order to enable UAC access to sufficiently privileged GStreamer
processes, call SetThreadDesktop() with the desktop handle that
currently receives user input before creating our output duplication.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2204>
The problem is for uploading YUV frames using derived images, is that
derived images imply tiling, so frames are wrongly uploaded.
Though derived for reading might work we cannot know the Intel graphics
generation to validate the caching. Overall, it's safer to disable derived
images for i965.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2127>
iHD driver sets a tiled DRM modifier if surface's usage hint is set to
VPP_WRITE. This result in a garbled rendering when using glimagesink.
This patch changes the usage hint to generic if the caps feature is
DMABuf. Either way only iHD driver, so far, uses the usage hint flag.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2127>
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>
