GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:23:37Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/425Add DRI3/Present extension support in ximagesink, glimagesink, etc.2021-09-24T13:23:37ZBugzilla Migration UserAdd DRI3/Present extension support in ximagesink, glimagesink, etc.## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#794339)](https://bugzilla.gnome.org/show_bug.cgi?id=794339)**
## Description
DRI3 has an extension which allows to convert DRM_PRIME_BUFFER to Pixmap and presen...## Submitted by Sreerenj Balachandran `@sree`
**[Link to original bug (#794339)](https://bugzilla.gnome.org/show_bug.cgi?id=794339)**
## Description
DRI3 has an extension which allows to convert DRM_PRIME_BUFFER to Pixmap and present it on the screen using "Present" extension.
This could help to do zero-copy pipelines like
VAAPI_decdoe ! ximagesink
MediaSDK_decode ! ximagesink
https://lwn.net/Articles/569701/
This is a PR against intel-vaapi-driver: https://github.com/intel/intel-vaapi-driver/pull/369
Another third-party implementation: https://github.com/intel/gstreamer-media-SDK/blob/master/gst-libs/mfx/x11/gstmfxwindow_x11.c#L469https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/279Using GST_PLUGIN_STATIC_DECLARE in c++ code2021-09-24T11:09:34ZBugzilla Migration UserUsing GST_PLUGIN_STATIC_DECLARE in c++ code## Submitted by Sylvain Chevalier
**[Link to original bug (#794296)](https://bugzilla.gnome.org/show_bug.cgi?id=794296)**
## Description
The GST_PLUGIN_STATIC_DECLARE macro must be wrapped inside an extern "C" block when building in...## Submitted by Sylvain Chevalier
**[Link to original bug (#794296)](https://bugzilla.gnome.org/show_bug.cgi?id=794296)**
## Description
The GST_PLUGIN_STATIC_DECLARE macro must be wrapped inside an extern "C" block when building in C++ as it resolved in a function declaration whose implementation is in C.
As this is not obvious (at least it was not obvious to me), should it be documented, or maybe better yet, improved in the macro itself?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/278segment: Change back gst_segment_do_seek() to use gint642021-09-24T11:09:34ZBugzilla Migration Usersegment: Change back gst_segment_do_seek() to use gint64## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#794215)](https://bugzilla.gnome.org/show_bug.cgi?id=794215)**
## Description
During 0.11 dev at commit bdbc069348 the gst_segment_do_seek() was changed to accep...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#794215)](https://bugzilla.gnome.org/show_bug.cgi?id=794215)**
## Description
During 0.11 dev at commit bdbc069348 the gst_segment_do_seek() was changed to accept only unsigned start/stop. Though, the code will do direct comparision with -1 and also assumes negative values for GST_SEEK_TYPE_END:
start = segment->duration + start;
Additionally, the gst_event_new_seek() API along with the GstElement API uses signed integer. Demuxers will pass these value unchecked to that API in order to update their segment. Looking at the code, it will properly wrap around resulting in the same behaviour, but it's all a bit of a lie. As this does not affect the API, I think it's fine to switch it back to gint64.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/667GStreamer Android, unhandled "java.lang.IllegalStateException" while decoding...2021-09-24T14:36:08ZBugzilla Migration UserGStreamer Android, unhandled "java.lang.IllegalStateException" while decoding mpeg4 video## Submitted by Kim Jonathan
**[Link to original bug (#794183)](https://bugzilla.gnome.org/show_bug.cgi?id=794183)**
## Description
Created attachment 369468
gst-logs
amcvideodec mpeg4 decoder failed on andoroid platform. log...## Submitted by Kim Jonathan
**[Link to original bug (#794183)](https://bugzilla.gnome.org/show_bug.cgi?id=794183)**
## Description
Created attachment 369468
gst-logs
amcvideodec mpeg4 decoder failed on andoroid platform. logs attached.
last working version: 1.8.3
media url: http://docs.gstreamer.com/media/large/starwars.mkv
error summary:
"storeMetaDataInBuffers failed w/ err -2147483648
E/ACodec: [OMX.sprd.mpeg4.decoder] ERROR(0x80001001)
Other details:
Device: Samsung J2
Android version: 6.0
**Attachment 369468**, "gst-logs":
[android_mpeg4-decoding-failed.txt](/uploads/4f4ca5779d4f4b481ffe3fe6206b5f5d/android_mpeg4-decoding-failed.txt)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/277streamiddemux: Not settings caps before adding pads2021-09-24T11:09:35ZBugzilla Migration Userstreamiddemux: Not settings caps before adding pads## Submitted by Vinod Kesti `@vinodkesti`
**[Link to original bug (#794168)](https://bugzilla.gnome.org/show_bug.cgi?id=794168)**
## Description
I am trying to mux and demux raw video/audio using funnel and streamiddemux
respecti...## Submitted by Vinod Kesti `@vinodkesti`
**[Link to original bug (#794168)](https://bugzilla.gnome.org/show_bug.cgi?id=794168)**
## Description
I am trying to mux and demux raw video/audio using funnel and streamiddemux
respectively.
Below is the pipeline, funnel is used to mux audio/x-raw and video/x-raw.
Later the stream is demuxed through streamiddemux. Pipeline behaviour is
inconsistent across multiple runs. Some times pipeline runs as expected and
some times I get negotiation error.
gst-launch-1.0 uridecodebin uri=file:Devdas.mp4 name=dec \
dec.! video/x-raw ! fun.sink_0 \
dec.! audio/x-raw ! fun.sink_1 \
funnel name=fun ! streamiddemux name=sid \
sid. ! video/x-raw ! videoconvert ! fakesink \
sid. ! audio/x-raw ! audioconvert ! fakesink
gst-launch-1.0 \
videotestsrc is-live=true ! fun.sink_0 \
audiotestsrc is-live=true ! fun.sink_1 \
funnel name=fun ! streamiddemux name=sid \
sid. ! video/x-raw ! queue ! videoconvert ! checksumsink \
sid. ! audio/x-raw ! queue ! audioconvert ! checksumsink
When I further debugged the streamiddemux behaviour.
Streamiddemux generated pad-added callback upon stream-start event, call
back comes with no caps. which is leading to negotiation error.
The sticky events comes in stream-start, caps, segment and tag. I even
tried add pad after segment event but no luck. I still continue getting
negotiation error.
Regards,
Vinod
Version: 1.12.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/448qtdemux: playback interrupt when reverse video2021-09-24T13:32:55ZBugzilla Migration Userqtdemux: playback interrupt when reverse video## Submitted by Chenglin Ye
**[Link to original bug (#794101)](https://bugzilla.gnome.org/show_bug.cgi?id=794101)**
## Description
Created attachment 369369
Fix media interruption issue when reverse video
I tried to reverse M...## Submitted by Chenglin Ye
**[Link to original bug (#794101)](https://bugzilla.gnome.org/show_bug.cgi?id=794101)**
## Description
Created attachment 369369
Fix media interruption issue when reverse video
I tried to reverse MJPEG format video, but it got media interruption error, and log shown that "This file is invalid and cannot be played.", I found the position of the log, as follow:
source code(qtdemux.c):
------------------------------------------------------------------------------
746 if (G_UNLIKELY (size > QTDEMUX_MAX_ATOM_SIZE)) {
747 if (qtdemux->state != QTDEMUX_STATE_MOVIE && qtdemux->got_moov) {
748 /* we're pulling header but already got most interesting bits,
749 * so never mind the rest (e.g. tags) (that much) */
750 GST_WARNING_OBJECT (qtdemux, "atom has bogus size %" G_GUINT64_FORMAT,
751 size);
752 return GST_FLOW_EOS;
753 } else {
754 GST_ELEMENT_ERROR (qtdemux, STREAM, DEMUX,
755 (_("This file is invalid and cannot be played.")),
756 ("atom has bogus size %" G_GUINT64_FORMAT, size));
757 return GST_FLOW_ERROR;
758 }
759 }
------------------------------------------------------------------------------
However, if (qtdemux->state == QTDEMUX_STATE_MOVIE && qtdemux->got_moov) is TRUE, could we consider that the file is invalid?
test video URL:https://cinelerra-cv.org/footage/grill-mjpeg.mov
**Patch 369369**, "Fix media interruption issue when reverse video":
[0001-qtdemux-add-judgment-condition-when-catch-bogus-size.patch](/uploads/1b6307fe6de5f59e342932c96927462b/0001-qtdemux-add-judgment-condition-when-catch-bogus-size.patch)
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/424decodebin2: Fix detecting when a group or chain is really done2021-09-24T13:23:36ZBugzilla Migration Userdecodebin2: Fix detecting when a group or chain is really done## Submitted by GstBlub
**[Link to original bug (#794099)](https://bugzilla.gnome.org/show_bug.cgi?id=794099)**
## Description
Created attachment 369367
decodebin2: Fix detecting when a group or chain is really done
I ran int...## Submitted by GstBlub
**[Link to original bug (#794099)](https://bugzilla.gnome.org/show_bug.cgi?id=794099)**
## Description
Created attachment 369367
decodebin2: Fix detecting when a group or chain is really done
I ran into a problem where decodebin2 accidentally emits the "drained" signal (which an application could act on) and then causes the pipeline to stall with the demuxer continuing on. This happened when using hlsdemux with a video stream, but without any (suitable) video decoder plugin present. The application intentionally ignores the typefind error as we're only interested in the audio portion. This works fine until hlsdemux triggers a bitrate switch, which causes decodebin2 to believe everything is drained (despite the new pads being added and properly signalled). When this happens there are two chains in a group, one for the video portion (that isn't active) and one for the audio portion.
I attached a patch that appears to fix this issue for me. Since I'm not too familiar with this code, I'd appreciate any feedback.
**Patch 369367**, "decodebin2: Fix detecting when a group or chain is really done":
[0001-decodebin2-Fix-detecting-when-a-group-or-chain-is-re.patch](/uploads/68a0ce4adc933b29456aca34eb3e6dd1/0001-decodebin2-Fix-detecting-when-a-group-or-chain-is-re.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/423missing vaapipostproc causes gstreamer crash in glupload2021-09-24T13:23:36ZBugzilla Migration Usermissing vaapipostproc causes gstreamer crash in glupload## Submitted by Vavooon
**[Link to original bug (#794080)](https://bugzilla.gnome.org/show_bug.cgi?id=794080)**
## Description
In some cases gst-launch crashes when I'm trying to display video without X11 using kmssink or glimagesin...## Submitted by Vavooon
**[Link to original bug (#794080)](https://bugzilla.gnome.org/show_bug.cgi?id=794080)**
## Description
In some cases gst-launch crashes when I'm trying to display video without X11 using kmssink or glimagesink.
Local video plays well (pipeline is
gst-launch-1.0 filesrc location=bbb_sunflower_1080p_30fps_normal.mp4 ! decodebin ! glupload ! glimagesink
) however, when I'm trying to play RTSP stream using
gst-launch-1.0 udpsrc port=9001 ! application/x-rtp, encoding-name=H264 ! rtph264depay ! h264parse ! vaapih264dec low-latency=true ! videoconvert ! glupload ! glimagesink
it fails with following message:
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayGBM\)\ gldisplaygbm0";
Got context from element 'vaapidecode_h264-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayDRM\)\ vaapidisplaydrm1";
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
Caught SIGSEGV
And here's the stack:
Thread 5 "gstglcontext" received signal SIGSEGV, Segmentation fault.
```
[Switching to Thread 0x7fffde651700 (LWP 2656)]
__memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:491
491 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt full
#0 __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:491
No locals.
#1 0x00007fffe96f87cf in memcpy (__len=3686400, __src=<optimized out>, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
No locals.
#2 gst_gl_buffer_upload_cpu_write (info=<optimized out>, size=3686400, mem=0x7fffd55a9470) at gstglbuffer.c:195
gl_map_flags = 2
gl = 0x555555c25950
data = <optimized out>
#3 _gl_buffer_map (mem=0x7fffd55a9470, info=<optimized out>, size=3686400) at gstglbuffer.c:212
gl = 0x555555c25950
#4 0x00007fffe96f7749 in _map_data_gl (context=<optimized out>, transfer=0x7fffde650b90) at gstglbasememory.c:277
alloc_class = 0x555555b43930
mem = 0x7fffd55a9470
info = 0x7fffde650c00
prev_map_flags = 0
prev_gl_map_count = 0
__func__ = "_map_data_gl"
__PRETTY_FUNCTION__ = "_map_data_gl"
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/422gl: GBM backend fixes2021-09-24T13:23:36ZBugzilla Migration Usergl: GBM backend fixes## Submitted by Daniel Stone `@daniels`
**[Link to original bug (#793997)](https://bugzilla.gnome.org/show_bug.cgi?id=793997)**
## Description
+++ This bug was initially created as a clone of [Bug 782923](https://bugzilla.gnome.org/...## Submitted by Daniel Stone `@daniels`
**[Link to original bug (#793997)](https://bugzilla.gnome.org/show_bug.cgi?id=793997)**
## Description
+++ This bug was initially created as a clone of [Bug 782923](https://bugzilla.gnome.org/show_bug.cgi?id=782923) +++
On devices with working libdrm support, it is possible to use Mesa3D's GBM library to set up an EGL context directly on top of KMS. This enhancement adds a GBM backend to the GstGL stack.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2772flvmux: dts/pts on output buffers2023-07-06T14:53:46ZBugzilla Migration Userflvmux: dts/pts on output buffers## Submitted by Tim Müller `@tpm`
**[Link to original bug (#793996)](https://bugzilla.gnome.org/show_bug.cgi?id=793996)**
## Description
Cloned bug to discuss pts/dts + negative-dts handling on output.
+++ This bug was initiall...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#793996)](https://bugzilla.gnome.org/show_bug.cgi?id=793996)**
## Description
Cloned bug to discuss pts/dts + negative-dts handling on output.
+++ This bug was initially created as a clone of [Bug 793457](https://bugzilla.gnome.org/show_bug.cgi?id=793457) +++
$ gst-launch-1.0 videotestsrc ! x264enc ! flvmux ! fakesink silent=false -v | grep -e Segment -e chain | head -n 5https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/446rtspsrc: one of 2 udpsrc elements not linking after 2 seconds2021-09-24T13:32:54ZBugzilla Migration Userrtspsrc: one of 2 udpsrc elements not linking after 2 seconds## Submitted by Tristan Matthews `@tmatth`
**[Link to original bug (#793991)](https://bugzilla.gnome.org/show_bug.cgi?id=793991)**
## Description
Given the following pipeline:
gst-launch-1.0 -q -e matroskamux streamable=true na...## Submitted by Tristan Matthews `@tmatth`
**[Link to original bug (#793991)](https://bugzilla.gnome.org/show_bug.cgi?id=793991)**
## Description
Given the following pipeline:
gst-launch-1.0 -q -e matroskamux streamable=true name=m ! fdsink \
rtspsrc location=$1 name=rdummy rdummy. ! application/x-rtp,media=video ! rtpjitterbuffer ! rtph264depay ! video/x-h264, stream-format=\(string\)byte-stream, alignment=\(string\)nal ! h264parse ! m. rdummy. ! application/x-rtp,media=audio ! rtpjitterbuffer ! rtpopusdepay ! m. > /dev/null
roughly 5% of the time, one of the two incoming media streams will fail after about 2 seconds (presumably after a latency query or reconfigure event?) as follows:
0:00:02.078042604 19777 0x7fc6dc026a80 LOG udpsrc gstudpsrc.c:986:gst_udpsrc_create:`<udpsrc4>` read packet of 93 bytes
0:00:02.078072313 19777 0x7fc6dc026a80 LOG udpsrc gstudpsrc.c:839:gst_udpsrc_create:`<udpsrc4>` doing select, timeout -1
0:00:02.081902970 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:986:gst_udpsrc_create:`<udpsrc1>` read packet of 1149 bytes
0:00:02.081942643 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:839:gst_udpsrc_create:`<udpsrc1>` doing select, timeout -1
0:00:02.085983387 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:986:gst_udpsrc_create:`<udpsrc1>` read packet of 1149 bytes
0:00:02.086292923 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:839:gst_udpsrc_create:`<udpsrc1>` doing select, timeout -1
0:00:02.090186233 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2515:new_manager_pad:`<rdummy>` got new manager pad <manager:recv_rtp_src_0_4129694351_100>
0:00:02.090220701 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2523:new_manager_pad:`<rdummy>` stream: 0, SSRC f626228f, PT 100
0:00:02.090233821 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2541:new_manager_pad:`<rdummy>` stream 0x7fc6dc034f90, container 0, added 1, setup 1
0:00:02.090242521 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2541:new_manager_pad:`<rdummy>` stream 0x7fc6dc039400, container 0, added 0, setup 1
0:00:02.090316801 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2497:copy_sticky_events:<'':recv_rtp_src_0_4129694351_100> store sticky event stream-start event: 0x7fc6c0001ae0, time 99:99:99.999999999, seq-num 197, GstEventStreamStart, stream-id=(string)04d49d18f97e5c7c23150b858a8db0013decbe84a153717fd9b6ca9957b2015b, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)2;
0:00:02.090349086 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2497:copy_sticky_events:<'':recv_rtp_src_0_4129694351_100> store sticky event caps event: 0x7fc69c004aa0, time 99:99:99.999999999, seq-num 273, GstEventCaps, caps=(GstCaps)"application/x-rtp\,\ media\=\(string\)video\,\ payload\=\(int\)100\,\ clock-rate\=\(int\)90000\,\ encoding-name\=\(string\)H264\,\ a-recvonly\=\(string\)\"\"\,\ npt-start\=\(guint64\)0\,\ play-speed\=\(double\)1\,\ play-scale\=\(double\)1";
0:00:02.090382172 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2497:copy_sticky_events:<'':recv_rtp_src_0_4129694351_100> store sticky event segment event: 0x7fc6b4001c20, time 99:99:99.999999999, seq-num 189, GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";
0:00:02.090057803 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2515:new_manager_pad:`<rdummy>` got new manager pad <manager:recv_rtp_src_1_2169136101_111>
0:00:02.090690826 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2523:new_manager_pad:`<rdummy>` stream: 1, SSRC 814a63e5, PT 111
0:00:02.090700695 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2541:new_manager_pad:`<rdummy>` stream 0x7fc6dc034f90, container 0, added 1, setup 1
0:00:02.090708291 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2541:new_manager_pad:`<rdummy>` stream 0x7fc6dc039400, container 0, added 1, setup 1
0:00:02.090714387 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:986:gst_udpsrc_create:`<udpsrc1>` read packet of 1150 bytes
0:00:02.091397125 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:839:gst_udpsrc_create:`<udpsrc1>` doing select, timeout -1
0:00:02.091431768 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2497:copy_sticky_events:<'':recv_rtp_src_1_2169136101_111> store sticky event stream-start event: 0x7fc6a4002800, time 99:99:99.999999999, seq-num 213, GstEventStreamStart, stream-id=(string)179e366b8498a8667173dfedcff39eb461f11618ae6d5b147030dc493d655258, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)4;
0:00:02.091606717 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2497:copy_sticky_events:<'':recv_rtp_src_1_2169136101_111> store sticky event caps event: 0x7fc69c004440, time 99:99:99.999999999, seq-num 270, GstEventCaps, caps=(GstCaps)"application/x-rtp\,\ media\=\(string\)audio\,\ payload\=\(int\)111\,\ clock-rate\=\(int\)48000\,\ encoding-name\=\(string\)OPUS\,\ encoding-params\=\(string\)2\,\ a-recvonly\=\(string\)\"\"\,\ npt-start\=\(guint64\)0\,\ play-speed\=\(double\)1\,\ play-scale\=\(double\)1";
0:00:02.091685560 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2497:copy_sticky_events:<'':recv_rtp_src_1_2169136101_111> store sticky event segment event: 0x7fc6a40028e0, time 99:99:99.999999999, seq-num 201, GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";
0:00:02.091822308 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_0_4129694351_100 received query caps
0:00:02.091918005 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received query caps
0:00:02.091981446 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2238:gst_rtspsrc_handle_src_event:`<rdummy>` pad rdummy:recv_rtp_src_0_4129694351_100 received event reconfigure
0:00:02.092019689 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_0_4129694351_100 received query caps
0:00:02.091957946 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received query caps
0:00:02.092692372 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_0_4129694351_100 received query caps
0:00:02.092794687 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2238:gst_rtspsrc_handle_src_event:`<rdummy>` pad rdummy:recv_rtp_src_0_4129694351_100 received event reconfigure
0:00:02.093092101 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received query caps
0:00:02.093123031 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2238:gst_rtspsrc_handle_src_event:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received event reconfigure
0:00:02.093145963 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received query caps
0:00:02.093179414 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received query caps
0:00:02.093223054 19777 0x7fc6b4001770 DEBUG rtspsrc gstrtspsrc.c:2238:gst_rtspsrc_handle_src_event:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received event reconfigure
0:00:02.093009008 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received query caps
0:00:02.093308037 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2238:gst_rtspsrc_handle_src_event:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received event reconfigure
0:00:02.093388795 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_1_2169136101_111 received query caps
0:00:02.094016160 19777 0x7fc6a40024f0 DEBUG rtspsrc gstrtspsrc.c:2565:new_manager_pad:`<rdummy>` We added all streams
0:00:02.095690762 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:986:gst_udpsrc_create:`<udpsrc1>` read packet of 1150 bytes
0:00:02.095756853 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:839:gst_udpsrc_create:`<udpsrc1>` doing select, timeout -1
0:00:02.098909941 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:986:gst_udpsrc_create:`<udpsrc1>` read packet of 1150 bytes
0:00:02.098946815 19777 0x7fc6dc0269e0 LOG udpsrc gstudpsrc.c:839:gst_udpsrc_create:`<udpsrc1>` doing select, timeout -1
0:00:02.099138373 19777 0x9c5d40 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_0_4129694351_100 received query seeking
0:00:02.099385232 19777 0x9c5d40 DEBUG rtspsrc gstrtspsrc.c:2352:gst_rtspsrc_handle_src_query:`<rdummy>` pad rdummy:recv_rtp_src_0_4129694351_100 received query duration
0:00:02.104513381 19777 0x7fc6dc026a80 LOG udpsrc gstudpsrc.c:986:gst_udpsrc_create:`<udpsrc4>` read packet of 93 bytes
0:00:02.104580298 19777 0x7fc6dc026a80 DEBUG rtspsrc gstrtspsrc.c:7604:gst_rtspsrc_handle_message:`<rdummy>` got error from udpsrc4
0:00:02.104589202 19777 0x7fc6dc026a80 DEBUG rtspsrc gstrtspsrc.c:7618:gst_rtspsrc_handle_message:`<rdummy>` combined flows: ok
Further debugging revealed that the udpsrc4 errors out due to not linking.
This may be pushing the limits of what one should expect from gst-launch, but the fact that this pipeline works without issue most of the time would seem to indicate that this is a bug.
I've reproduced this with GStreamer 1.8.3 and 1.13.1
Version: 1.13.1https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/87vaapi/mpeg2: segment fault when reverse playback2021-09-24T12:23:11ZBugzilla Migration Uservaapi/mpeg2: segment fault when reverse playback## Submitted by Chenglin Ye
**[Link to original bug (#793981)](https://bugzilla.gnome.org/show_bug.cgi?id=793981)**
## Description
I try rewind mpeg2 video(set playback rate to -1), however, segment fault caused at gstvaapidecoder_m...## Submitted by Chenglin Ye
**[Link to original bug (#793981)](https://bugzilla.gnome.org/show_bug.cgi?id=793981)**
## Description
I try rewind mpeg2 video(set playback rate to -1), however, segment fault caused at gstvaapidecoder_mpeg2.c:1461, traced by gdb, I found that packet.data value is 0x0. So, I think it is necessary to judge the value of packet.data before 1461, how do you think?
Else, It was strange to me why packet.data was 0x0 when rewind, and it was a valid value when playback normally, Dose mpeg2 video not support rewinding?
souce code:
--------------------------------------------------------------------
1454 if (!gst_buffer_map (buffer, &map_info, GST_MAP_READ)) {
1455 GST_ERROR ("failed to map buffer");
1456 return GST_VAAPI_DECODER_STATUS_ERROR_UNKNOWN;
1457 }
1458
1459 packet.data = map_info.data + unit->offset;
1460 packet.size = unit->size;
1461 packet.type = packet.data[3];
1462 packet.offset = 4;
--------------------------------------------------------------------
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/445rtspsrc: regression with streams marked as recvonly2021-09-24T13:32:54ZBugzilla Migration Userrtspsrc: regression with streams marked as recvonly## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#793964)](https://bugzilla.gnome.org/show_bug.cgi?id=793964)**
## Description
+++ This bug was initially created as a clone of [Bug 793715](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#793964)](https://bugzilla.gnome.org/show_bug.cgi?id=793964)**
## Description
+++ This bug was initially created as a clone of [Bug 793715](https://bugzilla.gnome.org/show_bug.cgi?id=793715) +++
We should find a way to enable filtering by recvonly/sendonly attributes again for the general case. Otherwise streams with recvonly (as in: the server wants to receive data from us) would not work in rtspsrc because we create a pad for those streams and it will never get any data.
Should be solved for 1.16.
### Depends on
* [Bug 793715](https://bugzilla.gnome.org/show_bug.cgi?id=793715)https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/31reqwesthttpsrc: Make it feature-complete2020-05-30T09:01:31ZSebastian Drögereqwesthttpsrc: Make it feature-completeThis should ideally become feature-equivalent with souphttpsrc to become a proper replacement.This should ideally become feature-equivalent with souphttpsrc to become a proper replacement.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/30Add plugin around rust-av2018-11-29T17:07:31ZSebastian DrögeAdd plugin around rust-avA start of this can be found here: https://github.com/sdroege/gst-plugin-rs/tree/rust-av
Needs more workA start of this can be found here: https://github.com/sdroege/gst-plugin-rs/tree/rust-av
Needs more workhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/666ksvideosrc: Device Monitor shows "video/x-raw,format=(string)H264" caps inste...2021-09-24T14:36:08ZBugzilla Migration Userksvideosrc: Device Monitor shows "video/x-raw,format=(string)H264" caps instead of "video/x-h264" for Logitech C920## Submitted by Marcos Kintschner
**[Link to original bug (#793939)](https://bugzilla.gnome.org/show_bug.cgi?id=793939)**
## Description
I'm using a webcam (Logitech C920) on Windows 10. Device monitor shows some caps containing "vi...## Submitted by Marcos Kintschner
**[Link to original bug (#793939)](https://bugzilla.gnome.org/show_bug.cgi?id=793939)**
## Description
I'm using a webcam (Logitech C920) on Windows 10. Device monitor shows some caps containing "video/x-raw, format(string)=H264", which AFAIK is not valid (it should be "video/x-h264").
Here are the full caps I got from device monitor:
___
gst-device-monitor-1.0.exe
Probing devices...
Device found:
name : HD Pro Webcam C920
class : Video/Source
caps : video/x-raw, format=(string)YUY2, width=(int)640, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)160, height=(int)90, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)160, height=(int)120, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)176, height=(int)144, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
video/x-raw, format=(string)YUY2, width=(int)320, height=(int)180, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)320, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)352, height=(int)288, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
video/x-raw, format=(string)YUY2, width=(int)432, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)640, height=(int)360, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)800, height=(int)448, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)800, height=(int)600, framerate=(fraction)[ 5/1, 24/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)864, height=(int)480, framerate=(fraction)[ 5/1, 24/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)960, height=(int)720, framerate=(fraction)[ 5/1, 15/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)1024, height=(int)576, framerate=(fraction)[ 5/1, 15/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, framerate=(fraction)[ 5/1, 10/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)1600, height=(int)896, framerate=(fraction)[ 5/1, 15/2 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, framerate=(fraction)5/1, pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)2304, height=(int)1296, framerate=(fraction)2/1, pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)YUY2, width=(int)2304, height=(int)1536, framerate=(fraction)2/1, pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)640, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)160, height=(int)90, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)160, height=(int)120, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)176, height=(int)144, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
video/x-raw, format=(string)H264, width=(int)320, height=(int)180, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)320, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)352, height=(int)288, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
video/x-raw, format=(string)H264, width=(int)432, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)640, height=(int)360, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)800, height=(int)448, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)800, height=(int)600, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)864, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)960, height=(int)720, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)1024, height=(int)576, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)1280, height=(int)720, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)1600, height=(int)896, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
video/x-raw, format=(string)H264, width=(int)1920, height=(int)1080, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)640, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)160, height=(int)90, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)160, height=(int)120, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)176, height=(int)144, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
image/jpeg, width=(int)320, height=(int)180, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)320, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)352, height=(int)288, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)12/11;
image/jpeg, width=(int)432, height=(int)240, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)640, height=(int)360, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)800, height=(int)448, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)800, height=(int)600, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)864, height=(int)480, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)960, height=(int)720, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)1024, height=(int)576, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)1280, height=(int)720, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)1600, height=(int)896, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
image/jpeg, width=(int)1920, height=(int)1080, framerate=(fraction)[ 5/1, 30/1 ], pixel-aspect-ratio=(fraction)1/1;
gst-launch-1.0 ksvideosrc device-path="\\\\\?\\usb\#vid_046d\&pid_082d\&mi_00\#7\&38a25b45\&0\&0000\#\{6994ad05-93ef-11d0-a3cc-00a0c9223196\}\\global" ! ...
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/86vaapisink: Crashes on padded (non-alpha) RGB video with AMD card2021-09-24T12:23:10ZBugzilla Migration Uservaapisink: Crashes on padded (non-alpha) RGB video with AMD card## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#793889)](https://bugzilla.gnome.org/show_bug.cgi?id=793889)**
## Description
$ gst-launch-1.0 multifilesrc location="/tmp/white.png" caps="image/png,framerate=\(...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#793889)](https://bugzilla.gnome.org/show_bug.cgi?id=793889)**
## Description
$ gst-launch-1.0 multifilesrc location="/tmp/white.png" caps="image/png,framerate=\(fraction\)3/1" ! pngdec ! videoconvert ! identity silent=false ! vaapisink -v
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx1";
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: stream-start (10254), GstEventStreamStart, stream-id=(string)116c669c7f52880c9f1b179be1334a19, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)0;) 0x55bdcbc9a8f0
/GstPipeline:pipeline0/GstMultiFileSrc:multifilesrc0.GstPad:src: caps = image/png, width=(int)1, height=(int)1, framerate=(fraction)3/1
/GstPipeline:pipeline0/GstPngDec:pngdec0.GstPad:sink: caps = image/png, width=(int)1, height=(int)1, framerate=(fraction)3/1
/GstPipeline:pipeline0/GstPngDec:pngdec0.GstPad:src: caps = video/x-raw, format=(string)RGB, width=(int)320, height=(int)240, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)sRGB, framerate=(fraction)3/1
/GstPipeline:pipeline0/GstVideoConvert:videoconvert0.GstPad:src: caps = video/x-raw, format=(string)BGRx, width=(int)320, height=(int)240, framerate=(fraction)3/1, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: caps (12814), GstEventCaps, caps=(GstCaps)"video/x-raw\,\ format\=\(string\)BGRx\,\ width\=\(int\)320\,\ height\=\(int\)240\,\ framerate\=\(fraction\)3/1\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1";) 0x7f5cd8005030
/GstPipeline:pipeline0/GstIdentity:identity0.GstPad:src: caps = video/x-raw, format=(string)BGRx, width=(int)320, height=(int)240, framerate=(fraction)3/1, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstVaapiSink:vaapisink0.GstPad:sink: caps = video/x-raw, format=(string)BGRx, width=(int)320, height=(int)240, framerate=(fraction)3/1, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstIdentity:identity0.GstPad:sink: caps = video/x-raw, format=(string)BGRx, width=(int)320, height=(int)240, framerate=(fraction)3/1, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstVideoConvert:videoconvert0.GstPad:sink: caps = video/x-raw, format=(string)RGB, width=(int)320, height=(int)240, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)sRGB, framerate=(fraction)3/1
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = event ******* (identity0:sink) E (type: segment (17934), GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";) 0x55bdcbc9aa40
/GstPipeline:pipeline0/GstIdentity:identity0: last-message = chain ******* (identity0:sink) (307200 bytes, dts: none, pts: 0:00:00.000000000, duration: 0:00:00.333333333, offset: -1, offset_end: -1, flags: 00000040 discont , meta: GstVideoMeta, GstVaapiVideoMeta) 0x7f5cd8009410
Caught SIGSEGV
```
#0 0x00007f5d1112d3db in poll () from /lib64/libc.so.6
#1 0x00007f5d11a7ae99 in g_main_context_iterate.isra ()
#2 0x00007f5d11a7b232 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3 0x00007f5d121df543 in gst_bus_poll () from /lib64/libgstreamer-1.0.so.0
#4 0x000055bdc9cc7aab in event_loop ()
#5 0x000055bdc9cc6b8e in main ()
Spinning. Please run 'gdb gst-launch-1.0 46210' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
^Chandling interrupt.
Interrupt: Stopping pipeline ...
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
```https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/85vaapisink: White is rendered pink with AMD card, wrong hue everywhere in RGBA...2021-09-24T12:23:09ZBugzilla Migration Uservaapisink: White is rendered pink with AMD card, wrong hue everywhere in RGBA and BGRA formats## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#793886)](https://bugzilla.gnome.org/show_bug.cgi?id=793886)**
## Description
Testcase:
$ gst-launch-1.0 multifilesrc location="frame_01.png" caps="image/png...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#793886)](https://bugzilla.gnome.org/show_bug.cgi?id=793886)**
## Description
Testcase:
$ gst-launch-1.0 multifilesrc location="frame_01.png" caps="image/png,framerate=\(fraction\)3/1" ! pngdec ! videoconvert ! vaapisink
Works fine with xvimagesink:
$ gst-launch-1.0 multifilesrc location="frame_01.png" caps="image/png,framerate=\(fraction\)3/1" ! pngdec ! videoconvert ! xvimagesinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/421gst-play-1.0 --videosink=fakesink : position gets confused2021-09-24T13:23:35ZBugzilla Migration Usergst-play-1.0 --videosink=fakesink : position gets confused## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#793726)](https://bugzilla.gnome.org/show_bug.cgi?id=793726)**
## Description
Use case: "Let me listen to the music on this video file"
gst-play-1.0 file.mp4 --...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#793726)](https://bugzilla.gnome.org/show_bug.cgi?id=793726)**
## Description
Use case: "Let me listen to the music on this video file"
gst-play-1.0 file.mp4 --videosink=fakesink
The time counter at the bottom of gst-play-1.0 progresses much more quickly than the audio, I assume it progresses according to the fakesink. If I pause, the correct position is displayed, but then unpausing doesn't work.
If I use --videosink="fakesink sync=true" it works fine.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/443wavparse: multi-channel audio playback with channels > 8 issue2021-09-24T13:32:53ZBugzilla Migration Userwavparse: multi-channel audio playback with channels > 8 issue## Submitted by Lyon
**[Link to original bug (#793709)](https://bugzilla.gnome.org/show_bug.cgi?id=793709)**
## Description
Hi,
We are facing issue that Gstreamer seems not support multi-channel audio with channels > 8.
i...## Submitted by Lyon
**[Link to original bug (#793709)](https://bugzilla.gnome.org/show_bug.cgi?id=793709)**
## Description
Hi,
We are facing issue that Gstreamer seems not support multi-channel audio with channels > 8.
in WavParse or audioconvert, riff-media etc, always there will report can't negotiate or no default layout / no channnel-mask property given etc...
I was trying to modify some table for more channels case, like default_mask[], but seems the original idea in current Gstreamer 8 channl is the maximum.
I'm wondering is there any plan to support multi-channel audio with channels>8 cases?
Thanks a lot~
Attached an audio clip(wav) with 10 channels.
It can be played by aplay on our target board, but with Gstreamer, seems failed to created the pipeline with negotiate failure
Thanks
Lyon
Version: 1.13.x