GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T11:10:01Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/197basetransform: Fix race when toggling passthrough2021-09-24T11:10:01ZBugzilla Migration Userbasetransform: Fix race when toggling passthrough## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773093)](https://bugzilla.gnome.org/show_bug.cgi?id=773093)**
## Description
This fixes a race where priv->passthrough is changed from TRUE to FALSE
while processin...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773093)](https://bugzilla.gnome.org/show_bug.cgi?id=773093)**
## Description
This fixes a race where priv->passthrough is changed from TRUE to FALSE
while processing a buffer and we end up passing a non-writable buffer to
transform_ip(). More precicely if passthrough is changed just after
prepare_output_buffer() is finished.
Since priv->passthrough and other priv variables are accessed throughout
the chain function a lock is introduced and held while processing the
buffer, but released before pushing downstream. Since sub-classes may
call is_passthrough() and similar functions during for instance
transform_ip() a recursive lock is needed.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/198element: bin: add flag to skip uniqueness checking2021-09-24T11:10:01ZBugzilla Migration Userelement: bin: add flag to skip uniqueness checking## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773095)](https://bugzilla.gnome.org/show_bug.cgi?id=773095)**
## Description
If a bin/element is sure that its children has unique name then skipping
the uniqness c...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773095)](https://bugzilla.gnome.org/show_bug.cgi?id=773095)**
## Description
If a bin/element is sure that its children has unique name then skipping
the uniqness check may be a significant optimization if there is a lot of
children.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/199queue: Fix race when calculating cur_level.time2021-09-24T11:10:00ZBugzilla Migration Userqueue: Fix race when calculating cur_level.time## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773096)](https://bugzilla.gnome.org/show_bug.cgi?id=773096)**
## Description
On the first buffer, it's possible that sink_segment is set but
src_segment has not bee...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773096)](https://bugzilla.gnome.org/show_bug.cgi?id=773096)**
## Description
On the first buffer, it's possible that sink_segment is set but
src_segment has not been set yet. If this is the case, we should not
calculate cur_level.time since sink_segment.position may be large and
src_segment.position default is 0, with the resulting diff being larger
than max-size-time, causing the queue to start leaking (if
leaky=downstream).
One potential consequence of this is that the segment event may be
stored on the srcpad before the caps event is pushed downstream, causing
a g_warning ("Sticky event misordering, got 'segment' before 'caps'").https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/203baseparse: do seek I/O in streaming thread and post progress messages for seek2021-09-24T11:09:59ZBugzilla Migration Userbaseparse: do seek I/O in streaming thread and post progress messages for seek## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774314)](https://bugzilla.gnome.org/show_bug.cgi?id=774314)**
## Description
+++ This bug was initially created as a clone of [Bug 613351](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774314)](https://bugzilla.gnome.org/show_bug.cgi?id=774314)**
## Description
+++ This bug was initially created as a clone of [Bug 613351](https://bugzilla.gnome.org/show_bug.cgi?id=613351) +++
BaseParse (and other parsers/demuxers) should not do any I/O in the seek handler, as currently done in gst_base_parse_locate_time(). This should be
done from the streaming thread instead, and the element should maybe also post PROGRESS messages on the bus about seek started/finished/failed.
### Blocking
* [Bug 617905](https://bugzilla.gnome.org/show_bug.cgi?id=617905)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/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/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/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/224GST_DEBUG_BIN_TO_DOT: creates invalid .dot file when GstStructure parameter c...2021-09-24T11:09:51ZBugzilla Migration UserGST_DEBUG_BIN_TO_DOT: creates invalid .dot file when GstStructure parameter contains string with "@"## Submitted by Brendan Shanks `@bshankstd`
**[Link to original bug (#779668)](https://bugzilla.gnome.org/show_bug.cgi?id=779668)**
## Description
When GST_DEBUG_BIN_TO_DOT_FILE dumps a bin containing an element with a GstStructure ...## Submitted by Brendan Shanks `@bshankstd`
**[Link to original bug (#779668)](https://bugzilla.gnome.org/show_bug.cgi?id=779668)**
## Description
When GST_DEBUG_BIN_TO_DOT_FILE dumps a bin containing an element with a GstStructure parameter, if the GstStructure contains a string value with "@" in it, the resulting .dot file is invalid. xdot gives the error "unexpected char '\'"
I came across this bug when dumping the media-pipeline of a GStreamer RTSP server. The GstRtpSession sdes parameter is a GstStructure with a string parameter ("cname") that has an "@" symbol in it.
I haven't investigated why this happens, but it looks like GstStructure
does extra quoting on the output string when it contains "@", and then g_strescape() adds too many backslashes when escaping.
Here's the invalid label line from the .dot file when the string doesn't contain "@": label="GstCapsFilter\nhi@\n[0]\nparent=(GstPipeline) pipeline\ncaps=application/x-rtp-source-sdes, cname=(string)user2341dqw";
And with "@":
label="GstCapsFilter\ncapsfilter0\n[0]\nparent=(GstPipeline) pipeline\ncaps=application/x-rtp-source-sdes, cname=(string)\\\"user2341\\\\@dqw\\\"";
According to the DOT language guide (http://www.graphviz.org/content/dot-language): "In quoted strings in DOT, the only escaped character is double-quote ("). That is, in quoted strings, the dyad \" is converted to "; all other characters are left unchanged. In particular, \\ remains \\"https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/227GstPushSrc.do_create and Gst.BaseSrc.do_query are not introspected properly i...2021-09-24T11:09:50ZBugzilla Migration UserGstPushSrc.do_create and Gst.BaseSrc.do_query are not introspected properly in bindings (Python)## Submitted by César Fabián Orccón Chipana
**[Link to original bug (#780945)](https://bugzilla.gnome.org/show_bug.cgi?id=780945)**
## Description
Created attachment 349314
Add annotations to vfuncs in base sources
For exampl...## Submitted by César Fabián Orccón Chipana
**[Link to original bug (#780945)](https://bugzilla.gnome.org/show_bug.cgi?id=780945)**
## Description
Created attachment 349314
Add annotations to vfuncs in base sources
For example,
When you use "do_create" vfunc in Python for a GstBaseSrc, you need to define the following method:
def do_create(self, buff):
# Implementation here
But what you actually should do is
def do_create(self):
# Implementation here
return buff
I am uploading a patch that fixes that.
PD: I also think that all vfuncs should be annotated.
**Patch 349314**, "Add annotations to vfuncs in base sources":
[0001-Add-annotations-to-vfuncs-in-base-sources.patch](/uploads/d32629f28c89585cda6e79c12ea5d6e0/0001-Add-annotations-to-vfuncs-in-base-sources.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/228Unexpected ERROR if changing states while pushing a sticky event.2021-09-24T11:09:49ZBugzilla Migration UserUnexpected ERROR if changing states while pushing a sticky event.## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#781000)](https://bugzilla.gnome.org/show_bug.cgi?id=781000)**
## Description
Currently, if the downstream element is stopped or goes flushing while a sticky event is ...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#781000)](https://bugzilla.gnome.org/show_bug.cgi?id=781000)**
## Description
Currently, if the downstream element is stopped or goes flushing while a sticky event is pushed downstream as caused by a buffer push, it will cause a castrophic failure as the gst_pad_push() will return GST_FLOW_ERROR.
I think it should return GST_FLOW_FLUSHING instead, so that it can be safely ignored if a flush caused it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/230rtsp: keep seqnum when performing seek2021-09-24T11:09:49ZBugzilla Migration Userrtsp: keep seqnum when performing seek## Submitted by Wonchul Lee
**[Link to original bug (#781386)](https://bugzilla.gnome.org/show_bug.cgi?id=781386)**
## Description
I tried to seek on rtsp stream, for example, rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
...## Submitted by Wonchul Lee
**[Link to original bug (#781386)](https://bugzilla.gnome.org/show_bug.cgi?id=781386)**
## Description
I tried to seek on rtsp stream, for example, rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov
The rtspsrc handles seek event and push the flush-start/stop event to udpsrcs what it has inside. The task running in the udpsrc stopped and restarted after rtspsrc set it's state to PLAYING. Then the udpsrc generated new segment event which has new seqnum (handled in basesrc), even if the segment event is related to the flush events from rtspsrc when performing seek.
In push mode, there seem not many cases handling seek event at upper bin or downstream element instead of Source element. It's not a good way to push segment event from the downstream element to upstream Source element, so I tried to keep the seqnum of the flush event which obviously triggers new segment event.
One problem here is that udpsrc didn't know the start / stop position of the segment what should be which was set to the seek event. I wonder it's a good way if I hook up segment event generated from udpsrc and updated start/stop position in rtspsrc in this case. please let me know if you have a good idea!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/231filesink/basesink: gst_element_query() for QUERY_URI on a filesink fails2021-09-24T11:09:48ZBugzilla Migration Userfilesink/basesink: gst_element_query() for QUERY_URI on a filesink fails## Submitted by Brendan Shanks `@bshankstd`
**[Link to original bug (#782135)](https://bugzilla.gnome.org/show_bug.cgi?id=782135)**
## Description
I'm trying to do a GST_QUERY_URI on a filesink using gst_element_query(), but the que...## Submitted by Brendan Shanks `@bshankstd`
**[Link to original bug (#782135)](https://bugzilla.gnome.org/show_bug.cgi?id=782135)**
## Description
I'm trying to do a GST_QUERY_URI on a filesink using gst_element_query(), but the query is never handled and fails. (It's actually on a bin containing a filesink, but I don't think that matters).
GstBaseSink's default_element_query() handles the query, and defaults to doing gst_pad_peer_query(). This sends the query upstream through the muxer, parser, etc., but the filesink itself never gets to answer.
filesink implements GstBaseSink::query() and handles GST_QUERY_URI there, but it looks like basesink only calls that for a pad query, not element query.
I can query the bin's sink pad instead, but gst_element_query(filesink, GST_QUERY_URI) seems like something that should work. Is this the case?
Relevant debug lines:
GST_ELEMENT_PADS gstelement.c:1707:gst_element_query: send query on element tdstream0
bin gstbin.c:4376:gst_bin_query:`<tdstream0>` Sending query 0x29c6c0 (type uri) to sink children
GST_ELEMENT_PADS gstelement.c:1707:gst_element_query: send query on element filesink
GST_PADS gstpad.c:4059:gst_pad_peer_query:<filesink:sink> peer query 0x29c6c0 (uri)
GST_PADS gstpad.c:3932:gst_pad_query:<muxer:src> doing query 0x29c6c0 (uri)
GST_PADS gstpad.c:3376:gst_pad_query_default:<muxer:src> forwarding 0x29c6c0 (uri) query
GST_PADS gstpad.c:2836:gst_pad_iterate_internal_links_default:<muxer:src> Making iterator
GST_PADS gstpad.c:4059:gst_pad_peer_query:<muxer:video_0> peer query 0x29c6c0 (uri)
GST_PADS gstpad.c:3932:gst_pad_query:<parser:src> doing query 0x29c6c0 (uri)
GST_PADS gstpad.c:3376:gst_pad_query_default:<parser:src> forwarding 0x29c6c0 (uri) query
GST_PADS gstpad.c:2836:gst_pad_iterate_internal_links_default:<parser:src> Making iterator
GST_PADS gstpad.c:4059:gst_pad_peer_query:<parser:sink> peer query 0x29c6c0 (uri)
... queries all the way to the src
Version: 1.10.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/234inputselector: Need flush when set active pad and then seek in PAUSE state2021-09-24T11:09:48ZBugzilla Migration Userinputselector: Need flush when set active pad and then seek in PAUSE state## Submitted by kevin
**[Link to original bug (#782417)](https://bugzilla.gnome.org/show_bug.cgi?id=782417)**
## Description
Old will be blocked on gst_pad_push() when set active pad in PAUSE state. Need flush when set active pad an...## Submitted by kevin
**[Link to original bug (#782417)](https://bugzilla.gnome.org/show_bug.cgi?id=782417)**
## Description
Old will be blocked on gst_pad_push() when set active pad in PAUSE state. Need flush when set active pad and then seek in PAUSE statehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/235plugin: Load validate tracer globals in the main namespace2021-09-24T11:09:48ZBugzilla Migration Userplugin: Load validate tracer globals in the main namespace## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#782430)](https://bugzilla.gnome.org/show_bug.cgi?id=782430)**
## Description
Otherwise other GstValidate plugins won't be able to access
GstValidate static v...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#782430)](https://bugzilla.gnome.org/show_bug.cgi?id=782430)**
## Description
Otherwise other GstValidate plugins won't be able to access
GstValidate static variables leading to totally broken behaviour and
segfaultshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/236heap-use-after-free in gst_debug_print_object() spotted by Asan2021-09-24T11:09:47ZBugzilla Migration Userheap-use-after-free in gst_debug_print_object() spotted by Asan## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#782648)](https://bugzilla.gnome.org/show_bug.cgi?id=782648)**
## Description
Created attachment 351856
heap-use-after-free in gstvalue.c
Hi,
Asan found a...## Submitted by Fabrice Bellet `@bellet`
**[Link to original bug (#782648)](https://bugzilla.gnome.org/show_bug.cgi?id=782648)**
## Description
Created attachment 351856
heap-use-after-free in gstvalue.c
Hi,
Asan found a couple of use after free cases when we print an object name, mainly when debugging level is high enough. There's a possibility that the name is read after the old pointer is freed and before the new one is assigned in gst_object_set_name().
**Attachment 351856**, "heap-use-after-free in gstvalue.c":
[empathy-call.asan.log.2](/uploads/36fb5f04211f0a81c0efa8315daef073/empathy-call.asan.log.2)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/237basesink: pipeline deadlocks when changing from PLAYING to PAUSED after proce...2021-09-24T11:09:47ZBugzilla Migration Userbasesink: pipeline deadlocks when changing from PLAYING to PAUSED after processing a segment seek## Submitted by Josep Torra `@adn770`
Assigned to **Josep Torra `@adn770`**
**[Link to original bug (#782960)](https://bugzilla.gnome.org/show_bug.cgi?id=782960)**
## Description
When using segment seeks to play sections of a stre...## Submitted by Josep Torra `@adn770`
Assigned to **Josep Torra `@adn770`**
**[Link to original bug (#782960)](https://bugzilla.gnome.org/show_bug.cgi?id=782960)**
## Description
When using segment seeks to play sections of a stream and we try to pause the pipeline after the segment-done event had reached the sink, the change state never finishes and it's stuck waiting for a preroll buffer.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/239queue, queue2: make segment position readable so that stalled/starved queues ...2021-09-24T11:09:46ZBugzilla Migration Userqueue, queue2: make segment position readable so that stalled/starved queues are obvious## Submitted by min..@..arp.fm
**[Link to original bug (#783667)](https://bugzilla.gnome.org/show_bug.cgi?id=783667)**
## Description
It is currently difficult to tell which queues are allowing data to flow and which queues are stal...## Submitted by min..@..arp.fm
**[Link to original bug (#783667)](https://bugzilla.gnome.org/show_bug.cgi?id=783667)**
## Description
It is currently difficult to tell which queues are allowing data to flow and which queues are stalled, making stalled complex pipelines very difficult to debug.
Expose the queue->src_segment.position and queue->sink_segment.position containing the PTS/DTS of the last buffer into and out of the queue to clearly show which queues are lagging behind and stalling the pipeline.
This also clearly shows queues that have never delivered data, as opposed to queues that are just empty.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/242[API] discussion: gst_element_link_delayed2021-09-24T11:09:46ZBugzilla Migration User[API] discussion: gst_element_link_delayed## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#784268)](https://bugzilla.gnome.org/show_bug.cgi?id=784268)**
## Description
The goal of this API would be to avoid requiring the use of pad-added callbacks for el...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#784268)](https://bugzilla.gnome.org/show_bug.cgi?id=784268)**
## Description
The goal of this API would be to avoid requiring the use of pad-added callbacks for elements that expose sometimes pads (eg rtpbin).
I'm not entirely sure what form the API should take, but here are a few use cases:
* When rtpbin exposes a pad named "send_rtp_src_0", link it with a given pad
* When rtpbin exposes a pad named "send_rtp_src_0", link it with any pad in a given element
* When rtpbin exposes a pad named "send_rtp_src_0", request a pad named 'audio_%02x' from a given element and link them.
A problematic part might be error handling :)
Thoughts?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/246basesrc: Sending eos maybe block for a small period or if pipeline is PAUSED2021-09-24T11:09:44ZBugzilla Migration Userbasesrc: Sending eos maybe block for a small period or if pipeline is PAUSED## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#785142)](https://bugzilla.gnome.org/show_bug.cgi?id=785142)**
## Description
While fixing [bug 783301](https://bugzilla.gnome.org/show_bug.cgi?id=783301) I had ...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#785142)](https://bugzilla.gnome.org/show_bug.cgi?id=785142)**
## Description
While fixing [bug 783301](https://bugzilla.gnome.org/show_bug.cgi?id=783301) I had to make a small thread-off. So now, instead of blocking forever in unpredictable condition, this call may block for a short period of time (or as long as the pipeline is paused).
This is a side effect of having to unlock/unlock_stop the source and not flushing downstream. This is needed to handle the case where we have udpsrc in the pipeline that isn't receiving data. In that case, the queued eos event would never be handled.
A possible solution would be to queue the EOS, and run the unlock/unlock_stop sequence asynchronously. Assuming we make sure the ref-count is done properly, and that we clearly the pending EOS is fully thread safe, I believe that gst_element_call_async() could be used. Obviously, large testing will be needed again.
We should probably have a look at [bug 752815](https://bugzilla.gnome.org/show_bug.cgi?id=752815) while at it, as it seems fairly similar, at least at first sight.
Version: 1.13.x
### Blocking
* [Bug 752815](https://bugzilla.gnome.org/show_bug.cgi?id=752815)