GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T11:10:26Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/159Crash on repeated pipeline, bus and signal watch creation2021-09-24T11:10:26ZBugzilla Migration UserCrash on repeated pipeline, bus and signal watch creation## Submitted by Xabier Rodríguez Calvar `@calvaris`
**[Link to original bug (#762552)](https://bugzilla.gnome.org/show_bug.cgi?id=762552)**
## Description
Created attachment 322010
Test program
If I run the attached test prog...## Submitted by Xabier Rodríguez Calvar `@calvaris`
**[Link to original bug (#762552)](https://bugzilla.gnome.org/show_bug.cgi?id=762552)**
## Description
Created attachment 322010
Test program
If I run the attached test program, in the end I get:
...
times 32000
(a.out:29888): GStreamer-CRITICAL **: gst_poll_get_read_gpollfd: assertion 'set != NULL' failed
(a.out:29888): GStreamer-CRITICAL **: gst_bus_create_watch: assertion 'bus->priv->poll != NULL' failed
(a.out:29888): GLib-CRITICAL **: g_source_set_callback: assertion 'source != NULL' failed
Fallo de segmento («core» generado)
**Attachment 322010**, "Test program":
[test.c](/uploads/fa1f4177df82e920df1452324f308326/test.c)
Version: 1.6.3
### See also
* [Bug 762849](https://bugzilla.gnome.org/show_bug.cgi?id=762849)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/158input-selector: remove some dead code2021-09-24T11:10:26ZBugzilla Migration Userinput-selector: remove some dead code## Submitted by Guillaume Marquebielle
**[Link to original bug (#762124)](https://bugzilla.gnome.org/show_bug.cgi?id=762124)**
## Description
Created attachment 321345
Patch removing dead code
In gst_input_selector_event () m...## Submitted by Guillaume Marquebielle
**[Link to original bug (#762124)](https://bugzilla.gnome.org/show_bug.cgi?id=762124)**
## Description
Created attachment 321345
Patch removing dead code
In gst_input_selector_event () method, previous cleaning has left some dead code.
Don't know if initial idea of GList "pushed_pads" has to be reworked or is no more useful.
**Patch 321345**, "Patch removing dead code":
[0001-input-selector-remove-dead-code.patch](/uploads/10c51c8ca1cf60a936b2ca18578b30d8/0001-input-selector-remove-dead-code.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/157pad: Race between push and (de)activate leads to data flow before events2022-11-10T09:20:46ZBugzilla Migration Userpad: Race between push and (de)activate leads to data flow before events## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#762086)](https://bugzilla.gnome.org/show_bug.cgi?id=762086)**
## Description
Created attachment 321263
Test
There is a race where data can be pushed without fo...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#762086)](https://bugzilla.gnome.org/show_bug.cgi?id=762086)**
## Description
Created attachment 321263
Test
There is a race where data can be pushed without forwarding the sticky
events. This test will trigger a g_warning about data flow before events.
There's likely more than one race here, probably both for buffers and
events. What can happen when trying to push a buffer while changing
element state and thus (de)activating the pads is:
1. Pads are active and buffers are flowing as normal.
2. Element changes state and its pads are deactivated, during which
the stored sticky events are removed.
3. A new buffer is pushed from a srcpad in the direction of the
element's deactive sinkpad.
4. check_sticky() in gst_pad_push_data() will not send events since
the flag PENDING_EVENTS on this srcpad is not set.
5. Before calling gst_pad_chain_data_unchecked() on the sinkpad, the pad
will be activated (because of an element state change). The flag
PENDING_EVENTS will be set, but it's too late for the srcpad to send
the sticky events.
6. The event check in gst_pad_chain_data_unchecked() will fail and give
g_warning.
Any thoughts on how this should be resolved?
**Patch 321263**, "Test":
[0001-pad-Stress-test-for-de-activate-while-pushing.patch](/uploads/5e90fb4d72177dadd296ce9b2748e4b5/0001-pad-Stress-test-for-de-activate-while-pushing.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/156gstinfo: Make GST_DEBUG_PAD_NAME "MT crash safe"2022-11-10T09:20:46ZBugzilla Migration Usergstinfo: Make GST_DEBUG_PAD_NAME "MT crash safe"## Submitted by Håvard Graff (hgr)
**[Link to original bug (#761916)](https://bugzilla.gnome.org/show_bug.cgi?id=761916)**
## Description
Created attachment 320952
test and fix
The pad may be unparented while this macro is ca...## Submitted by Håvard Graff (hgr)
**[Link to original bug (#761916)](https://bugzilla.gnome.org/show_bug.cgi?id=761916)**
## Description
Created attachment 320952
test and fix
The pad may be unparented while this macro is called which could result
in a segfault. The new macro protects against this. The parent may still
be disposed while the macro is called, but this will not result in a
crash (but the parent name may be garbage). Using gst_pad_get_parent ()
is undesirable since it takes the object lock.
The patch take advantage of compound expressions available as a C
extension in GCC and some other compilers.
~~**Patch 320952**~~, "test and fix":
[gstinfo-debug-pad-name-macro-fix.patch](/uploads/31ead0e98c821cde763b9037f5e6c976/gstinfo-debug-pad-name-macro-fix.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/155netclientclock: Only use observations with a RTT smaller than the median2021-09-24T11:10:28ZBugzilla Migration Usernetclientclock: Only use observations with a RTT smaller than the median## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#761812)](https://bugzilla.gnome.org/show_bug.cgi?id=761812)**
## Description
See commit message
### Depends on
* [Bug 774916](https://bugzilla.gnome.org/show_bug....## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#761812)](https://bugzilla.gnome.org/show_bug.cgi?id=761812)**
## Description
See commit message
### Depends on
* [Bug 774916](https://bugzilla.gnome.org/show_bug.cgi?id=774916)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/154basesink: Backward step operations fail and may lead to negative position val...2021-09-24T11:10:29ZBugzilla Migration Userbasesink: Backward step operations fail and may lead to negative position value in Totem## Submitted by Cosimo Cecchi
**[Link to original bug (#761439)](https://bugzilla.gnome.org/show_bug.cgi?id=761439)**
## Description
To reproduce:
- start playing a video
- (optional to make bug more obvious) seek in the middle ...## Submitted by Cosimo Cecchi
**[Link to original bug (#761439)](https://bugzilla.gnome.org/show_bug.cgi?id=761439)**
## Description
To reproduce:
- start playing a video
- (optional to make bug more obvious) seek in the middle
- hold comma
Notice that the state of the timeline becomes completely inconsistent.
See attached screenshot of Big Buck Bunny, but this seems reproducible with any video.
Version: 1.11.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/153utils: Add gst_object_(g|s)et_(string|int|...) functions2021-09-24T11:10:29ZBugzilla Migration Userutils: Add gst_object_(g|s)et_(string|int|...) functions## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#760705)](https://bugzilla.gnome.org/show_bug.cgi?id=760705)**
## Description
It's easy to get the type of properties wrong in the varargs functions, especially for 6...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#760705)](https://bugzilla.gnome.org/show_bug.cgi?id=760705)**
## Description
It's easy to get the type of properties wrong in the varargs functions, especially for 64 bit integers. We could provide helper functions that are typed and for one specific property, and also do checks in there if the types are matching with the one of the property.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/152basesink: always drops buffers before segment2022-11-10T09:20:46ZBugzilla Migration Userbasesink: always drops buffers before segment## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#760677)](https://bugzilla.gnome.org/show_bug.cgi?id=760677)**
## Description
+++ This bug was initially created as a clone of [Bug 752791](https://bugzil...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#760677)](https://bugzilla.gnome.org/show_bug.cgi?id=760677)**
## Description
+++ This bug was initially created as a clone of [Bug 752791](https://bugzilla.gnome.org/show_bug.cgi?id=752791) +++
Basesink drops buffers before segment, this can be harmful for streams that have keyframes. Appsink, network sinks and any other sinks that can handle any format would drop relevant data before the segment and rendering might not work as expected.
### Depends on
* [Bug 752791](https://bugzilla.gnome.org/show_bug.cgi?id=752791)
### See also
* [Bug 765734](https://bugzilla.gnome.org/show_bug.cgi?id=765734)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/151query: recursive accept-caps query2021-09-24T11:10:30ZBugzilla Migration Userquery: recursive accept-caps query## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#760590)](https://bugzilla.gnome.org/show_bug.cgi?id=760590)**
## Description
+++ This bug was initially created as a clone of [Bug 760477](https://bugzil...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#760590)](https://bugzilla.gnome.org/show_bug.cgi?id=760590)**
## Description
+++ This bug was initially created as a clone of [Bug 760477](https://bugzilla.gnome.org/show_bug.cgi?id=760477) +++
As we are replacing the current misused accept-caps queries we noticed that there is a certain feature gap.
Before we were believing that using an accept-caps query would cause all the pipeline downstream to verify if it would be able to accept a certain caps but the accept-caps was created to be a pre-check of a caps event and only goes to the next element.
Right now we have replaced accept-caps with a caps query + gst_caps_can_intersect() or gst_caps_is_subset() but for some elements we need to do a is_subset() while for others an intersect is enough.
Perhaps we should have a 'recursive' flag to a accept-caps query?
If we decide to do this in 1.x, we keep the current behavior and enable the flag when needed. Every baseclass and lots of elements out there will need to be updated so I'm not sure if this is a backwards compatible change.
Decided to open a bug so we can discuss and, if we defer it to 2.0, we can mark it as so to discuss it again once the time arrives.
### Depends on
* [Bug 760477](https://bugzilla.gnome.org/show_bug.cgi?id=760477)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/150bin, pipeline, sink: state change / async-done propagation issue with repeate...2022-11-10T09:20:46ZBugzilla Migration Userbin, pipeline, sink: state change / async-done propagation issue with repeated rtspsrc seeks## Submitted by ste..@..il.com
**[Link to original bug (#760532)](https://bugzilla.gnome.org/show_bug.cgi?id=760532)**
## Description
I'm having a issue at the moment with continuously seeks with RTSP playback. The rtsp client is co...## Submitted by ste..@..il.com
**[Link to original bug (#760532)](https://bugzilla.gnome.org/show_bug.cgi?id=760532)**
## Description
I'm having a issue at the moment with continuously seeks with RTSP playback. The rtsp client is connected with TCP interleave and I am seeking continuously, lets say every second or so I do a new seek. Then sometimes after seeking 3-5 times the video playback stalls for 20 seconds or so, but sometimes I can seek for 30 times before it happens.
### Server:
rtsp server serving a mkv file, the pipeline looks something like:
```
.---------. .---------------. .------------.
| filesrc |->| matroskademux |->| rtph264pay |
'---------' '---------------' '------------'
```
But I have also tried adding queues in between the elements.
The video file:
resolution: 1280x720
bitrate: 4096kb
framerate: 30fps
duration: 60 min
gov length: 10
### Client:
`rtspsrc location=rtsp://127.0.0.1:8554/something protocols=0x4 ! queue ! rtph264depay! avdec_h264 ! autovideosink`
### Test:
I have tried to create a test application for this, but it seems to not always happen.
``` c
#include <gst/gst.h>
void do_seek(GstElement *pipeline, gint64 timestamp)
{
unsigned int seek_flags = GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT | GST_SEEK_FLAG_SNAP_NEAREST;
gst_element_seek_simple(pipeline, GST_FORMAT_TIME, seek_flags, timestamp);
}
int main()
{
GstElement *pipeline;
GstBus *bus;
GstMessage *msg;
gint64 position = GST_SECOND * 5;
// initialize GStreamer
gst_init(NULL, NULL);
pipeline = gst_parse_launch("rtspsrc name=rtspsrc ! queue ! rtph264depay ! fakesink", NULL);
GstElement *rtspsrc = gst_bin_get_by_name(GST_BIN(pipeline), "rtspsrc");
g_object_set(rtspsrc,
"location", "rtsp://localhost:8554/something",
"protocols", 4, // 4 = GST_RTSP_LOWER_TRANS_TCP
NULL);
g_object_unref(rtspsrc);
gst_element_set_state(pipeline, GST_STATE_PLAYING);
gst_element_get_state(pipeline, NULL, NULL, GST_CLOCK_TIME_NONE);
// Wait until error, eos or async done
bus = gst_element_get_bus(pipeline);
unsigned int bus_flags = GST_MESSAGE_ERROR | GST_MESSAGE_EOS | GST_MESSAGE_ASYNC_DONE;
msg = gst_bus_timed_pop_filtered(bus, GST_CLOCK_TIME_NONE, (GstMessageType)(bus_flags));
unsigned int seek_count = 0;
while(GST_MESSAGE_TYPE(msg) != GST_MESSAGE_EOS)
{
g_print("seek (%u) again... :D\n", seek_count++);
position += GST_SECOND;
do_seek(pipeline, position);
gst_message_unref(msg);
msg = gst_bus_timed_pop_filtered(bus, GST_CLOCK_TIME_NONE, (GstMessageType)(bus_flags));
}
// Free resources
gst_message_unref(msg);
gst_object_unref(bus);
gst_element_set_state(pipeline, GST_STATE_NULL);
gst_object_unref(pipeline);
g_print("done");
return 0;
}
```
### Blocking
* #91
### See also
* #179https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/149baseparse: Need push remaining data in adapter when switching to pass through...2021-09-24T11:10:33ZBugzilla Migration Userbaseparse: Need push remaining data in adapter when switching to pass through mode## Submitted by Lyon
**[Link to original bug (#760513)](https://bugzilla.gnome.org/show_bug.cgi?id=760513)**
## Description
When we are trying to play some h264/avi streams, with our own parser plugin linked with h264parse and then...## Submitted by Lyon
**[Link to original bug (#760513)](https://bugzilla.gnome.org/show_bug.cgi?id=760513)**
## Description
When we are trying to play some h264/avi streams, with our own parser plugin linked with h264parse and then avdec_h264, there will be some corrupt video be observed. while using avidemux link with h264parse, it plays well.
After doing some investigation.
- avdec_h264 only support alignment au format.
- and avidemux output caps not specify the alignment as "au"
So h264parse will do the parse to convert alignment to "au"
- however, when using our own parser plugin, the output plugins already set the video as alignment "au", so that h264parse work in pass through mode.
But it seems the h264parse's output lost the sps/pps data in the begging, which cause the video decoding error for some frames.
So it maybe bugs in h264parse pass through mode, suppose in pass through mode, the output should be the same as when h246parse not linked in the pipeline.
I'm not sure if this issue has been raised before, so I recorded the issue here
Thanks a lot ~
Version: 1.6.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/148[API] value, tag lists, caps: add pretty serialization2021-09-24T11:10:33ZBugzilla Migration User[API] value, tag lists, caps: add pretty serialization## Submitted by Tim Müller `@tpm`
**[Link to original bug (#760027)](https://bugzilla.gnome.org/show_bug.cgi?id=760027)**
## Description
Serialized caps or tags can at times be very very long if they contain large buffers, e.g. if s...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#760027)](https://bugzilla.gnome.org/show_bug.cgi?id=760027)**
## Description
Serialized caps or tags can at times be very very long if they contain large buffers, e.g. if streamheaders include coverart.
It would be nice if we had API for 'pretty' serialization of values, tags, caps, structures, etc, so we can use shortened versions in more places including logs and dot files.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/146basesink: seeking issue when async is set to false2022-11-10T09:20:46ZBugzilla Migration Userbasesink: seeking issue when async is set to false## Submitted by Eunhae Choi
**[Link to original bug (#759730)](https://bugzilla.gnome.org/show_bug.cgi?id=759730)**
## Description
If I set the async property to false of sink element, seeking does not works well.
Forward seeki...## Submitted by Eunhae Choi
**[Link to original bug (#759730)](https://bugzilla.gnome.org/show_bug.cgi?id=759730)**
## Description
If I set the async property to false of sink element, seeking does not works well.
Forward seeking seems like okey but backward seeking does not work.
You can check the issue with gst-play-1.0.
# gst-play-1.0 /home/eunhye/content/mp3/piano.mp3 --audiosink="pulsesink async=false"
Thank you.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/145gst_element_lost_state() interfers with base-time resetting of later gst_elem...2021-09-24T11:10:34ZBugzilla Migration Usergst_element_lost_state() interfers with base-time resetting of later gst_element_set_state()## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#759604)](https://bugzilla.gnome.org/show_bug.cgi?id=759604)**
## Description
Created attachment 317583
testcase
Consider the following situation in a pipeline...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#759604)](https://bugzilla.gnome.org/show_bug.cgi?id=759604)**
## Description
Created attachment 317583
testcase
Consider the following situation in a pipeline with `async=true` sinks:
1) `gst_element_lost_state()` due to flushing for whatever reason
2) `gst_element_set_state(PAUSED)` on the pipeline due to `BUFFERING`<100% before 1) finished to put the pipeline to `PLAYING` again
3) `gst_element_set_state(PLAYING)` on the pipeline much later because `BUFFERING`==100%
What will happen here is that 1) does a "state change" without going through the `GstElement::change_state()` machinery and as such no start_time will be set. It will update current/next/pending state to `PAUSED` and target state stays at `PLAYING`. 2) will then immediately return and only update the target state to `PAUSED` but nothing will go through `GstElement::change_state()` anywhere. Later 3) will change the state to `PLAYING` again but `base_time` is not updated as in 1) and 2) the start_time was not set.
The effect of this is that the running time continued all the time the pipeline was buffering, and as such now everything that was buffered is most likely too late and will be dropped.
Note that similar code to `gst_element_lost_state()` is also in GstBin's `handle_async_start()`, which will cause the same problems if a child element is posting async-start messages. So this situation could also happen in pipelines where sinks are dynamically added.
`gst_element_lost_state()` (and the async-start handling in GstBin) intentionally does not update `start_time` as a) the clock might not work anymore at this point and b) the running time should continue if it can as losing state should just be something that happens very shortly and should not interrupt playback (e.g. of other pipeline branches inside the pipeline!).
Attached is a test application that reproduces this behaviour. Take a look at where the `LOST_STATE` #define is used to get an idea of the different variants that can happen, and which work and which don't.
I'm not sure how to fix this without breaking other things. IMHO for 2.0 we should clean up all this state change machinery a lot and make sure we have a sensible state machine again that does not come with weird non-states like the ones that currently happen when state is lost.
**Attachment 317583**, "testcase":
[test.c](/uploads/0914a21d8d3c02ecabed5c41d9f78d55/test.c)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/144input-selector element generates wrong DTS timestamps with sync-mode=0 and mu...2022-06-03T00:10:06ZBugzilla Migration Userinput-selector element generates wrong DTS timestamps with sync-mode=0 and multiple rtspsrc (same video format/framerates)## Submitted by Tapas Kumar Kundu
**[Link to original bug (#759470)](https://bugzilla.gnome.org/show_bug.cgi?id=759470)**
## Description
input-selector: it switches to active live video stream (rtspsrc) without checking for keyframe...## Submitted by Tapas Kumar Kundu
**[Link to original bug (#759470)](https://bugzilla.gnome.org/show_bug.cgi?id=759470)**
## Description
input-selector: it switches to active live video stream (rtspsrc) without checking for keyframes.
This causes input-selector to miss keyframe from rtspsrc and this causes additional delay (video is paused for 1second) during camera switching using input-selector.
Test case:
I have 5 ip cameras (all are rtspsrc element) and one audio src (rtspsrc)
All 5 ip cameras are connected with input-selector element and it switched from one camera to another camera.
My code works perfectly fine [1] : http://hastebin.com/raw/adatujewes
But there is one flaw in streaming. I am seeing a pause for 1 second whenever input-selector is switching between camera.
Look at timestamp 1min 12sec on my streaming video url which is using my binary generated from code [1]:
[2] https://www.youtube.com/watch?v=NPlN_3YhmrM
You will see cameras are switched every 5 seconds after 1:12 on that url [2] However, there is a pause of 1 second when camera switching happens,
I tried with changing delay of queue/ replacing queue with queue2/ making rtspsec latency=0 .
But nothing helps me .
Proposed Solution:
Fix input-selector element so that it can wait for keyframes before switching to live stream. This will give gapless video switching from input-selector element.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/143basesrc: When live, sending EOS after early runtime errors have no effect2021-09-24T11:10:35ZBugzilla Migration Userbasesrc: When live, sending EOS after early runtime errors have no effect## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#759033)](https://bugzilla.gnome.org/show_bug.cgi?id=759033)**
## Description
Filing against v4l2src for now, as it's the only src I found that could reproduce t...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#759033)](https://bugzilla.gnome.org/show_bug.cgi?id=759033)**
## Description
Filing against v4l2src for now, as it's the only src I found that could reproduce this.
gst-launch-1.0 -e v4l2src ! identity error-after=1 ! fakesinkhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/142Use common connection-speed range for all elements2022-11-10T09:20:46ZBugzilla Migration UserUse common connection-speed range for all elements## Submitted by Athanasios Oikonomou
**[Link to original bug (#758916)](https://bugzilla.gnome.org/show_bug.cgi?id=758916)**
## Description
Currently there there are differences between elements with connection-speed property.
...## Submitted by Athanasios Oikonomou
**[Link to original bug (#758916)](https://bugzilla.gnome.org/show_bug.cgi?id=758916)**
## Description
Currently there there are differences between elements with connection-speed property.
There are three ranges in total, 0 to 2147483 mmssrc/4294967 dashdemux,hlsdemux,mssdemux/18446744073709551.
Is there a reason having connection-speed not as guint64?
Here are all elements with connection-speed property.
dashdemux
connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967 Default: 0
decodebin
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0
hlsdemux
connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967 Default: 0
mmssrc
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 2147483 Default: 0
mssdemux
connection-speed : Network connection speed in kbps (0 = calculate from downloaded fragments)
flags: readable, writable
Unsigned Integer. Range: 0 - 4294967 Default: 0
playbin
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0
rtspsrc
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0
uridecodebin
connection-speed : Network connection speed in kbps (0 = unknown)
flags: readable, writable
Unsigned Integer64. Range: 0 - 18446744073709551 Default: 0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/140Faulty annotation of gst_buffer_new_wrapped_full / gst_memory_new_wrapped2021-09-24T11:10:36ZBugzilla Migration UserFaulty annotation of gst_buffer_new_wrapped_full / gst_memory_new_wrapped## Submitted by Rico Tzschichholz `@ricotz`
**[Link to original bug (#758550)](https://bugzilla.gnome.org/show_bug.cgi?id=758550)**
## Description
The data length attribute should point to maxsize instead of size.
Afaiu the relati...## Submitted by Rico Tzschichholz `@ricotz`
**[Link to original bug (#758550)](https://bugzilla.gnome.org/show_bug.cgi?id=758550)**
## Description
The data length attribute should point to maxsize instead of size.
Afaiu the relation of those arguments is "size <= maxsize - offset".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/139tests: Fix spuriously failing netclientclock test on OSX2021-09-24T11:44:43ZBugzilla Migration Usertests: Fix spuriously failing netclientclock test on OSX## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#758323)](https://bugzilla.gnome.org/show_bug.cgi?id=758323)**
## Description
On OSX, startup sync might take longer than what has been assumed in the test,
h...## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#758323)](https://bugzilla.gnome.org/show_bug.cgi?id=758323)**
## Description
On OSX, startup sync might take longer than what has been assumed in the test,
hence failing the test. OSX seems to be exposed to more OS scheduling jitter,
i.e. the observed RTTs take some time to be become stable enough.
As the comment in the original test says:
"can't in general make a precise assertion here, because this depends on
system load and a lot of things. however within half a second they should
at least be within 1/10 of a second of each other... "
IMO, if we can't make a precise assertion here, we shouldn't make it at all in
the unit test. See attached patch for a fix.
Related to this, here is the debug output of one of the observations being
dropped (originally causing the longer sync time on OSX):
`<netclientclock0>`
Dropping observation, long RTT 0:00:00.000977094 > 2 * avg 0:00:00.000182319
That shows that the RTT is of course very low (via localhost), but that this
observation is too far off the avg, likely because OS schedule jitter. slomo
(thanks for the analysis of the problem) suggested that maybe we can also
allow a higher deviation for RTTs lower than 1-2 ms. However, I am not
familiar enough with the netclientclock to write a patch for that/further
discuss if that makes sense or not. It would make the initial sync faster on
OSX in this case. Due to the dropped observations, sync can sometimes take
longer than 500ms on that platform. Does anybody have comments on that?
Anyway, IMO the test should be fixed nonetheless, patch is attached.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/138bufferpool config: function to remove an option in the config2021-09-24T11:10:37ZBugzilla Migration Userbufferpool config: function to remove an option in the config## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#757925)](https://bugzilla.gnome.org/show_bug.cgi?id=757925)**
## Description
The use case I have for this is if an element wants to override/perform the creation of...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#757925)](https://bugzilla.gnome.org/show_bug.cgi?id=757925)**
## Description
The use case I have for this is if an element wants to override/perform the creation of a meta on the buffer.
A simple solution of using gst_buffer_foreach_meta(); gst_buffer_remove_meta() will fail to remove any locked buffers that a bufferpool adds to the buffer. This makes it optional and possible for the meta to not appear on the buffer in the first place.