mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-18 15:51:11 +00:00
34ef2b2759
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> |
||
---|---|---|
.. | ||
alsa | ||
cdparanoia | ||
gl | ||
libvisual | ||
ogg | ||
opus | ||
pango | ||
theora | ||
vorbis | ||
meson.build |