gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2022-11-10T09:20:48Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/223Leaky queue might set latency max < min2022-11-10T09:20:48ZBugzilla Migration UserLeaky queue might set latency max < min## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#779461)](https://bugzilla.gnome.org/show_bug.cgi?id=779461)**
## Description
The latency calculation for leaky queues doesn't take the minimum latency in acc...## Submitted by Jan Alexander Steffens `@heftig`
**[Link to original bug (#779461)](https://bugzilla.gnome.org/show_bug.cgi?id=779461)**
## Description
The latency calculation for leaky queues doesn't take the minimum latency in account, and as a result can set the maximum latency to lower than the minimum.
GStreamer 1.10.4
Version: 1.10.4https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/222multiqueue: limit queueing to absolute minimum when dealing with single stream2022-11-10T09:20:48ZBugzilla Migration Usermultiqueue: limit queueing to absolute minimum when dealing with single stream## Submitted by Carlos Rafael Giani
**[Link to original bug (#779069)](https://bugzilla.gnome.org/show_bug.cgi?id=779069)**
## Description
Run this test pipeline:
`GST_DEBUG=2,*decodebin3*:9 gst-launch-1.0 concat name=x ! decod...## Submitted by Carlos Rafael Giani
**[Link to original bug (#779069)](https://bugzilla.gnome.org/show_bug.cgi?id=779069)**
## Description
Run this test pipeline:
`GST_DEBUG=2,*decodebin3*:9 gst-launch-1.0 concat name=x ! decodebin3 ! fakesink sync=true silent=false urisourcebin uri=file://$(pwd)/test-1000ms-48000hz.wav ! identity ! x. urisourcebin uri=file://$(pwd)/test-1000ms-48000hz.wav ! identity ! x. -v `
From the logs and the verbose fakesink output you can then see that from the time decodebin3 to the time fakesink see the stream-start event, about 300ms pass.
(You can use audiotestsrc to generate test-1000ms-48000hz.wav like this: `audiotestsrc num-buffers=1 samplesperbuffer=48000 ! "audio/x-raw, rate=48000, format=S16LE, channels=1" ! wavenc ! filesink location=test-1000ms-48000hz.wav`)
multiqueue's max-size-time size is set to a pretty high value (250ms) for a single stream. One improvement that was suggested by thaytan was this:
``` diff
--- a/plugins/elements/gstmultiqueue.c
+++ b/plugins/elements/gstmultiqueue.c
@@ -1279,7 +1279,8 @@ calculate_interleave (GstMultiQueue * mq)
interleave = high - low;
/* Padding of interleave and minimum value */
/* FIXME : Make the minimum time interleave a property */
- interleave = (150 * interleave / 100) + 250 * GST_MSECOND;
+ if (mq->nbqueues > 1)
+ interleave = (150 * interleave / 100) + 250 * GST_MSECOND;
/* Update the stored interleave if:
* * No data has arrived yet (high == low)
```
However, as he said: "I don't want to break a case where we don't have any interleave and it causes a deadlock waiting to request a 2nd pad that would then have allowed interleave."
So I opened this bugreport for discussing this.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/221caps: simplify creates invalid caps with sets or ranges, intersect fails even...2022-11-10T09:20:48ZBugzilla Migration Usercaps: simplify creates invalid caps with sets or ranges, intersect fails even more on them## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#779058)](https://bugzilla.gnome.org/show_bug.cgi?id=779058)**
## Description
intersect() of sets of ranges is broken:
"video/x-h264, framerate=(fraction){ [ 5/1...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#779058)](https://bugzilla.gnome.org/show_bug.cgi?id=779058)**
## Description
intersect() of sets of ranges is broken:
"video/x-h264, framerate=(fraction){ [ 5/1, 240/1 ], [ 3/1, 5/1 ] }"
intersected with itself gives
"video/x-h264, framerate=(fraction){ [ 5/1, 240/1 ], 5/1, { 5/1, [ 3/1, 5/1 ] } }"
There should not be ranges inside sets to begin with, but the intersection result is even worse than that. It's of a different type than the input, and the set contains elements of different types.
And these sets of ranges are caused by simplify():
"video/x-raw, framerate=(fraction) [3/1, 30/1]; video/x-raw, framerate=(fraction) [3/1, 120/1]"
gives simplified
"video/x-raw, framerate=(fraction){ [ 30/1, 60/1 ], [ 3/1, 30/1 ], [ 60/1, 120/1 ] }"https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/220Pipelines don't pre-roll on empty segments after a segment seek.2021-09-24T11:09:53ZBugzilla Migration UserPipelines don't pre-roll on empty segments after a segment seek.## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#778471)](https://bugzilla.gnome.org/show_bug.cgi?id=778471)**
## Description
GstBaseSink doesn't complete the preroll on an empty segment after a segment seek. So the...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#778471)](https://bugzilla.gnome.org/show_bug.cgi?id=778471)**
## Description
GstBaseSink doesn't complete the preroll on an empty segment after a segment seek. So the test case is to do a segment seek, which results in a segment event, immediately followed by a SEGMENT_DONE.. If you have more than one sink in the pipeline, then the other sinks wait in wait_preroll forever. The proposed solution is to just treat the SEGMENT_DONE event like EOS and complete the state change when it is received.
I'm not sure if I understand segment seeks correctly, or if they should just be ignored for prerolling purposes and that an actual buffer or EOS is needed?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/219race in gstpoll detected by TSan2022-11-10T09:20:48ZBugzilla Migration Userrace in gstpoll detected by TSan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778079)](https://bugzilla.gnome.org/show_bug.cgi?id=778079)**
## Description
Created attachment 344776
ThreadSanitizer: data race gstreamer/gst/gstpoll.c:1371 in g...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778079)](https://bugzilla.gnome.org/show_bug.cgi?id=778079)**
## Description
Created attachment 344776
ThreadSanitizer: data race gstreamer/gst/gstpoll.c:1371 in gst_poll_wait
This case detected by the ThreadSanitizer where the set->active_fds GArray is expanded/reallocated while another thread is calling ppoll() on it.
**Attachment 344776**, "ThreadSanitizer: data race gstreamer/gst/gstpoll.c:1371 in gst_poll_wait":
[gstpoll.txt](/uploads/b83ca44d20be07c2c4ad92a644dbeb7f/gstpoll.txt)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/218race in gstpad detected by TSan2022-11-10T09:20:48ZBugzilla Migration Userrace in gstpad detected by TSan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778038)](https://bugzilla.gnome.org/show_bug.cgi?id=778038)**
## Description
Created attachment 344717
ThreadSanitizer: data race gstreamer/gst/gstpad.c:5038 in st...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778038)](https://bugzilla.gnome.org/show_bug.cgi?id=778038)**
## Description
Created attachment 344717
ThreadSanitizer: data race gstreamer/gst/gstpad.c:5038 in store_sticky_event
This case suggested by ThreadSanitizer happens in gst_pad_query_caps_default() when pad flags are read by GST_PAD_IS_PROXY_CAPS (pad), without lock.
**Attachment 344717**, "ThreadSanitizer: data race gstreamer/gst/gstpad.c:5038 in store_sticky_event":
[gstpad.txt](/uploads/961153854175d4b7ec224b84ca1a89fb/gstpad.txt)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/217race in gst_base_src_loop() detected by TSan2022-11-10T09:20:47ZBugzilla Migration Userrace in gst_base_src_loop() detected by TSan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778035)](https://bugzilla.gnome.org/show_bug.cgi?id=778035)**
## Description
Created attachment 344715
ThreadSanitizer: data race gstreamer/gst/gstpad.c:5543 in gs...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778035)](https://bugzilla.gnome.org/show_bug.cgi?id=778035)**
## Description
Created attachment 344715
ThreadSanitizer: data race gstreamer/gst/gstpad.c:5543 in gst_pad_send_event_unchecked
This case suggested by the ThreadSanitizer occurs when updating the flags of the GstPad object while holding the object lock in gstpad.c, and when reading the flags in gst_base_src_loop(), unlocked:
if (G_UNLIKELY (src->priv->flushing || GST_PAD_IS_FLUSHING (pad)))
**Attachment 344715**, "ThreadSanitizer: data race gstreamer/gst/gstpad.c:5543 in gst_pad_send_event_unchecked":
[gstbasesrc.txt](/uploads/7ebb7bc755ed71ef0500d67b62a3c63c/gstbasesrc.txt)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/216race in gstclock detected by TSan2021-09-24T11:09:55ZBugzilla Migration Userrace in gstclock detected by TSan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778032)](https://bugzilla.gnome.org/show_bug.cgi?id=778032)**
## Description
Created attachment 344711
ThreadSanitizer: data race gstreamer/gst/gstclock.c:927 in g...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#778032)](https://bugzilla.gnome.org/show_bug.cgi?id=778032)**
## Description
Created attachment 344711
ThreadSanitizer: data race gstreamer/gst/gstclock.c:927 in gst_clock_adjust_unlocked
ThreadSanitizer reports a race in gst_clock_adjust_unlocked(), because priv->last_time is written while being in a reader seqlock sequence in gst_clock_get_time()
**Attachment 344711**, "ThreadSanitizer: data race gstreamer/gst/gstclock.c:927 in gst_clock_adjust_unlocked":
[gstclock.txt](/uploads/f984f4559533781488ffa09219e2097a/gstclock.txt)
Version: 1.10.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/215streamcollection: Supposed to be immutable but nothing enforcing that2022-11-10T09:20:47ZBugzilla Migration Userstreamcollection: Supposed to be immutable but nothing enforcing that## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#777643)](https://bugzilla.gnome.org/show_bug.cgi?id=777643)**
## Description
Quoting the docs, "Once posted, a GstStreamCollection is immutable.".
There is noth...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#777643)](https://bugzilla.gnome.org/show_bug.cgi?id=777643)**
## Description
Quoting the docs, "Once posted, a GstStreamCollection is immutable.".
There is nothing enforcing this, and at any time new streams can be added to the collection. The addition of streams is not even thread-safe.
I'd suggest using a GstObject flag, or some new boolean, in the stream collection to mark it is "sealed" (which could be done from application code, but will also be done when the collection is stored in a message). And then make sure that adding new streams fails from that point onwards.
Any opinions on which one is nicer?
### See also
* [Bug 777572](https://bugzilla.gnome.org/show_bug.cgi?id=777572)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/214GstStream: Thread-safety concerns and modification/refinement of stream details2022-11-10T09:20:47ZBugzilla Migration UserGstStream: Thread-safety concerns and modification/refinement of stream details## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#777572)](https://bugzilla.gnome.org/show_bug.cgi?id=777572)**
## Description
There seem to be two issues with the GstStream API as is currently.
1) Thread-safet...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#777572)](https://bugzilla.gnome.org/show_bug.cgi?id=777572)**
## Description
There seem to be two issues with the GstStream API as is currently.
1) Thread-safety
Currently the tags/caps/etc are locked with a mutex, which is good and solves the problem of one writer and multiple readers. However there could also be multiple writers according to the documentation (downstream could refine the information). In this case there is a race condition between getting the e.g. caps, modifying them and setting new caps. E.g. downstream could be a parser that is separated from the demuxer with some queue and refines the details from the demuxer.
2) How to decide when to refine specific details
These are actually a group of similar problems.
Consider the case of a demuxer knowing the resolution of a stream but not much more, and downstream a parser that adds more information (e.g. profile). Now at a later time, the resolution of the stream changes. How does the demuxer know whether it can update the resolution (maybe downstream was setting a more accurate resolution?), whether it has to remove other fields (they might not be valid anymore), and especially how would it know which fields were set by itself and which not (other than always remembering everything everywhere).
Another case, similar, would be a demuxer that first provides generic information without resolution. Then a parser adds the resolution. Then the demuxer also knows the resolution from somewhere. How would it decide whether to update it in the caps or not?
### See also
* [Bug 777643](https://bugzilla.gnome.org/show_bug.cgi?id=777643)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/213Playlist Support2022-11-10T09:20:47ZBugzilla Migration UserPlaylist Support## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#776613)](https://bugzilla.gnome.org/show_bug.cgi?id=776613)**
## Description
This is useful to support remote playlists and other formats than a simple
URI/filenam...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#776613)](https://bugzilla.gnome.org/show_bug.cgi?id=776613)**
## Description
This is useful to support remote playlists and other formats than a simple
URI/filename list. totem-plparser is rather small and doesn't do much more
than the name suggests.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/212Handling GST_RESOURCE_ERROR_NOT_FOUND for a stream2021-09-24T11:09:56ZBugzilla Migration UserHandling GST_RESOURCE_ERROR_NOT_FOUND for a stream## Submitted by Arnaud Rebillout
**[Link to original bug (#776495)](https://bugzilla.gnome.org/show_bug.cgi?id=776495)**
## Description
Dear Gst,
In the current version of GStreamer, when playing an audio stream, different erro...## Submitted by Arnaud Rebillout
**[Link to original bug (#776495)](https://bugzilla.gnome.org/show_bug.cgi?id=776495)**
## Description
Dear Gst,
In the current version of GStreamer, when playing an audio stream, different error cases lead to the same error:
GST_RESOURCE_ERROR: GST_RESOURCE_ERROR_NOT_FOUND
Could not resolve server name.
I identified clearly 2 error cases that lead to this error. I need to distinguish between these two error cases, and at the moment GStreamer doesn't provide a reliable way to do this.
----
There are clearly two different error cases that lead to this error message.
1. The network is done. Error reported by gst is as such:
Gst error msg: gst-resource-error-quark:3: Could not resolve server name.
Gst error debug: gstsouphttpsrc.c(1315): gst_soup_http_src_parse_status
(): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Error resolving 'direct.fipradio.fr': Temporary failure in name
resolution (2), URL: http://direct.fipradio.fr/live/fip-midfi.mp3,
Redirect to: (NULL)
2. The server name in the uri is wrong. Error:
Gst error msg: gst-resource-error-quark:3: Could not resolve server name.
Gst error debug: gstsouphttpsrc.c(1315): gst_soup_http_src_parse_status
(): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Error resolving 'direct.fipxxxxx.fr': Name or service not known (2),
URL: http://direct.fipxxxxx.fr/live/fip-midfi.mp3, Redirect to: (NULL)
In the 1st case, I want to keep on retrying, until the network is brought back up. In the 2nd case, I want to stop and report the error to the user. So I need to distinguish between these two error cases.
At the moment, the only way to do that would be to parse the debug string, since it contains the libsoup error string, and this gives me the information I want, as you can see in the debug messages above.
But parsing the debug string is not reliable, the content might change at any time.
This has been reported on the mailing list, and to quote Sebastian Dröge:
> There are ways to add additional information to error messages now, which you could use here. Maybe some kind of "try-again" flag.
----
Best regards,
Arnaud
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/211NULL GstStructures cannot be deserialized2022-11-10T09:20:47ZBugzilla Migration UserNULL GstStructures cannot be deserialized## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#776336)](https://bugzilla.gnome.org/show_bug.cgi?id=776336)**
## Description
When serializing a nested structure where a substructure is NULL, it will be serializes as...## Submitted by Stefan Kost `@ensonic`
**[Link to original bug (#776336)](https://bugzilla.gnome.org/show_bug.cgi?id=776336)**
## Description
When serializing a nested structure where a substructure is NULL, it will be serializes as:
sub=(structure)"\(NULL\)"
This cannot be serialized. Do we want to add support for (NULL) in the structure parser?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/210tracerrecord: Enable tracer logging when a tracer record is created2022-11-10T09:20:47ZBugzilla Migration Usertracerrecord: Enable tracer logging when a tracer record is created## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#776320)](https://bugzilla.gnome.org/show_bug.cgi?id=776320)**
## Description
See commit message## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#776320)](https://bugzilla.gnome.org/show_bug.cgi?id=776320)**
## Description
See commit messagehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/209validate: Deadlock when doing PAUSE->PLAYING dance on BUFFERING messages whil...2022-11-10T09:20:47ZBugzilla Migration Uservalidate: Deadlock when doing PAUSE->PLAYING dance on BUFFERING messages while transcoding in filesink## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#775993)](https://bugzilla.gnome.org/show_bug.cgi?id=775993)**
## Description
Created attachment 341827
validate: transcode: No buffering handling when the si...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#775993)](https://bugzilla.gnome.org/show_bug.cgi?id=775993)**
## Description
Created attachment 341827
validate: transcode: No buffering handling when the sink is not synced on the clock
In gst-validate-transcoder-1.0 we respect do the BUFFERING message and PAUSE the pipeline when starting buffering and go back to PLAYING when this is done, and that even if the sink is not synchronized on the clock.
Validate test: validate.http.transcode.to_vorbis_and_vp8_in_webm.raw_video_mkv
In racy/rare conditions we get a deadlock when `prerolling` going to PAUSED with the following stack trace:
```
Thread 7 (Thread 0x7fbb6a020700 (LWP 21809)):
#0 0x00007fbb7225db7d in poll () at /lib64/libc.so.6
#1 0x00007fbb7257218c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2 0x00007fbb7257229c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3 0x00007fbb725722d9 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4 0x00007fbb725988e5 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5 0x00007fbb73bb861a in start_thread () at /lib64/libpthread.so.0
#6 0x00007fbb722695fd in clone () at /lib64/libc.so.6
Thread 6 (Thread 0x7fbb541e8700 (LWP 21847)):
#0 0x00007fbb72263809 in syscall () at /lib64/libc.so.6
#1 0x00007fbb725b68df in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fbb5649e455 in gst_queue2_wait_free_space (queue=0x7fbb4c03c000) at gstqueue2.c:1826
#3 0x00007fbb564a2d7e in gst_queue2_chain_buffer_or_buffer_list (queue=0x7fbb4c03c000, item=0x7fbb4c0413b0, item_type=GST_QUEUE2_ITEM_TYPE_BUFFER) at gstqueue2.c:2754
#4 0x00007fbb564a3341 in gst_queue2_chain (pad=0x7fbb4c0364f0, parent=0x7fbb4c03c000, buffer=0x7fbb4c0413b0) at gstqueue2.c:2815
#5 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb4c0364f0, parent=0x7fbb4c03c000, buffer=0x7fbb4c0413b0) at gst-validate-pad-monitor.c:2121
#6 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb4c0364f0, type=4112, data=0x7fbb4c0413b0) at gstpad.c:4203
#7 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x125f030, type=4112, data=0x7fbb4c0413b0) at gstpad.c:4455
#8 0x00007fbb7366fff6 in gst_pad_push (pad=0x125f030, buffer=0x7fbb4c0413b0) at gstpad.c:4574
#9 0x00007fbb564ad065 in gst_type_find_element_chain (pad=0x125edf0, parent=0x127c090, buffer=0x7fbb4c0413b0) at gsttypefindelement.c:896
#10 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x125edf0, parent=0x127c090, buffer=0x7fbb4c0413b0) at gst-validate-pad-monitor.c:2121
#11 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x125edf0, type=4112, data=0x7fbb4c0413b0) at gstpad.c:4203
#12 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x125e970, type=4112, data=0x7fbb4c0413b0) at gstpad.c:4455
#13 0x00007fbb7366fff6 in gst_pad_push (pad=0x125e970, buffer=0x7fbb4c0413b0) at gstpad.c:4574
#14 0x00007fbb7397b1b3 in gst_base_src_loop (pad=0x125e970) at gstbasesrc.c:2855
#15 0x00007fbb736aa69f in gst_task_func (task=0x127d170) at gsttask.c:334
#16 0x00007fbb736ab858 in default_func (tdata=0x1272ec0, pool=0x1013910) at gsttaskpool.c:68
#17 0x00007fbb7259927e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#18 0x00007fbb725988e5 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#19 0x00007fbb73bb861a in start_thread () at /lib64/libpthread.so.0
#20 0x00007fbb722695fd in clone () at /lib64/libc.so.6
Thread 5 (Thread 0x7fbb537cd700 (LWP 21853)):
#0 0x00007fbb72263809 in syscall () at /lib64/libc.so.6
#1 0x00007fbb725b68df in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fbb73994ecb in gst_data_queue_push (queue=0x7fbb4c040480, item=0x7fbb4417d440) at gstdataqueue.c:520
#3 0x00007fbb5648bcea in gst_multi_queue_chain (pad=0x7fbb4c0376f0, parent=0x7fbb44044090, buffer=0x7fbb4c018ab0) at gstmultiqueue.c:2112
#4 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb4c0376f0, parent=0x7fbb44044090, buffer=0x7fbb4c018ab0) at gst-validate-pad-monitor.c:2121
#5 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb4c0376f0, type=4112, data=0x7fbb4c018ab0) at gstpad.c:4203
#6 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb4c037270, type=4112, data=0x7fbb4c018ab0) at gstpad.c:4455
#7 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb4c037270, buffer=0x7fbb4c018ab0) at gstpad.c:4574
#8 0x00007fbb5621bd6b in gst_matroska_demux_parse_blockgroup_or_simpleblock (demux=0x7fbb4403c130, ebml=0x7fbb537cc4f0, cluster_time=1333, cluster_offset=4609563, is_simpleblock=1) at matroska-demux.c:3842
#9 0x00007fbb5621e35b in gst_matroska_demux_parse_id (demux=0x7fbb4403c130, id=163, length=115204, needed=4) at matroska-demux.c:4507
#10 0x00007fbb5622023d in gst_matroska_demux_chain (pad=0x7fbb4c036df0, parent=0x7fbb4403c130, buffer=0x0) at matroska-demux.c:4889
#11 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb4c036df0, parent=0x7fbb4403c130, buffer=0x7fbb4c041080) at gst-validate-pad-monitor.c:2121
#12 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb4c036df0, type=4112, data=0x7fbb4c041080) at gstpad.c:4203
#13 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x125fdb0, type=4112, data=0x7fbb4c041080) at gstpad.c:4455
#14 0x00007fbb7366fff6 in gst_pad_push (pad=0x125fdb0, buffer=0x7fbb4c041080) at gstpad.c:4574
#15 0x00007fbb564ad065 in gst_type_find_element_chain (pad=0x125fb70, parent=0x127c810, buffer=0x7fbb4c041080) at gsttypefindelement.c:896
#16 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x125fb70, parent=0x127c810, buffer=0x7fbb4c041080) at gst-validate-pad-monitor.c:2121
#17 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x125fb70, type=4112, data=0x7fbb4c041080) at gstpad.c:4203
#18 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x125ca30, type=4112, data=0x7fbb4c041080) at gstpad.c:4455
#19 0x00007fbb7366fff6 in gst_pad_push (pad=0x125ca30, buffer=0x7fbb4c041080) at gstpad.c:4574
#20 0x00007fbb73651501 in gst_proxy_pad_chain_default (pad=0x1236a10, parent=0x7fbb4c034140, buffer=0x7fbb4c041080) at gstghostpad.c:126
#21 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x1236a10, type=4112, data=0x7fbb4c041080) at gstpad.c:4203
#22 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb4c036730, type=4112, data=0x7fbb4c041080) at gstpad.c:4455
#23 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb4c036730, buffer=0x7fbb4c041080) at gstpad.c:4574
#24 0x00007fbb564a3931 in gst_queue2_push_one (queue=0x7fbb4c03c000) at gstqueue2.c:2908
#25 0x00007fbb564a4486 in gst_queue2_loop (pad=0x7fbb4c036730) at gstqueue2.c:3030
#26 0x00007fbb736aa69f in gst_task_func (task=0x127d710) at gsttask.c:334
#27 0x00007fbb736ab858 in default_func (tdata=0x7fbb4c01d130, pool=0x1013910) at gsttaskpool.c:68
#28 0x00007fbb7259927e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#29 0x00007fbb725988e5 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#30 0x00007fbb73bb861a in start_thread () at /lib64/libpthread.so.0
#31 0x00007fbb722695fd in clone () at /lib64/libc.so.6
Thread 4 (Thread 0x7fbb529ca700 (LWP 21860)):
#0 0x00007fbb72263809 in syscall () at /lib64/libc.so.6
#1 0x00007fbb725b68df in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fbb56494a87 in gst_queue_chain_buffer_or_list (pad=0x7fbb48024050, parent=0x7fbb4800c4b0, obj=0x7fbb44048a00, is_list=0) at gstqueue.c:1222
#3 0x00007fbb56495226 in gst_queue_chain (pad=0x7fbb48024050, parent=0x7fbb4800c4b0, buffer=0x7fbb44048a00) at gstqueue.c:1320
#4 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48024050, parent=0x7fbb4800c4b0, buffer=0x7fbb44048a00) at gst-validate-pad-monitor.c:2121
#5 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48024050, type=4112, data=0x7fbb44048a00) at gstpad.c:4203
#6 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb480041e0, type=4112, data=0x7fbb44048a00) at gstpad.c:4455
#7 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb480041e0, buffer=0x7fbb44048a00) at gstpad.c:4574
#8 0x00007fbb73651501 in gst_proxy_pad_chain_default (pad=0x1237640, parent=0x12300d0, buffer=0x7fbb44048a00) at gstghostpad.c:126
#9 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x1237640, type=4112, data=0x7fbb44048a00) at gstpad.c:4203
#10 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x12373d0, type=4112, data=0x7fbb44048a00) at gstpad.c:4455
#11 0x00007fbb7366fff6 in gst_pad_push (pad=0x12373d0, buffer=0x7fbb44048a00) at gstpad.c:4574
#12 0x00007fbb73651501 in gst_proxy_pad_chain_default (pad=0x125dcb0, parent=0x12373d0, buffer=0x7fbb44048a00) at gstghostpad.c:126
#13 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x125dcb0, type=4112, data=0x7fbb44048a00) at gstpad.c:4203
#14 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb44006310, type=4112, data=0x7fbb44048a00) at gstpad.c:4455
#15 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb44006310, buffer=0x7fbb44048a00) at gstpad.c:4574
#16 0x00007fbb73651501 in gst_proxy_pad_chain_default (pad=0x125d5c0, parent=0x7fbb44006310, buffer=0x7fbb44048a00) at gstghostpad.c:126
#17 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x125d5c0, type=4112, data=0x7fbb44048a00) at gstpad.c:4203
#18 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb4c037930, type=4112, data=0x7fbb44048a00) at gstpad.c:4455
#19 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb4c037930, buffer=0x7fbb44048a00) at gstpad.c:4574
#20 0x00007fbb564892a7 in gst_single_queue_push_one (mq=0x7fbb44044090, sq=0x7fbb44043ab0, object=0x7fbb44048a00, allow_drop=0x7fbb529c9cf4) at gstmultiqueue.c:1611
#21 0x00007fbb5648ad2f in gst_multi_queue_loop (pad=0x7fbb4c037930) at gstmultiqueue.c:1923
#22 0x00007fbb736aa69f in gst_task_func (task=0x127dcb0) at gsttask.c:334
#23 0x00007fbb736ab858 in default_func (tdata=0x7fbb44004910, pool=0x1013910) at gsttaskpool.c:68
#24 0x00007fbb7259927e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#25 0x00007fbb725988e5 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#26 0x00007fbb73bb861a in start_thread () at /lib64/libpthread.so.0
#27 0x00007fbb722695fd in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7fbb51610700 (LWP 21865)):
#0 0x00007fbb72263809 in syscall () at /lib64/libc.so.6
#1 0x00007fbb725b68df in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fbb56494a87 in gst_queue_chain_buffer_or_list (pad=0x7fbb480084c0, parent=0x7fbb4800c1c0, obj=0x7fbb4c018230, is_list=0) at gstqueue.c:1222
#3 0x00007fbb56495226 in gst_queue_chain (pad=0x7fbb480084c0, parent=0x7fbb4800c1c0, buffer=0x7fbb4c018230) at gstqueue.c:1320
#4 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb480084c0, parent=0x7fbb4800c1c0, buffer=0x7fbb4c018230) at gst-validate-pad-monitor.c:2121
#5 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb480084c0, type=4112, data=0x7fbb4c018230) at gstpad.c:4203
#6 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb48009000, type=4112, data=0x7fbb4c018230) at gstpad.c:4455
#7 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb48009000, buffer=0x7fbb4c018230) at gstpad.c:4574
#8 0x00007fbb739851b0 in gst_base_transform_chain (pad=0x7fbb48008dc0, parent=0x7fbb480122b0, buffer=0x7fbb4c018230) at gstbasetransform.c:2378
#9 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48008dc0, parent=0x7fbb480122b0, buffer=0x7fbb4c018230) at gst-validate-pad-monitor.c:2121
#10 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48008dc0, type=4112, data=0x7fbb4c018230) at gstpad.c:4203
#11 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb480096c0, type=4112, data=0x7fbb4c018230) at gstpad.c:4455
#12 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb480096c0, buffer=0x7fbb4c018230) at gstpad.c:4574
#13 0x00007fbb566d5e39 in gst_stream_combiner_chain (pad=0x7fbb48025b50, parent=0x1270bf0, buf=0x7fbb4c018230) at gststreamcombiner.c:111
#14 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48025b50, parent=0x1270bf0, buffer=0x7fbb4c018230) at gst-validate-pad-monitor.c:2121
#15 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48025b50, type=4112, data=0x7fbb4c018230) at gstpad.c:4203
#16 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb48024dd0, type=4112, data=0x7fbb4c018230) at gstpad.c:4455
#17 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb48024dd0, buffer=0x7fbb4c018230) at gstpad.c:4574
#18 0x00007fbb740dbe95 in gst_video_encoder_finish_frame (encoder=0x7fbb480403e0, frame=0x0) at gstvideoencoder.c:2204
#19 0x00007fbb51fbd2e1 in gst_vpx_enc_process (encoder=0x7fbb480403e0) at gstvpxenc.c:1732
#20 0x00007fbb51fbdf63 in gst_vpx_enc_handle_frame (video_encoder=0x7fbb480403e0, frame=0x7fbb4c0417f0) at gstvpxenc.c:1921
#21 0x00007fbb740d903a in gst_video_encoder_chain (pad=0x7fbb48025010, parent=0x7fbb480403e0, buf=0x7fbb4c041900) at gstvideoencoder.c:1461
#22 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48025010, parent=0x7fbb480403e0, buffer=0x7fbb4c041900) at gst-validate-pad-monitor.c:2121
#23 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48025010, type=4112, data=0x7fbb4c041900) at gstpad.c:4203
#24 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb480422a0, type=4112, data=0x7fbb4c041900) at gstpad.c:4455
#25 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb480422a0, buffer=0x7fbb4c041900) at gstpad.c:4574
#26 0x00007fbb739851b0 in gst_base_transform_chain (pad=0x7fbb48042060, parent=0x7fbb480125f0, buffer=0x7fbb4c041900) at gstbasetransform.c:2378
#27 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48042060, parent=0x7fbb480125f0, buffer=0x7fbb4c041900) at gst-validate-pad-monitor.c:2121
#28 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48042060, type=4112, data=0x7fbb4c041900) at gstpad.c:4203
#29 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb48052710, type=4112, data=0x7fbb4c041900) at gstpad.c:4455
#30 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb48052710, buffer=0x7fbb4c041900) at gstpad.c:4574
#31 0x00007fbb51615c7b in gst_video_rate_flush_prev (videorate=0x7fbb480570d0, duplicate=0, next_intime=100000000) at gstvideorate.c:707
#32 0x00007fbb51619109 in gst_video_rate_transform_ip (trans=0x7fbb480570d0, buffer=0x7fbb4c018340) at gstvideorate.c:1434
#33 0x00007fbb7398489f in default_generate_output (trans=0x7fbb480570d0, outbuf=0x7fbb5160f068) at gstbasetransform.c:2184
#34 0x00007fbb73984fe0 in gst_base_transform_chain (pad=0x7fbb480524d0, parent=0x7fbb480570d0, buffer=0x7fbb4c018340) at gstbasetransform.c:2342
#35 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb480524d0, parent=0x7fbb480570d0, buffer=0x7fbb4c018340) at gst-validate-pad-monitor.c:2121
#36 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb480524d0, type=4112, data=0x7fbb4c018340) at gstpad.c:4203
#37 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb480434a0, type=4112, data=0x7fbb4c018340) at gstpad.c:4455
#38 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb480434a0, buffer=0x7fbb4c018340) at gstpad.c:4574
#39 0x00007fbb739851b0 in gst_base_transform_chain (pad=0x7fbb48043260, parent=0x7fbb4804f610, buffer=0x7fbb4c018340) at gstbasetransform.c:2378
#40 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48043260, parent=0x7fbb4804f610, buffer=0x7fbb4c018340) at gst-validate-pad-monitor.c:2121
#41 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48043260, type=4112, data=0x7fbb4c018340) at gstpad.c:4203
#42 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb48043020, type=4112, data=0x7fbb4c018340) at gstpad.c:4455
#43 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb48043020, buffer=0x7fbb4c018340) at gstpad.c:4574
#44 0x00007fbb739851b0 in gst_base_transform_chain (pad=0x7fbb48042de0, parent=0x7fbb4804cc50, buffer=0x7fbb4c018340) at gstbasetransform.c:2378
#45 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48042de0, parent=0x7fbb4804cc50, buffer=0x7fbb4c018340) at gst-validate-pad-monitor.c:2121
#46 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48042de0, type=4112, data=0x7fbb4c018340) at gstpad.c:4203
#47 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb48042ba0, type=4112, data=0x7fbb4c018340) at gstpad.c:4455
#48 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb48042ba0, buffer=0x7fbb4c018340) at gstpad.c:4574
#49 0x00007fbb739851b0 in gst_base_transform_chain (pad=0x7fbb48042960, parent=0x7fbb4804b0d0, buffer=0x7fbb4c018340) at gstbasetransform.c:2378
#50 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48042960, parent=0x7fbb4804b0d0, buffer=0x7fbb4c018340) at gst-validate-pad-monitor.c:2121
#51 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48042960, type=4112, data=0x7fbb4c018340) at gstpad.c:4203
#52 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb48052dd0, type=4112, data=0x7fbb4c018340) at gstpad.c:4455
#53 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb48052dd0, buffer=0x7fbb4c018340) at gstpad.c:4574
#54 0x00007fbb566d6ba4 in gst_stream_splitter_chain (pad=0x7fbb48009b40, parent=0x113f8c0, buf=0x7fbb4c018340) at gststreamsplitter.c:140
#55 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48009b40, parent=0x113f8c0, buffer=0x7fbb4c018340) at gst-validate-pad-monitor.c:2121
#56 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48009b40, type=4112, data=0x7fbb4c018340) at gstpad.c:4203
#57 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb48024290, type=4112, data=0x7fbb4c018340) at gstpad.c:4455
#58 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb48024290, buffer=0x7fbb4c018340) at gstpad.c:4574
#59 0x00007fbb56495393 in gst_queue_push_one (queue=0x7fbb4800c4b0) at gstqueue.c:1359
#60 0x00007fbb564961ab in gst_queue_loop (pad=0x7fbb48024290) at gstqueue.c:1506
#61 0x00007fbb736aa69f in gst_task_func (task=0x7fbb4403e290) at gsttask.c:334
#62 0x00007fbb736ab858 in default_func (tdata=0x7fbb48001c60, pool=0x1013910) at gsttaskpool.c:68
#63 0x00007fbb7259927e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#64 0x00007fbb725988e5 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#65 0x00007fbb73bb861a in start_thread () at /lib64/libpthread.so.0
#66 0x00007fbb722695fd in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7fbb50e0f700 (LWP 21868)):
#0 0x00007fbb72263809 in syscall () at /lib64/libc.so.6
#1 0x00007fbb725b68df in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fbb73966fab in gst_base_sink_wait_preroll (sink=0x1239ea0) at gstbasesink.c:2266
#3 0x00007fbb739674e0 in gst_base_sink_do_preroll (sink=0x1239ea0, obj=0x7fbb44049990) at gstbasesink.c:2360
#4 0x00007fbb73967dea in gst_base_sink_do_sync (basesink=0x1239ea0, obj=0x7fbb44049990, late=0x7fbb50e0e19c, step_end=0x7fbb50e0e198) at gstbasesink.c:2562
#5 0x00007fbb7396c47a in gst_base_sink_chain_unlocked (basesink=0x1239ea0, pad=0x125e070, obj=0x7fbb44049990, is_list=0) at gstbasesink.c:3518
#6 0x00007fbb7396d339 in gst_base_sink_chain_main (basesink=0x1239ea0, pad=0x125e070, obj=0x7fbb44049990, is_list=0) at gstbasesink.c:3674
#7 0x00007fbb7396d4a8 in gst_base_sink_chain (pad=0x125e070, parent=0x1239ea0, buf=0x7fbb44049990) at gstbasesink.c:3703
#8 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x125e070, parent=0x1239ea0, buffer=0x7fbb44049990) at gst-validate-pad-monitor.c:2121
#9 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x125e070, type=4112, data=0x7fbb44049990) at gstpad.c:4203
#10 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x1236050, type=4112, data=0x7fbb44049990) at gstpad.c:4455
#11 0x00007fbb7366fff6 in gst_pad_push (pad=0x1236050, buffer=0x7fbb44049990) at gstpad.c:4574
#12 0x00007fbb73651501 in gst_proxy_pad_chain_default (pad=0x125c0f0, parent=0x1236050, buffer=0x7fbb44049990) at gstghostpad.c:126
#13 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x125c0f0, type=4112, data=0x7fbb44049990) at gstpad.c:4203
#14 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x125e2b0, type=4112, data=0x7fbb44049990) at gstpad.c:4455
#15 0x00007fbb7366fff6 in gst_pad_push (pad=0x125e2b0, buffer=0x7fbb44049990) at gstpad.c:4574
#16 0x00007fbb5620b365 in gst_ebml_write_flush_cache (ebml=0x11fa8e0, is_keyframe=0, timestamp=0) at ebml-write.c:271
#17 0x00007fbb5620c829 in gst_ebml_write_header (ebml=0x11fa8e0, doctype=0x7fbb5624f4a0 "webm", version=2) at ebml-write.c:940
#18 0x00007fbb562369f6 in gst_matroska_mux_start (mux=0x1224230) at matroska-mux.c:2768
#19 0x00007fbb56239d8a in gst_matroska_mux_handle_buffer (pads=0x126c0d0, data=0x7fbb48007400, buf=0x7fbb4c041a10, user_data=0x1224230) at matroska-mux.c:3794
#20 0x00007fbb739916f4 in gst_collect_pads_default_collected (pads=0x126c0d0, user_data=0x0) at gstcollectpads.c:1567
#21 0x00007fbb73990f02 in gst_collect_pads_check_collected (pads=0x126c0d0) at gstcollectpads.c:1368
#22 0x00007fbb73992fa9 in gst_collect_pads_chain (pad=0x7fbb48008040, parent=0x1224230, buffer=0x7fbb4c041a10) at gstcollectpads.c:2216
#23 0x00007fbb75208f13 in gst_validate_pad_monitor_chain_func (pad=0x7fbb48008040, parent=0x1224230, buffer=0x7fbb4c041a10) at gst-validate-pad-monitor.c:2121
#24 0x00007fbb7366eb35 in gst_pad_chain_data_unchecked (pad=0x7fbb48008040, type=4112, data=0x7fbb4c041a10) at gstpad.c:4203
#25 0x00007fbb7366f8ce in gst_pad_push_data (pad=0x7fbb48008700, type=4112, data=0x7fbb4c041a10) at gstpad.c:4455
#26 0x00007fbb7366fff6 in gst_pad_push (pad=0x7fbb48008700, buffer=0x7fbb4c041a10) at gstpad.c:4574
#27 0x00007fbb56495393 in gst_queue_push_one (queue=0x7fbb4800c1c0) at gstqueue.c:1359
#28 0x00007fbb564961ab in gst_queue_loop (pad=0x7fbb48008700) at gstqueue.c:1506
#29 0x00007fbb736aa69f in gst_task_func (task=0x7fbb4403e170) at gsttask.c:334
#30 0x00007fbb736ab858 in default_func (tdata=0x7fbb48003480, pool=0x1013910) at gsttaskpool.c:68
#31 0x00007fbb7259927e in g_thread_pool_thread_proxy () at /lib64/libglib-2.0.so.0
#32 0x00007fbb725988e5 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#33 0x00007fbb73bb861a in start_thread () at /lib64/libpthread.so.0
#34 0x00007fbb722695fd in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7fbb75635800 (LWP 21777)):
#0 0x00007fbb7225db7d in poll () at /lib64/libc.so.6
#1 0x00007fbb7257218c in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2 0x00007fbb72572512 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3 0x0000000000405b73 in main (argc=3, argv=0x7ffc6bc97b88) at gst-validate-transcoding.c:967
```
Going to PAUSED when BUFFERING on a pipeline that is not sync on the clock is useless so I attach here a patch that removes that behaviour in -validate but this case should still work and defenitely not deadlock.
**Patch 341827**, "validate: transcode: No buffering handling when the sink is not synced on the clock":
[0001-validate-transcode-No-buffering-handling-when-the-si.patch](/uploads/6d50d9759f267a9894e907474759fc81/0001-validate-transcode-No-buffering-handling-when-the-si.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/208queue2: handle overwriting the current range correctly2021-09-24T11:09:57ZBugzilla Migration Userqueue2: handle overwriting the current range correctly## Submitted by Michael Olbrich `@mol`
**[Link to original bug (#774831)](https://bugzilla.gnome.org/show_bug.cgi?id=774831)**
## Description
Created attachment 340491
queue2: handle overwriting the current range correctly
Th...## Submitted by Michael Olbrich `@mol`
**[Link to original bug (#774831)](https://bugzilla.gnome.org/show_bug.cgi?id=774831)**
## Description
Created attachment 340491
queue2: handle overwriting the current range correctly
This basically reverts b3802f7a9e7988901367196dd3dc45cf4053d850 ("queue2:
fix crash deleting current region for small ring buffers") and fixes the
original problem correctly.
Ignoring the current range while checking which ranges must be truncated or
removed is incorrect. With just one range, it it possible, that the offset
of the current range must be adjusted because the corresponding data will
be overwritten.
To fix the original problem, the current range is never removed. Instead it
may be truncated to zero length before the new data is appended.
Note: The test-case from the original commit still works and my test-case (seeking backwards to a position in the current range that was overwritten but not removed from the range) works again. But I'm not 100% sure I got all possible corner cases, so someone with better understanding of queue2 should probably double check this.
**Patch 340491**, "queue2: handle overwriting the current range correctly":
[0001-queue2-handle-overwriting-the-current-range-correctl.patch](/uploads/bcd50b8ab4b3d7ae0fb906e0481bfa95/0001-queue2-handle-overwriting-the-current-range-correctl.patch)
### See also
* [Bug 767688](https://bugzilla.gnome.org/show_bug.cgi?id=767688)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/207Need new error code for signal loss2022-11-10T09:20:47ZBugzilla Migration UserNeed new error code for signal loss## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#774667)](https://bugzilla.gnome.org/show_bug.cgi?id=774667)**
## Description
+++ This bug was initially created as a clone of [Bug 774629](https://bugzilla.gnome.or...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#774667)](https://bugzilla.gnome.org/show_bug.cgi?id=774667)**
## Description
+++ This bug was initially created as a clone of [Bug 774629](https://bugzilla.gnome.org/show_bug.cgi?id=774629) +++
Tim-Philipp Müller changed [bug 774629](https://bugzilla.gnome.org/show_bug.cgi?id=774629)
What Removed Added
CC t.i.m@zen.co.uk
Comment # 5 on [bug 774629](https://bugzilla.gnome.org/show_bug.cgi?id=774629) from Tim-Philipp Müller
I think we should be making use of the new _WITH_DETAILS API for
error/warning/info messages here, since the error code itself is really quite
meaningless and the app can't rely on the error string (might be translated in
future) or the debug string (should not be looked at).
Or add a new error code for it.
Or use a different kind of message (maybe progress messages?)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/206streamcollection: Add gst_stream_collection_get_stream_list api2023-02-03T20:53:50ZBugzilla Migration Userstreamcollection: Add gst_stream_collection_get_stream_list api## Submitted by Wonchul Lee
**[Link to original bug (#774602)](https://bugzilla.gnome.org/show_bug.cgi?id=774602)**
## Description
Application seems to useful if the streamcollection provide a list of streams according to the type o...## Submitted by Wonchul Lee
**[Link to original bug (#774602)](https://bugzilla.gnome.org/show_bug.cgi?id=774602)**
## Description
Application seems to useful if the streamcollection provide a list of streams according to the type of stream when it counts number of audio/video/text streams or selecting one.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/205gdp: parsing GstStream in stream-start event issue2022-11-10T09:20:47ZBugzilla Migration Usergdp: parsing GstStream in stream-start event issue## Submitted by Nicolas Huet
**[Link to original bug (#774412)](https://bugzilla.gnome.org/show_bug.cgi?id=774412)**
## Description
Created attachment 339808
mpegts gdp test file
https://cgit.freedesktop.org/gstreamer/gstream...## Submitted by Nicolas Huet
**[Link to original bug (#774412)](https://bugzilla.gnome.org/show_bug.cgi?id=774412)**
## Description
Created attachment 339808
mpegts gdp test file
https://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=63f6f05d66537877365a1099ac176dc3afbb9f6b introduced variable GstStream. This is added in the stream-start event by tsdemux.
First, running the command:
gst-launch-1.0 -v filesrc location= mpegts.gdp ! gdpdepay ! tsdemux ! identity silent=false ! ac3parse ! gdppay ! filesink location= eac3.gdp
We can see the variable stream (stream=(GstStream)"\(GstStream\)\ stream1"):
E (type: stream-start (10254), GstEventStreamStart, stream-id=(string)fd91ddf0b44530850315c637f356514d:1282/000000e6, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, stream=(GstStream)"\(GstStream\)\ stream1", group-id=(uint)0;) 0x75b02450
Then trying to gdpdepay eac3.gdp:
gst-launch-1.0 -v --gst-debug=*gdp*:5 filesrc location= eac3.gdp ! gdpdepay ! fakesink silent=false
We have:
Could not parse payload string: GstEventStreamStart, stream-id=(string)fd91ddf0b44530850315c637f356514d:1282/000000e6, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, stream=(GstStream)"\(GstStream\)\ stream1", group-id=(uint)0;
Removing the stream variable makes it working.
It seems that something is missing in gstvalue or gststructure ?
**Attachment 339808**, "mpegts gdp test file":
[mpegts.gdp](/uploads/147a4c6890f6d554394603c99616bc2e/mpegts.gdp)
Version: 1.10.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/204GstStream: need API to deactivate streams2022-11-10T09:20:47ZBugzilla Migration UserGstStream: need API to deactivate streams## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774321)](https://bugzilla.gnome.org/show_bug.cgi?id=774321)**
## Description
+++ This bug was initially created as a clone of [Bug 646638](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774321)](https://bugzilla.gnome.org/show_bug.cgi?id=774321)**
## Description
+++ This bug was initially created as a clone of [Bug 646638](https://bugzilla.gnome.org/show_bug.cgi?id=646638) +++
We now have new API to select and thus also deselect streams in form of the SELECT_STREAMS event.
We also want API that can be used to deactivate streams, which goes one step further, and would instruct the demuxer to not even read/demux/expose it.
This could be used for example in a thumbnailing application to deactivate decoding of all audio streams, or in GES which uses separate sources/decodebins for audio/video from the same input file.
Question is if we only want to be able to deactivate streams, or if we also want to allow re-activating them again later at runtime.