There is no need to use DRM dumb pool if buffer to
render is already a DMABuf, just import it and render it.
This fixes a DMAbuf memory leakage when waylandsink downstream
element exports DMABuf while waylandsink is configured to be
DMABuf exporter (drm-device=/drv/dri/card0):
gst-launch-1.0 v4l2src io-mode=4 ! waylandsink drm-device=/dev/dri/card0
leakage identfied with command:
watch "cat /sys/kernel/debug/dma_buf/bufinfo | grep attached "
Fixes#2729
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5350>
* Library versioning should not be used for plugins since it will add
-{version}.dll suffix (and versioned libraries on Linux with symlink).
Then the library file name and plugin init function name mismatch
will result in blacklisted plugin.
* Don't define BUILDING_GST_CODECS, makes no sense
* Don't define G_LOG_DOMAIN, which should be used only for libraries,
not plugins
* Depends on gstcodecparsers libary, not gstcodecs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5249>
Section 3.4 in RFC8835 states that if a WebRTC endpoint uses an HTTP
proxy to access the Internet it MUST include the "ALPN" header. This
commit adds this header.
By default the ALPN used when connecting to the TURN/TCP server via a
proxy is set to "webrtc". It can be changed by adding an alpn url
option for the http-proxy. For example:
http://user:pass@my.http.proxy.com:8080?alpn=c-webrtc
This will add the header "ALPN: c-webrtc" to the HTTP proxy CONNECT
request.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4212>
Pass GstVideoInfoDmaDrm or GstVideoInfo whenever possible, avoiding passing
strange combination of GstVieoFormat + modifier. Even though we don't have any
at the moment, this also allow supporting GstVideoFormat that are not supported
in our DRM integration.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5120>
lc3enc:
- encodes raw audio into lc3 format
- uses the default bitrate property and frame duration
from the caps to determine the byte count of
the encoded frames if it is not specified in
the downstream caps after negotiation
- uses the same byte count value for all the channels
- all the common session configuration parameters
are passed in the src caps
lc3dec:
- decodes an lc3 encoded audio
- sink caps should contain all the common session configuration
params
- uses frame_duration and frame_bytes (byte count) in the sink
caps as parameters along with sample rate and channel count
- byte count is same for all the channels
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4376>
`srt_rejectreason_str` doesn't give us a unique string for every
possible reason. Peers can define their own reasons and SRT just gives
us the string `"Application-defined rejection reason"` for all of them.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4948>
Adding Direct3D11 backend Qt6 QML videosink element, qml6d3d11sink.
Implementation details are similar to the qt6 plugin in -good
but there are a few notable differences.
* qml6d3d11sink accepts all GstD3D11 supported video formats (e.g., NV12).
* Scene graph (owned by qml6d3d11sink) will hold dedicated and sharable
RGBA texture which belongs to Qt6's Direct3D11 device, instead of sharing
GStreamer's own texture with Qt6.
* All rendering operations will be done by using GStreamer's Direct3D11 device.
Specifically, upstream texture will be copied (in case of RGBA)
or converted to the above mentioned Qt6's sharable texture.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3707>
Even if we don't yet know what the echo probe format is, we want to be able to
provide silence for the reverse path, so that when the probe becomes available,
there is no ambiguity around what time period the new set of samples are for.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4849>
The probe's info may not precisely match the dsp's info. For instance,
the number of channels or their layout might be different.
```
GStreamer-Audio-CRITICAL **: 16:21:32.899: the GstAudioInfo argument is not equal to the GstAudioMeta's attached info
```
This broke in d5755744c3.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4849>
A race condition can occur in `srtpdec` during the READY -> NULL transition:
an RTCP buffer can make its way to `gst_srtp_dec_chain` while the element is
partially stopped, resulting in the following critical warning:
> Got data flow before segment event
The problematic sequence is the following:
1. An RTCP buffer is being handled by the chain function for the
`rtcp_sinkpad`. Since, this is the first buffer, we try pushing the sticky
events to `rtcp_srcpad`.
2. At the same moment, the element is being transitioned from PAUSED to READY.
3. While checking and pushing the sticky events for `rtcp_srcpad`, we reach the
Segment event. For this, we try to get it from the "otherpad", in this case
`rtp_srcpad`. In the problematic case, `rtp_srcpad` has already been
deactivated so its sticky events have been cleared. We won't be pushing any
Segment event to `rtcp_srcpad`.
4. We return to the chain function for `rtcp_sinkpad` and try pushing the
buffer to `rtcp_srcpad` for which deactivation hasn't started yet, hence the
"Got data flow before segment event".
This commit:
- Adds a boolean return value to `gst_srtp_dec_push_early_events`: in case the
Segment event can't be retrieved, `gst_srtp_dec_chain` can return an error
instead of calling `gst_pad_push`.
- Replaces the obsolete `gst_pad_set_caps` with `gst_pad_push_event`. The
additional preconditions checked by previous function are guaranteed here
since we push a fixed Caps which was built in the same function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4844>
A race condition can occur in `srtpdec` during the READY -> NULL transition:
an RTCP buffer can make its way to `gst_srtp_dec_chain` while the element is
partially stopped, resulting in the following critical warning:
> assertion 'parent->numsinkpads <= 1' failed
This can occur when the first RTCP buffer is received during the READY -> NULL
transition. If deactivation of the `rtp_srcpad` has already reached
`post_activate`, the sticky events are removed from this Pad. In this case,
`gst_srtp_dec_push_early_events` branches to the generation of a stream id
using `gst_pad_create_stream_id`. This function ensures that the element
doesn't own more than 1 sink pad. Since `srtpdec` owns two of them, the
assertion fails.
This commit uses `gst_element_decorate_stream_id` which doesn't perform this
check. The preconditions is not necessary in this particular context since the
stream id for the RTP / RTCP pads are derived from the same id.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4844>
Updated API usage appropriately, and now we have a versioned package to
track breaking vs. non-breaking updates.
Deprecates a number of properties (and we have to plug in our own values
for related enums which are now gone):
* echo-suprression-level
* experimental-agc
* extended-filter
* delay-agnostic
* voice-detection-frame-size-ms
* voice-detection-likelihood
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2943>
The `switch (n_rear)` supports up to 5 rear channels, but our channel
set only had space for 3. Size the set properly to fix this.
This didn't actually cause any memory unsafety as `PUSH_CHAN` would stop
incrementing `n_rear` if the channel set is already full.
Thanks to @alatiera for noticing this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4712>
New vulkan formats don't match the number of planes with the number of memories
attached to the buffer. This patch changes the pattern of using planes for
traverse the memories with the number of attached memories.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4351>
When transitioning from state PAUSED to READY, the sctpenc element
could previously be stuck in an endless loop trying to resend data
in case the underlying sctp stream was in the process of
resetting. usrsctp_sendv() would repeatedly return EAGAIN with the
result that 0 bytes were sent and then sctpenc would retry forever.
To bring sctpenc out of the resend loop we just need to inform the
sink pad that it is flushing, which is already done for the associated
data queue, but we also need to set the bools associated with the
sinkpads that are used as the loop criterion.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4601>
