Because ID3D12Device objects are singletons per adapter,
GstD3D12Device was following the API design, that is, keep track
of global GstD3D12Device objects and reuses it.
That means ID3D12Device object can be released at the time
when GstD3D12Device is destroyed.
But exetrnal APIs such as NVENC does not seem to be happy
with the released ID3D12Device, that could be a driver bug though.
Let's hold already opened ID3D12Device permanently without releasing
it for now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6395>
`on_error()` can be called with a NULL details structure, so in that situation
the `gst_structure_copy()` would raise a critical warning. Create an empty
structure instead of attempting to copy a NULL one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6385>
In order to simplify caps negotiations for clients and, notably, be more
compatible with va* decoders.
Crucially this allows clients to know ahead of time whether buffers will
actually be DMABufs.
Similar to GstVaBaseDec we only announce system memory caps if the peer
has ANY caps. Further more, and again like va decoders, we fail in
`decide_allocation()` if DMA_DRM caps are used without VideoMeta.
Apart from buggy peers this can happen e.g. when a peer with ANY caps
is used in combination with caps filters.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5890>
Most importantly rely on video info helpers instead of manual parsing
of caps, which will allow us to use additional helpers in the future.
While on it, tighen the check for supported formats - failing that
indicates a bug in caps negotiation - and make some style changes.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5890>
This ensures we don't create filter caps that are not supported by the
individual codec implementations, as well as that the resulting caps
have the required fields so they can be turned into a GstVideoFormat.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5890>
This is the maximum amount supported by aacenc. 8-channel output fully works.
16-channel also encodes fine, but codec-utils isn't able to parse its channel config,
so output level will not be shown in caps. For that to work, GASpecificConfig parsing
needs to be implemented. It's not a critical issue and can be worked on at a later date.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6359>
When this error gets caught the GstD3D11Device object raises the new
"device-removed" signal. This allows to handle the error from outside:
stop the playback, re-create the player, replace the catched GstContext by
the new one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6193>
Adds the `atenc` element capable of encoding AAC-LC audio, using the AudioToolbox framework.
It's able to encode up to 7.1 channel configurations.
Comes with basic knobs for rate control (bitrate for CBR, quality for VBR).
Support for more profiles (LD, HE-AAC) should be simple, but is not included here because of bugs
with parsing of the AudioSpecificConfig.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6254>
None of the GL allocators actually offer a generic alloc() implementation. As a
side effect, they cannot be offered as they don't work with generic video
buffer pool.
Our specialized buffer pool can be dropped by tee or alphacombine as sharing the
same buffer pool over two branch is not supported by the pool API.
Fixes#3372
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6327>
Do not chain up to parent's GstBufferPool::start() which will do
preallocation. We don't want it to be preallocated
since there are various cases where negotiated downstream buffer pool is
not used at all (e.g., zero-copy decoding, IPC elements).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6326>
This fixes a crash in `gst_va_h264_enc_class_init` and `gst_va_h265_enc_class_init`
(and probably also in gst_va_av1_enc_class_init) when calling
`g_object_class_install_properties (object_class, n_props, properties);`
When rate_control_type is 0, the following code is executed in :
```
} else {
n_props--;
properties[PROP_RATE_CONTROL] = NULL;
}
```
n_props has initially a value of N_PROPERTIES but PROP_RATE_CONTROL
is not the last element in the array, so it's making
g_object_class_install_properties fail to iterate over the
properties array.
This applies the same fix to gstvah264enc.c, gstvah265enc.c and
gstvaav1enc.c.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6319>
On systems using UsrMerge (like openSUSE or Fedora), /lib64 is
a symlink to /usr/lib64. So dladdr is returning the path to
the gstreamer library in /lib64 in priv_gst_get_relocated_libgstreamer.
Later gst_plugin_loader_spawn tries to build the path to the
gst-plugin-scanner helper from /lib64 and ends up trying to use
/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner which doesn't exist.
By canonicalizing the path with a call to realpath, gst-plugin-scanner
is found correctly under
/usr/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner
Similar change applied to gstreamer/libs/gst/net/gstptpclock.c
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6322>
