gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2021-09-24T14:39:14Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1557geometrictransform:perspective2021-09-24T14:39:14ZLuke Kgeometrictransform:perspectiveI seem to be unable to set the "matrix" array property using gst-launch. It expects a GValueArray of 9 gdouble.
It should be changed to be a GstValueArray to work from gst-launch I am told.I seem to be unable to set the "matrix" array property using gst-launch. It expects a GValueArray of 9 gdouble.
It should be changed to be a GstValueArray to work from gst-launch I am told.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1561tsdemux: Hang when ts packets including opus are lost2021-09-24T14:39:14Zsmsajjaditsdemux: Hang when ts packets including opus are lostHi
In a chain coded in C, a TS stream including MPEG4 video +Opus audio is transmitted on UDP on a local ethernet. After some losses (which seem to be on TS packets including opus encoded data) the output video and audio hang and the fo...Hi
In a chain coded in C, a TS stream including MPEG4 video +Opus audio is transmitted on UDP on a local ethernet. After some losses (which seem to be on TS packets including opus encoded data) the output video and audio hang and the following message shows up.
`ERROR tsdemux tsdemux.c:2833:parse_opus_access_unit: Failed to parse Opus access unit`
After some debugging, I know that what causes the error is this line of code:
` if (gst_byte_reader_get_remaining (&reader) < packet_size)
goto error;`
The chain is code in C, but it resembles this commandline chain:
`udpsrc port=5000 ! application/x-rtp,media=video,encoding-name=mp2t,clock-rate=90000 ! rtpjitterbuffer latency=1000 ! rtpmp2tdepay ! tsdemux name=mux ! queue ! h264parse ! vaapih264dec ! videoconvert ! autovideosink mux. ! queue ! opusdec ! alsasink`
About versioning:
gst-inspect-1.0 version 1.17.0
GStreamer 1.17.0 (GIT)
Unknown package origin
But I replaced the relevant codes in tsdemux and around to match the master on github, and nothing changed.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1562Memory leak in the `gaussianblur` visualization2021-09-24T14:39:14ZPriit LaesMemory leak in the `gaussianblur` visualizationI noticed following memory leak when running an example from https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html?gi-language=python#changing-elements-in-a-pipeline
```
==531204== 4...I noticed following memory leak when running an example from https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html?gi-language=python#changing-elements-in-a-pipeline
```
==531204== 4,915,200 bytes in 4 blocks are definitely lost in loss record 2,983 of 2,983
==531204== at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==531204== by 0x4A81E98: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6)
==531204== by 0x4855725: gst_gaussianblur_set_info (gstgaussblur.c:173)
==531204== by 0x6508FCE: ??? (in /usr/lib/x86_64-linux-gnu/libgstvideo-1.0.so.0.1602.0)
==531204== by 0x648B1EB: ??? (in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0.1602.0)
==531204== by 0x648CF29: ??? (in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0.1602.0)
==531204== by 0x48FEBB3: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1602.0)
==531204== by 0x48FF163: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1602.0)
==531204== by 0x48FF5D9: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1602.0)
==531204== by 0x48FD01F: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1602.0)
==531204== by 0x4907D70: gst_pad_push_event (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1602.0)
==531204== by 0x648BAA7: ??? (in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0.1602.0)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1564Removing webrtcbin during negotiation permanently messes up state: 'no negoti...2022-02-12T21:29:14ZAli AbbasRemoving webrtcbin during negotiation permanently messes up state: 'no negotiation possible until caps have been received on all sink pads'I have a fairly basic gstreamer pipeline running on a Nvidia Jetson Nano, and have code to dynamically add/remove webrtcbin elements, but if one of those elements is removed during the negotiation process (i.e the peer closes their brows...I have a fairly basic gstreamer pipeline running on a Nvidia Jetson Nano, and have code to dynamically add/remove webrtcbin elements, but if one of those elements is removed during the negotiation process (i.e the peer closes their browser tab/reloads), and any subsequent additions of webrtcbins never fires the 'on-negotiation-needed' event, which I looked at logs and it turned out to be: `no negotiation possible until caps have been received on all sink pads`
To be clear, this never happens, unless I close the session while it's negotiating, and after that it's broken unless I restart the pipelinehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1570webrtcbin: Not in the correct state for setting local rollback description2021-09-24T14:39:15ZJohannes Nauwebrtcbin: Not in the correct state for setting local rollback descriptionHi everyone, I couldn't find a related issue or any information on the topic so far.
I have the situation that I am in the have-local-offer state after creating an offer. After that, I get an offer from the remote peer. Normally you wou...Hi everyone, I couldn't find a related issue or any information on the topic so far.
I have the situation that I am in the have-local-offer state after creating an offer. After that, I get an offer from the remote peer. Normally you would now rollback and set the remote offer (perfect negotiation). However, trying to do so will raise:
`webrtcbin gstwebrtcbin.c:4320:_set_description_task:<webrtcbin0> Not in the correct state (have-local-offer) for setting local rollback description`
and subsequently:
`webrtcbin gstwebrtcbin.c:4320:_set_description_task:<webrtcbin0> Not in the correct state (have-local-offer) for setting remote offer description`
I narrowed the error down to [_check_valid_state_for_sdp_change](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/webrtc/webrtcsdp.c#L47). As it seems the check is not considering any rollback. Is this an error, or have I overlooked something?
I experienced the error on 1.18.1 on a windows machine, but looking at the source, I don't expect to be relevant here.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1571decklink: unable to use sinks together with playbin if source is an HTTP stream2021-09-24T14:39:15ZFrançois Goudaldecklink: unable to use sinks together with playbin if source is an HTTP streamHello,
I'm trying to use gstreamer in order to output a video stream coming from an HTTP live source through a DeckLink card with SDI outputs.
It works fine if I play a TS file from the local filesystem:
```
gst-play-1.0 --videosink 'dec...Hello,
I'm trying to use gstreamer in order to output a video stream coming from an HTTP live source through a DeckLink card with SDI outputs.
It works fine if I play a TS file from the local filesystem:
```
gst-play-1.0 --videosink 'decklinkvideosink device-number=0 mode=1080p30' --audiosink 'decklinkaudiosink device-number=0' test.ts
```
But it fails with an abort if I play the same TS stream over HTTP:
```
gst-play-1.0 --videosink 'decklinkvideosink device-number=0 mode=1080p30' --audiosink 'decklinkaudiosink device-number=0' http://example.org/test.ts
Press 'k' to see a list of keyboard shortcuts.
Now playing http://example.org/test.ts
gst-play-1.0: /build/libproxy-segITs/libproxy-0.4.15/libmodman/module_manager.hpp:58: std::vector<T*> libmodman::module_manager::get_extensions() const [with T = libproxy::network_extension]: Assertion `obj != NULL' failed.
Aborted
```
I have first tried with the gstreamer that ships with Debian 10 (1.14.4), but I then also built the latest 1.18.4 from source and I get the same behavior.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1579audiobuffersplit: Timestamp regressions2021-09-24T14:39:17ZJan Alexander Steffensaudiobuffersplit: Timestamp regressionsAfter adding `audiobuffersplit` in gapless mode to a pipeline, we've been seeing timestamp regressions (e.g. downstream `flvmux` complaining about backwards dts) when switching this pipeline between sources.
I've noticed that `drop_samp...After adding `audiobuffersplit` in gapless mode to a pipeline, we've been seeing timestamp regressions (e.g. downstream `flvmux` complaining about backwards dts) when switching this pipeline between sources.
I've noticed that `drop_samples` is calculated on [gstaudiobuffersplit.c:561](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/audiobuffersplit/gstaudiobuffersplit.c#L561) but then just used for a message and not saved to `self->drop_samples` like on [gstaudiobuffersplit.c:618](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/audiobuffersplit/gstaudiobuffersplit.c#L618).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1580audiobuffersplit: Downstream segment is not updated2021-09-24T14:39:17ZJan Alexander Steffensaudiobuffersplit: Downstream segment is not updatedWe've been using `audiobuffersplit` in gapless mode in an encoding pipeline. When the source is "looping" (repeating the same closed segment with adjusted base), `audiobuffersplit` seems to attempt to continue the first downstream segmen...We've been using `audiobuffersplit` in gapless mode in an encoding pipeline. When the source is "looping" (repeating the same closed segment with adjusted base), `audiobuffersplit` seems to attempt to continue the first downstream segment past its stop point instead of updating the downstream segment with a new stop, or ensuring that the downstream segment is open-ended.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1581wpesrc: pipeline shutdown deadlocks when WPE WebKit instance crashes2021-09-24T14:39:17ZNazar Mokrynskyiwpesrc: pipeline shutdown deadlocks when WPE WebKit instance crashesI think I have hit https://github.com/Igalia/WPEBackend-fdo/issues/145:
```
Backtrace:
/lib/x86_64-linux-gnu/libwayland-client.so.0(wl_proxy_marshal_constructor+0x8a)[0x7f5c8bb8d41a]
/lib/x86_64-linux-gnu/libWPEBackend-fdo-1.0.so.1(+0xbb...I think I have hit https://github.com/Igalia/WPEBackend-fdo/issues/145:
```
Backtrace:
/lib/x86_64-linux-gnu/libwayland-client.so.0(wl_proxy_marshal_constructor+0x8a)[0x7f5c8bb8d41a]
/lib/x86_64-linux-gnu/libWPEBackend-fdo-1.0.so.1(+0xbb0d)[0x7f5c8e198b0d]
/lib/x86_64-linux-gnu/libWPEBackend-fdo-1.0.so.1(+0x7c54)[0x7f5c8e194c54]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0xcc22d2)[0x7f5c90c672d2]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0x9f8ca5)[0x7f5c9099dca5]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0x9f6dc7)[0x7f5c9099bdc7]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0x3cfe9b8)[0x7f5c93ca39b8]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0x3d6b36d)[0x7f5c93d1036d]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0x3d6bd53)[0x7f5c93d10d53]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x15f)[0x7f5c8fa0352f]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x538d8)[0x7f5c8fa038d8]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x83)[0x7f5c8fa03bf3]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0x3d6beb0)[0x7f5c93d10eb0]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0x3d004fd)[0x7f5c93ca54fd]
/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4(+0x3d6de3d)[0x7f5c93d12e3d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9590)[0x7f5c8f13f590]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f5c8fed4223]
```
After which setting pipeline to `Null` deadlocks with these backtraces:
<details>
```
(gdb) info threads
Id Target Id Frame
5 LWP 4143700 "wpesrc_3982913_" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
6 LWP 4143701 "BMScavenger" 0x00007f8201a0ac06 in pthread_cond_wait@@GLIBC_2.3.2 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
7 LWP 4143703 "HashSaltStorage" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
8 LWP 4143704 "ebsiteDataStore" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
9 LWP 4143706 "gmain" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
10 LWP 4143707 "PressureMonitor" 0x00007f8201a0b07f in pthread_cond_timedwait@@GLIBC_2.3.2 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
11 LWP 4143709 "ReceiveQueue" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
12 LWP 4143769 "GstSystemClock" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
13 LWP 4143798 "dconf worker" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
14 LWP 4147009 "actix-rt:worker" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
15 LWP 4147011 "pool-streaming-" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
16 LWP 4147016 "appsrc_3676419_" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
17 LWP 4147020 "wpesrc_3676419_" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
18 LWP 4147027 "nicesrc2:src" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
19 LWP 4147028 "queue4:src" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
20 LWP 4147029 "queue5:src" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
21 LWP 4147030 "rtprtxsend2:src" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
22 LWP 4147031 "dtlsenc2:src" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
23 LWP 4147038 "task84" 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
24 LWP 4147955 "timer" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
25 LWP 4147956 "rtpjitterbuffer" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
26 LWP 4147960 "queue_3676419_d" 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
27 LWP 4148086 "queue_3676419_d" 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
28 LWP 4148087 "queue_3676419_d" 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
29 LWP 4148088 "queue_3676419_d" 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
30 LWP 4148089 "queue_3676419_d" 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
31 LWP 4148090 "queue_3676419_d" 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
32 LWP 4148091 "queue_3676419_d" 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
33 LWP 4148092 "queue_3676419_d" 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
34 LWP 4148554 "pool-streaming-" 0x00007f8201a0e8f0 in __lll_lock_wait () from target:/lib/x86_64-linux-gnu/libpthread.so.0
35 LWP 4148837 "pool-streaming-" 0x00007f8201a0e8f0 in __lll_lock_wait () from target:/lib/x86_64-linux-gnu/libpthread.so.0
(gdb) thread apply all bt
Thread 35 (LWP 4148837):
#0 0x00007f8201a0e8f0 in __lll_lock_wait () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a06991 in pthread_mutex_lock () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8201d2d20a in gst_element_set_state_func (element=0x7f81f40163f0, state=GST_STATE_NULL) at ../gst/gstelement.c:2925
#3 0x000055571d7e56d1 in <O as gstreamer::element::ElementExtManual>::call_async::trampoline ()
#4 0x00007f8201d27e92 in gst_element_call_async_func (data=0x55571fa17680, user_data=<optimized out>) at ../gst/gstelement.c:3784
#5 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#8 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 34 (LWP 4148554):
#0 0x00007f8201a0e8f0 in __lll_lock_wait () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a06991 in pthread_mutex_lock () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f8201d5450d in gst_pad_stop_task (pad=0x7f802c0539f0) at ../gst/gstpad.c:6424
#3 0x00007f8201e51ebd in gst_base_src_stop (basesrc=basesrc@entry=0x7f81fc067c60) at ../libs/gst/base/gstbasesrc.c:3740
#4 0x00007f8201e59c90 in gst_base_src_activate_push (pad=0x7f802c0539f0, active=<optimized out>, parent=0x7f81fc067c60) at ../libs/gst/base/gstbasesrc.c:3899
#5 gst_base_src_activate_mode (pad=0x7f802c0539f0, parent=0x7f81fc067c60, mode=<optimized out>, active=<optimized out>) at ../libs/gst/base/gstbasesrc.c:3971
#6 0x00007f8201d4e04e in activate_mode_internal (pad=pad@entry=0x7f802c0539f0, parent=parent@entry=0x7f81fc067c60, mode=mode@entry=GST_PAD_MODE_PUSH, active=active@entry=0) at ../gst/gstpad.c:1216
#7 0x00007f8201d4e838 in gst_pad_set_active (pad=pad@entry=0x7f802c0539f0, active=0) at ../gst/gstpad.c:1114
#8 0x00007f8201d27ca5 in activate_pads (vpad=<optimized out>, ret=0x7f7f78be32c0, active=0x7f7f78be331c) at ../gst/gstelement.c:3134
#9 0x00007f8201d3d9cb in gst_iterator_fold (it=it@entry=0x7f7fa80078e0, func=func@entry=0x7f8201d27c80 <activate_pads>, ret=ret@entry=0x7f7f78be32c0, user_data=user_data@entry=0x7f7f78be331c) at ../gst/gstiterator.c:617
#10 0x00007f8201d28386 in iterator_activate_fold_with_resync (iter=iter@entry=0x7f7fa80078e0, user_data=user_data@entry=0x7f7f78be331c, func=0x7f8201d27c80 <activate_pads>) at ../gst/gstelement.c:3158
#11 0x00007f8201d2a72b in gst_element_pads_activate (element=element@entry=0x7f81fc067c60, active=<optimized out>, active@entry=0) at ../gst/gstelement.c:3194
#12 0x00007f8201d2a9f1 in gst_element_change_state_func (element=0x7f81fc067c60, transition=<optimized out>) at ../gst/gstelement.c:3268
#13 0x00007f8201e576d7 in gst_base_src_change_state (element=0x7f81fc067c60, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../libs/gst/base/gstbasesrc.c:4008
#14 0x00007f81f34ddddf in gst_gl_base_src_change_state (element=0x7f81fc067c60, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst-libs/gst/gl/gstglbasesrc.c:708
#15 0x00007f8201d2cd02 in gst_element_change_state (element=element@entry=0x7f81fc067c60, transition=transition@entry=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstelement.c:3046
#16 0x00007f8201d2d44d in gst_element_set_state_func (element=0x7f81fc067c60, state=GST_STATE_READY) at ../gst/gstelement.c:3000
#17 0x00007f8201d094bc in gst_bin_element_set_state (next=GST_STATE_READY, current=GST_STATE_PAUSED, start_time=0, base_time=4751009624162577, element=0x7f81fc067c60, bin=0x7f81f40163f0) at ../gst/gstbin.c:2609
#18 gst_bin_change_state_func (element=0x7f81f40163f0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstbin.c:2951
#19 0x00007f8201d569ce in gst_pipeline_change_state (element=0x7f81f40163f0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstpipeline.c:529
#20 0x00007f8201d2cd02 in gst_element_change_state (element=element@entry=0x7f81f40163f0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../gst/gstelement.c:3046
#21 0x00007f8201d2d792 in gst_element_continue_state (element=element@entry=0x7f81f40163f0, ret=ret@entry=GST_STATE_CHANGE_NO_PREROLL) at ../gst/gstelement.c:2754
#22 0x00007f8201d2ce05 in gst_element_change_state (element=element@entry=0x7f81f40163f0, transition=transition@entry=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at ../gst/gstelement.c:3092
--Type <RET> for more, q to quit, c to continue without paging--c
#23 0x00007f8201d2d44d in gst_element_set_state_func (element=0x7f81f40163f0, state=GST_STATE_NULL) at ../gst/gstelement.c:3000
#24 0x000055571d7e5b44 in <O as gstreamer::element::ElementExtManual>::call_async::trampoline ()
#25 0x00007f8201d27e92 in gst_element_call_async_func (data=0x55571f9befb0, user_data=<optimized out>) at ../gst/gstelement.c:3784
#26 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#29 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 33 (LWP 4148092):
#0 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a0dc58 in __new_sem_wait_slow.constprop.0 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f80cc10eeb0 in ?? () from target:/lib/x86_64-linux-gnu/libvpx.so.6
#3 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 32 (LWP 4148091):
#0 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a0dc58 in __new_sem_wait_slow.constprop.0 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f80cc10eeb0 in ?? () from target:/lib/x86_64-linux-gnu/libvpx.so.6
#3 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 31 (LWP 4148090):
#0 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a0dc58 in __new_sem_wait_slow.constprop.0 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f80cc10eeb0 in ?? () from target:/lib/x86_64-linux-gnu/libvpx.so.6
#3 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 30 (LWP 4148089):
#0 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a0dc58 in __new_sem_wait_slow.constprop.0 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f80cc10eeb0 in ?? () from target:/lib/x86_64-linux-gnu/libvpx.so.6
#3 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 29 (LWP 4148088):
#0 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a0dc58 in __new_sem_wait_slow.constprop.0 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f80cc10eeb0 in ?? () from target:/lib/x86_64-linux-gnu/libvpx.so.6
#3 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 28 (LWP 4148087):
#0 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a0dc58 in __new_sem_wait_slow.constprop.0 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f80cc10eeb0 in ?? () from target:/lib/x86_64-linux-gnu/libvpx.so.6
#3 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 27 (LWP 4148086):
#0 0x00007f8201a0db54 in do_futex_wait.constprop () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f8201a0dc58 in __new_sem_wait_slow.constprop.0 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f80cc10eeb0 in ?? () from target:/lib/x86_64-linux-gnu/libvpx.so.6
#3 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#4 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 26 (LWP 4147960):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f82002b99ad in gst_queue_loop (pad=<optimized out>) at ../plugins/elements/gstqueue.c:1529
#3 0x00007f8201d81f17 in gst_task_func (task=0x7f7ff400f5f0) at ../gst/gsttask.c:384
#4 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 25 (LWP 4147956):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8200409a43 in gst_rtp_jitter_buffer_loop (jitterbuffer=0x7f8018395e70) at ../gst/rtpmanager/gstrtpjitterbuffer.c:4135
#3 0x00007f8201d81f17 in gst_task_func (task=0x7f7ff000a950) at ../gst/gsttask.c:384
#4 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 24 (LWP 4147955):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f820040aefa in wait_next_timeout (jitterbuffer=0x7f8018395e70) at ../gst/rtpmanager/gstrtpjitterbuffer.c:4105
#3 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#5 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 23 (LWP 4147038):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b84bf3 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f81cc0ba67f in gst_rtmp2_sink_task_func (user_data=<optimized out>) at ../gst/rtmp2/gstrtmp2sink.c:986
#4 0x00007f8201d81f17 in gst_task_func (task=0x7f8078011ef0) at ../gst/gsttask.c:384
#5 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#8 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 22 (LWP 4147031):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f81f06d295b in src_task_loop (pad=<optimized out>) at ../ext/dtls/gstdtlsenc.c:466
#3 0x00007f8201d81f17 in gst_task_func (task=0x7f81200af710) at ../gst/gsttask.c:384
#4 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 21 (LWP 4147030):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201e6dd03 in _gst_data_queue_wait_non_empty (queue=<optimized out>) at ../libs/gst/base/gstdataqueue.c:554
#3 gst_data_queue_pop (queue=0x7f8024007160, item=item@entry=0x7f7fdfffe730) at ../libs/gst/base/gstdataqueue.c:596
#4 0x00007f820041791c in gst_rtp_rtx_send_src_loop (rtx=0x7f8120044e60) at ../gst/rtpmanager/gstrtprtxsend.c:810
#5 0x00007f8201d81f17 in gst_task_func (task=0x7f80ec01b950) at ../gst/gsttask.c:384
#6 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#9 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 20 (LWP 4147029):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f82002b99ad in gst_queue_loop (pad=<optimized out>) at ../plugins/elements/gstqueue.c:1529
#3 0x00007f8201d81f17 in gst_task_func (task=0x7f80ec01b5f0) at ../gst/gsttask.c:384
#4 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 19 (LWP 4147028):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f82002b99ad in gst_queue_loop (pad=<optimized out>) at ../plugins/elements/gstqueue.c:1529
#3 0x00007f8201d81f17 in gst_task_func (task=0x7f801838e4d0) at ../gst/gsttask.c:384
#4 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 18 (LWP 4147027):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b84bf3 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f81e4028784 in gst_nice_src_create (basesrc=<optimized out>, buffer=0x7f7ffdffa638) at ../gst/gstnicesrc.c:291
#4 0x00007f8201e5349d in gst_base_src_get_range (src=src@entry=0x7f8120072100, offset=offset@entry=18446744073709551615, length=<optimized out>, length@entry=4096, buf=buf@entry=0x7f7ffdffa710) at ../libs/gst/base/gstbasesrc.c:2587
#5 0x00007f8201e56392 in gst_base_src_loop (pad=0x7f81f41a1300) at ../libs/gst/base/gstbasesrc.c:2911
#6 0x00007f8201d81f17 in gst_task_func (task=0x7f801838e710) at ../gst/gsttask.c:384
#7 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 17 (LWP 4147020):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f820009e3ab in WPEView::waitLoadCompletion (this=<optimized out>) at ../ext/wpe/WPEThreadedView.cpp:391
#3 WPEContextThread::createWPEView (this=<optimized out>, src=<optimized out>, src@entry=0x7f81fc067c60, context=<optimized out>, context@entry=0x0, display=<optimized out>, display@entry=0x0, width=<optimized out>, height=<optimized out>) at ../ext/wpe/WPEThreadedView.cpp:193
#4 0x00007f82000a03cf in gst_wpe_src_start (src=0x7f81fc067c60) at ../ext/wpe/gstwpesrc.cpp:281
#5 0x00007f8201e52ad1 in gst_base_src_prepare_allocation (caps=0x7f81240365e0, basesrc=0x7f81fc067c60) at ../libs/gst/base/gstbasesrc.c:3313
#6 gst_base_src_negotiate_unlocked (basesrc=basesrc@entry=0x7f81fc067c60) at ../libs/gst/base/gstbasesrc.c:3451
#7 0x00007f8201e5628e in gst_base_src_loop (pad=0x7f802c0539f0) at ../libs/gst/base/gstbasesrc.c:2867
#8 0x00007f8201d81f17 in gst_task_func (task=0x7f7fb0012ef0) at ../gst/gsttask.c:384
#9 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#12 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 16 (LWP 4147016):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201a447d7 in gst_app_src_create (bsrc=0x7f81fc066720, offset=<optimized out>, size=4096, buf=0x7f801effc638) at ../gst-libs/gst/app/gstappsrc.c:1382
#3 0x00007f8201e5349d in gst_base_src_get_range (src=src@entry=0x7f81fc066720, offset=offset@entry=563201, length=<optimized out>, length@entry=4096, buf=buf@entry=0x7f801effc710) at ../libs/gst/base/gstbasesrc.c:2587
#4 0x00007f8201e56392 in gst_base_src_loop (pad=0x7f802c0383e0) at ../libs/gst/base/gstbasesrc.c:2911
#5 0x00007f8201d81f17 in gst_task_func (task=0x7f8128007950) at ../gst/gsttask.c:384
#6 0x00007f8201baec34 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#9 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 15 (LWP 4147011):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b84bf3 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f8200a9d50b in _gst_pc_thread (webrtc=0x7f81200801c0) at ../ext/webrtc/gstwebrtcbin.c:708
#4 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 14 (LWP 4147009):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b84bf3 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f8200a94bac in _gst_nice_thread (ice=0x7f81f4076970) at ../ext/webrtc/gstwebrtcice.c:106
#4 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 13 (LWP 4143798):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b849a3 in g_main_context_iteration () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f81cc216fad in ?? () from target:/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 12 (LWP 4143769):
#0 0x00007f82017d367d in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201bd6c53 in g_cond_wait () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201d7a61c in gst_system_clock_async_thread (clock=0x7f81e000a0c0) at ../gst/gstsystemclock.c:677
#3 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#5 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 11 (LWP 4143709):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b84bf3 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f81eb0d6eb0 in WTF::RunLoop::run() () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#4 0x00007f81eb06b4fd in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#5 0x00007f81eb0d8e3d in WTF::wtfThreadEntryPoint(void*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#6 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 10 (LWP 4143707):
#0 0x00007f8201a0b07f in pthread_cond_timedwait@@GLIBC_2.3.2 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f81eb0d973f in WTF::ThreadCondition::timedWait(WTF::Mutex&, WTF::WallTime) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#2 0x00007f81eb066983 in WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#3 0x00007f81eb06a54c in WTF::sleep(WTF::Seconds) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#4 0x00007f81e7f2601a in WebKit::MemoryPressureMonitor::start()::{lambda()#1}::operator()() const [clone .constprop.0] () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#5 0x00007f81e7f2673f in WTF::Detail::CallableWrapper<WebKit::MemoryPressureMonitor::start()::{lambda()#1}, void>::call() () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#6 0x00007f81eb06b4fd in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#7 0x00007f81eb0d8e3d in WTF::wtfThreadEntryPoint(void*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#8 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#9 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 9 (LWP 4143706):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b849a3 in g_main_context_iteration () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f8201b849f1 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 8 (LWP 4143704):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b84bf3 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f81eb0d6eb0 in WTF::RunLoop::run() () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#4 0x00007f81eb06b4fd in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#5 0x00007f81eb0d8e3d in WTF::wtfThreadEntryPoint(void*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#6 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 7 (LWP 4143703):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b84bf3 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f81eb0d6eb0 in WTF::RunLoop::run() () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#4 0x00007f81eb06b4fd in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#5 0x00007f81eb0d8e3d in WTF::wtfThreadEntryPoint(void*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#6 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 6 (LWP 4143701):
#0 0x00007f8201a0ac06 in pthread_cond_wait@@GLIBC_2.3.2 () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f81f33b0e50 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from target:/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x00007f81eb0e8eb1 in bmalloc::Scavenger::threadRunLoop() () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#3 0x00007f81eb0e91bf in bmalloc::Scavenger::threadEntryPoint(bmalloc::Scavenger*) () from target:/lib/x86_64-linux-gnu/libWPEWebKit-1.0.so.4
#4 0x00007f81f33b6d84 in ?? () from target:/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
Thread 5 (LWP 4143700):
#0 0x00007f82017cd66f in poll () from target:/lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f8201b8486e in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f8201b84bf3 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f820009d6f6 in WPEContextThread::s_viewThread (data=0x7f81bc0072f0) at ../ext/wpe/WPEThreadedView.cpp:157
#4 0x00007f8201bae321 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f8201a04590 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f82017d9223 in clone () from target:/lib/x86_64-linux-gnu/libc.so.6
```
</details>
It is an edge-case, but ideally there would be something like pipeline error when this happens instead.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1582play: Missing g_object_notify signals2021-09-24T14:39:18ZRafał Dzięgielplay: Missing g_object_notify signalsOriginally `GstPlayer` library had used `g_object_notify_by_pspec` to notify about changed values on its properties. New `GstPlay` lib unfortunately lost this ability along the way, which makes is harder to use with toolkits that allow b...Originally `GstPlayer` library had used `g_object_notify_by_pspec` to notify about changed values on its properties. New `GstPlay` lib unfortunately lost this ability along the way, which makes is harder to use with toolkits that allow binding GObject properties e.g. `GTK`.
This also introduces API incompatibility with all apps that were using `g_object_bind_property` with player props and thus depend on them.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1583waylandsink in Qt5 be crashed2021-09-24T14:39:18ZSVENsuzhouwaylandsink in Qt5 be crashedI consulted tests/examples/waylandsink the example, the program is based on GTK. I tried to embed waylandsink in QT5, but it crashed in the code below.
```c
QPlatformNativeInterface * native = QGuiApplication::platformNativeInterface(...I consulted tests/examples/waylandsink the example, the program is based on GTK. I tried to embed waylandsink in QT5, but it crashed in the code below.
```c
QPlatformNativeInterface * native = QGuiApplication::platformNativeInterface();
struct wl_display *display_handle = (struct wl_display *)native->nativeResourceForWindow("display", NULL);
GstContext * context = gst_wayland_display_handle_context_new (display_handle);
gst_element_set_context (GST_ELEMENT(GST_MESSAGE_SRC(message)), context);
```
it crashed in function `gst_element_set_context `. Can you tell me how to fix this BUG? Or provide an example based on QT5. Thank you.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1586Follow-up from "wpe: Minor fixes to property handling"2021-09-24T14:39:19ZJan Alexander SteffensFollow-up from "wpe: Minor fixes to property handling"The following discussion from !2222 should be addressed:
- [ ] @thiblahute started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2222#note_909115):
> I wonder if consuming the bytes is th...The following discussion from !2222 should be addressed:
- [ ] @thiblahute started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2222#note_909115):
> I wonder if consuming the bytes is the right thing to do here though (orthogonal to your patch though).https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1588GstPlayer's first media-info-updated comes with 0 duration2021-09-24T14:39:19ZIvan MolodetskikhGstPlayer's first media-info-updated comes with 0 durationThe first time GstPlayer signals `media-info-updated`, the media info usually has duration = 0. This breaks GTK 4 MediaFile because it expects that media info is set once and never changed: https://gitlab.gnome.org/GNOME/gtk/-/issues/391...The first time GstPlayer signals `media-info-updated`, the media info usually has duration = 0. This breaks GTK 4 MediaFile because it expects that media info is set once and never changed: https://gitlab.gnome.org/GNOME/gtk/-/issues/3914
Here's a Rust reproducer based on the [`player.rs` example](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/65fd79f9730e08166f43d342ba9dff84c1a4fbbd/examples/src/bin/player.rs) where I only added `connect_media_info_updated` => print duration:
```rust
use std::sync::{Arc, Mutex};
use gstreamer as gst;
use gstreamer_player as gst_player;
use gst::{glib, prelude::*};
fn main() {
gst::init().unwrap();
let main_loop = glib::MainLoop::new(None, false);
let dispatcher = gst_player::PlayerGMainContextSignalDispatcher::new(None);
let player = gst_player::Player::new(
None,
Some(&dispatcher.upcast::<gst_player::PlayerSignalDispatcher>()),
);
// Tell the player what uri to play.
player.set_uri("file:///home/yalter/out.webm");
player.connect_media_info_updated(|player, _| {
println!("media-info-updated, media info duration: {:?}", player.get_media_info().unwrap().get_duration());
});
let error = Arc::new(Mutex::new(Ok(())));
let main_loop_clone = main_loop.clone();
// Connect to the player's "end-of-stream" signal, which will tell us when the
// currently played media stream reached its end.
player.connect_end_of_stream(move |player| {
let main_loop = &main_loop_clone;
player.stop();
main_loop.quit();
});
let main_loop_clone = main_loop.clone();
let error_clone = Arc::clone(&error);
// Connect to the player's "error" signal, which will inform us about eventual
// errors (such as failing to retrieve a http stream).
player.connect_error(move |player, err| {
let main_loop = &main_loop_clone;
let error = &error_clone;
*error.lock().unwrap() = Err(err.clone());
player.stop();
main_loop.quit();
});
player.play();
main_loop.run();
let guard = error.as_ref().lock().unwrap();
guard.clone().unwrap();
}
```
On both GStreamer 1.18.4 (Fedora 34) and 1.16.3 (`org.gnome.Platform`) I get something like this as an output:
```
media-info-updated, media info duration: ClockTime(Some(0))
media-info-updated, media info duration: ClockTime(Some(77650000000))
```
or
```
media-info-updated, media info duration: ClockTime(Some(0))
media-info-updated, media info duration: ClockTime(Some(47984000000))
media-info-updated, media info duration: ClockTime(Some(47984000000))
media-info-updated, media info duration: ClockTime(Some(47984000000))
media-info-updated, media info duration: ClockTime(Some(47984000000))
media-info-updated, media info duration: ClockTime(Some(47984000000))
media-info-updated, media info duration: ClockTime(Some(47984000000))
```
I suppose GstPlayer should delay the first `media-info-updated` until the duration (and other flags GTK 4 uses) is known (or it's known that they won't be known).
cc @slomo @companyhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1591srt: Setting "uri" property overrides other properties set earlier2021-09-24T14:39:21ZMart Raudseppsrt: Setting "uri" property overrides other properties set earlierThe `gst_srt_object_set_uri` implementation recreates the `application/x-srt-params` structure, losing all previously set values, including those not set in the URI.
So for example this code:
```c
g_object_set(srtsink, "latency", 300, NU...The `gst_srt_object_set_uri` implementation recreates the `application/x-srt-params` structure, losing all previously set values, including those not set in the URI.
So for example this code:
```c
g_object_set(srtsink, "latency", 300, NULL);
g_object_set(srtsink, "uri", "srt://127.0.0.1:7001", NULL);
```
or this:
```c
g_object_set(srtsink,
"latency", 300,
"uri", "srt://127.0.0.1:7001",
NULL);
```
will end up using default latency of 125, not what it explicitly set up here, as the URI setting will lose this with the `srtobject->parameters` recreation.
To fix this, we need to make sure uri is set first separately or in the same call:
```c
g_object_set(srtsink, "uri", "srt://127.0.0.1:7001", NULL);
g_object_set(srtsink, "latency", 300, NULL);
```
or
```c
g_object_set(srtsink,
"uri", "srt://127.0.0.1:7001",
"latency", 300,
NULL);
```
But if for some reason the URI needs to be set later in code flow (before going READY), all the previously set properties would need to be retrieved first and then set again after e.g. changing the IP address.
Any other property handled via srtobject->parameters is likely broken the same way if `uri` is set afterwards.
It would be nice to at least know about this behaviour via `"uri"` property description for a start, but of course ideally the URI setting shouldn't override properties that aren't overridden via GET parameters of the URI.
Edit: Earlier I claimed that this always happens when "uri" and "latency" are set up in the same g_object_set varargs, but this only happens if "uri" comes later in the vararg - it seemed to have been due to uri being handled via g_object_bind_property but latency via manual code making the behaviour be as latency set before the property bound uri when set in the same g_object_set call on the GstBin.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1598webrtcbin: First keyframe is usually lost2021-11-03T09:20:46ZSebastian Drögewebrtcbin: First keyframe is usually lostThe following discussion from !2260 should be addressed:
- [ ] @thaytan started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2260#note_935859): (+8 comments)
> > This pad probe is no lon...The following discussion from !2260 should be addressed:
- [ ] @thaytan started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2260#note_935859): (+8 comments)
> > This pad probe is no longer necessary, libnice now drops all buffers before the stream is connected.
>
> Does that mean we implicitly now depend on a particular libnice release, and if so which one?
>
> Dropping packets at the start probably means we'll always lose bits of our initial keyframe for video. It might be good if we requested a keyframe automatically as soon as the connection is established.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1600rsvgoverlay: allow dynamic images through data_sink2021-09-24T14:39:23ZBrett Downingrsvgoverlay: allow dynamic images through data_sink## issue:
rsvgoverlay cannot render a sequence of more than one svg frame from its data_sink, while rsvgdec can.
## cause:
rsvgoverlay waits for an EoF event before rendering a frame.
This prevents stream sources from being able to trig...## issue:
rsvgoverlay cannot render a sequence of more than one svg frame from its data_sink, while rsvgdec can.
## cause:
rsvgoverlay waits for an EoF event before rendering a frame.
This prevents stream sources from being able to trigger a push event, and once a push event has been triggered, it prevents the overlay from being updated.
This is fine for loading static images from filesrc, but that use-case is well-supported via the location property.
Other bugs prevent live animations in rsvgdec from being easily composited over a video.
## proposed fix:
rsvgdec contains logic to look for `</svg>` to trigger a push event, this can be replicated in rsvgoverlay. See [this comment](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/ext/rsvg/gstrsvgoverlay.c#L333)
Should I try to make a pull request?
edits: clarify this issue doesn't relate to svg animation featureshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1606cameraundistort: Provide description for "settings" parameter in documentation2021-09-24T14:39:25ZYegor Tcameraundistort: Provide description for "settings" parameter in documentationIn the plugin description, "settings" parameter is described as "Camera correction parameters (opaque string of serialized OpenCV objects)".
This description is very vague and lacks specific as to what exactly OpenCV object it expects, i...In the plugin description, "settings" parameter is described as "Camera correction parameters (opaque string of serialized OpenCV objects)".
This description is very vague and lacks specific as to what exactly OpenCV object it expects, in what format they should be serialized and provided to the pipeline.
Example pipeline omits giving actual example of the parameter, substituting it with question marks: settings="???"
I would be great if plugin description was extended to include actual settings parameters example and state what OpenCV object it expects and in what formats.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1610amc: add support for dynamic bitrate change2021-09-24T14:39:25ZRoman Shpuntovamc: add support for dynamic bitrate changeI use h264 encoder on Android 10 device. There is no effect after call `g_object_set(gstplugin, "bitrate", value, NULL);` when pipeline in playing state. The bitrate value can be set only on stopped pipeline. It would be nice to add bitr...I use h264 encoder on Android 10 device. There is no effect after call `g_object_set(gstplugin, "bitrate", value, NULL);` when pipeline in playing state. The bitrate value can be set only on stopped pipeline. It would be nice to add bitrate change feature during playing state. This is feature request issue. I use gstreamer version 1.16.3. Thanks!https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1611fdkaacdec: audio volume too low when decoding USAC(xHE-AAC) stream2021-09-24T14:39:25ZProvissyfdkaacdec: audio volume too low when decoding USAC(xHE-AAC) stream## Description
When decoding a USAC/xHE-AAC audio stream produced by exhale encoder([https://gitlab.com/ecodis/exhale](https://gitlab.com/ecodis/exhale)), the volume is so tiny which is just about 25% of the volume when decoding AAC-LC s...## Description
When decoding a USAC/xHE-AAC audio stream produced by exhale encoder([https://gitlab.com/ecodis/exhale](https://gitlab.com/ecodis/exhale)), the volume is so tiny which is just about 25% of the volume when decoding AAC-LC stream.
An audio sample is available here: [The_Piano_Sonatas_Disc_1_-_01._Sonata_for_Piano_No._1_in_C_major__K._189d-279-_I._Allegro.m4a](/uploads/da3ae141e62d10ea44991f41b9385ddb/The_Piano_Sonatas_Disc_1_-_01._Sonata_for_Piano_No._1_in_C_major__K._189d-279-_I._Allegro.m4a)
This sample works fine with Android and iOS.
USAC seems made DRC mandatory, is that the root cause?
Tested with `gst-launch-1.0 filesrc location=M4A_FILE ! decodebin ! pipewiresink`
## Details
```
$ gst-inspect-1.0 fdkaacdec
Factory Details:
Rank marginal (64)
Long-name FDK AAC audio decoder
Klass Codec/Decoder/Audio
Description FDK AAC audio decoder
Author Sebastian Dröge <sebastian@centricular.com>
Plugin Details:
Name fdkaac
Description Fraunhofer FDK AAC Codec plugin
Filename /usr/lib64/gstreamer-1.0/libgstfdkaac.so
Version 1.18.4
License LGPL
Source module gst-plugins-bad
Source release date 2021-03-15
Binary package Fedora GStreamer-plugins-bad package
Origin URL http://download.fedoraproject.org
GObject
+----GInitiallyUnowned
+----GstObject
+----GstElement
+----GstAudioDecoder
+----GstFdkAacDec
Pad Templates:
SRC template: 'src'
Availability: Always
Capabilities:
audio/x-raw
format: S16LE
layout: interleaved
rate: [ 8000, 96000 ]
channels: [ 1, 8 ]
SINK template: 'sink'
Availability: Always
Capabilities:
audio/mpeg
mpegversion: { (int)2, (int)4 }
stream-format: { (string)adts, (string)adif, (string)raw }
channels: [ 1, 8 ]
Element has no clocking capabilities.
Element has no URI handling capabilities.
Pads:
SINK: 'sink'
Pad Template: 'sink'
SRC: 'src'
Pad Template: 'src'
Element Properties:
max-errors : Max consecutive decoder errors before returning flow error
flags: readable, writable
Integer. Range: -1 - 2147483647 Default: 10
min-latency : Aggregate output data to a minimum of latency time (ns)
flags: readable, writable
Integer64. Range: 0 - 9223372036854775807 Default: 0
name : The name of the object
flags: readable, writable, 0x2000
String. Default: "fdkaacdec0"
parent : The parent of the object
flags: readable, writable, 0x2000
Object of type "GstObject"
plc : Perform packet loss concealment (if supported)
flags: readable, writable
Boolean. Default: false
tolerance : Perfect ts while timestamp jitter/imperfection within tolerance (ns)
flags: readable, writable
Integer64. Range: 0 - 9223372036854775807 Default: 0
```
```
# dnf info fdk-aac
Last metadata expiration check: 1:49:02 ago on Wed 30 Jun 2021 01:58:19 AM JST.
Installed Packages
Name : fdk-aac
Version : 2.0.2
Release : 1.fc34
Architecture : x86_64
Size : 1.2 M
Source : fdk-aac-2.0.2-1.fc34.src.rpm
Repository : @System
From repo : rpmfusion-nonfree-updates
Summary : Fraunhofer FDK AAC Codec Library
URL : https://github.com/mstorsjo/fdk-aac
License : FDK-AAC
Description : The Fraunhofer FDK AAC Codec Library ("FDK AAC Codec") is software that
: implements the MPEG Advanced Audio Coding ("AAC") encoding and decoding
: scheme for digital audio.
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1616onnx: Pipepeline fails to negotiate with yolov5 model2021-09-24T14:39:28Zzack xueonnx: Pipepeline fails to negotiate with yolov5 modelI follow https://github.com/ultralytics/yolov5/issues/251 guide to convert the yolov5s.pt format, the onnxobjectdetector can't work:
i have attached the yolo onnx file, the demo model.onnx file work well(https://github.com/zoq/onnx-runt...I follow https://github.com/ultralytics/yolov5/issues/251 guide to convert the yolov5s.pt format, the onnxobjectdetector can't work:
i have attached the yolo onnx file, the demo model.onnx file work well(https://github.com/zoq/onnx-runtime-examples/tree/main/data/models)
GST_DEBUG=onnxobjectdetector:7 gst-launch-1.0 rtspsrc location=rtsp://192.168.100.103:554/stream1 latency=0 protocols=0x00000004 buffer-mode=auto ! rtph264depay ! h264parse ! avdec_h264 ! videorate ! video/x-raw,framerate=3/1 ! videoconvert ! onnxobjectdetector box-node-index=0 class-node-index=1 score-node-index=2 detection-node-index=3 execution-provider=cpu model-file=yolov5s.onnx label-file=COCO_classes.txt ! videoconvert ! autovideosink
log is below, and the demo model[yolov5s.onnx](/uploads/79e5db38d8b5b5b25cca68716ace2be1/yolov5s.onnx)
```
0:00:00.059874635 2422 0x561867d41f20 INFO onnxobjectdetector gstonnxobjectdetector.cpp:512:gst_onnx_object_detector_create_session:<onnxobjectdetector0> Output node index: 0 for node: output
0:00:00.059916830 2422 0x561867d41f20 INFO onnxobjectdetector gstonnxobjectdetector.cpp:512:gst_onnx_object_detector_create_session:<onnxobjectdetector0> Output node index: 1 for node: 414
0:00:00.059922518 2422 0x561867d41f20 INFO onnxobjectdetector gstonnxobjectdetector.cpp:512:gst_onnx_object_detector_create_session:<onnxobjectdetector0> Output node index: 2 for node: 434
0:00:00.059955481 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, format=(string){ RGB, RGBA, BGR, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]
0:00:00.059980498 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, format=(string){ RGB, RGBA, BGR, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; => video/x-raw, format=(string){ RGB, RGBA, BGR, BGRA }, width=(int)640, height=(int)3, framerate=(fraction)[ 0/1, 2147483647/1 ];
0:00:00.060492133 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, format=(string){ RGB, RGBA, BGR, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]
0:00:00.060508027 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, format=(string){ RGB, RGBA, BGR, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ]; => video/x-raw, format=(string){ RGB, RGBA, BGR, BGRA }, width=(int)640, height=(int)3, framerate=(fraction)[ 0/1, 2147483647/1 ];
0:00:00.060963259 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]
0:00:00.060977258 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]; => video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)640, height=(int)3;
0:00:00.061567184 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]
0:00:00.061581016 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]; => video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)640, height=(int)3;
0:00:00.062173314 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]
0:00:00.062186853 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]; => video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)640, height=(int)3;
0:00:00.062701656 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]
0:00:00.062714963 2422 0x561867d41f20 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ]; => video/x-raw, framerate=(fraction)3/1, format=(string){ RGB, BGR, RGBA, BGRA }, width=(int)640, height=(int)3;
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Pipeline is PREROLLED ...
Prerolled, waiting for progress to finish...
Progress: (connect) Connecting to rtsp://192.168.100.103:554/stream1
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
Redistribute latency...
0:00:04.438870327 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.438974915 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.439375980 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1
0:00:04.439447269 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1;
0:00:04.441900517 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.441986085 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.442366132 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1
0:00:04.442435994 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1;
0:00:04.443580174 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.443595563 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.443696195 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1
0:00:04.443709786 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1;
Redistribute latency...
0:00:04.448324767 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.448344904 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.448441497 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1
0:00:04.448457171 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, format=(string){ BGRA, RGBA, BGR, RGB }, pixel-aspect-ratio=(fraction)1/1;
0:00:04.467887181 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.467907008 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.467993766 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.468008579 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.468085665 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.468100162 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.468180637 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.468194173 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
Redistribute latency...
0:00:04.468742895 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.468760984 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.468843672 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.468858118 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.468934688 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.468949433 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.469029461 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.469043236 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.469120462 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.469134485 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
0:00:04.469212929 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:580:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transforming caps video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }
0:00:04.469226399 2422 0x7f6df80068c0 LOG onnxobjectdetector gstonnxobjectdetector.cpp:597:gst_onnx_object_detector_transform_caps:<onnxobjectdetector0> transformed structure 0: video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB }; => video/x-raw, framerate=(fraction)3/1, width=(int)640, height=(int)3, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, format=(string){ BGRA, RGBA, BGR, RGB };
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Internal data stream error.
Additional debug info:
../subprojects/gst-plugins-good/gst/rtsp/gstrtspsrc.c(6188): gst_rtspsrc_loop (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:00.098627712
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1618tsdemux: filter out the stream with special pid when there is no PMT packet.2021-09-24T14:39:28ZRandy Litsdemux: filter out the stream with special pid when there is no PMT packet.There are some satellite standards that don't like to put everything in PMT, we can't demux them from TS stream. But VLC would work.
I think I may reuse the pad for private_%01x_%05x which was used for text and just extract all its data ...There are some satellite standards that don't like to put everything in PMT, we can't demux them from TS stream. But VLC would work.
I think I may reuse the pad for private_%01x_%05x which was used for text and just extract all its data assigned with that pid, letting the downstream plugin decide what they want to do with them.
satellite system may its own proprietary packet instead of PMT/PAT, likes APG.Randy LiRandy Lihttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1622tsdemux: Improve keyframe seeking2021-09-24T14:39:29ZEdward Herveytsdemux: Improve keyframe seekingCurrently keyframe seeking is done by:
1. Seeking to 2.5s before requested position
2. Guess-timating where the offset would be (based on PCR observations)
3. Collecting PES data (including for streams on which we don't do keyframe check...Currently keyframe seeking is done by:
1. Seeking to 2.5s before requested position
2. Guess-timating where the offset would be (based on PCR observations)
3. Collecting PES data (including for streams on which we don't do keyframe checking)
4. Figure out if a fully collected PES is a keyframe
5. If not seek back a bit, and go back to step 3
6. If it does contain a keyframe, but not SPS/PPS/... collect keyframe and go back to step 3
This could be improved by:
1. No longer offseting back the position if there is a keyframe handler for the video stream, but instead using the requested position.
2. in SEEKING state, create a dedicated Packetizer mode which allows scanning rapidly for given PIDs (the video one and the PCR one if it's not the same as the video one).
3. Scan for position
* Start from a guesstimated offset (PTS/DTS => PCR => offset) and search for those PID if PUSI bit is set or adaptation field is present. Ignore all other packets.
* If the stream is AVCHD/BDMV, every single packet has the PCR as the first 4 bytes. This can speed up guessing the initial start position to look for those given PID.
4. If the resulting offset is too far astray (or because of PCR jump/discont/gap), recalculate a new offset and go back to 3
5. Every time a video PID with PUSI bit is set, start scanning the content of that packet PES for actual PTS/DTS and keyframe/sps/pps presence. If scanner needs more data from that packet to decide whether it contains or not a keyframe/sps/pps, it can say so and the next packet from that video PID is provided
6. If that packet contains all needed information to start playback (SPS/PPS/keyframe), mark that as the starting position and go back to regular playback mode
7. If that packet doesn't contain the needed information, scan backwards for video PID with PUSI bit set, i.e. go back to step 5.
This will:
* reduce i/o to a minimum and ensure we always hit the *target* keyframe (and not some several seconds earlier)
* avoid messing up with the state of tsdemux regular playback (positions going completely astray, random stray data being pushed out, ...)
* allow much faster seeking, especially for AVCHD/BDMV contenthttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1624codecparsers: h265: Broken code in parser is duplicated and fixed in the deco...2021-09-24T14:39:30ZNicolas Dufresnecodecparsers: h265: Broken code in parser is duplicated and fixed in the decoder classWe should fix the parser code and stop duplicating code in the H265 decoder. This code was copied from gstreamer-vaapi, which was doing so already.
The following discussion from !2414 should be addressed:
- [ ] @ndufresne started a [di...We should fix the parser code and stop duplicating code in the H265 decoder. This code was copied from gstreamer-vaapi, which was doing so already.
The following discussion from !2414 should be addressed:
- [ ] @ndufresne started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2414#note_994696): (+1 comment)
> I notice also that gst_h265_decoder_prepare_rps() seems to duplicate what gst_h265_parser_parse_slice_hdr() is doing (wrongly, it forgot to reset the NumPicTotalCurr to zero as specified in the spec). The calculated values is needed in the parsing process, so it has to happen in the parser, duplicating it is just a bad friend, since we don't know how the parser may fail considering it has the wrong value.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1626hlsdemux: m3u8 forwarding to another single m3u8 uri don't play2021-11-24T13:14:31ZAndreas Frischhlsdemux: m3u8 forwarding to another single m3u8 uri don't playtrying to play
```
gst-play-1.0 "https://livecdn-de-earthtv-com.global.ssl.fastly.net/edge2/cdnedge/IsTeg6sABzM/playlist.m3u8?token=EAIY6wE4hJq0NUCIHUgF.CgdlYXJ0aHR2EAEyC0lzVGVnNmNBQnpFOgtJc1RlZzZzQUJ6TQ.7O0m5KuBHaIzpOhEpOUZaKp8tn-BTg3e...trying to play
```
gst-play-1.0 "https://livecdn-de-earthtv-com.global.ssl.fastly.net/edge2/cdnedge/IsTeg6sABzM/playlist.m3u8?token=EAIY6wE4hJq0NUCIHUgF.CgdlYXJ0aHR2EAEyC0lzVGVnNmNBQnpFOgtJc1RlZzZzQUJ6TQ.7O0m5KuBHaIzpOhEpOUZaKp8tn-BTg3eblRWtM55P7LcRQKDSFTbWCMHx4ej7fpyTiaY_0Iy0Xk2LDoqSuAuDw&domain=www.earthtv.com"
```
this will result in a `<souphttpsrc0> error: Forbidden (403)`
however, when directly playing the contained uri
```
gst-play-1.0 "https://livecdn-de-earthtv-com.global.ssl.fastly.net/edge2/cdnedge/IsTeg6sABzM/chunklist.m3u8?token=EAIY6wE4hJq0NUCIHUgF.CgdlYXJ0aHR2EAEyC0lzVGVnNmNBQnpFOgtJc1RlZzZzQUJ6TQ.7O0m5KuBHaIzpOhEpOUZaKp8tn-BTg3eblRWtM55P7LcRQKDSFTbWCMHx4ej7fpyTiaY_0Iy0Xk2LDoqSuAuDw&domain=www.earthtv.com"
```
then playback starts as expected.
vlc and mpv can play directly from the playlist.m3u8 thoughhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1630dvbsrc: v3 DVB API usage in gst_dvbsrc_output_frontend_stats()2021-09-24T14:39:31ZHarald Jennydvbsrc: v3 DVB API usage in gst_dvbsrc_output_frontend_stats()Hello,
while trying to use my DVB-S2 card with gstreamer I stumbled across the issue that despite dvbsrc claiming to use at least DVB_API_VERSION >= 5 (minor 5) the frontend stats collection still seems to be done in v3 mode. This resul...Hello,
while trying to use my DVB-S2 card with gstreamer I stumbled across the issue that despite dvbsrc claiming to use at least DVB_API_VERSION >= 5 (minor 5) the frontend stats collection still seems to be done in v3 mode. This results in the error message "dvbsrc gstdvbsrc.c:2235:gst_dvbsrc_output_frontend_stats:<dvbsrc0> There were errors getting frontend status information: 'Unknown error 524'" (which means ENOTSUPP). Would it be possible to modify gst_dvbsrc_output_frontend_stats() to do the stats collection in a v5 compatible way like it is done for example in https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/recorders/dvbchannel.cpp?
Kind regards
Harald Jennyhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1631Hanging in shmsink2023-06-28T15:18:11ZandrejlevkovitchHanging in shmsinkSometimes producer pipeline with shmsink hanging. That happens if consumer (shmsrc) not pull data (sleep) for some time. So shmsink allocate all acceptable blocks in shared memory and start waiting for free blocks, but it never happens, ...Sometimes producer pipeline with shmsink hanging. That happens if consumer (shmsrc) not pull data (sleep) for some time. So shmsink allocate all acceptable blocks in shared memory and start waiting for free blocks, but it never happens, because shmsink can't allocate new memory and blocks of shared memory (as GstBuffer-s) reuses by gstreamer. So producer freezes here:
https://github.com/GStreamer/gst-plugins-bad/blob/f9d7b708e12e5560759c585b44cfa3e523b61526/sys/shm/gstshmsink.c#L730-L742
I see this problem with gstreamer version 1.4 and 1.6
Looks like if we will ignore "need_new_memory" condition (just return from function and skip current frame) it fixes the problem. [Here](https://github.com/andrejlevkovitch/gst-shm-hanging-fix) you can find minimal example for bug reproducing and small fix that resolves the problem.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1635codecs: h264decoder: decoding performance regression in latest git2023-01-29T18:09:21ZRafał Dzięgielcodecs: h264decoder: decoding performance regression in latest gitWhile using latest GStreamer git with `vah264dec` + `glimagesink` I noticed a serious performance regression. While playing any H264 video, playback freezes for about 0.5 second every 2-3 seconds. No errors or warnings are logged.
This ...While using latest GStreamer git with `vah264dec` + `glimagesink` I noticed a serious performance regression. While playing any H264 video, playback freezes for about 0.5 second every 2-3 seconds. No errors or warnings are logged.
This does not happen if I use 1.19.1 or compile gst-plugins-bad from before !2373
Bisect indicated that f1df1207 and b4e38874 were the first 2 bad commits that introduced this bug.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1638SRT stats send-duration-us duplicated2021-09-24T14:39:33ZSektor van SkijlenSRT stats send-duration-us duplicatedThe `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is send...The `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is sending data (idle time exclusive) */
"send-duration-us", G_TYPE_INT64, stats.usSndDuration,
...
/* busy sending time (i.e., idle time exclusive) */
"send-duration-us", G_TYPE_UINT64, stats.usSndDuration,
"negotiated-latency-ms", G_TYPE_INT, stats.msSndTsbPdDelay, NULL);
```
Another minor problem is `*bytes += stats.byteSent;` for `is_sender` section, but `stats.byteRecvTotal` for else section. As you don't request clearing the stats in the `srt_bstats` call it shouldn't make a difference, but formally it's wrong.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1645msdk: decode and downscale with msdkh264dec and msdkvpp outputfile corrupted2021-09-24T14:39:33Ztengjinchungmsdk: decode and downscale with msdkh264dec and msdkvpp outputfile corruptedtrying to decode and down scale from 4K to 2048x1550 nv12 file, output file have greenline at the top of the stream. Issue is not observed with vaapih264dec and vaapipostproc.
```
platform: TigerLake
vainfo: VA-API version: 1.12 (libva ...trying to decode and down scale from 4K to 2048x1550 nv12 file, output file have greenline at the top of the stream. Issue is not observed with vaapih264dec and vaapipostproc.
```
platform: TigerLake
vainfo: VA-API version: 1.12 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 21.2.3 (2cc1938f)
```
`gst-launch-1.0 filesrc location=/home/test/media-profiling-tool/media-content/H264/Puppies_3840x2160_20mbps_60fps_High_at_L5.2.h264 num-buffers=1500 ! h264parse ! vaapih264dec ! vaapipostproc ! "video/x-raw,format=NV12,width=2048,height=1550" ! filesink location=2048x1550-nv12.yuv`https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1652Follow-up from "codecs: av1dec: Enable scalable decoding"2021-09-24T14:39:34ZVíctor Manuel Jáquez LealFollow-up from "codecs: av1dec: Enable scalable decoding"The following discussion from !2475 should be addressed:
- [ ] @He_Junyan started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2475#note_1043529):
> This patch can really solve the multi...The following discussion from !2475 should be addressed:
- [ ] @He_Junyan started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2475#note_1043529):
> This patch can really solve the multi layer problem, the correctness is OK, but have some performance flaw because of the caps negotiation.
>
> For example, there are 2 spatial layer, 0 with 800x600 res and 1 with 1092x1080 res. According to spec, we should only output the higher layer by default, which is the 1 with 1920x1080 res. But we need to decode both layers(The higher layer needs to reference the lower layer). The coded picture from both layers come in interweave sequence, and in the new_picture(), because the resolution changes, we need to re-negotiate the caps with the downstream element again and again. The is a big waste and have performance problem.
>
> If we want to avoid this, we should notify the sub-class whether this picture will be output or not when call the new_picture(). And the sub-class should maintain a buffer_pool for each non-output layers internally, and allocate the picutre/buffers/surfaces from that internal buffer pool to avoid that re-negotiation.
>
> This may take a big effect(Each internal layer can also change their resolution dynamically). I think this patch can already make us conform to the SPEC and pass all the conformance test about his. This multi layers feature is more or less like the SVC feature of the HEVC, we are not sure whether it will be widely used. And I think we can add a TODO for that, and this patch is already OK for me.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1655`srtpenc`, `dtlsenc`: Log keys to `SSLKEYLOGFILE`2022-05-17T00:01:21ZGerard Ryan`srtpenc`, `dtlsenc`: Log keys to `SSLKEYLOGFILE`Adding [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format) logging to `SSLKEYLOGFILE` for `srtpenc` and `dtlsenc` would allow easy diagnosis of network-related issues using Wireshark as it w...Adding [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format) logging to `SSLKEYLOGFILE` for `srtpenc` and `dtlsenc` would allow easy diagnosis of network-related issues using Wireshark as it will be able to decrypt the packet captures.
Adding it to these plugins, rather than higher-level plugins like `webrtcbin` would allow a large portion of GStreamer to use this feature.
[NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format) is followed by Chrome, Firefox, Curl and Wireshark.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1663mss stream playback failed2022-04-28T13:07:10Zrlandjmss stream playback failedgstreamer version:git master
Playbin3 cannot play this mss stream http://211.157.189.189:8000/multimedia/elephants-dream-h264-low-multi-aac/Manifest ,but I can play it normally after installing the [Native MPEG-Dash + HLS Playback plugi...gstreamer version:git master
Playbin3 cannot play this mss stream http://211.157.189.189:8000/multimedia/elephants-dream-h264-low-multi-aac/Manifest ,but I can play it normally after installing the [Native MPEG-Dash + HLS Playback plugin](https://chrome.google.com/webstore/detail/native-mpeg-dash-%2B-hls-pl/cjfbmleiaobegagekpmlhmaadepdeedn?hl=en) in chrome.
qtdemux/mssdemux complained about many errors. Is there any way for qtdemux/mssdemux to improve compatibility with this stream?
log [gst.zip](/uploads/18188cc9c8c68d41cfd6d316f2f4fbf9/gst.zip)
```shell
$ GST_DEBUG_COLOR_MODE=off GST_DEBUG=5 GST_DEBUG_FILE='/home/luckysk/work/log/gst.log' GST_DEBUG_DUMP_DOT_DIR='/home/luckysk/work/log' gst-launch-1.0 playbin3 uri=http://211.157.189.189:8000/multimedia/elephants-dream-h264-low-multi-aac/Manifest
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'souphttpsrc0': gst.soup.session=context, session=(SoupSession)NULL, force=(boolean)false;
Redistribute latency...
Redistribute latency...
Redistribute latency...
ERROR: from element /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstQTDemux:qtdemux3: This file is invalid and cannot be played.
Additional debug info:
../gst/isomp4/qtdemux.c(7406): gst_qtdemux_process_adapter (): /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0/GstQTDemux:qtdemux3:
sample data crosses atom boundary
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
ERROR: from element /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstURISourceBin:urisourcebin0/GstMssDemux:mssdemux0: Internal data stream error.
Additional debug info:
../gst-libs/gst/adaptivedemux/gstadaptivedemux.c(2708): _src_chain (): /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstURISourceBin:urisourcebin0/GstMssDemux:mssdemux0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1668h264parse: Forwarding SEI timecodes causes qtmux to produce non-playable output2021-09-24T14:39:37ZPaul Feeh264parse: Forwarding SEI timecodes causes qtmux to produce non-playable outputI've encountered a change in behaviour that first occurs with GStreamer 1.15.90. Processing of CCTV video that worked with GStreamer 1.12.5 breaks when I upgrade to GStreamer 1.16.2. I have narrowed down the change to commit 7c425cf3.
...I've encountered a change in behaviour that first occurs with GStreamer 1.15.90. Processing of CCTV video that worked with GStreamer 1.12.5 breaks when I upgrade to GStreamer 1.16.2. I have narrowed down the change to commit 7c425cf3.
[playable.h264](/uploads/a548c809d03a80c31b2b9c46037b39ae/playable.h264)
Attached is a depayed capture of RTP video from an IP CCTV camera. I initially investigated with GStreamer 1.12.5 and 1.16.2 as these were the versions bundled with openSUSE Leap 15.1 and 15.2. However it's commit 7c425cf3 that's of most interest.
The attached file is playable with both GStreamer 1.12.5 and 1.16.2 as follows:
```
$ gst-launch-1.0 filesrc location=playable.h264 ! h264parse ! decodebin ! autovideosink
```
Note: Ignore that it's a dark noisy image, the camera wasn't pointing at anything useful.
A pipeline including `h264parse` and `qtmux` elements illustrates the change in behaviour.
Output on Leap 15.1, GStreamer 1.12.5 (video plays onscreen, acceptable error as I closed the video playback window early):
```
$ gst-launch-1.0 filesrc location=playable.h264 ! h264parse ! qtmux fragment-duration=1000 ! filesink location=output.mp4
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.017978031
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
$ gst-play-1.0 output.mp4
Press 'k' to see a list of keyboard shortcuts.
Now playing /root/output.mp4
Redistribute latency...
Redistribute latency...
ERROR Output window was closed for file:///root/output.mp4
ERROR debug information: xvimagesink.c(554): gst_xv_image_sink_handle_xevents (): /GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstXvImageSink:xvimagesink0
Reached end of play list.
```
Output on Leap 15.2, GStreamer 1.16.2 (gst-play fails to display any video):
```
$ gst-launch-1.0 filesrc location=playable.h264 ! h264parse ! qtmux fragment-duration=1000 ! filesink location=output.mp4
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.019327141
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
$ gst-play-1.0 output.mp4
Press 'k' to see a list of keyboard shortcuts.
Now playing /root/output.mp4
ERROR This file contains no playable streams. for file:///root/output.mp4
ERROR debug information: qtdemux.c(716): gst_qtdemux_post_no_playable_stream_error (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
no known streams found
Reached end of play list.
```
If I patch gstreamer-plugins-bad to avoid the `gst_buffer_add_video_time_code_meta_full` call, added by 7c425cf3, then I can once again pass the h264 via through `h264parse` and `qtmux` elements and get playback video with GStreamer 1.16.2.
I'm unsure whether:
1. The handling of time codes from SEI NALs is flawed within `h264parse`,
2. the `qtmux` element incorrectly handles the additional `GstVideoTimeCodeMeta` or
3. if the resulting video is valid, but gst-play is at fault (unlikely as other players also fail to handle the output).
Also note, behaviour changes again with GStreamer 1.18 where the `qtmux` fails with `"Buffer has no PTS"`. However that's a separate issue. This bug is only about the SEI time code change introduced in 1.15.90.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1669VA: Need to create a property for device's tile selection.2021-10-28T15:50:49ZHe JunyanVA: Need to create a property for device's tile selection.The current vaD128h264dec kind VA plugins can specify the GPU device correctly, but we now have a sub division of each GPU device into multi tiles(It is like the NUMA in GPU side), so we may need to add a "tile" property to each VA eleme...The current vaD128h264dec kind VA plugins can specify the GPU device correctly, but we now have a sub division of each GPU device into multi tiles(It is like the NUMA in GPU side), so we may need to add a "tile" property to each VA element.
We just continue the discussion of:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2230#note_1059967https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1682mpegtsmux: error: Could not create handler for stream2021-10-27T12:18:29ZMarianna Smidth Buschlempegtsmux: error: Could not create handler for streamI have python app which is dynamically linking video (H264) from an `udpsrc` (RTP) and audio from a local `alsasrc` (converted to AAC) to `mpegtsmux`.
Depending on the order/timing of the linking I'm getting this error message:
`basets...I have python app which is dynamically linking video (H264) from an `udpsrc` (RTP) and audio from a local `alsasrc` (converted to AAC) to `mpegtsmux`.
Depending on the order/timing of the linking I'm getting this error message:
`basetsmux gstbasetsmux.c:811:gst_base_ts_mux_create_pad_stream:<mpegtsmux2> error: Could not create handler for stream`
I have tried asking both on the mailing list and IRC does this error means and what causes it, but nobody has been able to answer me so far...
A simpler gst-launch-1.0 representation of the pipeline works fine:
```
gst-launch-1.0 udpsrc address=224.1.1.1 port=5000 multicast-iface=eth1 ! application/x-rtp,media=video,payload=33,clock-rate=90000,encoding-name=MP2T ! rtpbin ! queue ! decodebin caps="video/x-h264" ! h264parse ! "video/x-h264,stream-format=byte-stream,alignment=au" ! tee name=t ! queue ! "video/x-h264,stream-format=byte-stream,alignment=au" ! multiqueue name=mq ! mpegtsmux name=mux ! rtpmp2tpay ! fakesink audiotestsrc ! "audio/x-raw,format=S32LE,layout=interleaved,rate=44100,channels=2,channel-mask=(bitmask)0x3" ! mq. mq. ! audioconvert ! avenc_aac ! mux. -v --gst-debug=*:3
```
So it must be a matter of order/timing
Raising the debug level to `*tsmux:5` or even `*tsmux:7` doesn't give all that much more clarity:
```
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168211501 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:1676:gst_base_ts_mux_find_best_pad:<mpegtsmux_cam1> Best pad found with 0:00:00.023219954: <mpegtsmux_cam1:sink_1>
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168320898 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:1094:gst_base_ts_mux_aggregate_buffer:<mpegtsmux_cam1> Pads collected
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168373356 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:403:gst_base_ts_mux_create_stream:<mpegtsmux_cam1:sink_0> Creating stream with PID 0x0041 for caps video/x-h264, stream-format=(string)byte-stream, width=(int)1920, height=(int)1080, framerate=(fraction)0/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, alignment=(string)au, profile=(string)high, level=(string)4
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168416277 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:780:gst_base_ts_mux_create_pad_stream:<mpegtsmux_cam1:sink_0> Use stream (pid=65) from pad as PCR for program (prog_id = 0)
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168447309 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:403:gst_base_ts_mux_create_stream:<mpegtsmux_cam1:sink_1> Creating stream with PID 0x0041 for caps audio/mpeg, mpegversion=(int)4, channels=(int)2, rate=(int)44100, stream-format=(string)raw, framed=(boolean)true, level=(string)2, base-profile=(string)lc, profile=(string)lc, codec_data=(buffer)1210
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168469731 75594 0x564857e0f8f0 DEBUG basetsmux gstbasetsmux.c:470:gst_base_ts_mux_create_stream:<mpegtsmux_cam1:sink_1> we have additional codec data (2 bytes)
Oct 27 08:53:24 qt5122-msb qtec-mediamixer[75594]: 0:00:01.168483311 75594 0x564857e0f8f0 WARN basetsmux gstbasetsmux.c:811:gst_base_ts_mux_create_pad_stream:<mpegtsmux_cam1> error: Could not create handler for stream
```
And looking at the source I seem to be getting here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/gst/mpegtsmux/gstbasetsmux.c#L727
```
if (ts_pad->stream == NULL) {
ret = gst_base_ts_mux_create_stream (mux, ts_pad);
if (ret != GST_FLOW_OK)
goto no_stream;
}
```
```
no_stream:
{
GST_ELEMENT_ERROR (mux, STREAM, MUX,
("Could not create handler for stream"), (NULL));
return ret;
}
```
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/blob/master/gst/mpegtsmux/gstbasetsmux.c#L370
```
if (st != TSMUX_ST_RESERVED) {
ts_pad->stream = tsmux_create_stream (mux->tsmux, st, ts_pad->pid,
ts_pad->language);
} else {
GST_DEBUG_OBJECT (pad, "Failed to determine stream type");
}
if (ts_pad->stream != NULL) {
```
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsmux/tsmux/tsmux.c#L682
My best guess:
```
/* Ensure we're not creating a PID collision */
if (tsmux_find_stream (mux, new_pid))
return NULL;
```
Finally if I compare with the output of the working gst-launch:
```
0:00:00.306454146 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:403:gst_base_ts_mux_create_stream:<mux:sink_0> Creating stream with PID 0x0041 for caps video/x-h264, stream-format=(string)byte-stream, width=(int)1920, height=(int)1080, framerate=(fraction)0/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, alignment=(string)au, profile=(string)high, level=(string)4
0:00:00.306529032 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:780:gst_base_ts_mux_create_pad_stream:<mux:sink_0> Use stream (pid=65) from pad as PCR for program (prog_id = 0)
0:00:00.306580500 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:403:gst_base_ts_mux_create_stream:<mux:sink_1> Creating stream with PID 0x0042 for caps audio/mpeg, channels=(int)2, rate=(int)44100, mpegversion=(int)4, base-profile=(string)lc, framed=(boolean)true, stream-format=(string)raw, channel-mask=(bitmask)0x0000000000000003, level=(string)2, profile=(string)lc, codec_data=(buffer)121056e500
0:00:00.306609142 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:470:gst_base_ts_mux_create_stream:<mux:sink_1> we have additional codec data (5 bytes)
0:00:00.306659206 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmuxaac.c:106:gst_base_ts_mux_prepare_aac_adts:<mux> Preparing AAC buffer for output
0:00:00.306679775 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmuxaac.c:111:gst_base_ts_mux_prepare_aac_adts:<mux> Rate index 4, channels 2, object type/profile 2
0:00:00.306703159 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:1187:gst_base_ts_mux_aggregate_buffer:<mux:sink_1> Chose stream for output (PID: 0x0042)
0:00:00.306724715 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:1201:gst_base_ts_mux_aggregate_buffer:<mux> Buffer has PTS 0:00:00.000000000 pts 0
0:00:00.306745826 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:1207:gst_base_ts_mux_aggregate_buffer:<mux> Buffer has DTS +0:00:00.000000000 dts 0
0:00:00.306760796 77005 0x5610ab7be370 DEBUG basetsmux gstbasetsmux.c:1229:gst_base_ts_mux_aggregate_buffer:<mux> delta: 1
```
Here it can be seen that the difference is that the audio and video streams both have their own PIDs (0x41 and 0x42) while when I get the error they both got the same PID (0x41)
And that is what must be triggering this:
```
/* Ensure we're not creating a PID collision */
if (tsmux_find_stream (mux, new_pid))
return NULL;
```
Is this expected behavior or a bug / race condition?
If this is expected is it at least possible to add more debug information (pad name, ...) that can give a better indication of what is wrong?
Fx, add an WARNING about PID collision?
And in that case what should I do to avoid collisions?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1685Video and audio are out of sync when using nvh264dec2022-05-03T16:48:57ZAnton MartynauVideo and audio are out of sync when using nvh264decUbuntu 18.04, GStreamer 1.18.4
I have a problematic source: https://drive.google.com/file/d/1I7G8qHhsedeW9-_hjiqoP4Lh643g_cEP/view
When I work with it I get a lot of warnings:
```
mpegtspacketizer mpegtspacketizer.c:2365:mpegts_packeti...Ubuntu 18.04, GStreamer 1.18.4
I have a problematic source: https://drive.google.com/file/d/1I7G8qHhsedeW9-_hjiqoP4Lh643g_cEP/view
When I work with it I get a lot of warnings:
```
mpegtspacketizer mpegtspacketizer.c:2365:mpegts_packetizer_pts_to_ts: Not enough information to calculate proper timestamp
mpegtspacketizer mpegtspacketizer.c:2363:mpegts_packetizer_pts_to_ts: No groups, can't calculate timestamp
tsdemux tsdemux.c:2295:check_pending_buffers: THIS SHOULD NOT HAPPEN !
basetsmux gstbasetsmux.c:1611:gst_base_ts_mux_clip:<mux:sink_1> ignoring DTS going backward
```
But when I use avdec_h264 with nvh264enc everything is fine:
```
gst-launch-1.0 --gst-debug=3 \
filesrc location="source01.ts" ! queue ! tsdemux name=demux \
demux. ! queue max-size-time=0 ! h264parse ! avdec_h264 ! queue ! videoconvert ! nvh264enc bitrate=4196 ! queue ! h264parse ! queue ! mux. \
demux. ! queue max-size-time=0 ! aacparse ! avdec_aac_latm ! queue ! audioconvert ! faac bitrate=196608 ! queue ! aacparse ! queue ! mux. \
mpegtsmux name=mux ! hlssink playlist-length=10 playlist-location="playlist.m3u8" location="fragment%06d.ts"
```
If I try to use nvh264dec and nvh264enc, then video and audio are out of sync:
```
gst-launch-1.0 --gst-debug=3 \
filesrc location="source01.ts" ! queue ! tsdemux name=demux \
demux. ! queue max-size-time=0 ! h264parse ! nvh264dec ! queue ! videoconvert ! nvh264enc bitrate=4196 ! queue ! h264parse ! queue ! mux. \
demux. ! queue max-size-time=0 ! aacparse ! avdec_aac_latm ! queue ! audioconvert ! faac bitrate=196608 ! queue ! aacparse ! queue ! mux. \
mpegtsmux name=mux ! hlssink playlist-length=10 playlist-location="playlist.m3u8" location="fragment%06d.ts"
```
When I try to play the result with nvh264dec in ffplay, warnings are displayed:
```
DTS 324214713 < 324228227 out of order
```
Is it possible to make nvh264dec to handle the source correctly in the way as avdec_h264 does?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1693Hlssink2 support for fileformats with dd-mm-yy2021-11-30T01:31:38ZGuru GovindanHlssink2 support for fileformats with dd-mm-yyThe current hlssink2 plugin has the location property that can be used to provide the ts segment names. example; `location=/some/path/fragment%005d.ts`
Can this be extended to support datetime formats like `location=/some/path/%Y-%m-%dT...The current hlssink2 plugin has the location property that can be used to provide the ts segment names. example; `location=/some/path/fragment%005d.ts`
Can this be extended to support datetime formats like `location=/some/path/%Y-%m-%dT%H-%M-%SZ_%%t.ts` ?
This is currently supported in ffmpeg and it would be really helpful if it can be supported in hlssink2 as well.
Thanks!https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1701avdec_h264 producing sudden PTS jumps in RTSP streams2022-02-14T16:35:14ZArkadiy Kulevavdec_h264 producing sudden PTS jumps in RTSP streamsHello!
I'm receiving a 30 FPS video stream from a RTSP camera via TCP. Every few seconds I experience sudden choppy playback:
`rtspsrc latency=2000 location=rtspt://guest:gstreamer1@sala.ath.cx:5540/Streaming/Channels/101 ! rtph264dep...Hello!
I'm receiving a 30 FPS video stream from a RTSP camera via TCP. Every few seconds I experience sudden choppy playback:
`rtspsrc latency=2000 location=rtspt://guest:gstreamer1@sala.ath.cx:5540/Streaming/Channels/101 ! rtph264depay ! h264parse ! identity name=id_parse ! avdec_h264 ! identity name=id_avdec ! watchdog timeout=10000 ! autovideosink`
I've been trying to wrap my head around this problem for quite a while and finally wrote a python script which shows me the PTS offsets in different parts of the pipeline ([gst.py](/uploads/1480a00860f8be0cbef49f409a4e50ce/gst.py) script attached)
`h264parse` produces a small jump in PTS only in the beginning of the playback, but stays more or less at 0.0333 afterwards (which is consistent with 30 FPS).
`avdec_h264`, however, produces jumps every several seconds:
```
[pts= 0.194 ] pts_parse delta from previous PTS not 0.0333 = 0.193780327
[pts= 0.194 ] pts_avdec delta from previous PTS not 0.0333 = 0.193780327
[pts= 4.31 ] pts_avdec delta from previous PTS not 0.0333 = 0.06699949600000021
[pts= 6.509 ] pts_avdec delta from previous PTS not 0.0333 = 0.06690735799999992
[pts= 8.307 ] pts_avdec delta from previous PTS not 0.0333 = 0.06704043799999937
[pts= 12.306 ] pts_avdec delta from previous PTS not 0.0333 = 0.06695861200000053
[pts= 13.705 ] pts_avdec delta from previous PTS not 0.0333 = 0.06703847100000004
[pts= 20.308 ] pts_avdec delta from previous PTS not 0.0333 = 0.06702971500000032
[pts= 20.642 ] pts_avdec delta from previous PTS not 0.0333 = 0.09999486099999899
[pts= 23.275 ] pts_avdec delta from previous PTS not 0.0333 = 0.06699473599999806
[pts= 24.341 ] pts_avdec delta from previous PTS not 0.0333 = 0.09999411300000105
```
Is it a bug? Or I should write a wrapper script which fixes the PTS after `avdec_h264` myself?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1705tsdemux: mpegts descriptors are parsed fail2022-02-25T09:19:14ZWenlin Hungtsdemux: mpegts descriptors are parsed failSome bitstream has private descriptor tags with invalid descriptor length bytes.
Should skip descriptor parsing which is invalid descriptor length and keep playing,
instead of returning descriptor parsing fail then stop playback.
What v...Some bitstream has private descriptor tags with invalid descriptor length bytes.
Should skip descriptor parsing which is invalid descriptor length and keep playing,
instead of returning descriptor parsing fail then stop playback.
What version of GStreamer you are using: Gstreamer 1.10.4
What operating system you are using (Windows, macOS, Linux): Embedded linuxhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1708[d3d11videosink] GPU Memory Leak2022-03-07T18:28:34ZStian Berglie[d3d11videosink] GPU Memory LeakFor each call to [action signal "draw"](https://gstreamer.freedesktop.org/documentation/d3d11/d3d11videosink.html?gi-language=c#d3d11videosink::draw), the GPU memory is increasing.
I am calling the action
`videoSink.Emit("draw", shared...For each call to [action signal "draw"](https://gstreamer.freedesktop.org/documentation/d3d11/d3d11videosink.html?gi-language=c#d3d11videosink::draw), the GPU memory is increasing.
I am calling the action
`videoSink.Emit("draw", sharedHandle, (uint)2, (ulong)0, (ulong)0);`
on every callback from [signal "begin-draw"](https://gstreamer.freedesktop.org/documentation/d3d11/d3d11videosink.html?gi-language=c#signals).
When commenting out the Emit action, there is no memory leak.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1716Exposing more SRT options, enabling changing some of them during runtime2022-04-29T11:04:43Zmoibrahim-devExposing more SRT options, enabling changing some of them during runtimeHello everyone,
For a project, I need to expose more SRT options than the ones exposed by the srtsrc/srtsink options (https://gstreamer.freedesktop.org/documentation/srt/srtsink.html?gi-language=python#properties)
I tried setting optio...Hello everyone,
For a project, I need to expose more SRT options than the ones exposed by the srtsrc/srtsink options (https://gstreamer.freedesktop.org/documentation/srt/srtsink.html?gi-language=python#properties)
I tried setting options other than that using query parameters in the srturi (for example srt://$IP:$PORT?retransmitalgo=1) but I cannot get those properties using the gstreamer API function get_property($PROPERTY)
Now, my first question would be:
- Is that a limitation in the gstreamer API or in the plugin implementation itself?
If it is a limitation in the plugin implementation, I would consider implementing that by my own
I could think of those different options:
- exposing the SRTSOCKET number to be able to access the socket using the SRT API from the "outside"
- Implementing a way to be able to add more SRT options in a configurable way. For example, using a configuration file, using gst command line options ..
I am asking this here because If I would implement it, it would like to contribute it and therefore implement it in a way that will be accepted by the community.
BRhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1717EOS problem in Gstreamer pipeline with webrtcbin2023-05-16T03:55:03Zoto313EOS problem in Gstreamer pipeline with webrtcbinI am using GStreamer 1.18.4 using GstSharp binding. And I am using following pipeline:
`filesrc name=source location=video.raw ! videoparse width=1920 height=1080 framerate=30/1 format=40 ! videoconvert ! openh264enc ! h264parse ! rtph...I am using GStreamer 1.18.4 using GstSharp binding. And I am using following pipeline:
`filesrc name=source location=video.raw ! videoparse width=1920 height=1080 framerate=30/1 format=40 ! videoconvert ! openh264enc ! h264parse ! rtph264pay ! webrtcbin bundle-policy=max-bundle`
I initialize pipeline with code:
```
_pipeline = (Gst.Pipeline)Gst.Parse.Launch("...");
_pipeline.MessageForward = true;
_pipeline.Bus.AddSignalWatch();
_pipeline.Bus.Message += HandleBusMessage;
_pipeline.SetState(Gst.State.Playing);
_loop.Run();
private void HandleBusMessage(object o, Gst.MessageArgs args) {
var msg = args.Message;
_logger.LogInformation($"Received message: {msg.Type}");
}
```
I need to stop the whole pipeline when filesrc read the whole file. I thought that I just need to handle the EOS message and exit the loop, but no EOS is received from the bus.
I never get EOS message type in HandleBusMessage method, when filesrc read whole file. I only get StreamStatus, Tag, StateChanged message types. I tried set the property "message-forward" on pipeline (I also try to set this property on the webrtcbin),but no Element message type is received in the method (https://gstreamer.freedesktop.org/documentation/gstreamer/gstbin.html?gi-language=c#GstBin:message-forward).
I also tried to remove the webrtcbin from the pipeline. Then the method HandleBusMessage is called also with Element and EOS message type. So the problem must be somehow with the webrtcbin element.
How can I get information that filesrc read whole file and generated EOS? Is webrtc handling event wrong?
Thankshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1742For DRC (container) streams H264parse is not providing updated caps(width/res...2023-07-13T15:57:46Zkudas-swFor DRC (container) streams H264parse is not providing updated caps(width/resolution)For container streams, H264parse overrides width/height values from upstream as per sink_caps, but for DRC streams it provides old resolutions even after resolution changed (Basically upstream is not updating the value in sink_caps), Due...For container streams, H264parse overrides width/height values from upstream as per sink_caps, but for DRC streams it provides old resolutions even after resolution changed (Basically upstream is not updating the value in sink_caps), Due to that DRC container streams are failing.
Check below code snippet of H264parse:
/* sps should give this but upstream overrides */
if (s && gst_structure_has_field (s, "width"))
gst_structure_get_int (s, "width", &width);
else
width = h264parse->width;
if (s && gst_structure_has_field (s, "height"))
gst_structure_get_int (s, "height", &height);
else
height = h264parse->height;
For DRC elementary streams sink_caps will be NULL, so "if (s && gst_structure_has_field (s, "width"))" and "if (s && gst_structure_has_field (s, "height"))" will be false and H264parse will use SPS parsed resolution and that is why it works.
If I take SPS parsed resolution, then it works fine for both DRC container and elementary streams. Below code works fine for both the cases:
```
#if 0
/* sps should give this but upstream overrides */
if (s && gst_structure_has_field (s, "width"))
gst_structure_get_int (s, "width", &width);
else
width = h264parse->width;
if (s && gst_structure_has_field (s, "height"))
gst_structure_get_int (s, "height", &height);
else
height = h264parse->height;
#else
/* do not override with upstream caps, use sps parsed resolution */
width = h264parse->width;
height = h264parse->height;
#endif
```
I am using GStreamer 1.16.3 on Ubuntu 20.04.5https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1761Caught segmentation fault while loading plugin file:.2023-07-13T17:08:15ZDivya Sampath KumarCaught segmentation fault while loading plugin file:.Hello,
I am using Gstreamer version 1.20.3. I encounter this log line in the issue title, but it does not report any library name. It just prints out ".". I also do not see any errors in the Gstreamer logs (it is set to INFO level). Whe...Hello,
I am using Gstreamer version 1.20.3. I encounter this log line in the issue title, but it does not report any library name. It just prints out ".". I also do not see any errors in the Gstreamer logs (it is set to INFO level). Where does the library loading actually happen? I thought it is when element_factory_make() and gst_init_check() is invoked but I am not so sure. Can somebody help me understand the different APIs of Gstreamer where library loading actually happens?
To include more details, I have a code where gstreamer is written in C++ and is being run on Java threads via JNI. Since multiple threads can invoke gst_element_make at the same time, I added locks around the calls to make sure no 2 threads try to load at the same time.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1775SRT simple loopback test pipeline not working_gstreamer_v_1.16.32023-07-18T15:57:01ZSujin KimSRT simple loopback test pipeline not working_gstreamer_v_1.16.3Hi,
Trying to do some SRT loopback test at NVIDIA AGX Orin which is using gstreamer v1.16.3.
However with no errors following pipeline is not working properly. Cannot see any video displays..
Encode : gst-launch-1.0 v4l2src io-mode=4 d...Hi,
Trying to do some SRT loopback test at NVIDIA AGX Orin which is using gstreamer v1.16.3.
However with no errors following pipeline is not working properly. Cannot see any video displays..
Encode : gst-launch-1.0 v4l2src io-mode=4 device=/dev/video0 do-timestamp=true ! 'video/x-raw, width=1920, height=1088, framerate=60/1, format=BGRx' ! nvvidconv ! 'video/x-raw(memory:NVMM), ftrate=4000000 ! h265parse ! mpegtsmux ! srtsink uri=srt://:8888
Decode : gst-launch-1.0 srtsrc uri=srt://127.0.0.1:8888 ! tsparse ! tsdemux ! h265parse ! nvv4l2decoder ! nvvidconv ! queue ! ximagesink
Can any one give me some advises?
Am I using MPEG-TS MUX/DEMUX wrong?
P.S. Loop back test over UDP using udpsink and udpsrc works finehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1788Audio artefacts with interaudiosrc/interaudiosink based pipelines2023-10-09T13:51:33ZHugo MelderAudio artefacts with interaudiosrc/interaudiosink based pipelinesThis is an isolated example of a GStreamer audio issue that exists when using interaudio* elements for pipeline seperation.
* OS: NixOS 23.05.4076.8a4c17493e5c (Stoat) aarch64
* Kernel: 6.1.55
* CPU: Apple M1 Pro (Virt)
* Memory: 8.0Gi...This is an isolated example of a GStreamer audio issue that exists when using interaudio* elements for pipeline seperation.
* OS: NixOS 23.05.4076.8a4c17493e5c (Stoat) aarch64
* Kernel: 6.1.55
* CPU: Apple M1 Pro (Virt)
* Memory: 8.0GiB
* gst-launch-1.0 version: 1.22.5
* GStreamer: 1.22.5
Everything works as normal when starting the first and second pipeline. When we start a new instance of the third pipeline (different port) skipping and audio artefacts start appearing on the first and second UDP stream.
- 1. `audiotestsrc is-live=1 ! capsfilter caps=audio/x-raw,format=S16LE,layout=interleaved,channels=2 ! queue ! interaudiosink channel=audio0`
- 2. `interaudiosrc channel=audio0 ! queue ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! udpsink host=127.0.0.1 port=5000`
- 3. `interaudiosrc channel=audio0 ! queue ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! udpsink host=127.0.0.1 port=5001`
Here is a small demonstration:
![20231007_GStreamer_Interaudio_Demo.mp4](/uploads/8fe06d0c8469ac54e302246c6d0a87e5/gstreamer-audio.mp4)
I experience the same issues on an Nvidia Jetson Nano Development Kit running GStreamer 1.14.x.
Is there something I missed in my pipeline configuration?
Here the isolated test code:
https://gist.github.com/hmelder/4a30bbee0748c48a2263d5233b2f3508https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1791mfvideosrc: how to select the source format?2023-11-13T12:51:28ZMaurizio Buratomfvideosrc: how to select the source format?some webcams supports both mjpeg or h264 stream. when using mfvideosrc how i can select the source format?some webcams supports both mjpeg or h264 stream. when using mfvideosrc how i can select the source format?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1798pitch breaks gapless playback2024-01-30T12:01:30ZSergey Vlasovpitch breaks gapless playback### Describe your issue
For some reason adding `pitch` element to the pipeline breaks gapless playback. When it moves to the next track, sounds disappears after 2 seconds and reappears 5 seconds later.
#### Expected Behavior
No audible ...### Describe your issue
For some reason adding `pitch` element to the pipeline breaks gapless playback. When it moves to the next track, sounds disappears after 2 seconds and reappears 5 seconds later.
#### Expected Behavior
No audible interruptions.
#### Observed Behavior
Sounds disappears after 2 seconds and reappears 5 seconds later.
#### Setup
- **Operating System:** Debian 12
- **Device:** Computer
- **GStreamer Version:** 1.22.0
### Steps to reproduce the bug
```
git clone https://github.com/nulloy/gstreamer-pitch-breaks-gapless
cd gstreamer-pitch-breaks-gapless
make
./test ./sounds/*
```
Wait till it switches to next file.
### How reproducible is the bug?
Always