gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2021-09-24T13:33:20Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/566matroskademux: race when src pads are created2021-09-24T13:33:20ZKristofermatroskademux: race when src pads are createdA race condition exists in matroska-demux.c
When it occurs:
The application thread, AT is changing state from PAUSED->READY.
The Streaming thread, ST is in the process of setting up a src pad eg Audio.
ST is in the process of creating ...A race condition exists in matroska-demux.c
When it occurs:
The application thread, AT is changing state from PAUSED->READY.
The Streaming thread, ST is in the process of setting up a src pad eg Audio.
ST is in the process of creating the src PAD and concurrently AT is closing down the same src PAD.
I our specific case the problem was seen when the signal "pad-added" was calling a callback (in ST). That callback
will do linking. But when it tried to get the src PAD caps by gst_pad_get_current_caps there were no caps.
They had been removed precisely before by AT.
AT was doing:
gst_element_change_state_func -> gst_element_pads_activate (element, FALSE) ->gst_pad_set_active->>activate_mode_internal> post_activate->remove_events (pad)
ST was doing:
gst_matroska_demux_add_stream -> "pad-added" signal CB
One possible solution is to add a gst_pad_set_activatemode_function to each src PAD created. In that function one
calls gst_pad_stop_task (src PAD) that will stop the ST and join it with AT. At least one downside with this proposed solution is that the gst_pad_stop_task will be called several times once from sink and some from the src PADs (now only sink PAD has a gst_pad_set_activatemode_function that closes down the ST by calling gst_pad_stop_task). Also the Streamin thread probably belongs to sink PAD not to src PAD/PADs.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/565v4l2: Add mapping for V4L2_PIX_FMT_YUY322021-09-24T13:33:20ZNicolas Dufresnev4l2: Add mapping for V4L2_PIX_FMT_YUY32Documented here:
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-packed-yuv.html
This formats matches GST_VIDEO_FORMAT_AYUV which is mostly only used by pack/unpack function for generic color convertion, but apparently it's ...Documented here:
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/pixfmt-packed-yuv.html
This formats matches GST_VIDEO_FORMAT_AYUV which is mostly only used by pack/unpack function for generic color convertion, but apparently it's also possible to use this on some IMX hardware (PXP / IPUv3 ?).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/563validate.rtsp.playback.seek_backward.bowlerhatdancer_sleepytom_SGP_mjpeg_avi ...2021-09-24T13:33:20ZThibault Sauniertsaunier@igalia.comvalidate.rtsp.playback.seek_backward.bowlerhatdancer_sleepytom_SGP_mjpeg_avi sometimes fails as EOS is received before the scenario finishes```
validate.rtsp.playback.seek_backward.bowlerhatdancer_sleepytom_SGP_mjpeg_avi: Failed 'Application returned 18 (critical errors: [The program stopped before some actions were executed])'
You can reproduce with: /builds/thiblahu...```
validate.rtsp.playback.seek_backward.bowlerhatdancer_sleepytom_SGP_mjpeg_avi: Failed 'Application returned 18 (critical errors: [The program stopped before some actions were executed])'
You can reproduce with: /builds/thiblahute/gst-ci/gst-build/build/subprojects/gst-devtools/validate/tools/gst-validate-rtsp-server-1.0 file:///builds/thiblahute/gst-ci/validate-output/gst-integration-testsuites/medias/defaults/avi/bowlerhatdancer.sleepytom.SGP.mjpeg.avi --port 51987 & GST_VALIDATE_SCENARIOS_PATH='/builds/thiblahute/gst-ci/gst-build/prefix/share/gstreamer-1.0/validate/scenarios:/builds/thiblahute/gst-ci/gst-build/subprojects/gst-devtools/validate/data/scenarios' GST_GL_XINITTHREADS='1' DISPLAY=':27' GST_VALIDATE_SCENARIO='seek_backward' /builds/thiblahute/gst-ci/gst-build/build/subprojects/gst-devtools/validate/tools/gst-validate-1.0 playbin uri=rtsp://127.0.0.1:51987/test 'audio-sink=fakesink sync=true' 'video-sink=fakevideosink qos=true max-lateness=20000000' --set-media-info /builds/thiblahute/gst-ci/validate-output/gst-integration-testsuites/medias/defaults/avi/bowlerhatdancer.sleepytom.SGP.mjpeg.avi.media_info
Dumping log files on failure
Dumping contents of /builds/thiblahute/gst-ci/validate-output/logs/validate/rtsp/playback/seek_backward/bowlerhatdancer_sleepytom_SGP_mjpeg_avi
=================
Test name: validate.rtsp.playback.seek_backward.bowlerhatdancer_sleepytom_SGP_mjpeg_avi
Command: '/builds/thiblahute/gst-ci/gst-build/build/subprojects/gst-devtools/validate/tools/gst-validate-1.0 playbin uri=rtsp://127.0.0.1:51987/test audio-sink=fakesink sync=true video-sink=fakevideosink qos=true max-lateness=20000000 --set-media-info /builds/thiblahute/gst-ci/validate-output/gst-integration-testsuites/medias/defaults/avi/bowlerhatdancer.sleepytom.SGP.mjpeg.avi.media_info'
=================
=========================================
Running scenario seek_backward on pipeline playbin0
=========================================
Starting pipeline
Prerolling...
Pipeline started
<position: 0:00:00.000000000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.000000000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.000000000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.000000000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.000000000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.000000000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.000000000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.000000000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.155201454 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.405882502 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.656817988 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.907820751 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:01.158356358 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:01.408456372 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:01.658962866 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:01.909313084 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:02.160154770 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:02.411236337 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:02.661707506 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:02.911765340 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:03.162750806 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:03.412799125 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:03.663013558 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:03.913925059 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:04.164981512 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:04.415865591 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:04.666733200 duration: 0:00:19.400000000 speed: 1.000000 />
Executing (subaction)seek (
- name=Backward-seek
- playback-time=0:00:04.850000000
- rate=1
- start=0:00:00.000000000
- flags=accurate+flush
)
-> Action seek done (duration: 0:00:02.015809950)
<position: 0:00:00.032731588 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.282802972 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.533765603 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:00.784459177 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:01.034592918 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:01.284700140 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:01.535286550 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:01.785553848 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:02.036298952 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:02.286847648 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:02.536981460 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:02.787267165 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:03.038219108 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:03.288515423 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:03.539024533 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:03.789155752 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:04.039346998 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:04.290102933 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:04.540469961 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:04.790729305 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:05.041436394 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:05.291777308 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:05.542160315 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:05.792973696 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:06.043365012 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:06.293498297 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:06.544097954 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:06.794736430 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:07.044984185 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:07.295819520 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:07.546895281 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:07.797202425 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:08.047869269 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:08.298457474 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:08.549181000 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:08.799560121 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:09.050271404 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:09.300384521 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:09.550912332 duration: 0:00:19.400000000 speed: 1.000000 />
Executing (subaction)seek (
- name=Backward-seek
- playback-time=0:00:09.700000000
- rate=1
- start=0:00:04.850000000
- flags=accurate+flush
)
-> Action seek done (duration: 0:00:02.012685025)
<position: 0:00:04.918380035 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:05.169285373 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:05.420209043 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:05.670463402 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:05.921143396 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:06.171425198 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:06.422329527 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:06.672637119 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:06.923406499 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:07.174055247 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:07.424731392 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:07.675731403 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:07.926802217 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:08.177089212 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:08.427292822 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:08.678117153 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:08.928381871 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:09.178699972 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:09.428913149 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:09.679692932 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:09.942084931 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:10.180813083 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:10.431295651 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:10.682055344 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:10.932528869 duration: 0:00:19.400000000 speed: 1.000000 />
<position: 0:00:11.183287077 duration: 0:00:19.400000000 speed: 1.000000 />
Executing stop ( )
seek_backward --> State change request NULL, quiting mainloop
<position: 0:00:11.402724409 duration: 0:00:19.400000000 speed: 1.000000 />
warning : a new segment event has different value than the received one
Detected on <rtpjpegdepay0:src>
Description : when receiving a new segment, an element should push an equivalent segment downstream
warning : received the same caps twice
Detected on <rtpjpegdepay0:sink>
Detected on <jpegdec0:sink>
Detected on <typefind:sink>
warning : Buffer didn't have expected DISCONT flag
Detected on <rtpsession0:send_rtcp_src>
Detected on <udpsink1:sink>
Detected on <udpsrc0:src>
Detected on <rtpsession0:recv_rtp_sink>
Detected on <rtpsession0:recv_rtp_src>
Detected on <rtpstorage0:sink>
Detected on <rtpstorage0:src>
Detected on <rtpssrcdemux0:sink>
Detected on <rtpssrcdemux0:src_88543734>
Detected on <rtpjitterbuffer0:sink>
Detected on <udpsrc1:src>
Detected on <rtpsession0:recv_rtcp_sink>
Detected on <rtpsession0:sync_src>
Detected on <rtpssrcdemux0:rtcp_sink>
Detected on <rtpssrcdemux0:rtcp_src_88543734>
Detected on <rtpjitterbuffer0:sink_rtcp>
Description : Buffers after SEGMENT and FLUSH must have a DISCONT flag
warning : a serialized event received should be pushed in the same 'time' as it was received
Detected on <rtpjpegdepay0:src>
Description : serialized events should be pushed in the same order they are received and serialized with buffers. If an event is received after a buffer with timestamp end 'X', it should be pushed right after buffers with timestamp end 'X'
warning : Query position reported a value outside of the current expected segment
Detected on <seek_backward>
issue : FLUSH_START events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <typefind:src>
Detected on <rtpjpegdepay0:src>
Detected on <jpegdec0:src>
Detected on <inputselector0:src>
Detected on <streamsynchronizer0:src_0>
Detected on <vdconv:src>
Detected on <deinterlace:src>
Detected on <vqueue:src>
Detected on <conv:src>
Detected on <scale:src>
Detected on <videobalance:src>
Detected on <conv2:src>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
issue : FLUSH_STOP events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <typefind:src>
Detected on <rtpjpegdepay0:src>
Detected on <jpegdec0:src>
Detected on <inputselector0:src>
Detected on <streamsynchronizer0:src_0>
Detected on <vdconv:src>
Detected on <deinterlace:src>
Detected on <vqueue:src>
Detected on <conv:src>
Detected on <scale:src>
Detected on <videobalance:src>
Detected on <conv2:src>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
issue : SEGMENT events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <udpsrc0:src>
Detected on <rtpsession0:recv_rtp_sink>
Detected on <rtpsession0:recv_rtp_src>
Detected on <rtpstorage0:sink>
Detected on <rtpstorage0:src>
Detected on <rtpssrcdemux0:sink>
Detected on <rtpssrcdemux0:src_88543734>
Detected on <rtpjitterbuffer0:sink>
Detected on <rtpjitterbuffer0:src>
Detected on <rtpptdemux0:sink>
Detected on <rtpptdemux0:src_96>
Detected on <typefind:sink>
Detected on <typefind:src>
Detected on <rtpjpegdepay0:sink>
Detected on <rtpjpegdepay0:src>
Detected on <jpegdec0:sink>
Detected on <jpegdec0:src>
Detected on <inputselector0:sink_0>
Detected on <inputselector0:src>
Detected on <streamsynchronizer0:sink_0>
Detected on <streamsynchronizer0:src_0>
Detected on <vdconv:sink>
Detected on <vdconv:src>
Detected on <deinterlace:sink>
Detected on <deinterlace:src>
Detected on <vqueue:sink>
Detected on <vqueue:src>
Detected on <conv:sink>
Detected on <conv:src>
Detected on <scale:sink>
Detected on <scale:src>
Detected on <videobalance:sink>
Detected on <videobalance:src>
Detected on <conv2:sink>
Detected on <conv2:src>
Detected on <sink:sink>
Detected on <udpsrc1:src>
Detected on <rtpsession0:recv_rtcp_sink>
Detected on <rtpsession0:sync_src>
Detected on <rtpssrcdemux0:rtcp_sink>
Detected on <rtpssrcdemux0:rtcp_src_88543734>
Detected on <rtpjitterbuffer0:sink_rtcp>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
issue : EOS events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <udpsrc0:src>
Detected on <rtpsession0:recv_rtp_sink>
Detected on <rtpsession0:recv_rtp_src>
Detected on <rtpstorage0:sink>
Detected on <rtpstorage0:src>
Detected on <rtpssrcdemux0:sink>
Detected on <rtpssrcdemux0:src_88543734>
Detected on <rtpjitterbuffer0:sink>
Detected on <rtpsession0:send_rtcp_src>
Detected on <udpsink1:sink>
Detected on <rtpjitterbuffer0:src>
Detected on <rtpptdemux0:sink>
Detected on <rtpptdemux0:src_96>
Detected on <typefind:sink>
Detected on <typefind:src>
Detected on <rtpjpegdepay0:sink>
Detected on <rtpjpegdepay0:src>
Detected on <jpegdec0:sink>
Detected on <jpegdec0:src>
Detected on <inputselector0:sink_0>
Detected on <inputselector0:src>
Detected on <streamsynchronizer0:sink_0>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
critical : The program stopped before some actions were executed
Detected on <seek_backward>
Details : 1 actions were not executed:
seek, name=(string)Backward-seek, playback-time=(guint64)14550000000, rate=(double)1, start=(string)"min\(10.0\,\ 2\*\(duration/4\)\)", flags=(string)accurate+flush;
dotfile : no dotfile produced as GST_DEBUG_DUMP_DOT_DIR is not set.
backtrace :
gst_debug_get_stack_trace (gstinfo.c:2886)
gst_validate_report_new (gst-validate-report.c:729)
gst_validate_report_valist (gst-validate-reporter.c:186)
gst_validate_report (gst-validate-reporter.c:303)
message_cb (gst-validate-scenario.c:2764)
ffi_call_unix64 (/usr/lib64/libffi.so.6.0.2:0x7fee645c7aca)
ffi_call (/usr/lib64/libffi.so.6.0.2:0x7fee645c748b)
g_cclosure_marshal_generic (/usr/lib64/libgobject-2.0.so.0.5800.2:0x7fee64c4dea1)
g_closure_invoke (/usr/lib64/libgobject-2.0.so.0.5800.2:0x7fee64c4d3d9)
?? (/usr/lib64/libgobject-2.0.so.0.5800.2:0x7fee64c6097f)
g_signal_emit_valist (/usr/lib64/libgobject-2.0.so.0.5800.2:0x7fee64c69aa6)
g_signal_emit (/usr/lib64/libgobject-2.0.so.0.5800.2:0x7fee64c6a09f)
gst_bus_async_signal_func (gstbus.c:1251)
gst_bus_source_dispatch (gstbus.c:839)
g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0.5800.2:0x7fee64ce1069)
?? (/usr/lib64/libglib-2.0.so.0.5800.2:0x7fee64ce1434)
g_main_loop_run (/usr/lib64/libglib-2.0.so.0.5800.2:0x7fee64ce175e)
main (gst-validate.c:526)
__libc_start_main (/usr/lib64/libc-2.28.so:0x7fee648cc40f)
_start (/builds/thiblahute/gst-ci/gst-build/build/subprojects/gst-devtools/validate/tools/gst-validate-1.0:0x403efa)
==== Got criticals. Return value set to 18 ====
Critical error 1 actions were not executed:
seek, name=(string)Backward-seek, playback-time=(guint64)14550000000, rate=(double)1, start=(string)"min\(10.0\,\ 2\*\(duration/4\)\)", flags=(string)accurate+flush;
Issues found: 10
Returning 18 as errors were found
=======> Test FAILED (Return value: 18)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/560v4l2transform: Automatically disable passthrough is2021-09-24T13:33:19ZNicolas Dufresnev4l2transform: Automatically disable passthrough isProblem we have right now is that whenever an extra-control is set, the extra controls only take effect if the element isn't going passthrough. This is a proposal to automatically disable passthrough whenever controls are set (regardless...Problem we have right now is that whenever an extra-control is set, the extra controls only take effect if the element isn't going passthrough. This is a proposal to automatically disable passthrough whenever controls are set (regardless of the control). This way, if you enable things like hflip, you do not get hflip applied randomly depending on the caps negotiation.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/551flac: Transcoding result in no audio (underflow)2021-09-24T13:33:17ZNicolas Dufresneflac: Transcoding result in no audio (underflow)I was surprised to find out, but a simple encoder/parse/decoder chain leads to no audio, disabling the sync fixes it.
```
gst-launch-1.0 pulsesrc ! flacenc ! flacparse ! flacdec ! pulsesink sync=1
```
p.s. I also don't know why a parse...I was surprised to find out, but a simple encoder/parse/decoder chain leads to no audio, disabling the sync fixes it.
```
gst-launch-1.0 pulsesrc ! flacenc ! flacparse ! flacdec ! pulsesink sync=1
```
p.s. I also don't know why a parser is required.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/539Pulsesink: “Disconnected: Bad state” error printed when play an audio with v...2021-09-24T13:33:15ZQi HouPulsesink: “Disconnected: Bad state” error printed when play an audio with varying number of channelsWhen play audio with varying number of channels, error like "Disconnected: Bad state" always appears when the number of channels changes. The issue is caused by stream check in function gst_pulsesink_get_sink_input_info () in pulsesink.c...When play audio with varying number of channels, error like "Disconnected: Bad state" always appears when the number of channels changes. The issue is caused by stream check in function gst_pulsesink_get_sink_input_info () in pulsesink.c. Is it necessary to check the state of pbuf->stream in function gst_pulsesink_get_sink_input_info ()?
If we don't check the state of stream in function gst_pulsesink_get_sink_input_info () in pulsesink.c like below by change TRUE to FALSE, then the audio can play normally. The attachment is the tested audio with varying number of channels.
while (pa_operation_get_state (o) == PA_OPERATION_RUNNING) {
pa_threaded_mainloop_wait (mainloop);
if (gst_pulsering_is_dead (psink, pbuf, FALSE))
goto unlock;
}
[AC3_48_448_Ch_all_acmodswp.ac3](/uploads/fecf8f370422cdb1d58ff6fa8327f865/AC3_48_448_Ch_all_acmodswp.ac3)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/529gstgtk: support CSS background if ignore-alpha is false2021-09-24T13:33:15ZJuan Pablo Ugartegstgtk: support CSS background if ignore-alpha is falseUse gtk_render_background() to render the background when the widget is honoring alphaUse gtk_render_background() to render the background when the widget is honoring alphahttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/526rtpg729depay not able to store correct audio data for codec G.729 annex B. N...2021-09-24T13:33:14ZSameer Thapartpg729depay not able to store correct audio data for codec G.729 annex B. No depayloader for the codec G.729 annex B or annex AMy app records rtp data from stream. It records fine for G.729 codec but not for G.729 B or A codecs. Following is the pipeline used in program:
udpsrc port=5008 caps="application/x-rtp,channels=(int)1,media=(string)audio,payload=(int)1...My app records rtp data from stream. It records fine for G.729 codec but not for G.729 B or A codecs. Following is the pipeline used in program:
udpsrc port=5008 caps="application/x-rtp,channels=(int)1,media=(string)audio,payload=(int)18,clock-rate=(int)8000,encoding-name=(string)G729" ! rtpg729depay ! filesink
Attached is a file recorded by using this pipeline for data encoded as G.729 B:
[7a6e3680-bed16aaa-1a1-1603a8c0.g729](/uploads/c3d8a33508ecb98f8ac454a08492fbe6/7a6e3680-bed16aaa-1a1-1603a8c0.g729)
When we try to convert the generated file to wav or mp3, sound is not clear. Attached is a sample audio after conversion(conversion is done using ffmpeg). [7a6e3680-bed16aaa-1a1-1603a8c0.wav](/uploads/9e5b250ecce786cb0374fc602b99d336/7a6e3680-bed16aaa-1a1-1603a8c0.wav)
Please let me know if there is any issue with the pipeline or if the codec is not supported by gstreamer.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/520v4l2deviceprober: Mark if cameras are front facing or back camera2021-09-24T13:33:13ZThibault Sauniertsaunier@igalia.comv4l2deviceprober: Mark if cameras are front facing or back cameraBasically in WebKit WebRTC we need to have that information and expose it to the application, currently we do not extract the information. The way we expose it should be common to all camera device provider.Basically in WebKit WebRTC we need to have that information and expose it to the application, currently we do not extract the information. The way we expose it should be common to all camera device provider.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/509splitmuxsink: last splitmuxsink-fragment-closed message is sent before file c...2021-09-24T13:33:13ZBugzilla Migration Usersplitmuxsink: last splitmuxsink-fragment-closed message is sent before file close() is called## Submitted by Peter Seiderer `@psreport`
**[Link to original bug (#797265)](https://bugzilla.gnome.org/show_bug.cgi?id=797265)**
## Description
Strace of a video encoding pipeline using splitmuxsink shows the following sequence fo...## Submitted by Peter Seiderer `@psreport`
**[Link to original bug (#797265)](https://bugzilla.gnome.org/show_bug.cgi?id=797265)**
## Description
Strace of a video encoding pipeline using splitmuxsink shows the following sequence for each fragment file besides the last one:
openat() --> splitmuxsink-fragment-opened --> close() --> splitmuxsink-fragment-closed
For the last fragment the sequence is as follows:
openat() --> splitmuxsink-fragment-opened --> splitmuxsink-fragment-closed --> close()
This leads to problems in case one registers on the splitmuxsink-fragment messages for file post-processing...
Strace output:
$ strace -tt -e openat,write,close -fo out_strace.log gst-launch-1.0 -m -v -e v4l2src device=/dev/v4l/by-path/platform-capture-subsystem-video-index4 io-mode=dmabuf ! \
video/x-raw,format=NV12,width=1920,height=1080,framerate=60000/1001 ! \
videorate drop-only=true ! \
video/x-raw,format=NV12,width=1920,height=1080,framerate=30000/1001 ! \
v4l2h264enc ! \
h264parse ! \
splitmuxsink location='Video_%d.mp4' max-size-time=5000000000
Video_0.mp4: 11264 16:00:07.905127 openat(AT_FDCWD, "Video_0.mp4", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 43
Video_0.mp4: 11263 16:00:08.945458 write(1, "splitmuxsink-fragment-opened, lo"..., 97) = 97
Video_0.mp4: 11264 16:00:13.108542 close(43) = 0
Video_1.mp4: 11264 16:00:13.111136 openat(AT_FDCWD, "Video_1.mp4", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 43
Video_0.mp4: 11263 16:00:14.122644 write(1, "splitmuxsink-fragment-closed, lo"..., 106) = 106
Video_1.mp4: 11263 16:00:14.493838 write(1, "splitmuxsink-fragment-opened, lo"..., 106) = 106
Video_1.mp4: 11264 16:00:17.913117 close(43) = 0
Video_2.mp4: 11264 16:00:17.939201 openat(AT_FDCWD, "Video_2.mp4", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 43
Video_1.mp4: 11263 16:00:18.937365 write(1, "splitmuxsink-fragment-closed, lo"..., 106) = 106
Video_2.mp4: 11263 16:00:19.319019 write(1, "splitmuxsink-fragment-opened, lo"..., 106) = 106
Video_2.mp4: 11264 16:00:22.717010 close(43) = 0
Video_3.mp4: 11264 16:00:22.730683 openat(AT_FDCWD, "Video_3.mp4", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 43
Video_2.mp4: 11263 16:00:23.734459 write(1, "splitmuxsink-fragment-closed, lo"..., 107) = 107
Video_3.mp4: 11263 16:00:24.102944 write(1, "splitmuxsink-fragment-opened, lo"..., 107) = 107
Video_3.mp4: 11263 16:00:25.783489 write(1, "splitmuxsink-fragment-closed, lo"..., 107) = 107
11263 16:00:25.855549 write(1, "Setting pipeline to NULL ...\n", 29) = 29
Video_2.mp4: 11263 16:00:25.856492 close(43) = 0
11263 16:00:25.860930 write(1, "Freeing pipeline ...\n", 21) = 21
Version: 1.14.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/508[udp]: Add property to allow multicast sockets to be bound to multicast addre...2021-09-24T13:33:12ZBugzilla Migration User[udp]: Add property to allow multicast sockets to be bound to multicast addresses## Submitted by Patricia Muscalu
**[Link to original bug (#797224)](https://bugzilla.gnome.org/show_bug.cgi?id=797224)**
## Description
It should be possible to configure the multicast sockets to be bound to multicast addresses, e.g...## Submitted by Patricia Muscalu
**[Link to original bug (#797224)](https://bugzilla.gnome.org/show_bug.cgi?id=797224)**
## Description
It should be possible to configure the multicast sockets to be bound to multicast addresses, e.g. in situations when it's desired that the traffic received on the socket is restricted to the multicast traffic only.
See https://bugzilla.gnome.org/show_bug.cgi?id=797059 for more information.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/507aacparse: Don't intersect with input caps to convert output format in renegot...2021-09-24T13:33:12ZBugzilla Migration Useraacparse: Don't intersect with input caps to convert output format in renegotiation## Submitted by Yeongjin Jeong
**[Link to original bug (#797120)](https://bugzilla.gnome.org/show_bug.cgi?id=797120)**
## Description
Created attachment 373602
aacparse: Don't intersect with input caps to convert output format in ...## Submitted by Yeongjin Jeong
**[Link to original bug (#797120)](https://bugzilla.gnome.org/show_bug.cgi?id=797120)**
## Description
Created attachment 373602
aacparse: Don't intersect with input caps to convert output format in renegotiation
It should only intersect with stream-format to convert output format when intersection fails in renegotiation case.
It is needed to mux AAC samples, such as requires multiple sample descriptions in isomp4.
**Patch 373602**, "aacparse: Don't intersect with input caps to convert output format in renegotiation":
[0001-aacparse-Don-t-intersect-with-input-caps-to-convert-.patch](/uploads/a2dba9ede00d7db9f2ecdef6a160d0a8/0001-aacparse-Don-t-intersect-with-input-caps-to-convert-.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/506v4l2object: Should read the pixel aspect ratio in gst_v4l2_object_acquire_for...2021-09-24T13:33:12ZBugzilla Migration Userv4l2object: Should read the pixel aspect ratio in gst_v4l2_object_acquire_format()## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797105)](https://bugzilla.gnome.org/show_bug.cgi?id=797105)**
## Description
The pixel aspect ratio is read at probe time using CROPCAP. Though, for m2m decoder...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797105)](https://bugzilla.gnome.org/show_bug.cgi?id=797105)**
## Description
The pixel aspect ratio is read at probe time using CROPCAP. Though, for m2m decoder, the PAR is only known after the headers has been processed by the driver. For this reason, gst_v4l2_object_acquire_format(), which reads the format returned by the driver, should also read the CROPCAP.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/503v4l2vp8dec: renders frames in the wrong order with Wayland on a Dragonboard 410c2021-09-24T13:33:11ZBugzilla Migration Userv4l2vp8dec: renders frames in the wrong order with Wayland on a Dragonboard 410c## Submitted by bug..@..uve.fr
**[Link to original bug (#797056)](https://bugzilla.gnome.org/show_bug.cgi?id=797056)**
## Description
Created attachment 373507
Animated Inubashiri Momiji
This is on a Dragonboard 410c[1], usin...## Submitted by bug..@..uve.fr
**[Link to original bug (#797056)](https://bugzilla.gnome.org/show_bug.cgi?id=797056)**
## Description
Created attachment 373507
Animated Inubashiri Momiji
This is on a Dragonboard 410c[1], using Linux 4.14.0 as provided by Linaro[2], using an up to date ALARM[3].
A short animation reproducing this bug is attached.
It displays a frame from the future about each half a second when using filesrc ! matroskademux ! v4l2vp8dec ! waylandsink.
Even with capture-io-mode=mmap (thus using wl_shm rather than linux_dmabuf for Wayland buffer upload), this still happens.
[1] https://www.96boards.org/product/dragonboard410c/
[2] https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/18.01/
[3] https://archlinuxarm.org/
**Attachment 373507**, "Animated Inubashiri Momiji":
![1474323580126](/uploads/7416f4a52d462a1716aec54b01cb6b43/1474323580126.webm)
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/501v4l2convert can't import padded DMA buffers2021-09-24T13:33:11ZBugzilla Migration Userv4l2convert can't import padded DMA buffers## Submitted by Philipp Zabel `@pH5`
**[Link to original bug (#796986)](https://bugzilla.gnome.org/show_bug.cgi?id=796986)**
## Description
gst_v4l2_object_set_format already handles VIDIOC_S_FMT returning larger than requested buff...## Submitted by Philipp Zabel `@pH5`
**[Link to original bug (#796986)](https://bugzilla.gnome.org/show_bug.cgi?id=796986)**
## Description
gst_v4l2_object_set_format already handles VIDIOC_S_FMT returning larger than requested buffers, and sets GstVideoMeta appropriately for the added padding.
This happens for example for v4l2videodec, which can produce buffers padded to macroblock alignment.
Currently such padded DMA buffers can't be imported info v4l2convert, as the OUTPUT queue format is set to the visible size, which causes VIDIOC_QBUF to fail with the incompatible larger DMA buffers.
A gst_v4l2_object_set_format variant is needed that gets passed the padding information obtained from GstVideoMeta, to actually request a compatible format at the importing OUTPUT queue. I'm unsure whether the parameter added to this _set_format variant should be GstVideoMeta directly, a derived GstVideoInfo, or even GstVideoAlignment.
Setting a padded queue format, and then setting the processed rectangle via the crop selection would allow v4l2convert to handle imported DMA buffers that are larger in either width or height than the negotiated visible size.
### Depends on
* [Bug 583890](https://bugzilla.gnome.org/show_bug.cgi?id=583890)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/500flvmux: Don't set DELTA_UNIT flag on audio buffer for non-audio only case2021-09-24T13:33:11ZBugzilla Migration Userflvmux: Don't set DELTA_UNIT flag on audio buffer for non-audio only case## Submitted by Seungha Yang
**[Link to original bug (#796969)](https://bugzilla.gnome.org/show_bug.cgi?id=796969)**
## Description
Unset DELTA_UNIT on audio buffer could make sense, however,
if downstream is waiting keyframe, the...## Submitted by Seungha Yang
**[Link to original bug (#796969)](https://bugzilla.gnome.org/show_bug.cgi?id=796969)**
## Description
Unset DELTA_UNIT on audio buffer could make sense, however,
if downstream is waiting keyframe, the downstream could be confused,
That is, downstream cannot know which buffer is a video keyframe,
because flvmux unset DELTA_UNIT flag on both keyframe and audio buffer.
Since the original intention of the code was
"mark the buffer if it's an audio buffer and there's also
video being muxed or it's a video interframe", rollback to previous
behavior before the commit 8b814f6.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/499rtspsrc: no error on timeout2021-09-24T13:33:10ZBugzilla Migration Userrtspsrc: no error on timeout## Submitted by Christian Lindeberg
**[Link to original bug (#796966)](https://bugzilla.gnome.org/show_bug.cgi?id=796966)**
## Description
Created attachment 373348
Proposed patch
When streaming from an RTSP source and a conn...## Submitted by Christian Lindeberg
**[Link to original bug (#796966)](https://bugzilla.gnome.org/show_bug.cgi?id=796966)**
## Description
Created attachment 373348
Proposed patch
When streaming from an RTSP source and a connection error occurs because of a temporary power loss in the source then there is no error informing the application that the steaming ended unexpectedly.
**Patch 373348**, "Proposed patch":
[0001-rtspsrc-Error-on-timeout.patch](/uploads/3992de48966fcadd3c71102b405043b6/0001-rtspsrc-Error-on-timeout.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/497multiudpsink not works properly2021-09-24T13:33:10ZBugzilla Migration Usermultiudpsink not works properly## Submitted by Mike
**[Link to original bug (#796939)](https://bugzilla.gnome.org/show_bug.cgi?id=796939)**
## Description
gst-launch-1.0 uridecodebin uri=\"file:///home/user/file.mp3\" ! tee name=t ! queue ! volume name=localVol !...## Submitted by Mike
**[Link to original bug (#796939)](https://bugzilla.gnome.org/show_bug.cgi?id=796939)**
## Description
gst-launch-1.0 uridecodebin uri=\"file:///home/user/file.mp3\" ! tee name=t ! queue ! volume name=localVol ! autoaudiosink sync=false t. ! queue ! audioconvert ! rtpL16pay ! multiudpsink clients=192.168.0.58:7000
This pipeline fails In case of 192.168.0.58 is switched off instead of sounds just to autoaudiosink as tee.
In case 192.168.0.58 is online, even if receiving pipeline if switched off - local sink (autoaudiosink) sounds as expected.
This problem is observed in Gstreamer 1.14.1 as well in 1.14.2, However in 1.8.3 there is no such issue.
Version: 1.14.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/496All mkv files generated by matroskamux are broken with audio and video present2021-09-24T13:33:10ZBugzilla Migration UserAll mkv files generated by matroskamux are broken with audio and video present## Submitted by Markus Ebner
**[Link to original bug (#796938)](https://bugzilla.gnome.org/show_bug.cgi?id=796938)**
## Description
No matter what pipeline generates a matroska file, the generated file is always broken when audio an...## Submitted by Markus Ebner
**[Link to original bug (#796938)](https://bugzilla.gnome.org/show_bug.cgi?id=796938)**
## Description
No matter what pipeline generates a matroska file, the generated file is always broken when audio and video are present.
# Generated from remuxing an existing mp4 file
wget https://www.sample-videos.com/video/mp4/720/big_buck_bunny_720p_10mb.mp4
gst-launch-1.0 filesrc location="big_buck_bunny_720p_10mb.mp4" ! parsebin name="demux" ! h264parse ! queue ! matroskamux name="mux" ! filesink location="1.mkv" demux. ! aacparse ! queue ! mux.
# Generated from test sources:
gst-launch-1.0 videotestsrc num-buffers=150 ! x265enc ! h265parse ! matroskamux name=mux ! filesink location="2.mkv" audiotestsrc num-buffers=150 ! lamemp3enc ! mux.
# Generated from test-source only using video:
gst-launch-1.0 videotestsrc num-buffers=150 ! videoconvert ! x264enc ! matroskamux name=mux ! filesink location="3.mkv"
mkvalidate as well as mpv both complain about the files 1.mkv and 2.mkv, whereas file 3.mkv does not seem to contain format errors.
The error does have something to do with keyframes, so this bug might have something to do with that one: https://bugzilla.gnome.org/show_bug.cgi?id=794105
Version: 1.14.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/495Issue with h264depay and avdec_h264 when using rtpulpfecenc/dec !2021-09-24T13:33:09ZBugzilla Migration UserIssue with h264depay and avdec_h264 when using rtpulpfecenc/dec !## Submitted by Dark_Knight
**[Link to original bug (#796929)](https://bugzilla.gnome.org/show_bug.cgi?id=796929)**
## Description
Created attachment 373283
Sample code for FEC sender and receiver with h264
Hello All,
I...## Submitted by Dark_Knight
**[Link to original bug (#796929)](https://bugzilla.gnome.org/show_bug.cgi?id=796929)**
## Description
Created attachment 373283
Sample code for FEC sender and receiver with h264
Hello All,
I am currently working on adding elements rtpulpfecenc and rtpulpfecdec
to my sender and receiver pipelines respectively. The example program for
these were written in rust and uses rtpvp8pay /depay along with vp8enc
and vp8dec . Since my application is only compatible with
rtph264pay/depay ,I have used ,
*Sender:*
filesrc >> decodebin >> videoconvert >> queue >> rtph264pay >> Queue >>
rtpbin ( rtpulpfecenc > rtpsession ) >> udpsink
*Receiver :*
udpsrc>> netsim >>rtpbin ( funnel > rtpsession > rtpstorage > rtpssrcdemux >
rtpjitterbuffer > rtpptdemux > rtpulpfecdec ) >> rtph264depay >> h264parse
>> capsfilter >> *decodebin *>>videoconvert >> videoscale >> capsfilter >>
x264enc >> matroskamux >> filesink
I am setting the fec percentage as 10 on sender and drop as 1 % on receiver
side , I am getting the ratio of packets unrecovered : recovered , But Issue
is that decode bin at the receiver side uses *avdec_h264 *internally as
decoder , it is producing the following errors,
/0:00:09.053600607 26017 0x7f7f6c003230 ERROR libav :0:: {] Missing
reference picture, default is 0
0:00:09.053652680 26017 0x7f7f6c003230 ERROR libav :0:: {]
decode_slice_header error
0:00:09.118489816 26017 0x7f7f6c003230 ERROR libav :0:: {] Missing reference
picture, default is 2
0:00:09.641810087 26017 0x7f7f6c003230 ERROR libav :0:: {]
decode_slice_header error
0:00:09.657737341 26017 0x7f7f6c003230 ERROR libav :0:: {] Missing
reference/
Attached below is the logs related to the same :
log_with_decode_bin_ERROR_.txt
<http://gstreamer-devel.966125.n4.nabble.com/file/t378456/log_with_decode_bin_ERROR_.txt>
The Dot diagram for the following is also attached :
*SERVER:*
<http://gstreamer-devel.966125.n4.nabble.com/file/t378456/server_h264.png>
*CLIENT:*
<http://gstreamer-devel.966125.n4.nabble.com/file/t378456/client_h264.png>
Is there any elements that I need to add when i use other pay/depay instead
of VP8 ,or is this because of any wrong configuration? /
Please Help me with this situation,
*Eagerly Waiting for a response.*
Sample code for sender and receiver is also attached below:
Regards,
Nithin Pradeep.
**Attachment 373283**, "Sample code for FEC sender and receiver with h264":
[Fec_Sender_Receiver.rar](/uploads/87ac950d18997b09bd6f5728f2dafd01/Fec_Sender_Receiver.rar)