The issue can be reproduced on a computer with a Radeon graphics card
when trying to force GStreamer Editing Services to use GL for video
mixing in GESSmartMixer, instead of the GstCompositor that smart mixer
would normally use. This change causes the resulting video stream to
have "video/x-raw(memory:GLMemory) ... texture-target: 2D" caps (instead
of "video/x-raw ..." caps). At the PlaySink stage of the pipeline, a
GstGLImageSinkBin is plugged, with a GstGLColorBalance on it. For some
reason that is still to be debugged (and out of the scope of this
patch), gst_gl_filter_set_caps() is never called on that color balance
element, leaving filter->in_texture_target set to its default
GST_GL_TEXTURE_TARGET_NONE value. The incomplete _create_shader() logic
does the rest and silently generates a shader code that doesn't build.
This is the command I use to reproduce the issue (I'm not sure if I
would be able to isolate the issue in a simple pipeline, though):
GST_PLUGIN_FEATURE_RANK=vaapih265enc:NONE,vaapih264enc:NONE,vaapisink:NONE,vaapidecodebin:NONE,vaapipostproc:NONE,vaapih265dec:NONE,vaapivc1dec:NONE,vaapih264dec:NONE,vaapimpeg2dec:NONE,vaapijpegdec:NONE,glvideomixer:260
ges-launch-1.0 +clip /tmp/video.mp4
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1159>
Like other foobarA variant APIs on Windows, formatted string
by strftime() is ANSI string, not unicode encoded one.
It would be problematic for non-english locale systems.
We should use unicode version API (wcsftime in this case)
whenever it's possible on Windows.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1093>
If the alsasink thread starts the write loop but another thread pauses
the underlying alsa device, the sink thread will endlessly loop.
snd_pcm_writei() will return 0 if the state is SND_PCM_STATE_PAUSED
and the loop will never make any progress.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1097>
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 current manner in transform_caps() for src direction is not very correct. For example,
when the src caps is:
video/x-raw(memory:DMABuf); video/x-raw; video/x-raw(memory:GLMemory)
this function returns:
video/x-raw(memory:DMABuf); video/x-raw; video/x-raw(memory:GLMemory)
as the sink caps. This is not correct, because DMABuf feature is not even in the sink pad's
caps template. The correct answer should be:
video/x-raw(memory:GLMemory); video/x-raw
only.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1058>
These parameters are incorrectly regarded as mutable in G-IR making them
"incompatible" with languages that are explicit about mutability like
Rust. In order to clean up the code and expected API there, update the
signatures here, right at the source (instead of overriding them in
Gir.toml and hoping for the best).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1005>
libvisual api expects a priv data pointer to be passed, though we know its
going to be `GstDebugLevel`.
```
../subprojects/gst-plugins-base/ext/libvisual/plugin.c:33:39: error: cast to smaller integer type 'GstDebugLevel' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
GST_CAT_LEVEL_LOG (libvisual_debug, (GstDebugLevel) (priv), NULL, "%s - %s",
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/975>
The sink_query just uses context, other_context and display to query info.
But all these objects can be changed or distroyed in state_change() func
and other places.
This patch is not very perfect. The condition race still exists in other
places in this element. All the functions directly access these objects
without protection. Most of them are executed when the data is pushing and
draw context/window have already been established, so they should not have
problems. But the sink_query and propose_allocation functions are the query
-like functions and executed in query context, which can be called in any
state of the element. So it can cause some crash issues because of destroyed
context object.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/922>
The operations for the inside GstGLUploadElement->upload have race
condition. The _transform_caps() will creates this object if it does
not exist, while the _stop() and change_state() can destroy this object.
The _transform_caps() is called by the gst_base_transform_query(),
so it does not hold the stream lock. It may use the upload while the
_stop() and change_state() has already destroy that object, and then
crash.
Fix: #645
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/913>
Setting telemetry options, even to zero, causes libtheora to enable an expensive code path. For large enough videos (e.g. 1920x1080) this can increase the time to decode each frame by 30-40 ms, which can be enough to cause noticeable stutter.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/887>
```
../subprojects/gst-plugins-base/ext/alsa/gstalsamidisrc.c:201:54: error: converting the result of '<<' to a boolean always evaluates to false [-Werror,-Wtautological-constant-compare]
snd_seq_ev_schedule_real (&ev, alsamidisrc->queue, SND_SEQ_TIME_MODE_ABS,
^
/usr/include/alsa/seq_event.h:215:34: note: expanded from macro 'SND_SEQ_TIME_MODE_ABS'
```
The ALSA API expects 0 or 1 here and will then add the flags accordingly,
and that's also what other code using this API does.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/777>
To document it, we instantiate a subclass and inspect the properties
on the created object. Subclasses (in that case textrender) may
initialize those properties with a different default, we do not
want to expose that in the base class documentation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/723>
