gst-plugins-base issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues2023-07-27T10:10:43Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/1000shmsink/shmsrc crashes if data is pushed too quickly2023-07-27T10:10:43ZKyle J. Vernyishmsink/shmsrc crashes if data is pushed too quicklyHello. I have noticed that pushing data "too quickly" to an AppSrc can cause it to crash. I am streaming extremely high bitrate 4K video which can range from 12Mbps to 120Mbps depending on my test. I feed an AppSrc with H264 RTP packets ...Hello. I have noticed that pushing data "too quickly" to an AppSrc can cause it to crash. I am streaming extremely high bitrate 4K video which can range from 12Mbps to 120Mbps depending on my test. I feed an AppSrc with H264 RTP packets that I have received in my own application. The pipeline is as follows:
appsrc ! queue2 ! shmsink
I have my application coded in C/C++. I am using a queue2 for the supposed advantage in network streams. Here are the important bits:
**Creating elements**
```
m_appsrc = gst_element_factory_make("appsrc", NULL);
m_shmQueue = gst_element_factory_make("queue2", NULL);
m_shmsink = gst_element_factory_make("shmsink", NULL);
```
**Configuring elements**
```
g_object_set(G_OBJECT(m_shmQueue), "max-size-buffers", 10000, "max-size-bytes", 0, "max-size-time", 0, "use-buffering", true, NULL );
g_object_set(G_OBJECT(m_shmsink), "socket-path", m_shmSocketPath.c_str(), "wait-for-connection", false, "sync", false, "async", false, NULL);
GstCaps * caps = gst_caps_from_string("application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96");
g_object_set(G_OBJECT(m_appsrc), "min-latency", 20000000, "is-live", true, "do-timestamp", true, "max-bytes", 20000000, "caps", caps, "format", GST_FORMAT_TIME, "block", true, NULL);
g_signal_connect (m_appsrc, "need-data", G_CALLBACK (StartFeed), &g_sourceid);
g_signal_connect (m_appsrc, "enough-data", G_CALLBACK (StopFeed), &g_sourceid);
```
**Building Pipeline**
```
gst_bin_add_many(GST_BIN(m_pipeline), m_appsrc, m_shmQueue, m_shmsink, NULL);
if (gst_element_link_many(m_appsrc, m_shmQueue, m_shmsink, NULL) != true) {
LOG_ERROR(subprocess) << "Elements could not be linked";
return -1;
}
gst_element_set_state (m_pipeline, GST_STATE_PLAYING);
```
I spawn a thread which pulls RTP packets from my application's `boost::circular_buffer<std::vector<uint8_t>>`. Each buffer in the circular buffer is a single RTP packet. I am 100% confident these packets are well formatted (in fact, they are generated by GStreamer). Here is the `PushData` thread.
```
PushData()
{
GstBuffer *buffer;
GstFlowReturn ret;
GstMapInfo map;
static const boost::posix_time::time_duration timeout(boost::posix_time::milliseconds(250));
static GstClockTime duration = 33333333; //.0333 seconds
while (m_running)
{
bool notInWaitForNewBundlesState = TryWaitForIncomingDataAvailable(timeout);
if (notInWaitForNewBundlesState) {
m_incomingQueueMutex.lock();
padded_vector_uint8_t incomingRtpFrame(std::move(m_incomingRtpPacketQueue.front()));
m_incomingRtpPacketQueue.pop_front();
m_incomingQueueMutex.unlock();
/* Create a new empty buffer */
buffer = gst_buffer_new_and_alloc(incomingRtpFrame.size());
// copy in from our local queue
gst_buffer_map(buffer, &map, GST_MAP_WRITE);
memcpy(map.data, incomingRtpFrame.data(), incomingRtpFrame.size());
/* Set its timestamp and duration */
GST_BUFFER_PTS(buffer) = gst_util_uint64_scale(m_numSamples, GST_SECOND, SAMPLE_RATE);
GST_BUFFER_DURATION(buffer) = duration;
/* Push the buffer into the appsrc */
gst_buffer_unmap(buffer, &map);
// code crashes if we get to push_buffer too quickly (too often?). Need to find a better solution. Crashes reguardless of the method used to push_buffer
boost::this_thread::sleep_for(boost::chrono::microseconds(30));
ret = gst_app_src_push_buffer((GstAppSrc *) GetAppSrc(), buffer); // takes ownership of buffer we DO NOT deref
// g_signal_emit_by_name((GstAppSrc *) GetAppSrc(), "push-buffer", buffer, &ret); // does not take ownership of buffer you must deref
// gst_buffer_unref(buffer);
if (ret != GST_FLOW_OK) {
/* We got some error */
std::cout << "WARNING: could not push data into app src. Err code: " << ret << std::endl;
continue;
}
m_numSamples += 1;
}
}
return; // get here only when shutting down
}
```
Note:
Some notes:
- The appsrc crashes regardless of the method used to push buffers (signal vs push_buffer). If the sleep command in the PushData is removed, about 1 second of video is passed to the shared memory sink before the data flow stops. With the sleep command, the code never crashes.
- I can tell the appsrc crashes because about 10 seconds after the crash my queue2 fills up and blocks as intended
- I can tell the appsrc crashes because my pipeline that picks up from the shmsink stops seeing new data
I am having a great deal of trouble debugging this issue. If I enable deep debugging (GST_DEBUG=5+) then GStreamer slows itself down such that it has the same effect as putting the sleep in the code! So I can either run the code with no debugging tools and sleep (it runs and I get no info). Or I can run the code with debugging tools and no sleep but it runs very slowly and the queue2 eventually fills up and I don't achieve my failure mode.
Some final notes
- TryWaitGetDataAvailable basically checks if my circular buffer is empty and if the enough-data signal was emitted
- The other end of the shmsink runs in a bash script and is something like
```
gst-launch-1.0 shmsrc socket-path=$shm_socket_path is-live=true do-timestamp=true ! "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! queue ! rtph264depay ! h264parse ! mp4mux ! filesink location=$file/$filename.mp4 -e &
```
With the sleep, the file is successfully reconstructed at the filesink. Without the sleep, the appsrc crashes and only the first second of the file is reconstructed at the filesink.
I am happy to investigate this issue more.
Thank you.
Kylehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/988Playsink: Failed to initialize colorbalance shader2023-03-02T10:14:00ZZaidan AlaouiPlaysink: Failed to initialize colorbalance shaderWe are getting the following failure when trying to create a pipeline under Android as follows:
filesrc -> decodebin -> playsink
```
The following log are returned:
../gst-libs/gst/gl/gstglslstage.c:519:_compile_shader:<glslstage1> frag...We are getting the following failure when trying to create a pipeline under Android as follows:
filesrc -> decodebin -> playsink
```
The following log are returned:
../gst-libs/gst/gl/gstglslstage.c:519:_compile_shader:<glslstage1> fragment shader compilation failed:1:1: L0001: Typename expected, found 'samplerExternalOES'
../gst-libs/gst/gl/gstgldebug.c:307:_gst_gl_debug_callback:<glcontextegl2> high: GL error from API id:38, Error:glDeleteShader::<shader> is not a value generated by OpenGL
../ext/gl/gstglcolorbalance.c:265:_create_shader:<glcolorbalance0> error: Failed to initialize colorbalance shader
../ext/gl/gstglcolorbalance.c:265:_create_shader:<glcolorbalance0> error: fragment shader compilation failed:1:1: L0001: Typename expected, found 'samplerExternalOES'
```
A native window is created and is passed to Playsink using:
gst_video_overlay_expose (GST_VIDEO_OVERLAY (data->playsink));
Is this a known issue ? Any suggestions ?
Thankshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/980DeviceMonitor no longer provides device.bus_path, device.profile.name2023-07-18T10:46:22Z3snowp7imDeviceMonitor no longer provides device.bus_path, device.profile.nameI revisited an old project and found that building a `device` property value for a `pulsesrc` element no longer worked because device monitor is no longer providing the `device.bus_path` or `device.profile.name` properties on the devices...I revisited an old project and found that building a `device` property value for a `pulsesrc` element no longer worked because device monitor is no longer providing the `device.bus_path` or `device.profile.name` properties on the devices returned from `get_devices`. Is it possible to get these properties through some new method, or, are there other means of getting the same information?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/972Support DSD native2023-07-27T12:22:14Zantonio manciniSupport DSD nativeHi,
there is no work on native DSD support?
It seems that someone did, successfully...
`[root@homepc tmp]# gst-typefind-1.0 /tmp/2L-45_stereo_01_DSF_2822k_1b.dsf
/tmp/2L-45_stereo_01_DSF_2822k_1b.dsf - audio/x-dsf`
```
[root@homepc...Hi,
there is no work on native DSD support?
It seems that someone did, successfully...
`[root@homepc tmp]# gst-typefind-1.0 /tmp/2L-45_stereo_01_DSF_2822k_1b.dsf
/tmp/2L-45_stereo_01_DSF_2822k_1b.dsf - audio/x-dsf`
```
[root@homepc tmp]# gst-inspect-1.0 | grep dsd
pcm2dsd128: pcm2dsd128: PCM to DSD Converter
pcm2dsd: pcm2dsd: PCM to DSD Converter
audiopcm2dsdbin: audiopcm2dsdbin: AudioPCM2DSDBin
pcm2dsd64: pcm2dsd64: PCM to DSD Converter
pcm2dsd256: pcm2dsd256: PCM to DSD Converter
audiopcm2dsd: audiopcm2dsd: AudioPCM2DSD
libav: avdec_dsd_msbf_planar: libav DSD (Direct Stream Digital), most significant bit first, planar decoder
libav: avdec_dsd_lsbf_planar: libav DSD (Direct Stream Digital), least significant bit first, planar decoder
libav: avdec_dsd_msbf: libav DSD (Direct Stream Digital), most significant bit first decoder
libav: avdec_dsd_lsbf: libav DSD (Direct Stream Digital), least significant bit first decoder
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/967gltransformation: Pipeline crashes after rotating stream for a certain time2023-07-27T11:05:07ZDragan Bozinovicgltransformation: Pipeline crashes after rotating stream for a certain timeI'm using simple pipeline which gets input from camera, processes it in GPU using gltransformation and sends it via udpsink. Pipeline is created within an application and it looks like this:
`gst-launch-1.0 -v v4l2src device=/dev/video0...I'm using simple pipeline which gets input from camera, processes it in GPU using gltransformation and sends it via udpsink. Pipeline is created within an application and it looks like this:
`gst-launch-1.0 -v v4l2src device=/dev/video0 ! "video/x-raw, width=(int)320, height=(int)240, framerate=(fraction)30/1,
format=(string)YUY2, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, interlace-mode=(string)progressive" !
imxvideoconvert_g2d ! glupload ! gltransformation ! gldownload ! rtpvrawpay pt=96 timestamp-offset=0 ! udpsink host=x.x.x.x port=yyyy`
In that application, I have an additional thread which periodically sets gltransformation property using g_object_set. After some time, pipeline crashes with error:
`gst_gl_filter_filter_texture: assertion 'gst_is_gl_memory (out_tex)' failed`
I've noticed that lowering periodicity of change enables program to work longer; for example, changing property on every 10ms makes pipeline to crash after ~3 minutes, whilst 20ms makes application crash at least after double amount of time.
I should note that I'm working on DART-MX8M-MINI. I've tried to track memory usage and there's no increase in used RAM memory. Using iMX script gpuinfo.sh I've noticed that texture memory is constantly being filled with data:
![mem](/uploads/4a958cc48413156872119811e9c3f08d/mem.png)
This intrigued me. Is there some problem with releasing used buffers from GStreamer side or this problem is specific because of environment I'm using?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/944"tee" causes green bar at bottom of video (Y out of sync with UV)2021-10-12T18:02:06Zlegerde2"tee" causes green bar at bottom of video (Y out of sync with UV)I want to send video to a display port and an H.265 encoder. Everything works with the exception of a green bar. The green bar is showing that the Y and UV channels are out of sync. I have circled the easy places to spot with red cir...I want to send video to a display port and an H.265 encoder. Everything works with the exception of a green bar. The green bar is showing that the Y and UV channels are out of sync. I have circled the easy places to spot with red circles.
![green_bar](/uploads/3e570c47ff279cb0acd307841a380888/green_bar.png)
My pipline is as follows.
![pipeline](/uploads/88d5b3d522ed3ce48b92f1a3eccabfed/pipeline.png)
My gstreamer command that causes the **green bar** is as follows:
`gst-launch-1.0 v4l2src io-mode=4 \`
` ! video/x-raw,format=NV16_10LE32,width=1920,height=1080,framerate=60/1 \`
` ! tee name=t \`
` t. ! queue \`
` ! kmssink bus-id="fd4a0000.zynqmp-display" plane-id=39 sync=false fullscreen-overlay=true driver-name=xlnx \`
` t. ! queue \`
` ! omxh265enc num-slices=8 control-rate=variable target-bitrate=2000 max-bitrate=3000 \`
` ! video/x-h265, alignment=nal \`
` ! h265parse \`
` ! perf \`
` ! rtph265pay config-interval=1 pt=96 \`
` ! udpsink host=192.168.168.100 port=5000`
The following gstreamer command **without a "tee" works** and does not have a green bar:
`gst-launch-1.0 v4l2src io-mode=4 \`
` ! video/x-raw,format=NV16_10LE32,width=1920,height=1080,framerate=60/1 \`
` ! omxh265enc num-slices=8 control-rate=variable target-bitrate=2000 max-bitrate=3000 \`
` ! video/x-h265 \`
` ! perf \`
` ! h265parse \`
` ! rtph265pay config-interval=1 pt=96 \`
` ! udpsink host=192.168.168.100 port=5000`
I believe the following warning is relevant:
**WARN** omxvideoenc gstomxvideoenc.c:2874:gst_omx_video_enc_configure_input_buffer:<omxh265enc-omxh265enc0> input buffer doesn't provide video meta, can't adjust stride and slice height
How can I fix the unaligned Y / UV?
I appreciate any ideas or help in resolving this. (I tried hard to format this for clarity. :) )https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/917parsebin: use chain after free2023-06-09T14:59:55ZSirius Wuparsebin: use chain after freeA use-after-free bug of parsebin occurs if playbin3 is set to NONE a few seconds after it is set to PLAYING. I'm using 1.16 on Android to play an mp4 video.
The following log shows that `connect_pad` executed by thread 0x7f5a5430 (tid ...A use-after-free bug of parsebin occurs if playbin3 is set to NONE a few seconds after it is set to PLAYING. I'm using 1.16 on Android to play an mp4 video.
The following log shows that `connect_pad` executed by thread 0x7f5a5430 (tid 3036) try to lock the chain 0x808fed90 after the chain 0x808fed90 was freed by thread 0x81a24520 (tid 2245).
```
06-28 04:54:37.004 2075 3036 D GStreamer+parsebin: 0:05:46.479062582 0x7f5a5430 ../gst/playback/gstparsebin.c:2855:gst_parse_chain_new:<parsebin40> Creating new chain 0x808fed90 with parent group 0x8ff272b0
06-28 04:54:37.010 2075 2245 V GStreamer+parsebin: 0:05:46.484662874 0x81a24520 ../gst/playback/gstparsebin.c:2678:gst_parse_chain_free_internal:<parsebin40> locking chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.010 2075 2245 V GStreamer+parsebin: 0:05:46.484768749 0x81a24520 ../gst/playback/gstparsebin.c:2678:gst_parse_chain_free_internal:<parsebin40> locked chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.010 2075 2245 D GStreamer+parsebin: 0:05:46.484866457 0x81a24520 ../gst/playback/gstparsebin.c:2681:gst_parse_chain_free_internal:<parsebin40> Hiding chain 0x808fed90
06-28 04:54:37.010 2075 2245 D GStreamer+parsebin: 0:05:46.484979624 0x81a24520 ../gst/playback/gstparsebin.c:2811:gst_parse_chain_free_internal:<parsebin40> Hidden chain 0x808fed90
06-28 04:54:37.010 2075 2245 V GStreamer+parsebin: 0:05:46.485093957 0x81a24520 ../gst/playback/gstparsebin.c:2812:gst_parse_chain_free_internal:<parsebin40> unlocking chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.018 2075 3036 D GStreamer+parsebin: 0:05:46.492812332 0x7f5a5430 ../gst/playback/gstparsebin.c:1751:connect_pad:<parsebin40> pad qtdemux37:video_0 , chain:0x808fed90, 2 factories, caps video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3, profile=(string)high, codec_data=(buffer)0164001effe1001c6764001eacd940b43dbff0020001b100000303e90000ea600f162d9601000668ebe3cb22c0, width=(int)720, height=(int)480, framerate=(fraction)30000/1001, pixel-aspect-ratio=(fraction)32/27
06-28 04:54:37.019 2075 2245 V GStreamer+parsebin: 0:05:46.494063874 0x81a24520 ../gst/playback/gstparsebin.c:2678:gst_parse_chain_free_internal:<parsebin40> locking chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.019 2075 2245 V GStreamer+parsebin: 0:05:46.494214082 0x81a24520 ../gst/playback/gstparsebin.c:2678:gst_parse_chain_free_internal:<parsebin40> locked chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.020 2075 2245 D GStreamer+parsebin: 0:05:46.494361957 0x81a24520 ../gst/playback/gstparsebin.c:2681:gst_parse_chain_free_internal:<parsebin40> Freeing chain 0x808fed90
06-28 04:54:37.020 2075 2245 D GStreamer+parsebin: 0:05:46.494531416 0x81a24520 ../gst/playback/gstparsebin.c:2811:gst_parse_chain_free_internal:<parsebin40> Freed chain 0x808fed90
06-28 04:54:37.020 2075 2245 V GStreamer+parsebin: 0:05:46.494663249 0x81a24520 ../gst/playback/gstparsebin.c:2812:gst_parse_chain_free_internal:<parsebin40> unlocking chain 0x808fed90 from thread 0x81a24520
06-28 04:54:37.023 2075 3036 V GStreamer+parsebin: 0:05:46.498147791 0x7f5a5430 ../gst/playback/gstparsebin.c:1839:connect_pad locking chain 0x808fed90 from thread 0x7f5a5430
```
The following are the backtraces of thread 0x7f5a5430 (tid 3036) and thread 0x81a24520 (tid 2245). Where should I put `CHAIN_MUTEX_LOCK(chain)` to fix this issue? Attached file is a more complete log after function `pad_added_cb` was called, which results in the `connect_pad` call.[use-after-free.log](/uploads/3dc99fa785a2823a36fb32638b52a9b5/use-after-free.log)
```
Thread 0x7f5a5430
Thread 106 (Thread 2075.3036):
#0 0xb18173f4 in syscall () from target:/system/lib/libc.so
#1 0xb1847560 in __pthread_mutex_lock_with_timeout(pthread_mutex_internal_t*, bool, timespec const*) () from target:/system/lib/libc.so
#2 0x837fb26a in g_mutex_lock (mutex=0x808fed98) at ../glib/gthread-posix.c:214
#3 0x835231ba in connect_pad (parsebin=<optimized out>, src=<optimized out>, parsepad=<optimized out>, pad=<optimized out>, caps=<optimized out>, factories=<optimized out>, chain=<optimized out>, deadend_details=<optimized out>) at ../gst/playback/gstparsebin.c:1839
#4 analyze_new_pad (parsebin=<optimized out>, src=<optimized out>, pad=0x80868e40, caps=0x80830918, chain=<optimized out>) at ../gst/playback/gstparsebin.c:1498
#5 0x8352586e in pad_added_cb (element=0x8e2c5ad0, pad=<optimized out>, chain=<optimized out>) at ../gst/playback/gstparsebin.c:2459
#6 0x837b0acc in ffi_call_SYSV () from target:/data/app/com.karaokeui-2/lib/arm/libgstreamer_android.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```
```
Thread 96 (Thread 2075.2245):
#0 0xb18173f4 in syscall () from target:/system/lib/libc.so
#1 0xb1847560 in __pthread_mutex_lock_with_timeout(pthread_mutex_internal_t*, bool, timespec const*) () from target:/system/lib/libc.so
#2 0x83742ae8 in gst_pad_stop_task (pad=0x80026ea8) at ../gst/gstpad.c:6306
#3 0x8373970a in activate_mode_internal (pad=0x80026ea8, parent=0x8e2c5ad0, mode=<optimized out>, active=<optimized out>) at ../gst/gstpad.c:1217
#4 0x83739250 in gst_pad_set_active (pad=0x80026ea8, active=0) at ../gst/gstpad.c:1115
#5 0x83727854 in activate_pads (vpad=<optimized out>, ret=0x8d80a148, active=0x8d80a198) at ../gst/gstelement.c:3062
#6 0x837324da in gst_iterator_fold (it=0x8b4e74a8, func=0x8372783d <activate_pads>, ret=0x8d80a148, user_data=0x8d80a198) at ../gst/gstiterator.c:617
#7 0x8372780a in iterator_activate_fold_with_resync (iter=0x8b4e74a8, func=<optimized out>, user_data=0x8d80a198) at ../gst/gstelement.c:3086
#8 0x83727652 in gst_element_pads_activate (element=0x8e2c5ad0, active=<optimized out>) at ../gst/gstelement.c:3131
#9 0x837261d2 in gst_element_change_state_func (element=0x8e2c5ad0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstelement.c:3196
#10 0x8347057c in gst_qtdemux_change_state (element=0x8e2c5ad0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/isomp4/qtdemux.c:2761
#11 0x83724d12 in gst_element_change_state (element=0x8e2c5ad0, transition=<optimized out>) at ../gst/gstelement.c:2974
#12 0x837265d4 in gst_element_set_state_func (element=0x8e2c5ad0, state=GST_STATE_NULL) at ../gst/gstelement.c:2928
#13 0x835277ac in gst_parse_chain_free_internal (chain=0x8b4e76d8, hide=<optimized out>) at ../gst/playback/gstparsebin.c:2817
#14 0x8352915c in gst_parse_chain_free (chain=0x8b4e76d8) at ../gst/playback/gstparsebin.c:2838
#15 gst_parse_bin_change_state (element=0x7fa75e10, transition=<optimized out>) at ../gst/playback/gstparsebin.c:4342
#16 0x83724d12 in gst_element_change_state (element=0x7fa75e10, transition=<optimized out>) at ../gst/gstelement.c:2974
#17 0x837265d4 in gst_element_set_state_func (element=0x7fa75e10, state=GST_STATE_READY) at ../gst/gstelement.c:2928
#18 0x837049f6 in gst_bin_element_set_state (bin=<optimized out>, element=<optimized out>, base_time=<optimized out>, current=<optimized out>, next=<optimized out>, start_time=<optimized out>) at ../gst/gstbin.c:2627
#19 gst_bin_change_state_func (element=<optimized out>, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2969
#20 0x8350fa2a in gst_decodebin3_change_state (element=0x8e53f338, transition=<optimized out>) at ../gst/playback/gstdecodebin3.c:2876
#21 0x83724d12 in gst_element_change_state (element=0x8e53f338, transition=<optimized out>) at ../gst/gstelement.c:2974
#22 0x837265d4 in gst_element_set_state_func (element=0x8e53f338, state=GST_STATE_READY) at ../gst/gstelement.c:2928
#23 0x837049f6 in gst_bin_element_set_state (bin=<optimized out>, element=<optimized out>, base_time=<optimized out>, current=<optimized out>, next=<optimized out>, start_time=<optimized out>) at ../gst/gstbin.c:2627
#24 gst_bin_change_state_func (element=<optimized out>, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2969
#25 0x8351beb6 in gst_uri_decode_bin3_change_state (element=0x8e53f1a0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/playback/gsturidecodebin3.c:1054
#26 0x83724d12 in gst_element_change_state (element=0x8e53f1a0, transition=<optimized out>) at ../gst/gstelement.c:2974
#27 0x837265d4 in gst_element_set_state_func (element=0x8e53f1a0, state=GST_STATE_READY) at ../gst/gstelement.c:2928
#28 0x837049f6 in gst_bin_element_set_state (bin=<optimized out>, element=<optimized out>, base_time=<optimized out>, current=<optimized out>, next=<optimized out>, start_time=<optimized out>) at ../gst/gstbin.c:2627
#29 gst_bin_change_state_func (element=<optimized out>, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2969
#30 0x834e9740 in gst_play_bin3_change_state (element=0x8b4e2040, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/playback/gstplaybin3.c:4944
#31 0x83724d12 in gst_element_change_state (element=0x8b4e2040, transition=<optimized out>) at ../gst/gstelement.c:2974
#32 0x837265d4 in gst_element_set_state_func (element=0x8b4e2040, state=GST_STATE_NULL) at ../gst/gstelement.c:2928
#33 0x88125e30 in set_uri (player=0x81a0c800, uri=0x7cbca960 "file:///data/user/0/com.karaokeui/files/broadcast/20201030_3.mp4") at jni/inul.c:780
#34 0x8812a550 in dispatch (action=0x7cb83380, player=0x81a0c800) at jni/actions.c:11
#35 0x837e51a8 in g_thread_pool_thread_proxy (data=0x82461a68) at ../glib/gthreadpool.c:307
#36 0x837e4600 in g_thread_proxy (data=0x81a24520) at ../glib/gthread.c:784
#37 0xb1846d34 in __pthread_start(void*) () from target:/system/lib/libc.so
#38 0xb1819aae in __start_thread () from target:/system/lib/libc.so
#39 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/900videorate: need implement prepare_output_buffer()2021-09-24T13:26:19ZKevin Songvideorate: need implement prepare_output_buffer()As videorate will ref input buffer, the input isn't writable. Below function will call gst_buffer_copy() which will cause issue when HW need fixed memory. Do we need implement prepare_output_buffer() in videorate?
```
static GstFlowRet...As videorate will ref input buffer, the input isn't writable. Below function will call gst_buffer_copy() which will cause issue when HW need fixed memory. Do we need implement prepare_output_buffer() in videorate?
```
static GstFlowReturn
default_prepare_output_buffer (GstBaseTransform * trans,
GstBuffer * inbuf, GstBuffer ** outbuf)
{
/* no pool, we need to figure out the size of the output buffer first */
if ((bclass->transform_ip != NULL) && priv->always_in_place) {
/* we want to do an in-place alloc */
if (gst_buffer_is_writable (inbuf)) {
GST_DEBUG_OBJECT (trans, "inplace reuse writable input buffer");
*outbuf = inbuf;
} else {
GST_DEBUG_OBJECT (trans, "making writable buffer copy");
/* we make a copy of the input buffer */
*outbuf = **gst_buffer_copy **(inbuf);
}
goto done;
}
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/893Error while compilation with dispmanx2022-10-22T09:44:58ZRobin Verdenal-TallieuxError while compilation with dispmanxHello
I'm trying to build gst-plugins-base on my raspberry pi.
But during compilation there is this error:
`error: unknown type name EGL_DISPMANX_WINDOW_T`
on the file gst-plugins-base/gst-libs/gst/gl/dispmanx/gstglwindow_dispmanx_egl.h:...Hello
I'm trying to build gst-plugins-base on my raspberry pi.
But during compilation there is this error:
`error: unknown type name EGL_DISPMANX_WINDOW_T`
on the file gst-plugins-base/gst-libs/gst/gl/dispmanx/gstglwindow_dispmanx_egl.h:66
I know it is due to the raspberry pi but, have you any idea to solved that?
Thank youhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/875HDR10 CLL metadata is allowed to change2022-06-20T13:13:59ZValZapodHDR10 CLL metadata is allowed to changeContrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to cha...Contrary to popular belief HDR10 static metadata can change per segment on seamless branching Blu-rays (ripping of which was also very broken due to wrong TrueHD duplicated frames deletion on segment border) and it is also allowed to change in mp4. As ffmpeg mail says (right now [last HDR metadata patches](https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=3373) are being accepted):
https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg108319.html
> in that some formats allow use to set it on frame,
> some on the stream, some on the container
> I notice that color data can be set per frame and per stream already
> and I don’t fully understand how these interact if converting between data in
> frame (e.g HEVC SEI in stream in hev1) or data in header (e.g. MOV mdcv tag or
> HEVC SEI in hvc1 format).
And this is correct. Free CTA-861-G (and now -H) standard mandate that and I quote:
> If the Source supports the transmission of the Dynamic Range and Mastering InfoFrame and if it
> determines that the Sink is capable of receiving that information, the Source shall send the Dynamic
> Range and Mastering InfoFrame **once per Video Field**
What that means is that it is allowed to change and display should be fast enough to change it on the fly.
In fact there is a sample from "In the Heart of the Sea" movie https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/uploads/16c628c535865d7282a48317064345a2/out.mp4 that utilizes that.
It can cause all kind of issues for you. mpv does support it and so does MadVR.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/859glfilterapp recordgraphic example doesn't work2021-01-22T08:19:25ZAndrey Burmaginglfilterapp recordgraphic example doesn't workHello everyone.
I'm trying to use `glfilterapp` gl-plugin to draw on the videostream.
For this I try to run this example:
`https://github.com/GStreamer/gst-plugins-base/blob/1.18.3/tests/examples/gl/generic/recordgraphic/main.cpp`
Bu...Hello everyone.
I'm trying to use `glfilterapp` gl-plugin to draw on the videostream.
For this I try to run this example:
`https://github.com/GStreamer/gst-plugins-base/blob/1.18.3/tests/examples/gl/generic/recordgraphic/main.cpp`
But here I get a link error.
Anyway, if I get rid of the caps filtering and put only `glimagesink` after `glfilterapp` and `gltestsrc` before it, I run into black screen.
Also if I don't pass a draw-callback into `glfilterapp`, videostream flows just fine.
I can't use `glimagesink` for drawing, like here:
https://github.com/GStreamer/gst-plugins-base/blob/1.18.3/tests/examples/gl/generic/cube/main.cpp
Because I just need to draw on the video without displaying it immediately.
So, could you please explain me how to change this example in order to draw something using `glfilterapp`?
My GStreamer version is 1.16.2.
Thanks.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/762gtkglsink: resize video widget causes SIGSEGV on Xwayland2020-05-31T09:29:06ZRussel Windergtkglsink: resize video widget causes SIGSEGV on XwaylandThe evidence comes from using Me TV (a DVB desktop application, https://github.com/Me-TV/Me-TV) on a fully up-to-date Debian Sid laptop. When running on Xorg there appears to be no problem. However when running on Xwayland using OpenGL a...The evidence comes from using Me TV (a DVB desktop application, https://github.com/Me-TV/Me-TV) on a fully up-to-date Debian Sid laptop. When running on Xorg there appears to be no problem. However when running on Xwayland using OpenGL any attempt to resize the video display window causes a SIGSEGV – this happens on every attempt at resize so is reproducible and consistent. There is no problem not using OpenGL.
Running Me TV from CLion, the stack trace (for thread 17 of 36) reports the SIGSEGV to have happened three anonymous function calls from a call to gst_gl_memory_copy_teximage.
* xwayland: 2:1.20.8-2
* libgl1-mesa-dri: 20.0.7
* libglx-mesa0: 20.0.7
The device driver appears to be i915 from the libgl1-mesa-dri package.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/755Issue Raspberry 4-64 + Mesa VC4 driver + Gstreamer = red Label on video2020-05-21T13:14:27ZehyoussefIssue Raspberry 4-64 + Mesa VC4 driver + Gstreamer = red Label on videoI Build an image with Mesa VC4 driver, weston and Webkit (wpebackend-fdo) on Wayland for Raspberry pi 4-64 i have an issue with playing video i have a red layer on video with Gstreamer.
when i play the video with Gstreamer the red label...I Build an image with Mesa VC4 driver, weston and Webkit (wpebackend-fdo) on Wayland for Raspberry pi 4-64 i have an issue with playing video i have a red layer on video with Gstreamer.
when i play the video with Gstreamer the red label on video exist
==>exp : gst-play-1.0 --videosink glimagesink simpson.mp4
![imFalse](/uploads/e6ffee07fd1952b93cdb3093e861b0e2/imFalse.jpg).
But when i play the video with Gstreamer and change "glimagesink" with "waylandsink" it work perfectly.
==>exp :gst-play-1.0 --videosink waylandsink simpson.mp4
![imTrue](/uploads/4c8f60ffedbd526193ae1e477623aa5c/imTrue.jpg)
#gst-inspect-1.0 --version :
gst-inspect-1.0 version 1.16.2
GStreamer 1.16.2
Unknown package origin
#Weston Version 8.0.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/741After updating the tags of a opus file several times with Picard and EasyTAG,...2021-09-24T13:25:42ZMateus Rodrigues Costamateusrodcosta@gmail.comAfter updating the tags of a opus file several times with Picard and EasyTAG, opusdec refuses to pick up updated metadataThis was initially reported as [a bug on tracker extract](https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/102), however it was pointed out that tracker-extract uses opusdec to get the metadata and I was pointed to this project.
S...This was initially reported as [a bug on tracker extract](https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/102), however it was pointed out that tracker-extract uses opusdec to get the metadata and I was pointed to this project.
System info:
Arch Linux 64-bits
gstreamer 1.16.2-1, gst-plugins-base 1.16.2-1, gst-plugins-base-libs 1.16.2-1
Basically, I recently decicded to have my music library as opus. So, for that I convert from flac to opus with this command: `parallel opusenc --music --bitrate 128 {} {.}.opus ::: *.flac`. At some point of the process I have to do things such as remove unwanted comments (which I do with EasyTAG) and update several tags (which I do with Picard); it just happens that for several of these songs I actually do the tags updates after the conversion. Problem now is that after a number of updates to the metadata, it seems that opusdec doesn't pick the new metadata at all.
The current metadata of the file according to ffprobe is:
```
[ogg @ 0x55cf08bec940] 1 bytes of comment header remain
Input #0, ogg, from '01. NiGHTS.opus':
Duration: 00:04:21.01, start: -0.960000, bitrate: 230 kb/s
Stream #0:0: Audio: opus, 48000 Hz, stereo, fltp
Metadata:
GENRE : Game
MUSICBRAINZ_RELEASEGROUPID: 5e22979b-2ef2-46a2-b8ae-c1b57371077d
ORIGINALDATE : 1996-07-10
ORIGINALYEAR : 1996
RELEASETYPE : album;soundtrack
MUSICBRAINZ_ALBUMID: 0acf9e25-a4a1-4abf-bf1b-79e3beeaf016
MUSICBRAINZ_ALBUMARTISTID: 8e986c66-2429-49a2-a32b-4ad3de114929;c77a7890-dc0e-4c5d-a7b4-96baa462c251;14b9c7f5-2c35-41ef-b389-764b0452b027
album_artist : Tomoko Sasaki, Naofumi Hataya & Fumie Kumatani
ALBUMARTISTSORT : Sasaki, Tomoko, Hataya, Naofumi & Kumatani, Fumie
RELEASECOUNTRY : JP
RELEASESTATUS : official
ALBUM : NiGHTS Original Soundtrack
ENGINEER : Meiji Takamatsu
PRODUCER : Hiroki Horio;Yukifumi Makino;Tsuneo Satou
ASIN : B00005FMZ8
LABEL : PolyGram
CATALOGNUMBER : POCX-1038
DATE : 1996-07-10
BARCODE : 4988005183149
SCRIPT : Latn
TOTALDISCS : 1
MEDIA : CD
TOTALTRACKS : 24
disc : 1
MUSICBRAINZ_TRACKID: 04e3bb69-fd64-42ef-8403-7b816882cd48
MUSICBRAINZ_ARTISTID: 8e986c66-2429-49a2-a32b-4ad3de114929
ARTIST : Tomoko Sasaki
ARTISTSORT : Sasaki, Tomoko
ARTISTS : Tomoko Sasaki
ISRC : JPX300830810
TITLE : NiGHTS
MUSICBRAINZ_RELEASETRACKID: 407897eb-67e0-4fb4-9806-c69ac7085208
track : 1
TRACKTOTAL : 24
DISCTOTAL : 1
Stream #0:1: Video: png, rgba(pc), 940x935 [SAR 3780:3780 DAR 188:187], 90k tbr, 90k tbn, 90k tbc (attached pic)
Metadata:
comment : Cover (front)
```
And the metadata according to opusdec is:
```
[mateusrc@delart NiGHTS Original Soundtrack]$ gst-launch-1.0 --tags filesrc location=/archive/Music/NiGHTS\ Original\ Soundtrack/01.\ NiGHTS.opus ! decodebin ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
FOUND TAG : found by element "fakesink0".
application name: opusenc from opus-tools 0.2
extended comment: ENCODER_OPTIONS=--music --bitrate 128
: MUSICBRAINZ_RELEASEGROUPID=5e22979b-2ef2-46a2-b8ae-c1b57371077d
: ORIGINALDATE=1996-07-10
: ORIGINALYEAR=1996
: RELEASETYPE=album
: RELEASETYPE=soundtrack
: BARCODE=4988005183149
: ASIN=B00005FMZ8
: RELEASESTATUS=official
: SCRIPT=Latn
: ENGINEER=高松明治
: PRODUCER=堀尾裕樹
: PRODUCER=牧野幸文
: PRODUCER=佐藤恒夫
: LABEL=PolyGram
: CATALOGNUMBER=POCX-1038
: RELEASECOUNTRY=JP
: MEDIA=CD
: ARTISTS=佐々木朋子
: MUSICBRAINZ_RELEASETRACKID=407897eb-67e0-4fb4-9806-c69ac7085208
comment: http://<snip>
genre: Game Soundtrack
organization: PolyGram
image: buffer of 1194438 bytes, type: image/png
album ID: 0acf9e25-a4a1-4abf-bf1b-79e3beeaf016
datetime: 1996-07-10
album artist ID: 8e986c66-2429-49a2-a32b-4ad3de114929
album artist: 佐々木朋子, 幡谷尚史 & 熊谷文恵
album artist sortname: Sasaki, Tomoko, Hataya, Naofumi & Kumatani, Fumie
album: NiGHTS Original Soundtrack
disc count: 1
track count: 24
disc number: 1
track ID: 04e3bb69-fd64-42ef-8403-7b816882cd48
artist ID: 8e986c66-2429-49a2-a32b-4ad3de114929
artist: Tomoko Sasaki
artist sortname: Sasaki, Tomoko
ISRC: JPX300830810
title: NiGHTS
track number: 1
encoder: libopus 1.3.1, libopusenc 0.2.1
audio codec: Opus
FOUND TAG : found by element "fakesink0".
container format: Ogg
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.956047753
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
```
Notice how things differ in such way that opusdec still sees the comment, the genre hasn't been updated and some of the artists names are still in Japanese characters.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/728glvideomixer combined with gltransformation crashes2021-09-24T13:25:38ZCarlos Rafael Gianiglvideomixer combined with gltransformation crashesThe following pipeline causes a crash:
gst-launch-1.0 \
videotestsrc ! "video/x-raw, width=240, height=240" ! glupload ! tee name=t \
glvideomixer name=c \
sink_0::xpos=0 sink_0::ypos=0 sink_0::width=240 sink_0...The following pipeline causes a crash:
gst-launch-1.0 \
videotestsrc ! "video/x-raw, width=240, height=240" ! glupload ! tee name=t \
glvideomixer name=c \
sink_0::xpos=0 sink_0::ypos=0 sink_0::width=240 sink_0::height=240 \
sink_1::xpos=0 sink_1::ypos=240 sink_1::width=240 sink_1::height=240 \
sink_2::xpos=240 sink_2::ypos=0 sink_2::width=240 sink_2::height=240 \
sink_3::xpos=240 sink_3::ypos=240 sink_3::width=240 sink_3::height=240 \
! glimagesink \
t. ! gltransformation rotation-z=0 ! c.sink_%u \
t. ! gltransformation rotation-z=90 ! c.sink_%u \
t. ! gltransformation rotation-z=180 ! c.sink_%u \
t. ! gltransformation rotation-z=270 ! c.sink_%u
However, it does work if either all rotation-z angles are set to 0, or the gltransformation elements are removed altogether. Tested with version 1.16.2 and git master. [A log file is attached.](/uploads/0e9f73067e8ca88b636eff63ed0ad61b/gltransformation-rotation-compositor.log) It was produced with GST_DEBUG set to `2,*gl*:9`.
This was run on Kubuntu 18.04, x86-64, with an Intel UHD Graphics 630 GPU.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/727HDR: MDCV and CLL should not be exposed as a caps2022-06-20T13:21:47ZStéphane Cerveauscerveau@igalia.comHDR: MDCV and CLL should not be exposed as a capsIn the case of HDR10+ dynamic meta (see #700), the GOPs or scene can change MDCV and CLL values during the stream playback.
A GstVideoMeta approach should be considered instead of caps.
Only the type of HDR (HDR10, HDR10+, DolbyVision...In the case of HDR10+ dynamic meta (see #700), the GOPs or scene can change MDCV and CLL values during the stream playback.
A GstVideoMeta approach should be considered instead of caps.
Only the type of HDR (HDR10, HDR10+, DolbyVision) should be exposed by caps allowing downstream element to adapt and optimize data retrieval.Stéphane Cerveauscerveau@igalia.comStéphane Cerveauscerveau@igalia.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/709alsasink: Awful sound when playing FLAC 44.1 khz2021-09-24T13:25:30ZTimur Yaroshalsasink: Awful sound when playing FLAC 44.1 khzPlease take a look at the [recording](https://www.dropbox.com/s/wsef5oak9h4ozoy/2019-12-15%2021.39.54.mp3?dl=0).
Here is the original [file](https://www.dropbox.com/s/lz03ly3hksgjcsp/01%20-%20Part%20One.flac?dl=0).
As you can see, the di...Please take a look at the [recording](https://www.dropbox.com/s/wsef5oak9h4ozoy/2019-12-15%2021.39.54.mp3?dl=0).
Here is the original [file](https://www.dropbox.com/s/lz03ly3hksgjcsp/01%20-%20Part%20One.flac?dl=0).
As you can see, the difference is huge. However, 96khz FLAC files played awesomely.
Here is the command to play:
`gst-launch-1.0 filesrc location=01-part-one.flac ! flacparse ! flacdec ! alsasink device=hw:1,1`
GStreamer version is 1.14.4 and it's installed on Raspbian Buster.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/699pbutils: Basic-tutorial-7 crashes2019-12-05T03:44:56ZSirius Wupbutils: Basic-tutorial-7 crashesI'm using Ubuntu 18.04. The following command crash.
```
cargo run --bin basic-tutorial-7
```
It crashed:
```
Obtained request pad src_0 for audio branch
Obtained request pad src_1 for video branch
Segmentation fault (core dumped)
```...I'm using Ubuntu 18.04. The following command crash.
```
cargo run --bin basic-tutorial-7
```
It crashed:
```
Obtained request pad src_0 for audio branch
Obtained request pad src_1 for video branch
Segmentation fault (core dumped)
```
I examine the binary with core dump:
```
gdb target/debug/basic-tutorial-7 ./tutorials/core
```
Although I got some backtrace, but I do not know how to continue from here, any suggestion?
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memset_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:188
188 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory.
[Current thread is 1 (Thread 0x7f3d26b1e700 (LWP 32416))]
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /media/ccwu/e7458cf5-858e-4184-afc4-73301087e303/home/alvin/mapacode/git/gstreamer-rs/target/debug/basic-tutorial-7.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) l
183 in ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S
(gdb) backtrace
#0 0x00007f3d4cc7c930 in __memset_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:188
#1 0x00007f3d4a53fd27 in () at /usr/lib/x86_64-linux-gnu/libgstpbutils-1.0.so.0
#2 0x00007f3d4ddd688b in () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#3 0x00007f3d4dddebb3 in gst_pad_push () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#4 0x00007f3d4b1acba9 in () at /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstcoreelements.so
#5 0x00007f3d4de0b269 in () at /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#6 0x00007f3d4d869b60 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007f3d4d869195 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00007f3d4d1d16db in start_thread (arg=0x7f3d26b1e700) at pthread_create.c:463
#9 0x00007f3d4cce288f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/694deadlock in konsole + phonon2021-09-24T13:24:24ZBugzilla Migration Userdeadlock in konsole + phonon## Submitted by me@..@..ebj.io
**[Link to original bug (#797106)](https://bugzilla.gnome.org/show_bug.cgi?id=797106)**
## Description
Created attachment 373575
gdb session with thread apply all bt
Konsole stops responding whe...## Submitted by me@..@..ebj.io
**[Link to original bug (#797106)](https://bugzilla.gnome.org/show_bug.cgi?id=797106)**
## Description
Created attachment 373575
gdb session with thread apply all bt
Konsole stops responding when I attempt to close a tab where an application other than the shell is still running. The prompt to close appears, but freezes and I can't interact with it anymore. I have to kill konsole when this happens. The traceback indicates that a deadlock is occurring in code related to an alert sound playback for the exit confirmation.
The problem doesn't seem to appear in a new user profile, but renaming ~/.config to something else doesn't fix it. For both existing and new users, I get the following in konsole's stdout just before the confirmation dialog shows up: "WARNING: Disabling PulseAudio integration for lack of GLib event loop."
**Attachment 373575**, "gdb session with thread apply all bt":
[file_797106.txt](/uploads/818b623725842c48c1cfb0930b3a777a/file_797106.txt)
Version: 1.14.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/670UriDecodeBin fails to use giosrc for dav URIs2022-05-04T05:29:40ZIñigo IllanUriDecodeBin fails to use giosrc for dav URIsI have been trying to reproduce videos from a dav server but uridecodebin doesn't seem to know how to handle dav resources.
More specifically, if I try running:
`gst-launch-1.0 -v playbin3 uri="dav://....mp4"`
I get the following erro...I have been trying to reproduce videos from a dav server but uridecodebin doesn't seem to know how to handle dav resources.
More specifically, if I try running:
`gst-launch-1.0 -v playbin3 uri="dav://....mp4"`
I get the following error:
```
Missing element: DAV protocol source
ERROR: from element /GstURISourceBin:urisourcebin0: No URI handler implemented for "dav".
Additional debug info:
gsturisourcebin.c(1521): gen_source_element (): /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstURISourceBin:urisourcebin0
```
I have giosrc installed and I can run `gst-launch-1.0 -v giosrc location="dav://....mp4" ! fakesink` perfectly fine
- Operating System: Ubuntu 19.10 (Beta)
- Gstreamer version: 1.16.0