gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2023-06-20T16:33:55Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2692asfdemux: Seeking close to duration not working2023-06-20T16:33:55ZBugzilla Migration Userasfdemux: Seeking close to duration not working## Submitted by Nirmal Palanisamy
**[Link to original bug (#789710)](https://bugzilla.gnome.org/show_bug.cgi?id=789710)**
## Description
When we seek close to file duration, playback exits immediately for the attached stream. Playba...## Submitted by Nirmal Palanisamy
**[Link to original bug (#789710)](https://bugzilla.gnome.org/show_bug.cgi?id=789710)**
## Description
When we seek close to file duration, playback exits immediately for the attached stream. Playback is not continuing from the seek position.
Attached stream duration is 50 sec. When seek is issued between 42 to 46 sec, playback ends immediately. Ideally playback should continue from 42 to 46 sec after seek operation.
Version: 1.12.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2750vtenc: vtenc_h264 causing too many Redistribute latency...2023-08-04T20:57:05ZBugzilla Migration Uservtenc: vtenc_h264 causing too many Redistribute latency...## Submitted by Miki Grof-Tisza
**[Link to original bug (#789415)](https://bugzilla.gnome.org/show_bug.cgi?id=789415)**
## Description
I'm having some trouble with the pipeline:
gst-launch-1.0 --gst-debug=*:2,vtenc:4 videotestsrc ...## Submitted by Miki Grof-Tisza
**[Link to original bug (#789415)](https://bugzilla.gnome.org/show_bug.cgi?id=789415)**
## Description
I'm having some trouble with the pipeline:
gst-launch-1.0 --gst-debug=*:2,vtenc:4 videotestsrc ! videorate ! video/x-raw, format=UYVY, width=1920, height=1080, framerate=30/1 ! queue ! vtenc_h264 ! fakesink
I’m running gstreamer version 1.12.3 built from git source, on a 2017 15” Macbook Pro, w/macOS 10.12.6.
The relevant output:
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.154950000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:00.235169000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.241439000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:00.253913000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.278467000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 7 fps 30/1 time 0:00:00.233333331
Redistribute latency...
0:00:00.288046000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:00.371569000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 7 fps 30/1 time 0:00:00.233333331
Redistribute latency...
0:00:03.043466000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 6 fps 30/1 time 0:00:00.199999998
Redistribute latency...
0:00:03.065692000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 5 fps 30/1 time 0:00:00.166666665
Redistribute latency...
0:00:03.090887000 72088 0x7ff6d7010370 INFO vtenc vtenc.c:1070:gst_vtenc_update_latency:`<vtenc_h264-0>` latency status 0 frames 4 fps 30/1 time 0:00:00.133333332
Redistribute latency...
The vtenc_h264 element is calling gst_video_encoder_set_latency() seemingly way too often. It results in gst-launch printing "Redistribute latency..." quite often (several times per second sometimes).
What's happening seems to be the element keeping track of the underlying encoder's pending frame count. If the pending frame count ever changes (checked every frame), then it calls gst_video_encoder_set_latency().
Is it not the case that instead of tracking exact latency each frame and forcing a pipeline latency redistribution every time it changes at all, the element should just check if the latency is greater than the currently configured range (checked via call to gst_video_encoder_get_latency()) and only call gst_video_encoder_set_latency() if it's outside the range?
I will attach a patch that works for me shortly.
Version: 1.12.3Piotr BrzezińskiPiotr Brzezińskihttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2781Gst.Bin __init__ changed behavior between 1.10 and 1.12 GStreamer version2023-07-06T16:40:08ZBugzilla Migration UserGst.Bin __init__ changed behavior between 1.10 and 1.12 GStreamer version## Submitted by Andreu N
**[Link to original bug (#789055)](https://bugzilla.gnome.org/show_bug.cgi?id=789055)**
## Description
In version 1.10 Gst.Bin component behaved like a regular GObject class used in python. I mean, you could...## Submitted by Andreu N
**[Link to original bug (#789055)](https://bugzilla.gnome.org/show_bug.cgi?id=789055)**
## Description
In version 1.10 Gst.Bin component behaved like a regular GObject class used in python. I mean, you could define a new component using Gst.Bin as parent, define properties as GObject.ParamFlags.CONSTRUCT_ONLY and pass values to __init__ method in order to set them.
class MyBin(Gst.Bin):
foo = GObject.Property(type=str,
flags=GObject.ParamFlags.CONSTRUCT_ONLY |
GObject.ParamFlags.READWRITE)
def __init__(self, *args, **kwargs):
Gst.Bin.__init__(self, *args, **kwargs)
# your stuff
my_bin = MyBin(foo='bar')
But currently in Gst version 1.12 it raise an error because it does not pass properties to GObject.Object.__init__.
TypeError: __init__() got an unexpected keyword argument 'foo'
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2509rtpjitterbuffer/h264parse timestamp issue (regression)2023-04-20T11:16:15ZBugzilla Migration Userrtpjitterbuffer/h264parse timestamp issue (regression)## Submitted by Nicola `@drakkan`
**[Link to original bug (#788777)](https://bugzilla.gnome.org/show_bug.cgi?id=788777)**
## Description
Created attachment 361248
logs that show the issue
In a pipeline like this:
rtspsrc...## Submitted by Nicola `@drakkan`
**[Link to original bug (#788777)](https://bugzilla.gnome.org/show_bug.cgi?id=788777)**
## Description
Created attachment 361248
logs that show the issue
In a pipeline like this:
rtspsrc ! rtph264depay ! h264parse ! ...
using rtsp over tcp can happen that rtspsrc outputs buffers with the same timestamp, when this happen h264parse outputs buffer with invalid timestamps.
Please take a look at the attached logs, you can see:
rtpjitterbuffer.c:916:rtp_jitter_buffer_calculate_pts:[00m backwards timestamps, using previous time
so different buffers with pts 0:15:23.020362975 are sended.
Not sure how to handle this case, we need to change rtpjitterbuffer or h264parse?
This problem seems to happen only using rtsp over tcp, I'm unable to reproduce it using rtsp over udp.
**Attachment 361248**, "logs that show the issue":
[log.txt](/uploads/beac41b97709f74dfb724f589e3b11e4/log.txt)
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2892audiobasesink: get time is racy2023-08-08T16:37:58ZBugzilla Migration Useraudiobasesink: get time is racy## Submitted by Philippe Renon
**[Link to original bug (#788562)](https://bugzilla.gnome.org/show_bug.cgi?id=788562)**
## Description
Here is a simplified version of the get_time method:
```
/* we call this function without hol...## Submitted by Philippe Renon
**[Link to original bug (#788562)](https://bugzilla.gnome.org/show_bug.cgi?id=788562)**
## Description
Here is a simplified version of the get_time method:
```
/* we call this function without holding the lock on sink for performance
* reasons. Try hard to not deal with and invalid ringbuffer and rate. */
static GstClockTime
gst_audio_base_sink_get_time (GstClock * clock, GstAudioBaseSink * sink)
{
[SNIP]
/* our processed samples are always increasing */
samples = gst_audio_ring_buffer_samples_done (ringbuffer); (1)
/** racy if a new sample is written when we are here... */
/* the number of samples not yet processed, this is still queued in the
* device (not played for playback). */
delay = gst_audio_ring_buffer_delay (ringbuffer); (2)
samples -= delay;
result = gst_util_uint64_scale_int (samples, GST_SECOND, rate);
return result;
}
```
It computes the time as time = samples - delay.
Where samples is the number of samples that have been written to the audio device and delay represents how much remains to be played by the device.
The race condition happens like this:
- samples value is gotten at line (1)
- a new sample is written to the device (but the samples variable does not account for it)
- delay value is gotten at (2) and is bigger than expected because of new sample that was written
If this happens then the delay is too big and when it gets subtracted to samples, the resulting time goes backwards (by 10ms in my case which corresponds I believe to the duration of a sample).
I don't know how to fix this issue because there are three classes involved : the audiobasesink, the audioringbugger and the specific sink (a directsoundsink in my case). The specific sink is involved because the get_delay method is implemented there.
There are solutions to mitigate the issue:
1. Get the delay before getting the samples
This will not solve the race condition but will make it less likely to happen.
If it happens, the clock will jump forward (and might jump backwards on a subsequent get_time
invocation).
2. Remember the last time value returned by get_time.
If the new time is before the last time then return the last time.
On a side note, I believe that directsoundsink delay method is also racy in a similar way.
Version: 1.12.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/249ghostpad : Issue in setting pad mode for a bin created dynamically(when pipel...2021-09-24T11:09:43ZBugzilla Migration Userghostpad : Issue in setting pad mode for a bin created dynamically(when pipeline is running)## Submitted by Baby octopus
**[Link to original bug (#787323)](https://bugzilla.gnome.org/show_bug.cgi?id=787323)**
## Description
Created attachment 359221
Sample application to reproduce the issue(based on test-segment-seek)
...## Submitted by Baby octopus
**[Link to original bug (#787323)](https://bugzilla.gnome.org/show_bug.cgi?id=787323)**
## Description
Created attachment 359221
Sample application to reproduce the issue(based on test-segment-seek)
I have had this issue in my application which I'm able to reproduce in a small testbench
I have a pipeline gst-launch-1.0 playbin uri=xxx.mp4. When this file xxx.mp4 play is done,
1. I create another srcBin ! typefind ! sink branch and add to the pipeline(and link). SrcBin is a bin encapsulating filesrc
2. Call gst_bin_sync_children_states()
I see that the filesrc's pad activation function called 3 times, pull-pull-push mode. However, typefind thinks the pad in PULL mode. And this gives error *pull range on pad bin_src_pad:proxypad16 but it wasnot activated in pull mode*
No such issue is seen is srcBin is replaced with filesrc(make #if 0 in line 156)
It seems like some bug in ghostpad's pad activation when done when pipeline is running
~~**Attachment 359221**~~, "Sample application to reproduce the issue(based on test-segment-seek)":
[ghostpad_test.c](/uploads/ed2ec4890d643792ad2c0822dbd26d9d/ghostpad_test.c)
Version: 1.12.1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/248basesink: Add property to handle seamless-seek by sink2021-09-24T13:06:17ZBugzilla Migration Userbasesink: Add property to handle seamless-seek by sink## Submitted by Seungha Yang
**[Link to original bug (#787300)](https://bugzilla.gnome.org/show_bug.cgi?id=787300)**
## Description
There seems to no way to set segment.rate immediately in pipeline without flush.
To mimic the feat...## Submitted by Seungha Yang
**[Link to original bug (#787300)](https://bugzilla.gnome.org/show_bug.cgi?id=787300)**
## Description
There seems to no way to set segment.rate immediately in pipeline without flush.
To mimic the feature, there might be 2 options but seems ugly for me.
- Reduce queue size in pipeline as much as possible and use non-flush seek.
- Adjust clock maybe??
Another option is that make use of step event but originally step event is not for this feature. So we need more pretty way to change rate immediately.
One of use case of this rate change is, Youtube rate change which is perfectly seamless.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/247harness: add support for pushing BufferList2021-09-24T11:09:44ZBugzilla Migration Userharness: add support for pushing BufferList## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#786800)](https://bugzilla.gnome.org/show_bug.cgi?id=786800)**
## Description
Created attachment 358399
harness: add support for pushing BufferList
Prov...## Submitted by Miguel París Díaz `@mparisdiaz`
**[Link to original bug (#786800)](https://bugzilla.gnome.org/show_bug.cgi?id=786800)**
## Description
Created attachment 358399
harness: add support for pushing BufferList
Providing support for pushing BufferList in Harness is quite useful to test elements being able to handle it.
In this way we could easily test that the behavior is the expected, that there is not memory leaks, etc.
~~**Patch 358399**~~, "harness: add support for pushing BufferList":
[0001-harness-add-support-for-pushing-BufferList.patch](/uploads/23fd240510fccded65b337da7594c4e0/0001-harness-add-support-for-pushing-BufferList.patch)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)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/245Seeking a pipeline containing concat only seeks the latest source2022-11-10T09:20:48ZBugzilla Migration UserSeeking a pipeline containing concat only seeks the latest source## Submitted by Jay Yang
**[Link to original bug (#784831)](https://bugzilla.gnome.org/show_bug.cgi?id=784831)**
## Description
Created attachment 355384
Code to reproduce the bug
It seems that concat simply forwards the seek...## Submitted by Jay Yang
**[Link to original bug (#784831)](https://bugzilla.gnome.org/show_bug.cgi?id=784831)**
## Description
Created attachment 355384
Code to reproduce the bug
It seems that concat simply forwards the seek event to the current sink pad, and so if we try to seek to the beginning of the pipeline it only seeks part of the way.
I've attached a file that demonstrates the issue. It needs a test.ogg file that runs for 2 minutes. The code runs a pipeline consisting of two copies of test.ogg concatenated with concat. It runs the pipeline for 3 minutes and then tries to seek to the start. I would expect then the code to run for a total of 7 minutes, instead it runs for 5 minutes.
I'm on 1.10.5
**Attachment 355384**, "Code to reproduce the bug":
[bug.c](/uploads/700b4fc1263136419f3c1f59f5135f87/bug.c)
Version: 1.10.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/244alsasrc: Incorrectly timestamps buffers when pipeline is using a network clock2022-11-10T09:20:48ZBugzilla Migration Useralsasrc: Incorrectly timestamps buffers when pipeline is using a network clock## Submitted by GstBlub
**[Link to original bug (#784803)](https://bugzilla.gnome.org/show_bug.cgi?id=784803)**
## Description
Created attachment 355339
netclientclock/ptpclock: Set clock-type property to "other"
The alsasrc ...## Submitted by GstBlub
**[Link to original bug (#784803)](https://bugzilla.gnome.org/show_bug.cgi?id=784803)**
## Description
Created attachment 355339
netclientclock/ptpclock: Set clock-type property to "other"
The alsasrc plugin looks at the selected clock and checks if it's a clock based on the monotonic clock. The problem is, the network clocks derive from the system clock and their clock-type property still defaults to the monotonic clock. If the pipeline clock is such a network clock, the alsasrc plugin then uses the timestamps provided by alsa (which are based on the monotonic clock) to timestamp the buffers it produces, which won't match what the pipeline expects.
There are multiple ways to fix this issue, but I'm not sure what the right approach is:
1. alsasrc should check if the clock *is* of type GstSystemClock, rather than merely checking whether it is or potentially was derived from that class
2. The network clock implementations should set the clock-type property to "other" by default
3. The GstSystemClock and network clock implementations should be based off another common base class, and only the GstSystemClock class would have the clock-type property
The attached patch fixes it by implementing` #2`.
**Patch 355339**, "netclientclock/ptpclock: Set clock-type property to "other"":
[0001-netclientclock-ptpclock-Set-clock-type-property-to-o.patch](/uploads/d3c3fd659ef49618b5c7d7e72a4356e9/0001-netclientclock-ptpclock-Set-clock-type-property-to-o.patch)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/240downloadbuffer: Watermark based buffering does not work reliable2022-04-30T06:58:15ZBugzilla Migration Userdownloadbuffer: Watermark based buffering does not work reliable## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#783674)](https://bugzilla.gnome.org/show_bug.cgi?id=783674)**
## Description
See
commit 66929f8970e397064251206f012e6f477a1c3506
Author: Sebastian Dröge <seba...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#783674)](https://bugzilla.gnome.org/show_bug.cgi?id=783674)**
## Description
See
commit 66929f8970e397064251206f012e6f477a1c3506
Author: Sebastian Dröge <sebastian@centricular.com>
Date: Mon Jun 12 10:24:43 2017 +0300
urisourcebin: Use downloadbuffer element
And only set low-percent/high-percent if not using downloadbuffer, just
like in old uridecodebin. using the watermark based buffering causes
playback to hang never finish buffering with downloadbuffer.
If the setting of low-percent/high-percent happens again, buffering will go to 60% (coincidentally high-percent) and never go higher again.
Version: 1.12.0https://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/834dashdemux: use MPD.Location element for manifest URL if present2021-10-20T08:24:08ZBugzilla Migration Userdashdemux: use MPD.Location element for manifest URL if present## Submitted by A Ashley
**[Link to original bug (#783590)](https://bugzilla.gnome.org/show_bug.cgi?id=783590)**
## Description
The DVB DASH specification section 10.11 states:
Players shall use the MPD.Location element...## Submitted by A Ashley
**[Link to original bug (#783590)](https://bugzilla.gnome.org/show_bug.cgi?id=783590)**
## Description
The DVB DASH specification section 10.11 states:
Players shall use the MPD.Location element URL for all MPD
updates and not the URL used to initially retrieve the MPD.
This bug ticket is to request addition of code in dashdemux check if any Location elements are present in the manifest and use one of these to set the URL that is used for the next manifest refresh.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/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/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/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/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.0