Our Direct3D11 abstraction layer has been improved and
it gained good shape from API point of view.
Also, On Windows, GstD3D11 has various advantages over GstGL
in terms of compatibility/stability/feature/performance.
Note that WGL implementation is known to be buggy for some
drivers/vendors/scenario (that's a reason why Google implemented ANGLE).
Moreover, GstGL is not fully optimized for Windows unfortunately.
It's the time to open this interface to application developers
for various optimized processing using our Direct3D11
infrastructure.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2646>
This patch adds general mechanism for handling specific hacks. In this
case for jpeg decoder in i965 driver, which cannot create surfaces
with fourcc specified.
From jpeg decoder to the allocator, which creates the surfaces,
there's a non-simple path: basedec pseudo-class adds a hacks guint32
which will be set by actual elements (vajpegdec, in this case) and
basedec will always set the hack to the allocator when the allocator
is instantiated.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1575>
Given the supported rt formats in a profile/entrypoint config it's
possible to know the supported JPEG colorspace and subsampling. This
patch adds this information in coded caps to a safer autoplugging
after jpegparser.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1575>
This base class is intented for hardware accelerated decoders, but since
only VA uses it, it will be kept internally in va plugin.
It follows the same logic as the others video decoders in the library but.
as JPEG are independet images, there's no need to handle a DBP so no need
of a picture object. Instead a scan object is added with all the structures
required to decode the image (huffman and quant tables, mcus, etc.).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1575>
Gallium drivers historically have reported strange dmabuf sizes, from always
zero to the whole frame (multiple fds). The simplest solution is to use lseek
SEEK_END to get the prime descriptor size.
Also the allocator raises a warning if both values differ in order to report
it to driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2574>
If compiled with -Dgstreamer:gst_debug=false and we have
GST_REMOVE_DISABLED defined we will get the following compiler error:
```
[...]/libgstreamer-1.0.so.0.2100.0.p/gst.c.o: in function `gst_deinit':
[...]/gst/gst.c:1258: undefined reference to `_priv_gst_debug_cleanup'
[...] hidden symbol `_priv_gst_debug_cleanup' isn't defined
```
Add the missing define guard to avoid this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2648>
The latency messages are non-deterministic and can arrive before/after
async-done or during state-changes as they are posted by e.g. sinks from
their streaming thread but bins are finishing asynchronous state changes
from a secondary helper thread.
To solve this, expect latency messages at any time and assert that we
receive one at some point during the test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2643>
The commit b90d0274 introduces uninitialized width and height when we
consider to change the "pixel-aspect-ratio" for some interlaced stream.
We need to check the resolution in the src caps, and if no resolution
info found, there is no need to consider the aspect ratio.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2630>
Previously it was only possible to request them with the exact template
name, e.g. 'src_%s', but not with "instantiated" names that would match
this template, e.g.'src_foo_bar'.
This is now possible and a test was added for this, in addition to
fixing a previously invalid test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2635>
Removing glvideomixer-like nuance (it was initially referenced)
and rewriting element since it's not an optimal design at all
from performance point of view.
* Remove wrapper bin (and internal conversion/upload/download elements)
which will waste CPU/GPU resources. Conversion/blending can be done by the
d3d11compositor element at once.
* Add support YUV blending without RGB conversion.
The RGB <-> YUV conversion is completely unnecessary since YUV textures
support blending as well.
* Remove complicated blending operation properties since it's hard
to use from application point of view. Instead, adding "operator" property
like what compositor element does.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2631>
Similar to and inspired by glimagesink and gtkglsink.
Using the Wayland buffer transform API allows to offload
rotate operations to the Wayland compositor. This can have
several advantages:
- The Wayland compositor may be able to use hardware plane
capabilities to do the rotation.
- In case of pre-rotated content on rotated outputs the
rotations may equal out, potentially allowing the
compositor to use hardware planes even if they don't
support rotate operations.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2543>
AVC and HEVC define crop rectangle and the x/y coordinates might
not be zero. This commit will address the non-zero x/y offset coordinates
via GstVideoCropMeta if downstream supports the meta and d3d11 memory.
Otherwise decoder will copy decoded texture into output frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2624>
Some mpeg-ts streams have extra data at the beginning. While it's not ideal, we
should be able to cope with it.
Therefore increase the initial search window for at least 4 consecutive
synchronization points to 1kB.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2626>
This allows the reception of streams that don't exactly match
the codec preferences. In particular, the ssrc in the codec preferences
is local sender SSRC, the other side is expected to send a different SSRC.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2615>
Some encoders (e.g. Makito) have H265 field-based interlacing, but then
also specify an 1:2 pixel aspect ratio. That makes it kind-of work with
decoders that don't properly support field-based decoding, but makes us
end up with the wrong aspect ratio if we implement everything properly.
As a workaround, detect 1:2 pixel aspect ratio for field-based
interlacing, and check if making that 1:1 would make the new display
aspect ratio common. In that case, we override it with 1:1.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2577>
Various variables were of smaller types than needed and there were no
checks for any overflows when doing additions on the sizes. This is all
checked now.
In addition the size of the decompressed data is limited to 200MB now as
any larger sizes are likely pathological and we can avoid out of memory
situations in many cases like this.
Also fix a bug where the available output size on the next iteration in
the zlib decompression code was provided too large and could
potentially lead to out of bound writes.
Thanks to Adam Doupe for analyzing and reporting the issue.
CVE: tbd
https://gstreamer.freedesktop.org/security/sa-2022-0003.html
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2610>
Various variables were of smaller types than needed and there were no
checks for any overflows when doing additions on the sizes. This is all
checked now.
In addition the size of the decompressed data is limited to 120MB now as
any larger sizes are likely pathological and we can avoid out of memory
situations in many cases like this.
Also fix a bug where the available output size on the next iteration in
the zlib/bz2 decompression code was provided too large and could
potentially lead to out of bound writes.
Thanks to Adam Doupe for analyzing and reporting the issue.
CVE: CVE-2022-1922, CVE-2022-1923, CVE-2022-1924, CVE-2022-1925
https://gstreamer.freedesktop.org/security/sa-2022-0002.html
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1225
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2610>
Uses prelude header files with #defines to rename DASH and MSS
symbols duplicated in their old standalone versions.
Also redefines soup-related functions when building it for
adaptivedemux2 to prevent symbol conflicts there.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2534>
Currently, video format is decided with downstream caps intersection,
but that's not correct since chroma is not considered. The video
decoders have to decide the output format given the used chroma, not
by the downstream caps negotiation.
This patch changes that. Still, caps feature is selected by caps
negotiation, then, with the preferred caps feature, the output format
is search within that caps feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2569>
The mq we get out of the weak ref might be NULL if we're
shutting down, which could cause assertion failures or
crashes.
It might also cause miscompilations where the compiler just
optimises away the NULL check because it jumps to a code path
that then dereferences the pointer which clearly isn't going
to work. Seems like something like this happens with gcc 11.
Fixes#1262
Co-authored-by: Doug Nazar <nazard@nazar.ca>
Co-authored-by: Sebastian Dröge <sebastian@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2599>
Fixes:
../plugins/elements/gstmultiqueue.c: In function ‘gst_multi_queue_loop’:
../plugins/elements/gstmultiqueue.c:2394:19: warning: ‘is_query’ may be used uninitialized in this function [-Wmaybe-uninitialized]
2394 | if (object && !is_query)
| ^~~~~~~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2593>
Rewriting GstD3D11Converter (equivalent to GstVideoConverter)
to optimize some conversion path and clean up.
* Extract YUV <-> RGB conversion matrix building method to
utils. It will be used by other implementation
* Use calculated offset values for YCbCr <-> YPbPr conversion
instead of hardcoded values
* Handle color range adjustment
* Move transform matrix building helper function to utils.
The method will be used by other elements
* Use single constant buffer. Multiple constatne buffer for
conversion pipeline is almost pointless
* Remove lots of duplicated HLSL code and split pixel shader
code path into sampling -> colorspace conversion ->
shader output packing
* Avoid floating point precision error around UV coordinates
* Optimize RGB -> YUV conversion path
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2581>
Copy V4L2_PIX_FMT_P010 define from linux header.
V4L2_PIX_FMT_P010 is the little endian definition of P010 so map
it GST_VIDEO_FORMAT_P010_10LE.
Add it v4l2 default video formats to allows v4l2 decoders to
enumerate and use it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2590>
In case that input is D3D11 texture, QSV seems to work regardless
of the alignment. Actually the alignment requirement seems to make
only sense for system memory.
Other Intel GPU dependent implementations (new VA encoder, and MediaFoundation)
do not require such alignment nor other vendor specific ones (NVENC and AMF)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2540>
A few header files in -bad contain comments that start with the
/** gtk-doc pattern, but should not actually be parsed (and warned
about as such).
Previously, we were using far-reaching wildcard patterns to avoid
parsing those, but this had the unintended side effect of also
excluding legitimate files, and creating confusion when comments
were not parsed from those.
Switch to excluding specific files instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2576>
macOS features hidden devices. These are devices that will
not be shown in the macOS UIs and that cannot be retrieved
without having the specific UID of the hidden device. There
are cases when you might want to have a hidden device, for example
when having a virtual speaker that forwards the data to a virtual
hidden input device from which you can then grab the audio.
The blackhole project supports these hidden devices and
this patch provides a way that if the device id is a hidden
device it will use it instead of check the hardware list of devices
to understand if the device is valid.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2251>
