GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T11:10:08Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/182baseparse: Buffers are dropped after concat element switches pad2021-09-24T11:10:08ZBugzilla Migration Userbaseparse: Buffers are dropped after concat element switches pad## Submitted by Carlos Rafael Giani
**[Link to original bug (#769949)](https://bugzilla.gnome.org/show_bug.cgi?id=769949)**
## Description
If a baseparse-based element is placed after a concat element, and the parser element lets ba...## Submitted by Carlos Rafael Giani
**[Link to original bug (#769949)](https://bugzilla.gnome.org/show_bug.cgi?id=769949)**
## Description
If a baseparse-based element is placed after a concat element, and the parser element lets baseparse compute timestamps, then after concat switches to the next sinkpad, baseparse will drop buffers.
Example:
gst-launch-1.0 -v \
filesrc location=test.mp3 name=a \
filesrc location=test.mp3 name=b \
concat name=c \
a. ! c. b. ! c. \
c. ! mpegaudioparse ! fakesink sync=false silent=false
The -v switch shows that after concat switched to element "b", no buffers are received by the fakesink.
(I picked mpegaudioparse because it fulfilled the criteria above. It does not have to be MP3 data.)
After some digging, I found that it may have something to do with the PTS timestamps that come from the sources. I inserted identity elements into the pipeline to check:
gst-launch-1.0 -v \
filesrc location=test.mp3 ! identity silent=false name=a \
filesrc location=test.mp3 ! identity silent=false name=b \
concat name=c \
a. ! c. b. ! c. \
c. ! mpegaudioparse ! fakesink sync=false silent=false
And the output shows for "a":
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: 0:00:00.000000000, pts: none, duration: none, offset: 0, offset_end: 4096, flags: 00000040 discont ) 0x7f3f280060b0
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 4096, offset_end: 8192, flags: 00000000 ) 0x7f3f280063e0
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 8192, offset_end: 12288, flags: 00000000 ) 0x7f3f280061c0
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 12288, offset_end: 16384, flags: 00000000 ) 0x7f3f280064f0
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 16384, offset_end: 20480, flags: 00000000 ) 0x7f3f280060b0
....
while for "b", it shows:
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: 0:00:00.000000000, pts: 0:00:00.000000000, duration: none, offset: 0, offset_end: 4096, flags: 00000040 discont ) 0x7f5884006820
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 4096, offset_end: 8192, flags: 00000000 ) 0x7f5884006b50
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 8192, offset_end: 12288, flags: 00000000 ) 0x7f5884006600
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 12288, offset_end: 16384, flags: 00000000 ) 0x7f5884006c60
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 16384, offset_end: 20480, flags: 00000000 ) 0x7f5884006930
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 20480, offset_end: 24576, flags: 00000000 ) 0x7f5884006600
....
Note that the first "a" buffer has PTS NONE, while the first "b" buffer has PTS 0.
It is my impression that baseparse sees this first PTS 0, and bases its computed PTS on that. In other words, they start at 0, and they are *not* adjusted to the segment's base time. The result is that baseparse drops the buffer because the timestamp is too old:
0:00:00.115488463 19446 0x20f7720 TRACE baseparse gstbaseparse.c:2389:gst_base_parse_push_frame:`<mpegaudioparse0>` pushing frame 0x7f3a5c0021e0
0:00:00.115496270 19446 0x20f7720 LOG baseparse gstbaseparse.c:2399:gst_base_parse_push_frame:`<mpegaudioparse0>` processing buffer of size 288 with dts 0:00:00.036000000, pts 0:00:00.036000000, duration 0:00:00.036000000
0:00:00.115512084 19446 0x20f7720 LOG baseparse gstbaseparse.c:1858:gst_base_parse_update_bitrates:`<mpegaudioparse0>` frame bitrate 64000, avg bitrate 64000
0:00:00.115520227 19446 0x20f7720 LOG baseparse gstbaseparse.c:2525:gst_base_parse_push_frame:`<mpegaudioparse0>` Dropped frame, before segment
0:00:00.115525584 19446 0x20f7720 LOG baseparse gstbaseparse.c:2534:gst_base_parse_push_frame:`<mpegaudioparse0>` frame (288 bytes) dropped
0:00:00.115532254 19446 0x20f7720 LOG baseparse gstbaseparse.c:2173:gst_base_parse_handle_buffer:`<mpegaudioparse0>` handle_frame skipped 0, flushed 288
0:00:00.115539301 19446 0x20f7720 TRACE baseparse gstbaseparse.c:711:gst_base_parse_frame_free: freeing frame 0x7f3a5c0021e0
....
However, I am not sure if this is a bug in basesrc or in baseparse. basesrc's behavior with regards to the first buffer's PTS is odd. I do not know if it is expected though.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/181multiqueue: Deadlock in _sink_activate_mode when releasing pad2022-11-10T09:20:46ZBugzilla Migration Usermultiqueue: Deadlock in _sink_activate_mode when releasing pad## Submitted by Marcin Lewandowski
**[Link to original bug (#769764)](https://bugzilla.gnome.org/show_bug.cgi?id=769764)**
## Description
I am using GStreamer 1.8.2 to create a pipeline that has multiple input branches, created dyna...## Submitted by Marcin Lewandowski
**[Link to original bug (#769764)](https://bugzilla.gnome.org/show_bug.cgi?id=769764)**
## Description
I am using GStreamer 1.8.2 to create a pipeline that has multiple input branches, created dynamically after D-Bus method call. Each of the branch contains shmsrc do_timestamp=true is_live=true ! capsfilter. They are wrapped into bin, where capsfilter's src pad becomes ghost pad.
Each of such branches is linked with multiqueue, and multiqueue is linked to the audiomixer.
It may happen that such branches are added/removed in the runtime.
In case of adding I just create them, request new pads on the multiqueue, audiomixer and link them (no pausing or pad blocking involved).
In case of removing I just unlink the bin, release pads (no pausing or pad blocking involved).
In case of errors (e.g. when SHM socket is closed) I override bin's virtual handle_message and intercept ERROR messages (I don't want them to propagate accross whole pipeline), and remove bin using method above in the next idle cycle of the mainloop.
This is what I got today, after D-Bus call that involved adding a branch.
```
(gdb) thr a a bt
Thread 10 (Thread 0x7f36b491c700 (LWP 16701)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007f36c121b8cf in g_cond_wait (cond=cond@entry=0x231e850, mutex=mutex@entry=0x22ba290) at gthread-posix.c:1397
#2 0x00007f36bd64ca6e in gst_multi_queue_sink_query (pad=<optimized out>, parent=0x22ba120, query=0x7f36880018f0) at gstmultiqueue.c:2192
#3 0x00007f36c08f17e8 in gst_pad_query (pad=pad@entry=0x231d490, query=query@entry=0x7f36880018f0) at gstpad.c:3922
#4 0x00007f36c08f1db3 in gst_pad_peer_query (pad=pad@entry=0x22e02c0, query=0x7f36880018f0) at gstpad.c:4054
#5 0x00007f36c08f24e3 in query_forward_func (pad=pad@entry=0x22e02c0, data=data@entry=0x7f36b491b9d0) at gstpad.c:3303
#6 0x00007f36c08f04de in gst_pad_forward (pad=pad@entry=0x22e23c0, forward=forward@entry=0x7f36c08f2430 <query_forward_func>, user_data=user_data@entry=0x7f36b491b9d0) at gstpad.c:2936
#7 0x00007f36c08f0761 in gst_pad_query_default (pad=0x22e23c0, parent=<optimized out>, query=0x7f36880018f0) at gstpad.c:3370
#8 0x00007f36c08f17e8 in gst_pad_query (pad=pad@entry=0x22e23c0, query=query@entry=0x7f36880018f0) at gstpad.c:3922
#9 0x00007f36c08f1db3 in gst_pad_peer_query (pad=0x2317230, query=query@entry=0x7f36880018f0) at gstpad.c:4054
#10 0x00007f36bd3fb962 in gst_base_transform_default_propose_allocation (trans=0x7f36a4007530, decide_query=<optimized out>, query=0x7f36880018f0) at gstbasetransform.c:1435
#11 0x00007f36bd3fe991 in gst_base_transform_default_query (trans=0x7f36a4007530, direction=<optimized out>, query=0x7f36880018f0) at gstbasetransform.c:1535
#12 0x00007f36c08f17e8 in gst_pad_query (pad=pad@entry=0x2317b30, query=query@entry=0x7f36880018f0) at gstpad.c:3922
#13 0x00007f36c08f1db3 in gst_pad_peer_query (pad=0x2317d70, query=query@entry=0x7f36880018f0) at gstpad.c:4054
#14 0x00007f36bd3f5a48 in gst_base_src_prepare_allocation (caps=0x0, basesrc=0x23209a0) at gstbasesrc.c:3137
#15 gst_base_src_negotiate (basesrc=0x23209a0) at gstbasesrc.c:3281
#16 gst_base_src_loop (pad=0x2317d70) at gstbasesrc.c:2698
#17 0x00007f36c091ded1 in gst_task_func (task=0x22b0950) at gsttask.c:332
#18 0x00007f36c11fe27e in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307
#19 0x00007f36c11fd8e5 in g_thread_proxy (data=0x7f36900041e0) at gthread.c:778
#20 0x00007f36c0f776fa in start_thread (arg=0x7f36b491c700) at pthread_create.c:333
#21 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 9 (Thread 0x7f36a2ffd700 (LWP 16292)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007f36c121b8cf in g_cond_wait (cond=cond@entry=0x22b00b0, mutex=mutex@entry=0x22b0068) at gthread-posix.c:1397
#2 0x00007f36c091e06d in gst_task_func (task=0x22b0050) at gsttask.c:317
#3 0x00007f36c11fe27e in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307
#4 0x00007f36c11fd8e5 in g_thread_proxy (data=0x7f3694003230) at gthread.c:778
#5 0x00007f36c0f776fa in start_thread (arg=0x7f36a2ffd700) at pthread_create.c:333
#6 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 8 (Thread 0x7f36a37fe700 (LWP 16129)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007f36c121b8cf in g_cond_wait (cond=cond@entry=0x21baa88, mutex=mutex@entry=0x21baa78) at gthread-posix.c:1397
#2 0x00007f36bd409872 in _gst_data_queue_wait_non_empty (queue=queue@entry=0x21baad0) at gstdataqueue.c:553
#3 0x00007f36bd40ab90 in gst_data_queue_pop (queue=0x21baad0, item=item@entry=0x7f36a37fde40) at gstdataqueue.c:595
#4 0x00007f36bd6516d5 in gst_multi_queue_loop (pad=<optimized out>) at gstmultiqueue.c:1575
#5 0x00007f36c091ded1 in gst_task_func (task=0x22b0cb0) at gsttask.c:332
#6 0x00007f36c11fe27e in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307
#7 0x00007f36c11fd8e5 in g_thread_proxy (data=0x7f3690001a30) at gthread.c:778
#8 0x00007f36c0f776fa in start_thread (arg=0x7f36a37fe700) at pthread_create.c:333
#9 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 7 (Thread 0x7f36b5530700 (LWP 21373)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007f36c121b8cf in g_cond_wait (cond=0x22e89b0, mutex=0x22e89a8) at gthread-posix.c:1397
#2 0x00007f36bc8c93d3 in gst_aggregator_pad_chain_internal (self=0x22bf940, aggpad=0x22e8a00, buffer=0x7f369c01aad0, head=1) at gstaggregator.c:2187
#3 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f369c01aad0, type=4112, pad=0x22e8a00) at gstpad.c:4177
#4 gst_pad_push_data (pad=pad@entry=0x22c18f0, type=type@entry=4112, data=data@entry=0x7f369c01aad0) at gstpad.c:4429
#5 0x00007f36c08f34d3 in gst_pad_push (pad=0x22c18f0, buffer=buffer@entry=0x7f369c01aad0) at gstpad.c:4548
#6 0x00007f36bd652124 in gst_single_queue_push_one (allow_drop=<synthetic pointer>, object=0x7f369c01aad0, sq=0x22e77f0, mq=0x22ba120) at gstmultiqueue.c:1417
#7 gst_multi_queue_loop (pad=<optimized out>) at gstmultiqueue.c:1701
#8 0x00007f36c091ded1 in gst_task_func (task=0x22b03b0) at gsttask.c:332
#9 0x00007f36c11fe27e in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307
#10 0x00007f36c11fd8e5 in g_thread_proxy (data=0x22bf280) at gthread.c:778
#11 0x00007f36c0f776fa in start_thread (arg=0x7f36b5530700) at pthread_create.c:333
#12 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 6 (Thread 0x7f36b5d31700 (LWP 21372)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007f36c121b8cf in g_cond_wait (cond=cond@entry=0x21ba9e0, mutex=mutex@entry=0x21ba9b8) at gthread-posix.c:1397
#2 0x00007f36bd40a602 in gst_data_queue_push (queue=0x21baa10, item=item@entry=0x7f3694004120) at gstdataqueue.c:520
#3 0x00007f36bd650ad5 in gst_multi_queue_chain (pad=<optimized out>, parent=<optimized out>, buffer=0x7f36a4029d20) at gstmultiqueue.c:1890
#4 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f36a4029d20, type=4112, pad=0x22c16b0) at gstpad.c:4177
#5 gst_pad_push_data (pad=pad@entry=0x22c1470, type=type@entry=4112, data=data@entry=0x7f36a4029d20) at gstpad.c:4429
#6 0x00007f36c08f34d3 in gst_pad_push (pad=pad@entry=0x22c1470, buffer=0x7f36a4029d20) at gstpad.c:4548
#7 0x00007f36bd3f58d5 in gst_base_src_loop (pad=0x22c1470) at gstbasesrc.c:2850
#8 0x00007f36c091ded1 in gst_task_func (task=0x22b04d0) at gsttask.c:332
#9 0x00007f36c11fe27e in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307
#10 0x00007f36c11fd8e5 in g_thread_proxy (data=0x22eaad0) at gthread.c:778
#11 0x00007f36c0f776fa in start_thread (arg=0x7f36b5d31700) at pthread_create.c:333
#12 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f36b6532700 (LWP 21371)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007f36c121b8cf in g_cond_wait (cond=cond@entry=0x22d83a8, mutex=mutex@entry=0x22d8380) at gthread-posix.c:1397
#2 0x00007f36bd656166 in gst_queue_chain_buffer_or_list (parent=0x22d8100, obj=0x7f369c0226f0, is_list=0, pad=<optimized out>) at gstqueue.c:1225
#3 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f369c0226f0, type=4112, pad=0x22c0ff0) at gstpad.c:4177
#4 gst_pad_push_data (pad=pad@entry=0x22c0db0, type=type@entry=4112, data=data@entry=0x7f369c0226f0) at gstpad.c:4429
#5 0x00007f36c08f34d3 in gst_pad_push (pad=0x22c0db0, buffer=0x7f369c0226f0) at gstpad.c:4548
#6 0x00007f36bd3f9fad in gst_base_transform_chain (pad=<optimized out>, parent=0x22d64e0, buffer=<optimized out>) at gstbasetransform.c:2369
#7 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f369c0226f0, type=4112, pad=0x22c0b70) at gstpad.c:4177
#8 gst_pad_push_data (pad=pad@entry=0x22c0930, type=type@entry=4112, data=data@entry=0x7f369c0226f0) at gstpad.c:4429
#9 0x00007f36c08f34d3 in gst_pad_push (pad=0x22c0930, buffer=0x7f369c0226f0) at gstpad.c:4548
#10 0x00007f36bd3f9fad in gst_base_transform_chain (pad=<optimized out>, parent=0x22d42d0, buffer=<optimized out>) at gstbasetransform.c:2369
#11 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f369c0226f0, type=4112, pad=0x22c06f0) at gstpad.c:4177
#12 gst_pad_push_data (pad=pad@entry=0x22c04b0, type=type@entry=4112, data=data@entry=0x7f369c0226f0) at gstpad.c:4429
#13 0x00007f36c08f34d3 in gst_pad_push (pad=0x22c04b0, buffer=0x7f369c0226f0) at gstpad.c:4548
#14 0x00007f36bd3f9fad in gst_base_transform_chain (pad=<optimized out>, parent=0x22c4bd0, buffer=<optimized out>) at gstbasetransform.c:2369
#15 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f369c0114b0, type=4112, pad=0x22c0270) at gstpad.c:4177
#16 gst_pad_push_data (pad=pad@entry=0x22c0030, type=type@entry=4112, data=data@entry=0x7f369c0114b0) at gstpad.c:4429
#17 0x00007f36c08f34d3 in gst_pad_push (pad=0x22c0030, buffer=buffer@entry=0x7f369c0114b0) at gstpad.c:4548
#18 0x00007f36bc8cb788 in gst_aggregator_finish_buffer (self=self@entry=0x22bf940, buffer=0x7f369c0114b0) at gstaggregator.c:579
#19 0x00007f36bcfb4e86 in gst_audio_aggregator_aggregate (agg=0x22bf940, timeout=0) at gstaudioaggregator.c:1357
#20 0x00007f36bc8cbe53 in gst_aggregator_aggregate_func (self=0x22bf940) at gstaggregator.c:816
#21 0x00007f36c091ded1 in gst_task_func (task=0x22b0290) at gsttask.c:332
#22 0x00007f36c11fe27e in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307
#23 0x00007f36c11fd8e5 in g_thread_proxy (data=0x22bf2d0) at gthread.c:778
#24 0x00007f36c0f776fa in start_thread (arg=0x7f36b6532700) at pthread_create.c:333
#25 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f36b6d33700 (LWP 21370)):
#0 0x00007f36c0ca1f51 in __GI_ppoll (fds=0x7f36ac01deb0, nfds=1, timeout=<optimized out>, timeout@entry=0x7f36b6d32410, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:50
#1 0x00007f36c0900878 in ppoll (__ss=0x0, __timeout=0x7f36b6d32410, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:77
#2 gst_poll_wait (set=0x22eab70, timeout=timeout@entry=24000000) at gstpoll.c:1248
#3 0x00007f36b7599032 in gst_shout2send_render (basesink=0x22f5210, buf=0x7f369c0501f0) at gstshout2.c:648
#4 0x00007f36bd3eecca in gst_base_sink_chain_unlocked (basesink=basesink@entry=0x22f5210, obj=obj@entry=0x7f369c0501f0, is_list=is_list@entry=0, pad=<optimized out>) at gstbasesink.c:3532
#5 0x00007f36bd3f0150 in gst_base_sink_chain_main (basesink=0x22f5210, pad=<optimized out>, obj=0x7f369c0501f0, is_list=0) at gstbasesink.c:3655
#6 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f369c0501f0, type=4112, pad=0x22ee030) at gstpad.c:4177
#7 gst_pad_push_data (pad=pad@entry=0x22c1d70, type=type@entry=4112, data=data@entry=0x7f369c0501f0) at gstpad.c:4429
#8 0x00007f36c08f34d3 in gst_pad_push (pad=0x22c1d70, buffer=0x7f369c0501f0) at gstpad.c:4548
#9 0x00007f36bcd7e834 in gst_audio_encoder_finish_frame (enc=enc@entry=0x22ebe20, buf=0x7f369c0501f0, samples=<optimized out>, samples@entry=1152) at gstaudioencoder.c:1001
#10 0x00007f36b79ebd12 in gst_lamemp3enc_finish_frames (lame=lame@entry=0x22ebe20) at gstlamemp3enc.c:692
#11 0x00007f36b79ec157 in gst_lamemp3enc_handle_frame (enc=0x22ebe20, in_buf=0x7f369c019400) at gstlamemp3enc.c:807
#12 0x00007f36bcd7f43d in gst_audio_encoder_push_buffers (enc=enc@entry=0x22ebe20, force=force@entry=0) at gstaudioencoder.c:1127
#13 0x00007f36bcd80568 in gst_audio_encoder_chain (pad=<optimized out>, parent=0x22ebe20, buffer=0x7f369c022e60) at gstaudioencoder.c:1346
#14 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f369c022e60, type=4112, pad=0x22c1b30) at gstpad.c:4177
#15 gst_pad_push_data (pad=pad@entry=0x22e0050, type=type@entry=4112, data=data@entry=0x7f369c022e60) at gstpad.c:4429
#16 0x00007f36c08f34d3 in gst_pad_push (pad=pad@entry=0x22e0050, buffer=buffer@entry=0x7f369c022e60) at gstpad.c:4548
#17 0x00007f36c08dc573 in gst_proxy_pad_chain_default (pad=0x22e2170, parent=<optimized out>, buffer=0x7f369c022e60) at gstghostpad.c:126
#18 0x00007f36c08eb59f in gst_pad_chain_data_unchecked (data=0x7f369c022e60, type=4112, pad=0x22e2170) at gstpad.c:4177
#19 gst_pad_push_data (pad=pad@entry=0x22c1230, type=type@entry=4112, data=data@entry=0x7f369c022e60) at gstpad.c:4429
#20 0x00007f36c08f34d3 in gst_pad_push (pad=0x22c1230, buffer=buffer@entry=0x7f369c022e60) at gstpad.c:4548
#21 0x00007f36bd655a79 in gst_queue_push_one (queue=0x22d8100) at gstqueue.c:1362
#22 gst_queue_loop (pad=<optimized out>) at gstqueue.c:1509
#23 0x00007f36c091ded1 in gst_task_func (task=0x22b0170) at gsttask.c:332
#24 0x00007f36c11fe27e in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307
#25 0x00007f36c11fd8e5 in g_thread_proxy (data=0x22eaca0) at gthread.c:778
#26 0x00007f36c0f776fa in start_thread (arg=0x7f36b6d33700) at pthread_create.c:333
#27 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f36be083700 (LWP 21369)):
#0 0x00007f36c0ca1e8d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f36c11d71dc in g_main_context_poll (priority=2147483647, n_fds=2, fds=0x7f36b00010c0, timeout=<optimized out>, context=0x21c4a70) at gmain.c:4264
#2 g_main_context_iterate (context=0x21c4a70, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3964
#3 0x00007f36c11d7562 in g_main_loop_run (loop=0x22a96e0) at gmain.c:4163
#4 0x00007f36c17f8276 in gdbus_shared_thread_func (user_data=0x21c4a40) at gdbusprivate.c:246
#5 0x00007f36c11fd8e5 in g_thread_proxy (data=0x223c540) at gthread.c:778
#6 0x00007f36c0f776fa in start_thread (arg=0x7f36be083700) at pthread_create.c:333
#7 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f36be884700 (LWP 21368)):
#0 0x00007f36c0ca1e8d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f36c11d71dc in g_main_context_poll (priority=2147483647, n_fds=1, fds=0x7f36b80008c0, timeout=<optimized out>, context=0x22a57a0) at gmain.c:4264
#2 g_main_context_iterate (context=context@entry=0x22a57a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3964
#3 0x00007f36c11d72ec in g_main_context_iteration (context=0x22a57a0, may_block=may_block@entry=1) at gmain.c:4030
#4 0x00007f36c11d7329 in glib_worker_main (data=<optimized out>) at gmain.c:5801
#5 0x00007f36c11fd8e5 in g_thread_proxy (data=0x223c4f0) at gthread.c:778
#6 0x00007f36c0f776fa in start_thread (arg=0x7f36be884700) at pthread_create.c:333
#7 0x00007f36c0cadb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f36c216e700 (LWP 21367)):
#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007f36c0f79e82 in __GI___pthread_mutex_lock (mutex=0x2313fd0) at ../nptl/pthread_mutex_lock.c:115
#2 0x00007f36bd64cc18 in gst_multi_queue_sink_activate_mode (pad=0x231d490, parent=<optimized out>, mode=GST_PAD_MODE_PUSH, active=0) at gstmultiqueue.c:1948
#3 0x00007f36c08ef68d in activate_mode_internal (pad=pad@entry=0x231d490, parent=parent@entry=0x22ba120, mode=mode@entry=GST_PAD_MODE_PUSH, active=active@entry=0) at gstpad.c:1176
#4 0x00007f36c08efdcd in gst_pad_set_active (pad=0x231d490, active=active@entry=0) at gstpad.c:1077
#5 0x00007f36bd64be95 in gst_multi_queue_release_pad (element=0x22ba120, pad=0x231d490) at gstmultiqueue.c:803
#6 0x00007f36c1d53a69 in my_app_core_common_input_bin_remove_input_unlocked (self=self@entry=0x22b40f0, model=model@entry=0x2301780 "Media.Input.File.MyApp.Model", id=id@entry=0x22f6660 "1ec0798f-7abb-4f09-91ca-ec79683ea509") at input_bin.c:1223
#7 0x00007f36c1d53ff3 in my_app_core_common_input_bin_add_input_unlocked (self=0x22b40f0, model=0x2301780 "Media.Input.File.MyApp.Model", id=0x22f6660 "1ec0798f-7abb-4f09-91ca-ec79683ea509") at input_bin.c:839
#8 0x00007f36c1d5524b in my_app_core_common_input_bin_sync_inputs (self=<optimized out>, target_linked_inputs=target_linked_inputs@entry=0x22f7020, target_linked_inputs_length1=target_linked_inputs_length1@entry=2) at input_bin.c:663
#9 0x00007f36c1d4fec9 in my_app_core_common_player_stream_real_sync_inputs (base=<optimized out>, linked_inputs=0x22f7020, linked_inputs_length1=2) at player.c:1252
#10 0x00007f36c1d4e41e in _dbus_my_app_core_common_daemon_media_output_base_sync_linked_inputs (self=0x21b10a0, _parameters_=<optimized out>, invocation=0x7f3690001ca0) at daemon/media/output/base.c:879
#11 0x00007f36c17e89bc in call_in_idle_cb (user_data=0x7f3690001ca0) at gdbusconnection.c:4832
#12 0x00007f36c11d6e9a in g_main_dispatch (context=0x21af730) at gmain.c:3237
#13 g_main_context_dispatch (context=context@entry=0x21af730) at gmain.c:3898
#14 0x00007f36c11d7240 in g_main_context_iterate (context=0x21af730, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3969
#15 0x00007f36c11d7562 in g_main_loop_run (loop=0x21af7f0) at gmain.c:4163
#16 0x00007f36c1abb969 in my_app_common_app_template_base_start_real (self=self@entry=0x21b10a0) at app/template/base.c:682
#17 0x00007f36c1abbf79 in my_app_common_app_template_base_start (self=self@entry=0x21b10a0) at app/template/base.c:470
#18 0x0000000000401ab8 in my_app_core_media_output_stream_rk_diffusor_main (argv=0x7fffbafd3d58, argv_length1=2) at main.c:38
#19 0x00007f36c0bc7830 in __libc_start_main (main=0x401980 <main>, argc=2, argv=0x7fffbafd3d58, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbafd3d48) at ../csu/libc-start.c:291
#20 0x00000000004019b9 in _start ()
```
Version: 1.8.2https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/180streamiddemux: Reconfigure output pads when stream is changed from upstream2021-09-24T11:10:09ZBugzilla Migration Userstreamiddemux: Reconfigure output pads when stream is changed from upstream## Submitted by HoonHee Lee
**[Link to original bug (#768709)](https://bugzilla.gnome.org/show_bug.cgi?id=768709)**
## Description
Created attachment 331290
streamiddemux: Reconfigure output pads when stream is changed from upstre...## Submitted by HoonHee Lee
**[Link to original bug (#768709)](https://bugzilla.gnome.org/show_bug.cgi?id=768709)**
## Description
Created attachment 331290
streamiddemux: Reconfigure output pads when stream is changed from upstream
Dear All.
When stream is changed from upstream, it is better to remove output pads
for deactivated streams and to keep it for activated streams.
Please review my patch and feedback me.
**Patch 331290**, "streamiddemux: Reconfigure output pads when stream is changed from upstream":
[0001-streamiddemux-reconfigure-output-pads-when-stream-is.patch](/uploads/eff402c1ca7a62e99099dde0138c4b3a/0001-streamiddemux-reconfigure-output-pads-when-stream-is.patch)
Version: 1.9.1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/179bin: Child elements can miss state changes happening during async state trans...2021-09-24T11:10:10ZBugzilla Migration Userbin: Child elements can miss state changes happening during async state transitions## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#768522)](https://bugzilla.gnome.org/show_bug.cgi?id=768522)**
## Description
`gst_element_set_state_func()` currently only updates the target state of the element i...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#768522)](https://bugzilla.gnome.org/show_bug.cgi?id=768522)**
## Description
`gst_element_set_state_func()` currently only updates the target state of the element itself, if there is a pending state and it's either smaller/equal than the new state, or the next state is the same as the new state.
These basically mean that currently an async state transition is happening while the new state is set, and we go to the same or a higher state.
Now consider the following scenario:
1) bin is in `PLAYING` and all child elements know that
2) app sends flushing seek, state is lost
3) bin records that, goes current=next=pending=`PAUSED`, target still `PLAYING` and no child elements get notified
4) app sets state to `PAUSED`
5) `gst_element_set_state()` only updates the target state of the bin but not the child's (last state change they saw is `PAUSED->PLAYING` from before)
6) at some point the async state change is finished
7) bin is happy because target=current=pending and all good
If you carefully followed this, the child elements saw as very last state change `PAUSED->PLAYING`. That is, they think they are actually `PLAYING` it this point.
For most elements this doesn't matter as `PLAYING` and `PAUSED` are the same for them. For `rtspsrc` it has a very big impact though: the pipeline (and sinks!) are `PAUSED` after all this, but `rtspsrc` told the server that we're `PLAYING` after the seek (because that's all it knows) and the server sends us data until all queues are full and memory is exhausted or other bads things happen.
### See also
* #150https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/178Hang while changing to pause mode in id3demux2021-09-24T11:54:09ZBugzilla Migration UserHang while changing to pause mode in id3demux## Submitted by Jyoti tripathi
**[Link to original bug (#768179)](https://bugzilla.gnome.org/show_bug.cgi?id=768179)**
## Description
Created attachment 330570
ID3 hang on changing state to pause
Hang is seen while changing s...## Submitted by Jyoti tripathi
**[Link to original bug (#768179)](https://bugzilla.gnome.org/show_bug.cgi?id=768179)**
## Description
Created attachment 330570
ID3 hang on changing state to pause
Hang is seen while changing state to pause on multiple playbacks of few id3v2 tag files.
On analysing this issue I found that while changing typefind from push to pull mode, it performs a gst_pad_pause_task where it is trying to take STREAM_LOCK and hangs there.
Logs attached.
This issue cannot be seen if id3demux is in push mode.
**Attachment 330570**, "ID3 hang on changing state to pause":
[id3_hang.tar.bz2](/uploads/a41a8e30b0aa250a7916791190842c5d/id3_hang.tar.bz2)
Version: 1.4.1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/176QA: run tests using leaks tracer2023-02-11T16:12:37ZBugzilla Migration UserQA: run tests using leaks tracer## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#767856)](https://bugzilla.gnome.org/show_bug.cgi?id=767856)**
## Description
Now that the leaks tracer has been merged ([bug 765052](https://bugzilla.gnome.or...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#767856)](https://bugzilla.gnome.org/show_bug.cgi?id=767856)**
## Description
Now that the leaks tracer has been merged ([bug 765052](https://bugzilla.gnome.org/show_bug.cgi?id=765052)) we could consider adding a Jenkins job on https://ci.gstreamer.net/ running tests with the leaks tracer to prevent memory leaks regressions.
To do so we first should make sure that all tests are currently not reported as leaking. I'll mark those as blockers.
### Depends on
* [Bug 766561](https://bugzilla.gnome.org/show_bug.cgi?id=766561)
* [Bug 766663](https://bugzilla.gnome.org/show_bug.cgi?id=766663)
* [Bug 767159](https://bugzilla.gnome.org/show_bug.cgi?id=767159)
* [Bug 768577](https://bugzilla.gnome.org/show_bug.cgi?id=768577)
* [Bug 768762](https://bugzilla.gnome.org/show_bug.cgi?id=768762)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/175Add helper to create src/sink ghost pad on a GstBin2021-09-24T11:10:12ZBugzilla Migration UserAdd helper to create src/sink ghost pad on a GstBin## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767451)](https://bugzilla.gnome.org/show_bug.cgi?id=767451)**
## Description
gst_parse_bin_from_description() already have code to create a src/sink ghost pad fo...## Submitted by Xavier Claessens `@xclaesse`
**[Link to original bug (#767451)](https://bugzilla.gnome.org/show_bug.cgi?id=767451)**
## Description
gst_parse_bin_from_description() already have code to create a src/sink ghost pad for the simple case where there is only one unlinked src/sink. I think it can be useful to expose that part as its own method.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/174Add missing filename type annotations2021-09-24T11:10:13ZBugzilla Migration UserAdd missing filename type annotations## Submitted by Christoph Reiter (lazka)
**[Link to original bug (#767268)](https://bugzilla.gnome.org/show_bug.cgi?id=767268)**
## Description
Created attachment 329156
Add missing filename type annotations
I'm currently wor...## Submitted by Christoph Reiter (lazka)
**[Link to original bug (#767268)](https://bugzilla.gnome.org/show_bug.cgi?id=767268)**
## Description
Created attachment 329156
Add missing filename type annotations
I'm currently working on improving filename handling support in PyGObject which depends on filenames being annotated as such. See [bug 746564](https://bugzilla.gnome.org/show_bug.cgi?id=746564)
~~**Patch 329156**~~, "Add missing filename type annotations":
[0001-Add-missing-filename-type-annotations.patch](/uploads/837bf3d872df01aeabaf8d509988a59b/0001-Add-missing-filename-type-annotations.patch)
Version: 1.6.0
### Depends on
* [Bug 767266](https://bugzilla.gnome.org/show_bug.cgi?id=767266)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/173build failure in flatpak apps for gstreamer2021-09-24T11:46:53ZBugzilla Migration Userbuild failure in flatpak apps for gstreamer## Submitted by Matthias Clasen `@mclasen`
**[Link to original bug (#767255)](https://bugzilla.gnome.org/show_bug.cgi?id=767255)**
## Description
Some apps fail to build in the flatpak builder with this error:
In file included ...## Submitted by Matthias Clasen `@mclasen`
**[Link to original bug (#767255)](https://bugzilla.gnome.org/show_bug.cgi?id=767255)**
## Description
Some apps fail to build in the flatpak builder with this error:
In file included from /usr/include/gstreamer-1.0/gst/gstpad.h:69:0,
from /usr/include/gstreamer-1.0/gst/gstelement.h:57,
from /usr/include/gstreamer-1.0/gst/gstbin.h:27,
from /usr/include/gstreamer-1.0/gst/gst.h:35,
from /usr/include/gstreamer-1.0/gst/pbutils/encoding-profile.h:24,
from /usr/include/gstreamer-1.0/gst/pbutils/encoding-target.h:24,
from rb-gst-media-types.c:32:
/usr/include/gstreamer-1.0/gst/gstbuffer.h: In function ‘gst_buffer_ref’:
/usr/include/gstreamer-1.0/gst/gstbuffer.h:353:10: error: cast increases required alignment of target type [-Werror=cast-align]
See e.g.
https://gnome7.codethink.co.uk//logs/build-2016-06-04-200001/build-org.gnome.Rhythmbox3.txthttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/172identity: add property keep every N-th buffer2021-09-24T11:10:14ZBugzilla Migration Useridentity: add property keep every N-th buffer## Submitted by Gregoire
**[Link to original bug (#766537)](https://bugzilla.gnome.org/show_bug.cgi?id=766537)**
## Description
Created attachment 328029
Patch identity drop every N frame
Here is a patch against head to add a...## Submitted by Gregoire
**[Link to original bug (#766537)](https://bugzilla.gnome.org/show_bug.cgi?id=766537)**
## Description
Created attachment 328029
Patch identity drop every N frame
Here is a patch against head to add a property to the identity plugin in order to drop every N frames.
It seems to be a no-risk patch and add an handy feature if one wants to drop every other frame for instance.
~~**Patch 328029**~~, "Patch identity drop every N frame":
[identity-drop.patch](/uploads/f717964df0e30d8a5018f24cc09b268c/identity-drop.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/171gst-launch: Does not support non-UTF8 shell2021-09-24T11:10:14ZBugzilla Migration Usergst-launch: Does not support non-UTF8 shell## Submitted by Martin Proksa
**[Link to original bug (#766214)](https://bugzilla.gnome.org/show_bug.cgi?id=766214)**
## Description
Writing stream to file with local characters in filename fails on windows to open file with that na...## Submitted by Martin Proksa
**[Link to original bug (#766214)](https://bugzilla.gnome.org/show_bug.cgi?id=766214)**
## Description
Writing stream to file with local characters in filename fails on windows to open file with that name. Same filename works fine on linux.
example of problem:
gst-launch-1.0 videotestsrc ! filesink location=tést.raw
fails with
WARNING: erroneous pipeline: no element "filesink"
works fine:
gst-launch-1.0 videotestsrc ! filesink location=test.raw
Problem is in function gst_fopen in file gstfilesink.c, this function expect its argument filename to be in UTF8, but in fact filename is in ASCII and character é is represented as single BYTE 0xE9.
Converting filename to UTF8 before calling g_utf8_to_utf16 solves the problem.
gchar *ufilename = g_locale_to_utf8(filename, -1, NULL, NULL, NULL);
wchar_t *wfilename = g_utf8_to_utf16 (ufilename, -1, NULL, NULL, NULL);
Version: 1.6.3https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/170baseparse: use gst_util_uint64_scale to avoid overflow.2021-09-24T11:10:15ZBugzilla Migration Userbaseparse: use gst_util_uint64_scale to avoid overflow.## Submitted by kevin
**[Link to original bug (#765660)](https://bugzilla.gnome.org/show_bug.cgi?id=765660)**
## Description
use gst_util_uint64_scale_int will overflow as parse->priv->avg_bitrate
is unsigned int.## Submitted by kevin
**[Link to original bug (#765660)](https://bugzilla.gnome.org/show_bug.cgi?id=765660)**
## Description
use gst_util_uint64_scale_int will overflow as parse->priv->avg_bitrate
is unsigned int.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/169baseparse: Timestamp tracking has accumulating rounding errors when using fra...2021-09-24T11:10:16ZBugzilla Migration Userbaseparse: Timestamp tracking has accumulating rounding errors when using frame rate## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765093)](https://bugzilla.gnome.org/show_bug.cgi?id=765093)**
## Description
Audio parsers often just use the frame rate based timestamp tracking, i.e. gst_base_pars...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#765093)](https://bugzilla.gnome.org/show_bug.cgi?id=765093)**
## Description
Audio parsers often just use the frame rate based timestamp tracking, i.e. gst_base_parse_set_frame_rate(). The base class then simply stores fps_d/fps_n and uses this for the buffer durations. And then uses the buffer durations to interpolate the next buffer timestamps.
So if upstream only provides timestamps every now and then, or only one in the very beginning, or none at all (filesrc ! mpegaudioparse ! ...), the rounding errors caused by the division will accumulate until the point when things start to fail.
Version: 1.8.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/168pad: Offset handling inconsistencies2024-03-28T17:53:31ZBugzilla Migration Userpad: Offset handling inconsistencies## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#765049)](https://bugzilla.gnome.org/show_bug.cgi?id=765049)**
## Description
14:24 `< slomo_>` after probes, always check if sticky events have changed (when handli...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#765049)](https://bugzilla.gnome.org/show_bug.cgi?id=765049)**
## Description
14:24 `< slomo_>` after probes, always check if sticky events have changed (when handling serialized events/buffers/buffer lists)
14:24 `< slomo_>` after probes, always check if pad offsets have changed (on sinkpads) and apply them if so
Current situation: Apply buffer pad probe on a sinkpad, change the pad offset in the probe => this has no effect.
### See also
* [Bug 795330](https://bugzilla.gnome.org/show_bug.cgi?id=795330)
* [Bug 796898](https://bugzilla.gnome.org/show_bug.cgi?id=796898)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/166Add GST_EVENT_LATENCY_CHANGED2021-09-24T11:10:18ZBugzilla Migration UserAdd GST_EVENT_LATENCY_CHANGED## Submitted by Håvard Graff (hgr)
**[Link to original bug (#764396)](https://bugzilla.gnome.org/show_bug.cgi?id=764396)**
## Description
Created attachment 325055
suggested implementation
clipped from #gstreamer:
Lets s...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#764396)](https://bugzilla.gnome.org/show_bug.cgi?id=764396)**
## Description
Created attachment 325055
suggested implementation
clipped from #gstreamer:
Lets start with some history:
Back in 2008 we needed a dynamic jitterbuffer.
After discussing back and forth with wtay, we came to the conclusion that
the proper way to do this was to:
1. Change the latency property on the jitterbuffer
2. The jb would then post a latency message on the bus
3. in the bus-handler (in the application), this msg would be picked up,
and wtay added a new method gst_bin_recalculate_latency that the
application could emit on the main pipeline to have the whole pipeline
query its latency again (each sink sending upstream latency queries etc).
Now this has worked ok for us ever since, in Pexip we terminate the
latency in the mixers, not in the sinks, but other then that it works
exactly the same way as before. But lately we have discovered that this
has some horrific side-effects, in that with many participants connecting,
and latency changing often, we in fact, using this method,
are recalculating EVERYONES latency when we only want to reconfigure that
of a single participant. or more specifically the jitterbuffers with the
same cname belonging to that participant.
Now, I know the idea of "groups of sinks" have been mentioned before,
but we are at a stage now where we really need to be able to re-calculate
latency only for the affected sinks / mixers, and this is where I have a
concrete suggestions: a downstream "latency-changed" event that in turn
can trigger an upstream latency query, either from a sink or from a mixer.
If this was emitted from the jitterbuffer in the same place the
latency-message is emitted, it would mean all affected downstream
mixers/sinks would know "directly" that latency had changed somewhere
upstream from them, and could make decisions based on this.
For us it would mean re-sending latency-queries upstream from the mixers
that received this event, and then using this new latency in the mix.
For this sink-case, it would be the same way, only that with using
this "mode" the sinks would get their new latency "independent" of the
pipeline latency, and the "grouping" would then happen from whichever
sources decided to send this event.
So in the case of rtpbin, you are already changing latency for all the
jitterbuffers with the same cname as one "group", and hence all of them
would also be sending the latency event, ensuring lipsync at the
mixers/sinks.
**Patch 325055**, "suggested implementation":
[latency-changed-event.patch](/uploads/a930c05ad0605378d16153acfb7365ec/latency-changed-event.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/165[2.0] GstUriHandler interface issue in vala2022-04-19T06:37:11ZBugzilla Migration User[2.0] GstUriHandler interface issue in vala## Submitted by Yannick Inizan
**[Link to original bug (#764345)](https://bugzilla.gnome.org/show_bug.cgi?id=764345)**
## Description
some interfaces in GStreamer and other projects are ugly, ex. with URIHandler :
struct _GstU...## Submitted by Yannick Inizan
**[Link to original bug (#764345)](https://bugzilla.gnome.org/show_bug.cgi?id=764345)**
## Description
some interfaces in GStreamer and other projects are ugly, ex. with URIHandler :
struct _GstURIHandlerInterface {
GTypeInterface parent;
/* vtable */
/*`< public >`*/
/* querying capabilities */
GstURIType (* get_type) (GType type);
const gchar * const * (* get_protocols) (GType type);
/* using the interface */
gchar * (* get_uri) (GstURIHandler * handler);
gboolean (* set_uri) (GstURIHandler * handler,
const gchar * uri,
GError ** error);
};
where some members don't have 'GstURIHandler * handler' parameter. with these interfaces, languages like Vala can't implement it because the language implement interface with this parameter by defaulthttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/164structure: Large integer gets detected as double instead of int642021-09-24T11:10:20ZBugzilla Migration Userstructure: Large integer gets detected as double instead of int64## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#764288)](https://bugzilla.gnome.org/show_bug.cgi?id=764288)**
## Description
Created attachment 324893
Test case
Running the attached test case gives this ou...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#764288)](https://bugzilla.gnome.org/show_bug.cgi?id=764288)**
## Description
Created attachment 324893
Test case
Running the attached test case gives this output:
Serialized structure measurement, field1=(int)1000000000;
Structure didn't contain an int64 field1
Serialized structure measurement, field1=(double)10000000000;
Structure didn't contain an int64 field1
Why double? There's no decimal point anywhere, shouldn't it be detected as an int64 instead?
PS: I know it's leaky, it's just a small demo.
PS2: Why is there no GST_STRUCTURE_FORMAT ? Now I'm leaking the strings as well as the structures :(
**Attachment 324893**, "Test case":
[serializeme.c](/uploads/bacdbecb1cbec90725402844f731ed05/serializeme.c)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/163GstPreset: fix enum properties2022-11-10T09:20:46ZBugzilla Migration UserGstPreset: fix enum properties## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764240)](https://bugzilla.gnome.org/show_bug.cgi?id=764240)**
## Description
+++ This bug was initially created as a clone of [Bug 763814](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764240)](https://bugzilla.gnome.org/show_bug.cgi?id=764240)**
## Description
+++ This bug was initially created as a clone of [Bug 763814](https://bugzilla.gnome.org/show_bug.cgi?id=763814) +++
GstPreset has the same problem. Resulting in things like "frame-packing=Automatic (use incoming video information)" (this is from x264enc) in the generated preset files. Changing that one is more tricky as we need to keep backwards compatibility...https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/162preset: Complains about not being able to serialize NULL string properties2023-02-03T20:53:50ZBugzilla Migration Userpreset: Complains about not being able to serialize NULL string properties## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764019)](https://bugzilla.gnome.org/show_bug.cgi?id=764019)**
## Description
It checks for gst_value_serialize() to return non-NULL to decide if a property was succe...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#764019)](https://bugzilla.gnome.org/show_bug.cgi?id=764019)**
## Description
It checks for gst_value_serialize() to return non-NULL to decide if a property was successfully serialized or not. a NULL string is serialized as NULL though, which is probably correct.
Should probably add some special cases here to not fill the logs with useless things.
Another thing that should be added as a special case is the "parent" property. We can't realistically serialize that one anyway.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/160funnel: add 'forward-sticky-events-mode' property2021-09-24T11:10:23ZBugzilla Migration Userfunnel: add 'forward-sticky-events-mode' property## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#763338)](https://bugzilla.gnome.org/show_bug.cgi?id=763338)**
## Description
Created attachment 323424
funnel: add 'forward-sticky-events-mode' property
...## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#763338)](https://bugzilla.gnome.org/show_bug.cgi?id=763338)**
## Description
Created attachment 323424
funnel: add 'forward-sticky-events-mode' property
Expands the idea of this issue: https://bugzilla.gnome.org/show_bug.cgi?id=749315
~~**Patch 323424**~~, "funnel: add 'forward-sticky-events-mode' property":
[0001-funnel-add-forward-sticky-events-mode-property.patch](/uploads/75f59f8f717eec9b1fc473310104d6ea/0001-funnel-add-forward-sticky-events-mode-property.patch)
Version: 1.7.90