GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-11-10T09:20:51Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/312uri: fix roundtrip for file:// URIs2022-11-10T09:20:51ZBugzilla Migration Useruri: fix roundtrip for file:// URIs## Submitted by Tim Müller `@tpm`
**[Link to original bug (#797146)](https://bugzilla.gnome.org/show_bug.cgi?id=797146)**
## Description
Created attachment 373661
uri: fix roundtrip for file:// uris
uri = gst_uri_from_string ...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#797146)](https://bugzilla.gnome.org/show_bug.cgi?id=797146)**
## Description
Created attachment 373661
uri: fix roundtrip for file:// uris
uri = gst_uri_from_string ("file:///path/to/foo.bar");
string = gst_uri_to_string (uri);
would return "file:/path/to/foo.bar".
Slashes get lost somewhere.
Setting the hostname to "" after gst_uri_from_string() "fixes" it.
Attached patch fixes it also without making any of the other unit tests fail, but it's pretty much cargo-culted without real understanding.
Question is if this is something that needs to be fixed serialisation-side or parsing-side I guess.
**Patch 373661**, "uri: fix roundtrip for file:// uris":
[0001-uri-fix-roundtrip-for-file-uris.patch](/uploads/178257802e609d6e6ad05236655281b9/0001-uri-fix-roundtrip-for-file-uris.patch)
### See also
* [Bug 771756](https://bugzilla.gnome.org/show_bug.cgi?id=771756)Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/311caps: Using gst_caps_fixate() on src pad leads to lies in the caps2022-11-10T09:20:50ZBugzilla Migration Usercaps: Using gst_caps_fixate() on src pad leads to lies in the caps## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797142)](https://bugzilla.gnome.org/show_bug.cgi?id=797142)**
## Description
The default implementation of fixate in basesrc is based on gst_caps_fixate(). This...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#797142)](https://bugzilla.gnome.org/show_bug.cgi?id=797142)**
## Description
The default implementation of fixate in basesrc is based on gst_caps_fixate(). This though can lead to terribly lies in the resulting caps if downstream element uses ranges or set to explicitly state what is supported.
As in:
udpsrc caps="video/x-h264" ! h264parse ! avdec_h264 ! fakesink
avdec_h264 sets the alignment to { au, nal }, in order to ensure that it's one of these two alignment that are provided. udpsrc, which uses BaseSrc default, will happily pretend to produce:
video/x-h264, alignment=(string)au, stream-format=(string)avc
This is highly problematic, since we now lie to h264parse, triggering optimization that should not.
The downstream solution to that is to remove the alignment and to write code in When we receive that caps that check that alignment is present. That's not a great solution because it requires coding the requirements and also it reduce the quality of the documentation.
While I'm under the impression this may break some valid use cases, I'd like to start experimenting a solution that would make our caps negotiation more strict. My first proposal would be to create a new version of gst_caps_fixate(), let's say gst_caps_fixate_known (caps, known_field), or gst_caps_fixate_from_template (caps, template). The idea is that the opration would first remove all the unkmown field before fixating. As a side effect, in the previous example, udpsrc would negotiate just "https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/310aggregator: allocation query management makes buffering suboptimal when using...2021-09-24T11:09:24ZBugzilla Migration Useraggregator: allocation query management makes buffering suboptimal when using dynamic/live pipelines## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#797100)](https://bugzilla.gnome.org/show_bug.cgi?id=797100)**
## Description
Since we implemented downstream allocation negotiation support in [Bug 746529](htt...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#797100)](https://bugzilla.gnome.org/show_bug.cgi?id=797100)**
## Description
Since we implemented downstream allocation negotiation support in [Bug 746529](https://bugzilla.gnome.org/show_bug.cgi?id=746529), reconfiguring videoaggregator/compositor blocks downstream on the allocation query (basically until the queued data has been processed) meaning that no further data processing can happen meanwhile. That makes queuing way less effective and in NLE/Pitivi for example it leads to bad "perfs". We should find a way to make renegotiation happen as soon as required and not block that way downstream.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/309downloadbuffer: does not recover from failed seek2021-09-24T11:09:25ZBugzilla Migration Userdownloadbuffer: does not recover from failed seek## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#797098)](https://bugzilla.gnome.org/show_bug.cgi?id=797098)**
## Description
This is some code from perform_seek_to_offset() from gstdownloadbuffer.c
/* u...## Submitted by Alicia Boya García `@ntrrgc`
**[Link to original bug (#797098)](https://bugzilla.gnome.org/show_bug.cgi?id=797098)**
## Description
This is some code from perform_seek_to_offset() from gstdownloadbuffer.c
/* until we receive the FLUSH_STOP from this seek, we skip data */
dlbuf->seeking = TRUE;
dlbuf->write_pos = offset;
dlbuf->filling = FALSE;
GST_DOWNLOAD_BUFFER_MUTEX_UNLOCK (dlbuf);
GST_DEBUG_OBJECT (dlbuf, "Seeking to %" G_GUINT64_FORMAT, offset);
event =
gst_event_new_seek (1.0, GST_FORMAT_BYTES,
GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE, GST_SEEK_TYPE_SET, offset,
GST_SEEK_TYPE_NONE, -1);
res = gst_pad_push_event (dlbuf->sinkpad, event);
GST_DOWNLOAD_BUFFER_MUTEX_LOCK (dlbuf);
return res;
Problem is: what happens if the seek fails? `write_pos` has already been set to the attempted seek position.
What I've seen happening next is that then downloadbuffer waits endlessly for that data with the offset of the seek to arrive; which never happens because gst_download_buffer_chain() has this check:
/* while we didn't receive the newsegment, we're seeking and we skip data */
if (dlbuf->seeking)
goto out_seeking;
(and downloadbuffer falsely believes the seek went through)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/307queue2: Add the avg-out-rate property2021-09-24T11:09:26ZBugzilla Migration Userqueue2: Add the avg-out-rate property## Submitted by Seungha Yang
**[Link to original bug (#797017)](https://bugzilla.gnome.org/show_bug.cgi?id=797017)**
## Description
Straightforward translation of 45fa81e and 1ff80fb
for out rate estimation. This could be helpful ...## Submitted by Seungha Yang
**[Link to original bug (#797017)](https://bugzilla.gnome.org/show_bug.cgi?id=797017)**
## Description
Straightforward translation of 45fa81e and 1ff80fb
for out rate estimation. This could be helpful for
an application to monitor data rate such as network
throughput and etc.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/306Warning log printed when running glvideomixer command2021-09-24T11:09:26ZBugzilla Migration UserWarning log printed when running glvideomixer command## Submitted by Qi Hou
**[Link to original bug (#797007)](https://bugzilla.gnome.org/show_bug.cgi?id=797007)**
## Description
Reproduce steps:
1. Boot up the system;
2. Run below command:
$ gst-launch-1.0 glvideomixer backg...## Submitted by Qi Hou
**[Link to original bug (#797007)](https://bugzilla.gnome.org/show_bug.cgi?id=797007)**
## Description
Reproduce steps:
1. Boot up the system;
2. Run below command:
$ gst-launch-1.0 glvideomixer background=2 name=m sink_1::xpos=200 sink_1::ypos=200 sink_2::xpos=400 sink_2::ypos=400 sink_2::alpha=0.5 ! glimagesink sync=false uridecodebin uri=file:///mnt/src/H264Dec/Conformance/Resolution/H264_BP12_320x240_25_384_MP3_48_320_2.avi ! m. uridecodebin uri=file:///mnt/src/H264Dec/Conformance/Resolution/H264_BP12_320x240_25_384_MP3_48_320_2.avi ! m. uridecodebin uri=file:///mnt/src/H264Dec/Conformance/Resolution/H264_BP12_320x240_25_384_MP3_48_320_2.avi ! m.
Actual result:
Below warning log print but image showed correctly
(gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '1'
(gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '2'
Actual result:
Below warning log print but image showed correctly
(gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '1'
(gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '2'
Log:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"(GstGLDisplayWayland)\ gldisplaywayland0";
====== AIUR: 4.4.3 build on Aug 4 2018 10:38:52. ======
Core: AVI_PARSER_03.05.29 build on Aug 31 2017 09:15:57
file: /usr/lib/imx-mm/parser/lib_avi_parser_arm_elinux.so.3.1
====== AIUR: 4.4.3 build on Aug 4 2018 10:38:52. ======
Core: AVI_PARSER_03.05.29 build on Aug 31 2017 09:15:57
file: /usr/lib/imx-mm/parser/lib_avi_parser_arm_elinux.so.3.1
====== AIUR: 4.4.3 build on Aug 4 2018 10:38:52. ======
Core: AVI_PARSER_03.05.29 build on Aug 31 2017 09:15:57
file: /usr/lib/imx-mm/parser/lib_avi_parser_arm_elinux.so.3.1
------------------------
------------------------
Track 00 [video_0] Enabled
------------------------
Track 00 [video_0] Enabled
Duration: 0:01:22.200000000
Duration: 0:01:22.200000000
Track 00 [video_0] Enabled
Language: und
Duration: 0:01:22.200000000
Language: und
Mime:
video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)byte-stream, width=(int)320, height=(int)240, framerate=(fraction)25/1
Mime:
video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)byte-stream, width=(int)320, height=(int)240, framerate=(fraction)25/1
Language: und
------------------------
Mime:
video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)byte-stream, width=(int)320, height=(int)240, framerate=(fraction)25/1
------------------------
------------------------
====== VPUDEC: 4.4.3 build on Aug 4 2018 10:39:18. ======
====== VPUDEC: 4.4.3 build on Aug 4 2018 10:39:18. ======
====== VPUDEC: 4.4.3 build on Aug 4 2018 10:39:18. ======
wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Aug 4 2018 10:20:40)
wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Aug 4 2018 10:20:40)
wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Aug 4 2018 10:20:40)
vpulib: 1.1.1
firmware: 1.1.1.65535
vpulib: 1.1.1
vpulib: 1.1.1
firmware: 1.1.1.65535
firmware: 1.1.1.65535
------------------------
------------------------
Track 01 [audio_0] Enabled
------------------------
Track 01 [audio_0] Enabled
Track 01 [audio_0] Enabled
Duration: 0:01:22.248000000
Duration: 0:01:22.248000000
Language: und
Language: und
Duration: 0:01:22.248000000
Mime:
audio/mpeg, mpegversion=(int)1, channels=(int)2, rate=(int)48000, bitrate=(int)320000
Language: und
Mime:
audio/mpeg, mpegversion=(int)1, channels=(int)2, rate=(int)48000, bitrate=(int)320000
------------------------
Mime:
audio/mpeg, mpegversion=(int)1, channels=(int)2, rate=(int)48000, bitrate=(int)320000
------------------------
------------------------
====== BEEP: 4.4.3 build on Aug 4 2018 10:38:59. ======
Core: MP3 decoder Wrapper build on Jan 11 2018 10:20:25
file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm_elinux.so.3
====== BEEP: 4.4.3 build on Aug 4 2018 10:38:59. ======
Core: MP3 decoder Wrapper build on Jan 11 2018 10:20:25
file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm_elinux.so.3
CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.01_ARMV8 build on Jan 11 2018 10:05:45.
CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.01_ARMV8 build on Jan 11 2018 10:05:45.
====== BEEP: 4.4.3 build on Aug 4 2018 10:38:59. ======
Core: MP3 decoder Wrapper build on Jan 11 2018 10:20:25
file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm_elinux.so.3
CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.01_ARMV8 build on Jan 11 2018 10:05:45.
(gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '1'
(gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '2'
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:41.116603250
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Total showed frames (2057), playing for (0:00:41.118146125), fps (50.027).
Freeing pipeline ...https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/304Problems deserializing stream-start events2021-09-24T11:09:26ZBugzilla Migration UserProblems deserializing stream-start events## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#796806)](https://bugzilla.gnome.org/show_bug.cgi?id=796806)**
## Description
> 0:00:07.399046676 12893 0x7f6d700040a0 DEBUG rtpgstdepay gstrtpgstdepay.c:2...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#796806)](https://bugzilla.gnome.org/show_bug.cgi?id=796806)**
## Description
> 0:00:07.399046676 12893 0x7f6d700040a0 DEBUG rtpgstdepay gstrtpgstdepay.c:290:read_event:`<depayloader>` parsing event GstEventStreamStart, stream-id=(string)d9486e4ba1afa28e746e6a227057a1bbffd29ae47871dbe2c22d900098420579, flags=(GstStreamFlags)GST_STREAM_FLAG_NONE, group-id=(uint)7, stream=(GstStream)"\(GstStream\)\ stream0";
> 0:00:07.399060467 12893 0x7f6d700040a0 WARN structure gststructure.c:1974:gst_structure_parse_field: failed to parse value stream=(GstStream)(GstStream) stream0eam0";
> 0:00:07.399073720 12893 0x7f6d700040a0 WARN structure gststructure.c:2042:priv_gst_structure_parse_fields: Failed to parse field, r=stream=(GstStream)(GstStream) stream0eam0";
There are multiple problems here:
a) There's the stream in here now, which is not serializable. In older versions of GStreamer this was not a problem and as such it's arguably a backwards compatibility breakage
Not sure what we can do about that, other than letting deserialization skip over fields that it can't deserialize... which might have other problems if they are fields that are actually expected to be there (and then other code dereferences a NULL later)
b) Trying to deserialize the stream field just completely falls apart, not sure what the parsing code tries to do there at all. This might also affect other structureshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/303flowcombiner: update_pad_flow should check that the pad is inside the combiner2021-09-24T11:09:27ZBugzilla Migration Userflowcombiner: update_pad_flow should check that the pad is inside the combiner## Submitted by Xabier Rodríguez Calvar `@calvaris`
Assigned to **Xabier Rodríguez Calvar `@calvaris`**
**[Link to original bug (#796794)](https://bugzilla.gnome.org/show_bug.cgi?id=796794)**
## Description
Created attachment 3730...## Submitted by Xabier Rodríguez Calvar `@calvaris`
Assigned to **Xabier Rodríguez Calvar `@calvaris`**
**[Link to original bug (#796794)](https://bugzilla.gnome.org/show_bug.cgi?id=796794)**
## Description
Created attachment 373000
patch
Currently it is not doing that and that can create issues
~~**Patch 373000**~~, "patch":
[0001-flowcombiner-update_pad_flow-check-for-the-pad-to-ha.patch](/uploads/9fd0b8d7e3865a4b4a13ad07fc2705e6/0001-flowcombiner-update_pad_flow-check-for-the-pad-to-ha.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/302miniobject: Locking functionality complicated, unused/misused and not having ...2023-05-31T09:02:00ZBugzilla Migration Userminiobject: Locking functionality complicated, unused/misused and not having any advantage over refcount-based writability## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#796744)](https://bugzilla.gnome.org/show_bug.cgi?id=796744)**
## Description
While working on a solution for [bug 796692](https://bugzilla.gnome.org/show_bug.cgi?id=...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#796744)](https://bugzilla.gnome.org/show_bug.cgi?id=796744)**
## Description
While working on a solution for [bug 796692](https://bugzilla.gnome.org/show_bug.cgi?id=796692), I looked at the locking functionality in more detail and came to the conclusion that we better get rid of it for 2.0, and ideally for 1.0 too in one way or another (see below).
To shortly reiterate what it is for and how it works:
- it decouples reference count from writability of the objects
- it requires explicit lock/unlock calls with the EXCLUSIVE flag whenever something "takes ownership" of the object. This is basically a reference count again, that does not decide over the object lifetime. 0/1 means object is writable, > 1 means it is not
- it contains a second component which is the read/write mapping part. Once locked readable, only readable locks are possible, once writeable/readwrite all is possible. And write locks require the object to have an exclusive count of 0 or 1 to succeed
So in short: we have a second reference count for deciding writability, and at the same time keep track of read/write mapping of the object. In an atomic way.
This was introduced for bindings: apart from C++/Rust (and possibly some other languages) you don't have explicit control over the reference counting so could accidentially end up with non-writable objects although they should be writable, or you could share the object in multiple places but the refcount is still 1.
----
So why I believe we should get rid of this is the following:
1) Nobody outside gstmemory.c, gstbuffer.c and gstminiobject.c is using these functions but everybody who is doing anything with GstMemory should to modify the writability of the object correct
2) Bindings can't make automatic use of this (except for C++/Rust possibly), and nowadays don't, and also no user-code in bindings is making use of these functions. So the original goal was clearly not achieved
3) It is only used for GstMemory right now and we can't use it for anything else existing because that would break ABI. So even if it was useful, its usefulness would have no effect because most code does not work with GstMemory but other things
4) It's complicated! The implementation is (it involves an atomic spinlock among other things), but more so the concept is. That nobody currently calls that API although they should, should be enough proof of that. Many people already struggle with reference counting, and this adds yet another unfamiliar concept that is not reference counting but almost but not really
5) Current code seems to assume reference count based writability, leading to annoying bugs (if you assume reference counting, your objects are always writable although they shouldn't).
6) It does not bring any advantage compared to using the reference count for writability (for the bindings case see above). If reference count == 1, you can write and keep track of that in an instance variable. If not, you can't. Only the check for the reference count has to be atomic, the other part not. The only theoretical advantage of mixing both things is that you currently can't increase the "exclusive count" if the object is write-locked. The only place that actually checks for this to fail is in gstbuffer.c (all other code silently fails and worse things happen), and even there it is not much of an advantage: what it means is that someone has the memory write mapped, there might be 1000 other places referencing the memory and one of those gave the memory to you and now you want to write map it too. So the only thing that this can do right now is to copy the memory, but the memory is write-mapped and some other thread might do whatever it wants with the content while we're copying it. There's not much gained here.
In this case the original bug is that a write-mapped memory actually has multiple references, and that should've never happened to begin with. Anything that is done from that point onwards is just mitigation, and not very effective.
----
My proposal is to disable the locking functionality by default (make it noops and use the reference count instead, which is what code currently assumes anyway), use the struct field for keeping track for memory mapping only, and only fall back to the current behaviour if an environment variable is used.
I didn't find any code on the Internet that is making use of the API, but quite some code that should make use of it (our own code among other things, whenever dealing with GstMemory) and would potentially have subtile bugs now that would be solved by switching to reference counting instead.
Any opinions, anything I'm missing here?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/301ASYNC_DONE message is dropped leading to hanging application2022-11-10T09:20:50ZBugzilla Migration UserASYNC_DONE message is dropped leading to hanging application## Submitted by Joakim Johansson
**[Link to original bug (#796737)](https://bugzilla.gnome.org/show_bug.cgi?id=796737)**
## Description
Created attachment 372914
Problem with ASYNC_DONE
The ASYNC_DONE message is dropped in gs...## Submitted by Joakim Johansson
**[Link to original bug (#796737)](https://bugzilla.gnome.org/show_bug.cgi?id=796737)**
## Description
Created attachment 372914
Problem with ASYNC_DONE
The ASYNC_DONE message is dropped in gstbin in this scenario. (for more detailed information, see attached sequence)
If change_state is executing at the same time as ASYNC_START is received then is the "polling" flag indicating that gstbin is busy with a state change and the PENDING state is not set but the ASYNC_START message is posted.
But when the ASYNC_DONE is handled, then is pending == VOID_PENDING (initial value received when creating the pipeline) and the ASYNC_DONE is dropped leaving the application hanging.
This might be the same problem as reported in` #740121` and I don't have a solution for the problem that is working.
**Attachment 372914**, "Problem with ASYNC_DONE":
![Problem_with_Async_done](/uploads/986018a264d1d8d13991081e9763f23f/Problem_with_Async_done.jpg)
### See also
* [Bug 740121](https://bugzilla.gnome.org/show_bug.cgi?id=740121)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/300queues: Should influence the number of allocated buffers when possible2022-11-10T09:20:50ZBugzilla Migration Userqueues: Should influence the number of allocated buffers when possible## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#796721)](https://bugzilla.gnome.org/show_bug.cgi?id=796721)**
## Description
As of now, queues completely ignore the allocation query. Though, for sized queue t...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#796721)](https://bugzilla.gnome.org/show_bug.cgi?id=796721)**
## Description
As of now, queues completely ignore the allocation query. Though, for sized queue to work properly, you need enough buffers to be allocated. So far, most of the time this worked because the buffers pools can grow, or dynamic allocation is being used. In this bug report, I'm suggesting that queues, when they are configured with size in number of buffers, should influence the allocation query to ensure that they are useful and that their thread does not cause contention or starvation. Here's an example of starvation cause by queues (requires a driver that do not implement VIDIOC_CREATE_BUFS):
gst-launch-1.0 v4l2src device=/dev/video1 ! queue min-threshold-buffers=10 ! glimagesink sync=0
p.s. This case should also try and increase the latency, worked around using sync=0 here.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/298filesink: Add create-dirs property for creating missing directories in path2022-11-10T09:20:49ZBugzilla Migration Userfilesink: Add create-dirs property for creating missing directories in path## Submitted by Seungha Yang
**[Link to original bug (#796664)](https://bugzilla.gnome.org/show_bug.cgi?id=796664)**
## Description
This could be a convenient way for creating file. I copied the "create-dir" property of curfilesink## Submitted by Seungha Yang
**[Link to original bug (#796664)](https://bugzilla.gnome.org/show_bug.cgi?id=796664)**
## Description
This could be a convenient way for creating file. I copied the "create-dir" property of curfilesinkhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/296Unified names for buffer timestamp meta2022-11-10T09:20:49ZBugzilla Migration UserUnified names for buffer timestamp meta## Submitted by Linus Svensson
**[Link to original bug (#796542)](https://bugzilla.gnome.org/show_bug.cgi?id=796542)**
## Description
I'm currently adding support for wallclock timestamps on a proprietary source element of ours. I t...## Submitted by Linus Svensson
**[Link to original bug (#796542)](https://bugzilla.gnome.org/show_bug.cgi?id=796542)**
## Description
I'm currently adding support for wallclock timestamps on a proprietary source element of ours. I thought it's a good idea to have a common description for wallclock/utc timestamps regardless of what element produces them.
I file this bug to open up for a discussion/conclusion on names for both wallclock and UTC buffer timestamps meta.
I suggest something like:
timestamp/x-utc
timestamp/x-wallclock
It would be very nice if all elements that (potentially) adds wallclock timestamps on buffers can be accessed the same way in downstream elements.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/289allocation: add event notifying downstream about allocated buffers2022-11-10T09:20:49ZBugzilla Migration Userallocation: add event notifying downstream about allocated buffers## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#795747)](https://bugzilla.gnome.org/show_bug.cgi?id=795747)**
## Description
We have a couple of use cases where elements would need to know about the buffers...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#795747)](https://bugzilla.gnome.org/show_bug.cgi?id=795747)**
## Description
We have a couple of use cases where elements would need to know about the buffers which have been allocated upstream:
- [bug 794817](https://bugzilla.gnome.org/show_bug.cgi?id=794817) : Msdk requires to know all the dmabuf fds which will be used.
- [bug 795746](https://bugzilla.gnome.org/show_bug.cgi?id=795746) : in gst-omx when using dynamic buffer mode, we'd like to have the same number of input/output buffers allocated on two consecutive ports.
This is not possible with the current allocation API. The ALLOCATION query retrieves information from downstream but does not propagate its own requirement or notify downstream about what has actually be allocated.
We could solve this by adding a new serialized downstream event sent once buffers have been allocated.
Here is the event I used in my local branch to try solving` #795746`.
It is sent as soon as the pool has been activated.
gst_event_new_custom (GST_EVENT_CUSTOM_DOWNSTREAM,
gst_structure_new ("buffers-allocated",
"nb-buffers", G_TYPE_UINT, min,
"pool", GST_TYPE_BUFFER_POOL, self->out_port_pool, NULL));
We could retrieve the number of buffers from the pool but having a specific field make it usable even if no pool is being used.
Open questions:
- Proper naming of this event and its fields.
- Should we resend this event if extra buffers are being allocated in the pool?
### Blocking
* [Bug 795746](https://bugzilla.gnome.org/show_bug.cgi?id=795746)
* [Bug 794817](https://bugzilla.gnome.org/show_bug.cgi?id=794817)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/287gsttaglist: Add new tag GST_TAG_RFC6381_CODECS2022-11-10T09:20:49ZBugzilla Migration Usergsttaglist: Add new tag GST_TAG_RFC6381_CODECS## Submitted by Yeongjin Jeong
**[Link to original bug (#795708)](https://bugzilla.gnome.org/show_bug.cgi?id=795708)**
## Description
Created attachment 371566
Suggests adding the following new tags: GST_TAG_RFC6381_CODECS.
S...## Submitted by Yeongjin Jeong
**[Link to original bug (#795708)](https://bugzilla.gnome.org/show_bug.cgi?id=795708)**
## Description
Created attachment 371566
Suggests adding the following new tags: GST_TAG_RFC6381_CODECS.
Suggests adding the following new tags: GST_TAG_RFC6381_CODECS.
This is useful for information which creates Live streaming protocol metadata such as M3U8 master playlist or MPD manifest.
Becase, some media player framework such as MSE (Media Source Extensions) need more information 'rfc6381-codecs' to test support for in the current browser.
=> https://developer.mozilla.org/en-US/docs/Web/API/MediaSource/isTypeSupported
Also I uploaded patches that push rfc6381-codecs tag in hlsdemuxer and dashdemuxer.
**Patch 371566**, "Suggests adding the following new tags: GST_TAG_RFC6381_CODECS.":
[0001-gsttaglist-Add-new-tag-GST_TAG_RFC6381_CODECS.patch](/uploads/077f622b1a78911bf263c70e0639c017/0001-gsttaglist-Add-new-tag-GST_TAG_RFC6381_CODECS.patch)
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/286Please add gst_element_sync_state_with_parent_many()2022-11-10T09:20:49ZBugzilla Migration UserPlease add gst_element_sync_state_with_parent_many()## Submitted by Daniel F
**[Link to original bug (#795535)](https://bugzilla.gnome.org/show_bug.cgi?id=795535)**
## Description
When new elements of pipeline are created and added to bin, code has to call gst_element_sync_state_with...## Submitted by Daniel F
**[Link to original bug (#795535)](https://bugzilla.gnome.org/show_bug.cgi?id=795535)**
## Description
When new elements of pipeline are created and added to bin, code has to call gst_element_sync_state_with_parent() for every new element. GStreamer has functions like gst_bin_add_many() which allows to perform the same operation on set of elements. Please also add gst_element_sync_state_with_parent_many(), which would allow to sync multiple elements at once.
Version: 1.14.0https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/285aggregator: Add a property to allow more queuing without increasing the latency2022-11-10T09:20:49ZBugzilla Migration Useraggregator: Add a property to allow more queuing without increasing the latency## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#795444)](https://bugzilla.gnome.org/show_bug.cgi?id=795444)**
## Description
As many will notice, GStreamer requires a lot of thread (hence others doing researc...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#795444)](https://bugzilla.gnome.org/show_bug.cgi?id=795444)**
## Description
As many will notice, GStreamer requires a lot of thread (hence others doing research in thread sharing). Recently, I've been using the fact the aggregator based element implement queueing to avoid creating yet another thread per branch. The problem I had, is that there was no way other then increasing the latency to get my aggregator to just queue, without blocking.
The situation is a special, I'm doing synchronized playback, local and remote in the following pattern (simplified, each sink have different latency settings).
alsasrc ! tee name=tt1
t1. ! audiointerleave ! alsasink (300ms latency)
t1. ! queue ! opusenc ! rtpopuspay ! udpsink (60ms latency)
So basically this node is playing it's own mic to speaker, and sending it over the network, to a similar node. The interleaver is used to aggregate all stream to this single 8 channels codec (each channel is wired to a different speaker). The idea is that what this node is playing locally should play at the same time on the remove node, so for that, I need to transmit the stream a bit earlier.
In this situation though, we quickly block on the audiointerleave queue, as we have limited it's size to avoid uselessly adding more latency. To be honest, in our usecase, this latency property does not seems to provide any benifit, if we drop the latency part and just use it a queue size, we can increase it enough and then the interleaver can accumulate a large enough backlog so that the data sent over udp isn't delayed.
The latency property is not in stable API, so it will stay, I would suggest to add a new property that would let users select a queue size. It could be a queue size, where the queue size become max(latency, queue-size), or if we prefer total-size = latency + queue-size. Note that latency is already a bit confusing because the total latency of an audioaggregator is in fact latency + output-buffer-duration.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/282funnel: Allow request_new_pad with null PadTemplate2021-09-24T11:09:33ZBugzilla Migration Userfunnel: Allow request_new_pad with null PadTemplate## Submitted by Seungha Yang
**[Link to original bug (#794696)](https://bugzilla.gnome.org/show_bug.cgi?id=794696)**
## Description
To fix null pointer access in case of calling request_new_pad()
virtual function directly with nul...## Submitted by Seungha Yang
**[Link to original bug (#794696)](https://bugzilla.gnome.org/show_bug.cgi?id=794696)**
## Description
To fix null pointer access in case of calling request_new_pad()
virtual function directly with null PadTemplate.
funnel has only one sinkpad template and we do not need to refer to
incoming PadTemplate.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/281object: Forward the type of the argument to gst_object_ref() if compiling wit...2021-09-24T11:09:34ZBugzilla Migration Userobject: Forward the type of the argument to gst_object_ref() if compiling with gcc## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#794529)](https://bugzilla.gnome.org/show_bug.cgi?id=794529)**
## Description
See commit message. Same change was done in latest GLib.
If we want to do the same,...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#794529)](https://bugzilla.gnome.org/show_bug.cgi?id=794529)**
## Description
See commit message. Same change was done in latest GLib.
If we want to do the same, various code will have to be fixed up in our
repositories.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/280gstmeta test crashes on sparc2021-09-24T12:00:29ZBugzilla Migration Usergstmeta test crashes on sparc## Submitted by Rolf Eike Beer
**[Link to original bug (#794419)](https://bugzilla.gnome.org/show_bug.cgi?id=794419)**
## Description
Same with 1.12.3 and 1.12.4.
gstmeta.log says:
Running suite(s): GstMeta
75%: Checks: ...## Submitted by Rolf Eike Beer
**[Link to original bug (#794419)](https://bugzilla.gnome.org/show_bug.cgi?id=794419)**
## Description
Same with 1.12.3 and 1.12.4.
gstmeta.log says:
Running suite(s): GstMeta
75%: Checks: 4, Failures: 0, Errors: 1
/var/tmp/portage/media-libs/gstreamer-1.12.4/work/gstreamer-1.12.4/tests/check/gst/gstmeta.c:237:E:general:test_meta_test:0: (after this point) Received signal 10 (Bus error)
FAIL gst/gstmeta (exit status: 1)
gdb says:
```
Program received signal SIGBUS, Bus error.
0xf7f01008 in _priv_gst_registry_chunks_load_plugin () from /var/tmp/portage/media-libs/gstreamer-1.12.4/work/gstreamer-1.12.4-.sparc32/gst/.libs/libgstreamer-1.0.so.0
(gdb) bt
#0 0xf7f01008 in _priv_gst_registry_chunks_load_plugin () from /var/tmp/portage/media-libs/gstreamer-1.12.4/work/gstreamer-1.12.4-.sparc32/gst/.libs/libgstreamer-1.0.so.0
#1 0xf7eee070 in exchange_packets () from /var/tmp/portage/media-libs/gstreamer-1.12.4/work/gstreamer-1.12.4-.sparc32/gst/.libs/libgstreamer-1.0.so.0
#2 0xf7eee994 in plugin_loader_free () from /var/tmp/portage/media-libs/gstreamer-1.12.4/work/gstreamer-1.12.4-.sparc32/gst/.libs/libgstreamer-1.0.so.0
#3 0xf7efde50 in gst_update_registry () from /var/tmp/portage/media-libs/gstreamer-1.12.4/work/gstreamer-1.12.4-.sparc32/gst/.libs/libgstreamer-1.0.so.0
#4 0xf7e7d1b4 in init_post () from /var/tmp/portage/media-libs/gstreamer-1.12.4/work/gstreamer-1.12.4-.sparc32/gst/.libs/libgstreamer-1.0.so.0
#5 0xf7d84594 in g_option_context_parse () from /usr/lib/libglib-2.0.so.0
#6 0xf7f9f80c in gst_check_init () from /var/tmp/portage/media-libs/gstreamer-1.12.4/work/gstreamer-1.12.4-.sparc32/libs/gst/check/.libs/libgstcheck-1.0.so.0
#7 0x00010dd8 in main ()
```
Version: 1.13.91