Direct3D11 objects are COM, and most COM C APIs are verbose
(C++ is a little better). So, by using C++ APIs, we can make code
shorter and more readable.
Moreover, "ComPtr" helper class (which is C++ only) can be
utilized, that is very helpful for avoiding error-prone COM refcounting
issue/leak.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2077>
While preparing a blist for pushing, some RTP header extension may
request caps change for a specific buffer in the list. When this
happens, depayloader should immediately push those buffers from the list
that precede the currently processed buffer (for which the caps change
was requested) and only then apply the new caps to the src pad.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1011>
Some header extensions may need to read information from the payloader's
sink caps. Introduce gst_rtp_header_extension_update_from_sinkcaps ()
that passes the caps to the extension, which can then use it to update
its internal state.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1011>
If the driver supports it (iHD, so far) and the parameter -d is set,
the direction of the video will be changed randomly.
In the code you can select, at compilation time, if the direction
change is done by element's property or by pipeline events.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2074>
Added helper function _update_passthrough() which will define and set
the pass-through mode of the filter, and it'll either reconfigure both
pads or it will just mark the src pad for renegotiation or nothing at
all.
There are cases where both pads have to be reconfigured (direction
changed, for example), other when just src pad has to (filters
updated) or none (changing to ready state).
The requirement of renegotiation depends on the need to enable/disable
its VA buffer pools.
This patch sets pass-through mode by default, so the buffer pools
aren't allocated if no filtering/direction operations are defined,
which is the correct behavior.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2074>
This because underlying driver may have constraint on
buffer size to be dependent on period size, so period
time needs to be set first.
For e.g. Xilinx ASoC driver requires
buffer size to be multiple of period size for it's DMA
operation.
alsa-utils also set period time first as seen in below commit :
9b621eeac4
Tested it on zcu106 board with HDMI based record and playback.
Also tested on Intel PC using Logitech C920 Webcam mic and ALC887-VD
Analog for playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1040>
The way pad->priv->input_buffer reference was managed was pretty
spurious:
- it was overridden without unrefing it, which could potentially lead to
leaks.
- we were unreffing it while keeping the pointer around, which could
potentially lead to use-after-free or double-free.
As priv->input_buffer is actually no longer used outside of the
aggregate() method, remove it from pad->priv to simplify the code and
prevent the issues desribed above.
Fix a single buffer leak when shutting down the pipeline as the buffer
returned from gst_aggregator_pad_drop_buffer() was never unreffed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1061>
This code path is meant to convert the current buffer to the new format
on update. It was using priv->input_buffer as input which is either
priv->buffer or a converted version of it.
Use priv->buffer instead as priv->input_buffer may no longer be a valid
reference.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1061>
For the time being the GstPlayer library remains as a wrapper for GstPlay, in
order to keep existing applications working and give them time to port to
GstPlay. GstPlayer will remain in -bad for a couple cycles and the plan for
GstPlay is to move it to -base before 1.20.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2061>
This aims to be a replacement for the GstPlayer library. In GstPlay, notifications are
sent as application messages through a dedicated GstBus. The GMainContext-based
signal dispatcher was replaced by a GObject signal adapter, now relying on the
bus to emit its signals. The signal dispatcher is now optional and fully
decoupled from the GstPlay object.
Co-authored with: Philippe Normand <philn@igalia.com>
Fixes#394
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2061>
It was possible to generate a SDP that had an RTX payload type
that matched one of the media payload types when providing caps via
codec_preferences without any sink pads.
Fixes
m=video 9 UDP/TLS/RTP/SAVPF 96
...
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack pli
a=fmtp:96 apt=96
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2046>
Especially specify the field-order in the interleaved mode. Otherwise it
might cause the negotiation to fail, because
GST_PAD_SET_ACCEPT_INTERSECT is not set on the sinkpad, and the
field-order is missing in the sink template but can be present in the
outside caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2062>
The ret test is unrelevant and confusing.
We dont want the code to fail and the register
to succeed by example.
In the case of a conditional element_init,
the element should be defined with
GST_ELEMENT_REGISTER_DEFINE_CUSTOM instead
of GST_ELEMENT_REGISTER_DEFINE_WITH_CODE.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/768>
This commit negotiate F32 audio format if MODE_FLOAT used in wavpack file.
Wavpack float mode is always in 32-bit IEEE format.
The following pipeline plays distorted audio if source file is encoded in float mode:
gst-launch-1.0 filesrc ... ! wavpackparse ! wavpackdec ! pulsesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/894>
Current windows image doesn't seem to be able to spawn procceses for reason,
use a different image until this is debuged
```
Running command 'c:/builds/alatiera/gst-ci/cerbero-build/build-tools/bin/meson --prefix=c:/builds/alatiera/gst-ci/cerbero-build/dist/msvc_x86_64 --libdir=lib -Ddebug=true --default-library=both -Doptimization=2 --backend=ninja --wrap-mode=nodownload -Db_vscrt=md --native-file c:/builds/alatiera/gst-ci/cerbero-build/sources/msvc_x86_64/gstreamer-1.0-1.19.0.1/_builddir/meson-native-file.txt -Dlibunwind=disabled -Ddbghelp=enabled -Dintrospection=disabled -Dexamples=disabled'
failed to create process
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-ci/-/merge_requests/399>
Some cameras (e.g. HikVision DS-2CD2732F-IS) return "551 Option
not supported" when a command is sent that is not implemented
(e.g. PAUSE). Instead; it should return "501 Not Implemented".
This is wrong, as previously, the camera did announce support for PAUSE
in the OPTIONS.
In this case, handle the 551 as if it was 501 to avoid throwing errors
to application level. */
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/885>
... instead of the largest we ever seen.
Note that d3d11h264dec element holds previously configured DPB size
for later decoder object re-open decision.
This is to fix below case:
1) Initial SPS, required DPB size is 6
- decoder object is opened with DPB size 6
- max_dpb_size is now 6
2) SPS update with resolution change, required DPB size is 1
- decoder object is re-opened with DPB size 1
- max_dpb_size should be updated to 1, but it didn't happen (BUG)
3) SPS update without resolution change, only required DPB size is updated to 6
- decoder object should be re-opened but didn't happen
because we didn't update max_dpb_size at 2).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2056>
