gst-plugins-base issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues2021-09-24T13:23:26Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/412appsrc: uncertainty moment in the documentation2021-09-24T13:23:26ZBugzilla Migration Userappsrc: uncertainty moment in the documentation## Submitted by Aleksandr Slobodeniuk
**[Link to original bug (#792265)](https://bugzilla.gnome.org/show_bug.cgi?id=792265)**
## Description
About the ownership of the buffer, when pushing it to appsrc.
https://gstreamer.freede...## Submitted by Aleksandr Slobodeniuk
**[Link to original bug (#792265)](https://bugzilla.gnome.org/show_bug.cgi?id=792265)**
## Description
About the ownership of the buffer, when pushing it to appsrc.
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-appsrc.html#gst-app-src-push-buffer
Function takes ownership, but signal doesn't.
It was tricky, because I didn't find the documentation for signal in the web.
But in appsrc's code it exists:
/**
* GstAppSrc::push-buffer:
* @appsrc: the appsrc
* @buffer: a buffer to push
*
* Adds a buffer to the queue of buffers that the appsrc element will
* push to its source pad. This function does not take ownership of the
* buffer so the buffer needs to be unreffed after calling this function.
*
And the web-page only says:
----
The main way of handing data to the appsrc element is by calling the gst_app_src_push_buffer() method or by emitting the push-buffer action signal.
----
But gst_app_src_push_buffer
is not a signal handler for "push-buffer", that's what's tricky.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/394audiovisualizer: basic-tutorial-8.c is crashing with vaapisink2021-09-24T13:23:17ZBugzilla Migration Useraudiovisualizer: basic-tutorial-8.c is crashing with vaapisink## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#789542)](https://bugzilla.gnome.org/show_bug.cgi?id=789542)**
## Description
gst-docs/examples/tutorial/basic-tutorial-8.c is raising a crash in audiovisualiz...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#789542)](https://bugzilla.gnome.org/show_bug.cgi?id=789542)**
## Description
gst-docs/examples/tutorial/basic-tutorial-8.c is raising a crash in audiovisualizer with master.
(It would be good to somehow integrate those examples in our CI system).
Thread 5 "video_queue:src" received signal SIGSEGV, Segmentation fault.
```
Thread 8 (Thread 0x7fffe92ee700 (LWP 26260)):
#0 0x00007ffff6e0ac8d in nanosleep () at /lib64/libpthread.so.0
#1 0x00007ffff708b278 in g_usleep () at /lib64/libglib-2.0.so.0
#2 0x00007ffff2e7f78c in gst_vaapisink_event_thread (sink=0x87c200) at ../subprojects/gstreamer-vaapi/gst/vaapi/gstvaapisink.c:905
#3 0x00007ffff7089b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#4 0x00007ffff6e0173a in start_thread () at /lib64/libpthread.so.0
#5 0x00007ffff6b3be7f in clone () at /lib64/libc.so.6
Thread 7 (Thread 0x7fffe9b3f700 (LWP 26259)):
#0 0x00007ffff6b35b19 in syscall () at /lib64/libc.so.6
#1 0x00007ffff70a79df in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007ffff42cedb4 in gst_queue_chain_buffer_or_list (pad=0x8344b0, parent=0x82a180, obj=0x8ff5c0, is_list=0) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1246
#3 0x00007ffff42cf553 in gst_queue_chain (pad=0x8344b0, parent=0x82a180, buffer=0x8ff5c0) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1344
#4 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x8344b0, type=4112, data=0x8ff5c0) at ../subprojects/gstreamer/gst/gstpad.c:4215
#5 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x8425e0, type=4112, data=0x8ff5c0) at ../subprojects/gstreamer/gst/gstpad.c:4471
#6 0x00007ffff761c3df in gst_pad_push (pad=0x8425e0, buffer=0x8ff5c0) at ../subprojects/gstreamer/gst/gstpad.c:4590
#7 0x00007ffff42d5ee5 in gst_tee_do_push (tee=0x837000, pad=0x8425e0, data=0x8ff5c0, is_list=0) at ../subprojects/gstreamer/plugins/elements/gsttee.c:856
#8 0x00007ffff42d615a in gst_tee_handle_data (tee=0x837000, data=0x8ff5c0, is_list=0) at ../subprojects/gstreamer/plugins/elements/gsttee.c:939
#9 0x00007ffff42d656f in gst_tee_chain (pad=0x834270, parent=0x837000, buffer=0x8ff5c0) at ../subprojects/gstreamer/plugins/elements/gsttee.c:1022
#10 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x834270, type=4112, data=0x8ff5c0) at ../subprojects/gstreamer/gst/gstpad.c:4215
#11 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x834030, type=4112, data=0x8ff5c0) at ../subprojects/gstreamer/gst/gstpad.c:4471
#12 0x00007ffff761c3df in gst_pad_push (pad=0x834030, buffer=0x8ff5c0) at ../subprojects/gstreamer/gst/gstpad.c:4590
#13 0x00007ffff791b506 in gst_base_src_loop (pad=0x834030) at ../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:2918
#14 0x00007ffff7655a5b in gst_task_func (task=0x8515f0) at ../subprojects/gstreamer/gst/gsttask.c:332
#15 0x00007ffff7656c20 in default_func (tdata=0x825590, pool=0x619910) at ../subprojects/gstreamer/gst/gsttaskpool.c:69
#16 0x00007ffff708a58e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#17 0x00007ffff7089b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#18 0x00007ffff6e0173a in start_thread () at /lib64/libpthread.so.0
#19 0x00007ffff6b3be7f in clone () at /lib64/libc.so.6
Thread 6 (Thread 0x7fffea340700 (LWP 26258)):
#0 0x00007ffff6b35b19 in syscall () at /lib64/libc.so.6
#1 0x00007ffff70a79df in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007ffff79077fa in gst_base_sink_wait_preroll (sink=0x8d2b30) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:2267
#3 0x00007ffff7907d15 in gst_base_sink_do_preroll (sink=0x8d2b30, obj=0x8542d0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:2361
#4 0x00007ffff79085eb in gst_base_sink_do_sync (basesink=0x8d2b30, obj=0x8542d0, late=0x7fffea33f364, step_end=0x7fffea33f360) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:2564
#5 0x00007ffff790c9e8 in gst_base_sink_chain_unlocked (basesink=0x8d2b30, pad=0x84b260, obj=0x8542d0, is_list=0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:3513
#6 0x00007ffff790d84c in gst_base_sink_chain_main (basesink=0x8d2b30, pad=0x84b260, obj=0x8542d0, is_list=0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:3672
#7 0x00007ffff790d9bb in gst_base_sink_chain (pad=0x84b260, parent=0x8d2b30, buf=0x8542d0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:3701
#8 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x84b260, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4215
#9 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x842150, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4471
#10 0x00007ffff761c3df in gst_pad_push (pad=0x842150, buffer=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4590
#11 0x00007ffff75fb01f in gst_proxy_pad_chain_default (pad=0x840050, parent=0x83f060, buffer=0x8542d0) at ../subprojects/gstreamer/gst/gstghostpad.c:127
#12 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x840050, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4215
#13 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x834ff0, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4471
#14 0x00007ffff761c3df in gst_pad_push (pad=0x834ff0, buffer=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4590
#15 0x00007ffff792536c in gst_base_transform_chain (pad=0x834db0, parent=0x83bfe0, buffer=0x8542d0) at ../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2312
#16 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x834db0, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4215
#17 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x834b70, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4471
#18 0x00007ffff761c3df in gst_pad_push (pad=0x834b70, buffer=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4590
#19 0x00007ffff792536c in gst_base_transform_chain (pad=0x834930, parent=0x8306d0, buffer=0x8542d0) at ../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2312
#20 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x834930, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4215
#21 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x8346f0, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4471
#22 0x00007ffff761c3df in gst_pad_push (pad=0x8346f0, buffer=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4590
#23 0x00007ffff42cf6c0 in gst_queue_push_one (queue=0x82a180) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1383
#24 0x00007ffff42d051c in gst_queue_loop (pad=0x8346f0) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1536
#25 0x00007ffff7655a5b in gst_task_func (task=0x8514d0) at ../subprojects/gstreamer/gst/gsttask.c:332
---Type <return> to continue, or q <return> to quit---
#26 0x00007ffff7656c20 in default_func (tdata=0x8257c0, pool=0x619910) at ../subprojects/gstreamer/gst/gsttaskpool.c:69
#27 0x00007ffff708a58e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#28 0x00007ffff7089b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#29 0x00007ffff6e0173a in start_thread () at /lib64/libpthread.so.0
#30 0x00007ffff6b3be7f in clone () at /lib64/libc.so.6
Thread 5 (Thread 0x7fffeab41700 (LWP 26257)):
#0 0x00007ffff6ac4dba in __memset_erms () at /lib64/libc.so.6
#1 0x00007ffff383dcc2 in gst_audio_visualizer_chain (pad=0x835d70, parent=0x8503f0, buffer=0x904a10) at ../subprojects/gst-plugins-base/gst-libs/gst/pbutils/gstaudiovisualizer.c:1163
#2 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x835d70, type=4112, data=0x904a10) at ../subprojects/gstreamer/gst/gstpad.c:4215
#3 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x835b30, type=4112, data=0x904a10) at ../subprojects/gstreamer/gst/gstpad.c:4471
#4 0x00007ffff761c3df in gst_pad_push (pad=0x835b30, buffer=0x904a10) at ../subprojects/gstreamer/gst/gstpad.c:4590
#5 0x00007ffff792536c in gst_base_transform_chain (pad=0x8358f0, parent=0x848c40, buffer=0x854600) at ../subprojects/gstreamer/libs/gst/base/gstbasetransform.c:2312
#6 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x8358f0, type=4112, data=0x854600) at ../subprojects/gstreamer/gst/gstpad.c:4215
#7 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x8356b0, type=4112, data=0x854600) at ../subprojects/gstreamer/gst/gstpad.c:4471
#8 0x00007ffff761c3df in gst_pad_push (pad=0x8356b0, buffer=0x854600) at ../subprojects/gstreamer/gst/gstpad.c:4590
#9 0x00007ffff42cf6c0 in gst_queue_push_one (queue=0x82a480) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1383
#10 0x00007ffff42d051c in gst_queue_loop (pad=0x8356b0) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1536
#11 0x00007ffff7655a5b in gst_task_func (task=0x851170) at ../subprojects/gstreamer/gst/gsttask.c:332
#12 0x00007ffff7656c20 in default_func (tdata=0x8258c0, pool=0x619910) at ../subprojects/gstreamer/gst/gsttaskpool.c:69
#13 0x00007ffff708a58e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#14 0x00007ffff7089b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#15 0x00007ffff6e0173a in start_thread () at /lib64/libpthread.so.0
#16 0x00007ffff6b3be7f in clone () at /lib64/libc.so.6
Thread 4 (Thread 0x7fffeb342700 (LWP 26256)):
#0 0x00007ffff6b35b19 in syscall () at /lib64/libc.so.6
#1 0x00007ffff70a79df in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007ffff79077fa in gst_base_sink_wait_preroll (sink=0x861cb0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:2267
#3 0x00007ffff7907d15 in gst_base_sink_do_preroll (sink=0x861cb0, obj=0x8542d0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:2361
#4 0x00007ffff79085eb in gst_base_sink_do_sync (basesink=0x861cb0, obj=0x8542d0, late=0x7fffeb341a04, step_end=0x7fffeb341a00) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:2564
#5 0x00007ffff790c9e8 in gst_base_sink_chain_unlocked (basesink=0x861cb0, pad=0x84ade0, obj=0x8542d0, is_list=0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:3513
#6 0x00007ffff790d84c in gst_base_sink_chain_main (basesink=0x861cb0, pad=0x84ade0, obj=0x8542d0, is_list=0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:3672
#7 0x00007ffff790d9bb in gst_base_sink_chain (pad=0x84ade0, parent=0x861cb0, buf=0x8542d0) at ../subprojects/gstreamer/libs/gst/base/gstbasesink.c:3701
#8 0x00007ffff761b0c7 in gst_pad_chain_data_unchecked (pad=0x84ade0, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4215
#9 0x00007ffff761bcb4 in gst_pad_push_data (pad=0x84aba0, type=4112, data=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4471
#10 0x00007ffff761c3df in gst_pad_push (pad=0x84aba0, buffer=0x8542d0) at ../subprojects/gstreamer/gst/gstpad.c:4590
#11 0x00007ffff42cf6c0 in gst_queue_push_one (queue=0x82a780) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1383
#12 0x00007ffff42d051c in gst_queue_loop (pad=0x84aba0) at ../subprojects/gstreamer/plugins/elements/gstqueue.c:1536
#13 0x00007ffff7655a5b in gst_task_func (task=0x8513b0) at ../subprojects/gstreamer/gst/gsttask.c:332
#14 0x00007ffff7656c20 in default_func (tdata=0x825910, pool=0x619910) at ../subprojects/gstreamer/gst/gsttaskpool.c:69
#15 0x00007ffff708a58e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#16 0x00007ffff7089b93 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#17 0x00007ffff6e0173a in start_thread () at /lib64/libpthread.so.0
#18 0x00007ffff6b3be7f in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7fffebb43700 (LWP 26255)):
#0 0x00007ffff6b2ff3d in poll () at /lib64/libc.so.6
#1 0x00007fffee628c91 in poll_func () at /lib64/libpulse.so.0
#2 0x00007fffee61a4a1 in pa_mainloop_poll () at /lib64/libpulse.so.0
#3 0x00007fffee61ab3e in pa_mainloop_iterate () at /lib64/libpulse.so.0
#4 0x00007fffee61abf0 in pa_mainloop_run () at /lib64/libpulse.so.0
#5 0x00007fffee628bd9 in thread () at /lib64/libpulse.so.0
#6 0x00007fffee3c81d8 in internal_thread_func () at /usr/lib64/pulseaudio/libpulsecommon-10.0.so
#7 0x00007ffff6e0173a in start_thread () at /lib64/libpthread.so.0
#8 0x00007ffff6b3be7f in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7ffff7fb5300 (LWP 26249)):
---Type <return> to continue, or q <return> to quit---
#0 0x00007ffff6b2ff3d in poll () at /lib64/libc.so.6
#1 0x00007ffff7062166 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2 0x00007ffff70624f2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3 0x0000000000401ec1 in main ()
==26544== Conditional jump or move depends on uninitialised value(s)
==26544== at 0x4C3432F: memset (vg_replace_strmem.c:1234)
==26544== by 0xA9DACC1: gst_audio_visualizer_chain (gstaudiovisualizer.c:1163)
==26544== by 0x53D40C6: gst_pad_chain_data_unchecked (gstpad.c:4215)
==26544== by 0x53D4CB3: gst_pad_push_data (gstpad.c:4471)
==26544== by 0x53D53DE: gst_pad_push (gstpad.c:4590)
==26544== by 0x510A36B: gst_base_transform_chain (gstbasetransform.c:2312)
==26544== by 0x53D40C6: gst_pad_chain_data_unchecked (gstpad.c:4215)
==26544== by 0x53D4CB3: gst_pad_push_data (gstpad.c:4471)
==26544== by 0x53D53DE: gst_pad_push (gstpad.c:4590)
==26544== by 0x9F6C6BF: gst_queue_push_one (gstqueue.c:1383)
==26544== by 0x9F6D51B: gst_queue_loop (gstqueue.c:1536)
==26544== by 0x540EA5A: gst_task_func (gsttask.c:332)
==26544==
==26544== Conditional jump or move depends on uninitialised value(s)
==26544== at 0x4C34369: memset (vg_replace_strmem.c:1234)
==26544== by 0xA9DACC1: gst_audio_visualizer_chain (gstaudiovisualizer.c:1163)
==26544== by 0x53D40C6: gst_pad_chain_data_unchecked (gstpad.c:4215)
==26544== by 0x53D4CB3: gst_pad_push_data (gstpad.c:4471)
==26544== by 0x53D53DE: gst_pad_push (gstpad.c:4590)
==26544== by 0x510A36B: gst_base_transform_chain (gstbasetransform.c:2312)
==26544== by 0x53D40C6: gst_pad_chain_data_unchecked (gstpad.c:4215)
==26544== by 0x53D4CB3: gst_pad_push_data (gstpad.c:4471)
==26544== by 0x53D53DE: gst_pad_push (gstpad.c:4590)
==26544== by 0x9F6C6BF: gst_queue_push_one (gstqueue.c:1383)
==26544== by 0x9F6D51B: gst_queue_loop (gstqueue.c:1536)
==26544== by 0x540EA5A: gst_task_func (gsttask.c:332)
==26544==
==26544== Invalid write of size 8
==26544== at 0x4C34357: memset (vg_replace_strmem.c:1234)
==26544== by 0xA9DACC1: gst_audio_visualizer_chain (gstaudiovisualizer.c:1163)
==26544== by 0x53D40C6: gst_pad_chain_data_unchecked (gstpad.c:4215)
==26544== by 0x53D4CB3: gst_pad_push_data (gstpad.c:4471)
==26544== by 0x53D53DE: gst_pad_push (gstpad.c:4590)
==26544== by 0x510A36B: gst_base_transform_chain (gstbasetransform.c:2312)
==26544== by 0x53D40C6: gst_pad_chain_data_unchecked (gstpad.c:4215)
==26544== by 0x53D4CB3: gst_pad_push_data (gstpad.c:4471)
==26544== by 0x53D53DE: gst_pad_push (gstpad.c:4590)
==26544== by 0x9F6C6BF: gst_queue_push_one (gstqueue.c:1383)
==26544== by 0x9F6D51B: gst_queue_loop (gstqueue.c:1536)
==26544== by 0x540EA5A: gst_task_func (gsttask.c:332)
==26544== Address 0x4179000 is not stack'd, malloc'd or (recently) free'd
==26544==
==26544==
==26544== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==26544== Access not within mapped region at address 0x4179000
==26544== at 0x4C34357: memset (vg_replace_strmem.c:1234)
==26544== by 0xA9DACC1: gst_audio_visualizer_chain (gstaudiovisualizer.c:1163)
==26544== by 0x53D40C6: gst_pad_chain_data_unchecked (gstpad.c:4215)
==26544== by 0x53D4CB3: gst_pad_push_data (gstpad.c:4471)
==26544== by 0x53D53DE: gst_pad_push (gstpad.c:4590)
==26544== by 0x510A36B: gst_base_transform_chain (gstbasetransform.c:2312)
==26544== by 0x53D40C6: gst_pad_chain_data_unchecked (gstpad.c:4215)
==26544== by 0x53D4CB3: gst_pad_push_data (gstpad.c:4471)
==26544== by 0x53D53DE: gst_pad_push (gstpad.c:4590)
==26544== by 0x9F6C6BF: gst_queue_push_one (gstqueue.c:1383)
==26544== by 0x9F6D51B: gst_queue_loop (gstqueue.c:1536)
==26544== by 0x540EA5A: gst_task_func (gsttask.c:332)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/379Unable to decode h.264 from RTSP server2021-09-24T13:22:55ZBugzilla Migration UserUnable to decode h.264 from RTSP server## Submitted by Allan Matthew
**[Link to original bug (#787044)](https://bugzilla.gnome.org/show_bug.cgi?id=787044)**
## Description
I've got an IPTV device which appears to work just fine with VLC and other RTSP-capable software. ...## Submitted by Allan Matthew
**[Link to original bug (#787044)](https://bugzilla.gnome.org/show_bug.cgi?id=787044)**
## Description
I've got an IPTV device which appears to work just fine with VLC and other RTSP-capable software. However within the playbin (as well as other pipelines I've tried) it appears h264parse is unable to handle the datastream. I see the following from the gstreamer debug output:
gst-launch-1.0 playbin uri=rtsp://192.168.1.168:554/hdmi --gst-debug=3
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://192.168.1.168:554/hdmi
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (request) SETUP stream 1
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
0:00:00.162460000 5723 0x7fe20900b450 FIXME default gstutils.c:3826:gchar *gst_pad_create_stream_id_internal(GstPad *, GstElement *, const gchar *):<fakesrc0:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
0:00:00.162479000 5723 0x7fe20900b4a0 FIXME default gstutils.c:3826:gchar *gst_pad_create_stream_id_internal(GstPad *, GstElement *, const gchar *):<fakesrc1:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
0:00:02.245090000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:494:gst_h264_parse_vui_parameters: failed to read uint8, nbits: 1
0:00:02.245108000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:519:gst_h264_parse_vui_parameters: error parsing "VUI Parameters"
0:00:02.245112000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:1771:gst_h264_parse_sps: error parsing "Sequence parameter set"
0:00:02.245117000 5723 0x7fe207820f70 WARN h264parse gsth264parse.c:732:gst_h264_parse_process_nal:`<h264parse0>` failed to parse SPS:
0:00:02.251065000 5723 0x7fe207820f70 FIXME videodecoder gstvideodecoder.c:945:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):`<vtdechw0>` Sub-class should implement drain()
0:00:02.260569000 5723 0x7fe207820f70 WARN vtdec vtdec.c:310:gst_vtdec_negotiate:`<vtdechw0>` error: VTDecompressionSessionCreate returned -12913
0:00:02.260609000 5723 0x7fe207820f70 WARN videodecoder gstvideodecoder.c:745:gboolean gst_video_decoder_setcaps(GstVideoDecoder *, GstCaps *):`<vtdechw0>` Subclass refused caps
0:00:02.260617000 5723 0x7fe207820f70 WARN decodebin gstdecodebin2.c:2505:gboolean connect_pad(GstDecodeBin *, GstElement *, GstDecodePad *, GstPad *, GstCaps *, GValueArray *, GstDecodeChain *, gchar **):`<decodebin1>` Couldn't set vtdechw0 to PAUSED
0:00:02.261430000 5723 0x7fe207820f70 ERROR libav :0:: Overread VUI by 5 bits
0:00:02.261448000 5723 0x7fe207820f70 ERROR libav :0:: Overread VUI by 5 bits
0:00:02.261454000 5723 0x7fe207820f70 ERROR libav :0:: Decoding sps 0 from avcC failed
0:00:02.261549000 5723 0x7fe207820f70 WARN videodecoder gstvideodecoder.c:745:gboolean gst_video_decoder_setcaps(GstVideoDecoder *, GstCaps *):`<avdec_h264-0>` Subclass refused caps
0:00:02.261558000 5723 0x7fe207820f70 WARN decodebin gstdecodebin2.c:2505:gboolean connect_pad(GstDecodeBin *, GstElement *, GstDecodePad *, GstPad *, GstCaps *, GValueArray *, GstDecodeChain *, gchar **):`<decodebin1>` Couldn't set avdec_h264-0 to PAUSED
0:00:02.261831000 5723 0x7fe207820f70 FIXME videodecoder gstvideodecoder.c:945:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):`<vtdec0>` Sub-class should implement drain()
0:00:02.285609000 5723 0x7fe207820f70 FIXME videodecoder gstvideodecoder.c:945:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):`<vtdec0>` Sub-class should implement drain()
0:00:02.285719000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:494:gst_h264_parse_vui_parameters: failed to read uint8, nbits: 1
0:00:02.285727000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:519:gst_h264_parse_vui_parameters: error parsing "VUI Parameters"
0:00:02.285731000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:1771:gst_h264_parse_sps: error parsing "Sequence parameter set"
0:00:02.285735000 5723 0x7fe207820f70 WARN h264parse gsth264parse.c:732:gst_h264_parse_process_nal:`<h264parse0>` failed to parse SPS:
0:00:02.285939000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:494:gst_h264_parse_vui_parameters: failed to read uint8, nbits: 1
0:00:02.285948000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:519:gst_h264_parse_vui_parameters: error parsing "VUI Parameters"
0:00:02.285952000 5723 0x7fe207820f70 WARN codecparsers_h264 gsth264parser.c:1771:gst_h264_parse_sps: error parsing "Sequence parameter set"
0:00:02.285956000 5723 0x7fe207820f70 WARN h264parse gsth264parse.c:732:gst_h264_parse_process_nal:`<h264parse0>` failed to parse SPS:
Redistribute latency...
0:00:02.487635000 5723 0x7fe207820f70 FIXME videodecoder gstvideodecoder.c:945:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):`<vtdec0>` Sub-class should implement drain()
0:00:02.500567000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:02.992016000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.026161387 < -+0:00:00.020000000
0:00:03.002633000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.022304414 < -+0:00:00.020000000
0:00:03.056081000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.025659650 < -+0:00:00.020000000
0:00:03.098606000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.024199670 < -+0:00:00.020000000
0:00:03.162608000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.025542416 < -+0:00:00.020000000
0:00:03.237276000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.020886785 < -+0:00:00.020000000
0:00:03.344099000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.021757938 < -+0:00:00.020000000
0:00:03.381288000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:03.503956000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.022442428 < -+0:00:00.020000000
0:00:03.727885000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.021587424 < -+0:00:00.020000000
0:00:04.122796000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.021214951 < -+0:00:00.020000000
0:00:04.609725000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:05.584356000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1512:gst_audio_base_sink_skew_slaving:`<osxaudiosink0>` correct clock skew -0:00:00.020102705 < -+0:00:00.020000000
0:00:05.747763000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:06.979292000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:07.013708000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130181405, resyncing
0:00:08.208908000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:08.496646000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130068027, resyncing
0:00:09.347761000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:09.968630000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130204081, resyncing
0:00:10.581011000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:11.430185000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130249433, resyncing
0:00:11.814706000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
0:00:12.902327000 5723 0x7fe207918a80 WARN audiobasesink gstaudiobasesink.c:1807:gst_audio_base_sink_get_alignment:`<osxaudiosink0>` Unexpected discontinuity in audio timestamps of -0:00:00.130113378, resyncing
0:00:12.947475000 5723 0x7fe206d63750 ERROR vtdec vtdec.c:765:gst_vtdec_session_output_callback:`<vtdec0>` Error decoding frame -12348
`^`Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:13.542908000
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
I've also attached a wireshark pcap.
Version: 1.10.4https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/368video-format: Add a new 10bit depth format packed into 20 bytes2021-09-24T13:22:50ZBugzilla Migration Uservideo-format: Add a new 10bit depth format packed into 20 bytes## Submitted by kevin
**[Link to original bug (#785384)](https://bugzilla.gnome.org/show_bug.cgi?id=785384)**
## Description
Hi,
Currently only have GST_VIDEO_FORMAT_P010_10LE video format. The Y of one pixel will be 16 bits fo...## Submitted by kevin
**[Link to original bug (#785384)](https://bugzilla.gnome.org/show_bug.cgi?id=785384)**
## Description
Hi,
Currently only have GST_VIDEO_FORMAT_P010_10LE video format. The Y of one pixel will be 16 bits for one pixel. We need NV12 10 bits LE with packed, not 0 pading. The Y of one pixel should be 10 bits for one pixel.
Can you help?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/366Internal Data Stream Error when trying to play certain ogg vorbis files2021-09-24T13:22:49ZBugzilla Migration UserInternal Data Stream Error when trying to play certain ogg vorbis files## Submitted by aha..@..ok.com
**[Link to original bug (#784851)](https://bugzilla.gnome.org/show_bug.cgi?id=784851)**
## Description
I am using Ubuntu 17.04 and the default gstreamer version from the ubuntu 17.04 repo.
I can n...## Submitted by aha..@..ok.com
**[Link to original bug (#784851)](https://bugzilla.gnome.org/show_bug.cgi?id=784851)**
## Description
I am using Ubuntu 17.04 and the default gstreamer version from the ubuntu 17.04 repo.
I can not play some of my ogg vorbis files. Some of them have worked before but do not work now after setting tags with EasyTAG (I set the album cover and track-/album-title).
I get an "internal data stream error" on Rhythmbox, Lollypop and Clementine.
I can play these files with ffplay.
Sadly, I can not upload an example file because of the file size limit.
They are all encoded in 256kbit/s, so they are too big.
Also, copyright could be an issue.
Output of "gst-play-1.0 01\ Hells\ Bells.ogg":
Geben Sie »k« ein, um die Liste der Tastenkombinationen zu sehen.
Momentan wird /home/ahahn94/Musik/AC-DC/Back In Black/01 Hells Bells.ogg wiedergegeben
ERROR Internal data stream error. for file:///home/ahahn94/Musik/AC-DC/Back%20In%20Black/01%20Hells%20Bells.ogg
ERROR debug information: gstoggdemux.c(4851): gst_ogg_demux_loop (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstOggDemux:oggdemux0:
streaming stopped, reason error (-5)
Das Ende der Wiedergabeliste wurde erreicht.
I hope you can help me fix this problem.
Greetings from Germany.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/360appsink hangs if sync is true2021-09-24T13:22:47ZBugzilla Migration Userappsink hangs if sync is true## Submitted by dashesy
**[Link to original bug (#784063)](https://bugzilla.gnome.org/show_bug.cgi?id=784063)**
## Description
This happens sporadically and in a slow VM (just connecting multifilesrc to appsink):
```
thread #...## Submitted by dashesy
**[Link to original bug (#784063)](https://bugzilla.gnome.org/show_bug.cgi?id=784063)**
## Description
This happens sporadically and in a slow VM (just connecting multifilesrc to appsink):
```
thread #6: tid = 41178, 0x00007fe29b600c21 libc.so.6`__GI_ppoll(fds=0x00007fe27c043ac0, nfds=1, timeout=<unavailable>, sigmask=0x0000000000000000) + 145 at ppoll.c:50, name = 'multifilesrc0:s', stop reason = signal SIGSTOP
frame #0: 0x00007fe29b600c21 libc.so.6`__GI_ppoll(fds=0x00007fe27c043ac0, nfds=1, timeout=<unavailable>, sigmask=0x0000000000000000) + 145 at ppoll.c:50
frame #1: 0x00007fe2a5e0e818 libgstreamer-1.0.so.0`gst_poll_wait + 1784
frame #2: 0x00007fe2a5e24eb1 libgstreamer-1.0.so.0`??? + 145
frame #3: 0x00007fe2a5dd3dfb libgstreamer-1.0.so.0`gst_clock_id_wait + 91
frame #4: 0x00007fe2a60dcadc libgstbase-1.0.so.0`gst_base_sink_wait_clock + 332
frame #5: 0x00007fe2a60ddf80 libgstbase-1.0.so.0`??? + 1824
frame #6: 0x00007fe2a60defb2 libgstbase-1.0.so.0`??? + 1938
frame #7: 0x00007fe2a60e0620 libgstbase-1.0.so.0`??? + 240
frame #8: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #9: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #10: 0x00007fe2a60ea47d libgstbase-1.0.so.0`??? + 397
frame #11: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #12: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #13: 0x00007fe2a5dea513 libgstreamer-1.0.so.0`gst_proxy_pad_chain_default + 179
frame #14: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #15: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #16: 0x00007fe2a3eab8df libgstvideo-1.0.so.0`??? + 3167
frame #17: 0x00007fe2a3eb2110 libgstvideo-1.0.so.0`gst_video_decoder_finish_frame + 512
frame #18: 0x00007fe2833f46d3 libgstjpeg.so
frame #19: 0x00007fe2a3eaa4c6 libgstvideo-1.0.so.0`??? + 422
frame #20: 0x00007fe2a3eaa97d libgstvideo-1.0.so.0`??? + 157
frame #21: 0x00007fe2a3ead173 libgstvideo-1.0.so.0`??? + 755
frame #22: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #23: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #24: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #25: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #26: 0x00007fe2a5dea513 libgstreamer-1.0.so.0`gst_proxy_pad_chain_default + 179
frame #27: 0x00007fe2a5df954f libgstreamer-1.0.so.0`??? + 1935
frame #28: 0x00007fe2a5e01483 libgstreamer-1.0.so.0`gst_pad_push + 275
frame #29: 0x00007fe2a60e5da5 libgstbase-1.0.so.0`??? + 1013
frame #30: 0x00007fe2a5e2be71 libgstreamer-1.0.so.0`??? + 401
frame #31: 0x00007fe29ebfd55e libglib-2.0.so.0`??? + 158
frame #32: 0x00007fe29ebfcbc5 libglib-2.0.so.0`??? + 85
frame #33: 0x00007fe29ca936ba libpthread.so.0`start_thread + 202
frame #34: 0x00007fe29b60c82d libc.so.6`__clone + 109 at clone.S:109
```
If I set "sync=false" for appsink, the problem is resolved.
The error looks similar to this: https://lists.freedesktop.org/archives/gstreamer-bugs/2015-February/141581.html which specifies [Bug 737427](https://bugzilla.gnome.org/show_bug.cgi?id=737427)
Version: 1.8.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/340First buffer from theoradec always has segment.start timestamp2021-09-24T13:22:37ZBugzilla Migration UserFirst buffer from theoradec always has segment.start timestamp## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#779347)](https://bugzilla.gnome.org/show_bug.cgi?id=779347)**
## Description
I've encountered an error with splitmuxsrc and reverse playback. The first buffer from ogg...## Submitted by Jan Schmidt `@thaytan`
**[Link to original bug (#779347)](https://bugzilla.gnome.org/show_bug.cgi?id=779347)**
## Description
I've encountered an error with splitmuxsrc and reverse playback. The first buffer from oggdemux for a file fragment always has timestamp NONE. Theoradec/ videodecoder guess a timestamp equal to segment->start which is normally OK, except here.
With splitmuxsrc, it each fragment is a separate ogg file, so there'll be a first buffer for each part with timestamp NONE.
TBH, I'm not sure how we should fix it. Either oggdemux needs to be able to work out the correct timestamp to put on the first theora packet in a stream, or theoradec needs to somehow work backward from the 2nd packet to calculate the timestamp for the first. videodecoder might be able to do the 2nd if it defers guessing a timestamp until it's pushing out the reverse buffers.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/322gl: Allow build even if no window system is enabled2021-09-24T13:22:29ZBugzilla Migration Usergl: Allow build even if no window system is enabled## Submitted by Olivier Blin
**[Link to original bug (#776578)](https://bugzilla.gnome.org/show_bug.cgi?id=776578)**
## Description
The gst-gl plugins and libraries should be allowed to build even if no window system is enabled.
...## Submitted by Olivier Blin
**[Link to original bug (#776578)](https://bugzilla.gnome.org/show_bug.cgi?id=776578)**
## Description
The gst-gl plugins and libraries should be allowed to build even if no window system is enabled.
On platforms that do not provide a standard GL window system, this is useful for applications using gst-gl with their own sink, like WebKit with GSTREAMER_GL enabled.
When no window system is supported, glimagesink will use a dummy window (see gst_gl_window_new).https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/321GstGL: Occasional assertion failures on GST_IS_GL_DISPLAY and GST_IS_GL_CONTEXT2021-09-24T13:22:29ZBugzilla Migration UserGstGL: Occasional assertion failures on GST_IS_GL_DISPLAY and GST_IS_GL_CONTEXT## Submitted by Petros
**[Link to original bug (#776540)](https://bugzilla.gnome.org/show_bug.cgi?id=776540)**
## Description
Created attachment 342522
GST_DEBUG=*gl:6
I am experiencing some weird behavior related to the GstG...## Submitted by Petros
**[Link to original bug (#776540)](https://bugzilla.gnome.org/show_bug.cgi?id=776540)**
## Description
Created attachment 342522
GST_DEBUG=*gl:6
I am experiencing some weird behavior related to the GstGL elements when trying to load videos in async mode ( i.e not blocking the pipeline until its pre-rolled ).
More specifically I occasionally get :
** (`<unknown>`:65255): CRITICAL **: gst_gl_context_get_display: assertion 'GST_IS_GL_CONTEXT (context)' failed
** (`<unknown>`:65255): CRITICAL **: gst_gl_display_get_handle_type: assertion 'GST_IS_GL_DISPLAY (display)' failed
(`<unknown>`:65255): GStreamer-CRITICAL **: gst_object_unref: assertion 'object != NULL' failed
(`<unknown>`:65255): GStreamer-CRITICAL **: gst_object_unref: assertion 'object != NULL' failed
and / or
(`<unknown>`:65255): GStreamer-CRITICAL **: invalid unclassed object pointer for value type 'GstGLDisplay'
These assertion failures show up in a non-consistent way and although the application most of the times will still continue properly there are other times where it will just fail an abort. What is interesting is that if I export GST_DEBUG=*gl:6 to try and observe what is happening the application will fail after some reloads with:
** (`<unknown>`:64943): CRITICAL **: gst_gl_context_fill_info: assertion 'context->priv->active_thread == g_thread_self ()' failed
**
ERROR:gstglcontext.c:1252:gst_gl_context_create_thread: assertion failed: (error == NULL || *error != NULL)
Attached you can find the log output of such a failure configured with GST_DEBUG=*gl:6.
Again, this does not manifest if I block the pipeline until its pre-rolled .
I ve been seeing this behavior on both OS X and Linux but I m currently testing on OS X.
The player is playbin based and is located here :
https://github.com/PetrosKataras/Cinder/blob/master/src/cinder/linux/GstPlayer.cpp
with the relevant parts of initializing and setting the GL components :
https://github.com/PetrosKataras/Cinder/blob/master/src/cinder/linux/GstPlayer.cpp#L168-L193
https://github.com/PetrosKataras/Cinder/blob/master/src/cinder/linux/GstPlayer.cpp#L465-L503
https://github.com/PetrosKataras/Cinder/blob/master/src/cinder/linux/GstPlayer.cpp#L561-L585
I would really appreciate any clues on this..
**Attachment 342522**, "GST_DEBUG=*gl:6":
[log.txt](/uploads/295bcf407f8f08f92d1bfde3ac38d66b/log.txt)
Version: 1.10.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/305audiotestsrc: Improvements to the "ticks" waveform2021-09-24T13:22:18ZBugzilla Migration Useraudiotestsrc: Improvements to the "ticks" waveform## Submitted by Carlos Rafael Giani
**[Link to original bug (#774050)](https://bugzilla.gnome.org/show_bug.cgi?id=774050)**
## Description
The ticks waveform can be useful for audio synchronization diagnostics and other cases where ...## Submitted by Carlos Rafael Giani
**[Link to original bug (#774050)](https://bugzilla.gnome.org/show_bug.cgi?id=774050)**
## Description
The ticks waveform can be useful for audio synchronization diagnostics and other cases where the time offset between waveforms is important. However, in its current form, it is too limited, and has problems with discontinuities, which result in severe artifacts when this waveform is output by a DAC.
These patches fix some discontinuities and considerably expand the ticks waveform's flexibility.
They also introduce the notion of a "marker tick"; every Nth tick can have a different amplitude (usually one that is larger than the others). This is useful for combining frequent oscilloscope triggering with large time offset detection. For example, without marker ticks, the tick intervals must not be too small, otherwise the maximum time offset that can be unambiguously detected is quite small (for example, if the interval is 50ms, then no time offset larger than 25ms can be unambiguously recognized). If the tick intervals are too far apart, then no sudden changes can be clearly observed, since the oscilloscope is not updated quickly enough. But with marker ticks, this is not an issue: If there's for example a tick every 100 ms, then the oscilloscope can be triggered every 100 ms. And, if every 20th tick is a marker tick, then time offsets of up to 1 second can be discovered, even though the time between ticks is 100 ms.
The patches also apply some minor cleanup to the audiotestsrc documentation.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/287glupload: propose dma buffer pool upstream based on ion allocator2021-09-24T13:22:10ZBugzilla Migration Userglupload: propose dma buffer pool upstream based on ion allocator## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#770585)](https://bugzilla.gnome.org/show_bug.cgi?id=770585)**
## Description
1. Propose ion dma-fd buffer pool to upstream
2. If upstream don't choose the proposed buf...## Submitted by Haihua Hu `@JaredHu`
**[Link to original bug (#770585)](https://bugzilla.gnome.org/show_bug.cgi?id=770585)**
## Description
1. Propose ion dma-fd buffer pool to upstream
2. If upstream don't choose the proposed buffer pool, then create our own and do buffer copy to avoid memory copy from CPU to GPU side
3. Add buffer alignment
### Depends on
* [Bug 768794](https://bugzilla.gnome.org/show_bug.cgi?id=768794)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/279playbin: Add videoflip/glvideoflip or similar to the video-sink2021-09-24T13:22:05ZBugzilla Migration Userplaybin: Add videoflip/glvideoflip or similar to the video-sink## Submitted by Andy Robinson
**[Link to original bug (#769147)](https://bugzilla.gnome.org/show_bug.cgi?id=769147)**
## Description
Created attachment 332099
2 second video of a door, portrait mode.
I attach a 2-second video...## Submitted by Andy Robinson
**[Link to original bug (#769147)](https://bugzilla.gnome.org/show_bug.cgi?id=769147)**
## Description
Created attachment 332099
2 second video of a door, portrait mode.
I attach a 2-second video taken on an iPhone 4S. It's a portrait mode video of a normal upright door. I can double-click it on Windows 10 or Mac 10.0 and it plays correctly as portrait mode. However GStreamer displays it in landscape mode with the door on its side. I've tried:
gst-launch-1.0 filesrc location=door_rotn.mov ! decodebin ! videoconvert ! autovideosink
Linux GST 1.2.4
Windows GST 1.8.2
Mac GST 1.8.2
Obviously it's easy enough to put a rotation into the GStreamer pipeline to correct it, but it shouldn't be necessary.
Andy Robinson
**Attachment 332099**, "2 second video of a door, portrait mode.":
![door_rotn](/uploads/0d0007f324a2eea52b54ff40717f1d45/door_rotn.mov)
Version: 1.8.2
### Depends on
* [Bug 768687](https://bugzilla.gnome.org/show_bug.cgi?id=768687)
### Blocking
* [Bug 765309](https://bugzilla.gnome.org/show_bug.cgi?id=765309)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/275CGLCreateContext hangs on a lock with context sharing and java (maybe CFRunLo...2021-09-24T13:22:01ZBugzilla Migration UserCGLCreateContext hangs on a lock with context sharing and java (maybe CFRunLoop issues?)## Submitted by gohai
**[Link to original bug (#768630)](https://bugzilla.gnome.org/show_bug.cgi?id=768630)**
## Description
I have a playbin-pipeline of a local file, which is initially being set to paused to allow for seeking etc....## Submitted by gohai
**[Link to original bug (#768630)](https://bugzilla.gnome.org/show_bug.cgi?id=768630)**
## Description
I have a playbin-pipeline of a local file, which is initially being set to paused to allow for seeking etc. When I call gst_element_get_state() afterwards, to wait for the asynchronous state change to succeed this hangs forever.
My application uses GL context sharing. Marcin spotted the following line in the logs, which he thought was suspicious "pad_query:<glcolorconvertelement0:src> pad peer query failed". Indeed, when I remove the glcolorconvert from the pipeline, the problem (hang) disappears.
You find the setup of the application's pipeline here:
https://github.com/gohai/processing-glvideo/blob/b8bc94f59630b010e52fe25846e1c5423c8398dd/src/native/impl.c#L240
I am attaching a GST_DEBUG=*:5 trace. When I gdb the process as it hangs I find the following two threads that are gstreamer-related:
```
Thread 36 (Thread 0x3c03 of process 35111):
#0 0x00007fff8a68707a in ?? () from /usr/lib/system/libsystem_kernel.dylib
#1 0x000000012dc0a0fa in g_poll () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglib-2.0.0.dylib
#2 0x000000012dbfbc9d in g_main_context_iterate () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglib-2.0.0.dylib
#3 0x000000012dbfc01f in g_main_loop_run () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglib-2.0.0.dylib
#4 0x000000012d9ffe41 in gst_gl_window_navigation_thread () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libgstgl-1.0.0.dylib
#5 0x000000012dc2344a in g_thread_proxy () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglib-2.0.0.dylib
#6 0x00007fff8ed6699d in ?? () from /usr/lib/system/libsystem_pthread.dylib
#7 0x000000000000f503 in ?? ()
#8 0x0000700002006000 in ?? ()
#9 0x0000700002005f50 in ?? ()
#10 0x00007fff8ed6691a in ?? () from /usr/lib/system/libsystem_pthread.dylib
#11 0x0000000000000000 in ?? ()
Thread 27 (Thread 0x3303 of process 35111):
#0 0x00007fff8a68707a in ?? () from /usr/lib/system/libsystem_kernel.dylib
#1 0x000000012dc0a0fa in g_poll () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglib-2.0.0.dylib
#2 0x000000012dbfbc9d in g_main_context_iterate () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglib-2.0.0.dylib
#3 0x000000012dbfc01f in g_main_loop_run () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglib-2.0.0.dylib
#4 0x000000012d9db68c in glvideo_mainloop () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglvideo.jnilib
#5 0x000000012dc2344a in g_thread_proxy () from /Users/gohai/Documents/Code/processing-glvideo/library/macosx/libglib-2.0.0.dylib
#6 0x00007fff8ed6699d in ?? () from /usr/lib/system/libsystem_pthread.dylib
#7 0x000000000000ed07 in ?? ()
#8 0x0000700001c71000 in ?? ()
#9 0x0000700001c70f50 in ?? ()
#10 0x00007fff8ed6691a in ?? () from /usr/lib/system/libsystem_pthread.dylib
#11 0x0000000000000000 in ?? ()
```
Version: 1.8.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/250http: cookies sharing in the pipeline2021-09-24T13:21:48ZBugzilla Migration Userhttp: cookies sharing in the pipeline## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#761099)](https://bugzilla.gnome.org/show_bug.cgi?id=761099)**
## Description
Currently if there are multiple http source elements in a pipeline they will...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#761099)](https://bugzilla.gnome.org/show_bug.cgi?id=761099)**
## Description
Currently if there are multiple http source elements in a pipeline they will all use independent connections, causing their cookies to be also independent. This can be harmful when those elements are communicating with the same service and this service uses some kind of cookie-based feature, causing the connections to be rejected or not working as expected.
One particular use case is for adaptive streaming for servers that set some cookie on the playlist/manifest and then check that the cookie exists in subsequent requests to the fragments.
A test server that does this verification can be found at: https://github.com/thiagoss/adaptive-test-server.
A few bugs that are related/duplicates of this. Decided to open a new one because the others seem to only attempt to solve partially the problem.
https://bugzilla.gnome.org/show_bug.cgi?id=726314
https://bugzilla.gnome.org/show_bug.cgi?id=751371
https://bugzilla.gnome.org/show_bug.cgi?id=751372
https://bugzilla.gnome.org/show_bug.cgi?id=731170
### Blocking
* [Bug 775920](https://bugzilla.gnome.org/show_bug.cgi?id=775920)
### See also
* [Bug 780117](https://bugzilla.gnome.org/show_bug.cgi?id=780117)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/242When a pipeline is in GST_STATE_READY, "sync-message::need-context" is not em...2021-09-24T13:21:45ZBugzilla Migration UserWhen a pipeline is in GST_STATE_READY, "sync-message::need-context" is not emitted for GstGL.## Submitted by ChangSeok Oh
**[Link to original bug (#757933)](https://bugzilla.gnome.org/show_bug.cgi?id=757933)**
## Description
This issue is found while testing yoon's experimental webkit branch implementing GstGL support along...## Submitted by ChangSeok Oh
**[Link to original bug (#757933)](https://bugzilla.gnome.org/show_bug.cgi?id=757933)**
## Description
This issue is found while testing yoon's experimental webkit branch implementing GstGL support along with threaded compositor in webkitgtk+.
https://github.com/ryumiel/webkit-experimental/tree/threaded-compositor-wip
It works fine in overall, but there is some issues related with gstreamer.
How to reproduce.
1. Play a video and watch it completely.
2. Replay it in 60 secs.
When replaying a video, an unknown xwindow shows up of which name is "OpenGL renderer". I have investigated it for a while, I found it was created by gstreamer if no gl context is passed from the outside to the gstreamer at beginning of the gst pipeline.
Of course webkit create a GstGL context and passes it to gst when listening the "sync-message::need-context" signal from gstreamer.
The problem is that the singal is only emitted when the pipeline is in GST_STATE_NULL, but not in GST_STATE_READY. I don't know why.
WebKit changes the pipeline state to GST_STATE_READY when receiving GST_MESSAGE_EOS, and then changes it again to GST_STATE_NULL after 60 secs. As I heard, this is due to better performance for replaying video.
Anyway if replaying video is triggered in the 60secs, the need-context signal is not emitted so webkit can not create and pass a GstGL context for the new gst pipeline and then it eventually leads gstreamer to create its own xwindow along with a gl context. Replaying *after* 60secs is no problem.
So I think the best fix for this issue is that gstreamer emits "sync-message::need-context" even in GST_STATE_READY so that it gives an application a chance to create a gstgl context.
Any idea?
I'trying to make a test case for you though, I'm not a gst expert. So don't believe me. :P (Of course, I'll provide you one if it is ready.)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/207glfiltercube: the cube does not look like a cube2021-09-24T13:21:28ZBugzilla Migration Userglfiltercube: the cube does not look like a cube## Submitted by Julien Isorce `@cap`
**[Link to original bug (#752745)](https://bugzilla.gnome.org/show_bug.cgi?id=752745)**
## Description
glfiltercube does not output a cube :)
Instead of properly computing the Model-View-Pro...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#752745)](https://bugzilla.gnome.org/show_bug.cgi?id=752745)**
## Description
glfiltercube does not output a cube :)
Instead of properly computing the Model-View-Projection matrixes, we currently provide this fixed matrix: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/gl/gstglfiltercube.c#n454
The cube was showing ok when not using shaders but since we moved to use shaders not only on gles2 I realize the cube was already wrong with gles2+GstGL-0.10 (see http://cgit.freedesktop.org/gstreamer/attic/gst-plugins-gl/commit/gst/gl/gstglfiltercube.c?id=e12532c6c5bb0fcbbf94abb6aa8e98757e536d1d)
But it requires to manually do some maths. See http://cgit.freedesktop.org/gstreamer/gst-omx/tree/examples/egl/testegl.c#n123
Maybe we can add gst_gl_matrix_load_identity/gst_gl_matrix_multiply/gst_gl_matrix_translate/gst_gl_matrix_frustum/gst_gl_matrix_perspective
It seems to me to be "a small piece of library API there" (from "master feature freeze email") but not sure.
Otherwise we keep these functions locally in glfiltercube and move them to GstGL after 1.6, see following patch.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/175glimagesink: cannot set window handle to 02021-09-24T13:21:11ZBugzilla Migration Userglimagesink: cannot set window handle to 0## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#746701)](https://bugzilla.gnome.org/show_bug.cgi?id=746701)**
## Description
When I set glimagesink's window-handle to 0, I get that critical:
** (lt-scout-...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#746701)](https://bugzilla.gnome.org/show_bug.cgi?id=746701)**
## Description
When I set glimagesink's window-handle to 0, I get that critical:
** (lt-scout-client-gtk:25380): CRITICAL **: gst_gl_window_set_window_handle: assertion 'handle != 0' failed
But gst_video_overlay_set_window_handle()'s doc says this:
"Passing 0 as the handle will tell the overlay to stop using that window and create an internal one."
In my case I'm on android, since it cannot create a new window there, I guess the sink has 2 options: drop buffers or block the streaming thread (equivalent of PAUSED, right?) until it get a new window handle. On android when switching app the SurfaceView is destroyed so in that case it sets the window-handle to 0 and I think it makes sense to pause the stream.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/174opusenc: headers are never sent2021-09-24T13:21:10ZBugzilla Migration Useropusenc: headers are never sent## Submitted by Ilya Konstantinov
**[Link to original bug (#746617)](https://bugzilla.gnome.org/show_bug.cgi?id=746617)**
## Description
opusenc is creating headers but they never get sent. Therefore opusdec resorts to fallback valu...## Submitted by Ilya Konstantinov
**[Link to original bug (#746617)](https://bugzilla.gnome.org/show_bug.cgi?id=746617)**
## Description
opusenc is creating headers but they never get sent. Therefore opusdec resorts to fallback values, e.g. always 2 channels.
(e.g. in OpenWebRTC this results in wasteful audioconverts)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/173tests: Add unit test for alpha manipulation in video-converter2021-09-24T13:21:10ZBugzilla Migration Usertests: Add unit test for alpha manipulation in video-converter## Submitted by RaviKiran
**[Link to original bug (#746142)](https://bugzilla.gnome.org/show_bug.cgi?id=746142)**
## Description
Add unit test for alpha manipulation in video-converter.## Submitted by RaviKiran
**[Link to original bug (#746142)](https://bugzilla.gnome.org/show_bug.cgi?id=746142)**
## Description
Add unit test for alpha manipulation in video-converter.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/154videodecoder: Spurious renegotiation2021-09-24T13:21:02ZBugzilla Migration Uservideodecoder: Spurious renegotiation## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#742883)](https://bugzilla.gnome.org/show_bug.cgi?id=742883)**
## Description
We made changed recently in the video decoder behaviour and I think they might be r...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#742883)](https://bugzilla.gnome.org/show_bug.cgi?id=742883)**
## Description
We made changed recently in the video decoder behaviour and I think they might be related to spurious renegotiation happening in various decoder. Right not it happens twice in v4l2videodec, and every frame with avdec_h264. To reproduce:
gdb --args gst-launch-1.0 filesrc location=some.mp4 ! qtdemux ! avdec_h264 ! fakesink
$ break gst_ffmpegviddec_negotiate
Normally in such a simple pipeline, negotiate should be called only once.