gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2021-09-24T11:10:51Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/114gstchildproxy: some improvements2021-09-24T11:10:51ZBugzilla Migration Usergstchildproxy: some improvements## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#750189)](https://bugzilla.gnome.org/show_bug.cgi?id=750189)**
## Description
The purpose of these patches is to remove redundant code in GESTrackElement,
I can i...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#750189)](https://bugzilla.gnome.org/show_bug.cgi?id=750189)**
## Description
The purpose of these patches is to remove redundant code in GESTrackElement,
I can imagine a lot of use cases for fetching all the elements exposing a
property in a bin aside from that.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/113gstbuffer: _get_merged_memory: support memories that happen to be consecutive2021-09-24T11:10:51ZBugzilla Migration Usergstbuffer: _get_merged_memory: support memories that happen to be consecutive## Submitted by Ilya Konstantinov
**[Link to original bug (#750103)](https://bugzilla.gnome.org/show_bug.cgi?id=750103)**
## Description
Sometimes GstMemory objects might not be in a parent-child hierarchy which allows them to know ...## Submitted by Ilya Konstantinov
**[Link to original bug (#750103)](https://bugzilla.gnome.org/show_bug.cgi?id=750103)**
## Description
Sometimes GstMemory objects might not be in a parent-child hierarchy which allows them to know that they span a single consecutive memory area.
However, when mapped, they end up being perfectly consecutive. For example, this can happen with GstCoreVideoMemory on Apple platforms.
Wouldn't it be nice if _get_merged_memory will recognize such cases and avoid allocating and memcpy'ing a new buffer in such cases?
Does this make sense?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/112gstevent: add new api for parse seek event2021-09-24T11:10:52ZBugzilla Migration Usergstevent: add new api for parse seek event## Submitted by Jimmy Ohn
**[Link to original bug (#748738)](https://bugzilla.gnome.org/show_bug.cgi?id=748738)**
## Description
generally, when we parse seek event using gst_event_parse_seek function, parameter is too many I think....## Submitted by Jimmy Ohn
**[Link to original bug (#748738)](https://bugzilla.gnome.org/show_bug.cgi?id=748738)**
## Description
generally, when we parse seek event using gst_event_parse_seek function, parameter is too many I think.
For example, If we just want to get the rate value from event, we should use like this gst_event_parse_seek(event, NULL, &rate, NULL, NULL, NULL...).
I agree this is minor problem but I think that If we use segment for parsing event, it would be better.
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/111basetransform: old pool incorrectly disabled2022-11-10T09:20:45ZBugzilla Migration Userbasetransform: old pool incorrectly disabled## Submitted by Andreea Fulger
**[Link to original bug (#748590)](https://bugzilla.gnome.org/show_bug.cgi?id=748590)**
## Description
Created attachment 302519
Check if the new pool is the one we are already using
In gst_base...## Submitted by Andreea Fulger
**[Link to original bug (#748590)](https://bugzilla.gnome.org/show_bug.cgi?id=748590)**
## Description
Created attachment 302519
Check if the new pool is the one we are already using
In gst_base_transform_set_allocation, if the new pool is the same as the old one, it still gets deactivated as there is no check on oldpool != pool as it is already done for basesrc.
**Patch 302519**, "Check if the new pool is the one we are already using":
[0001-DEBUG-basetransform-don-t-accidentally-disable-the-p.patch](/uploads/0c525ea26055cff10e46e8b09dc52baa/0001-DEBUG-basetransform-don-t-accidentally-disable-the-p.patch)
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/110registry: System registry cache file2021-09-24T11:10:52ZBugzilla Migration Userregistry: System registry cache file## Submitted by Dan Nicholson
**[Link to original bug (#748452)](https://bugzilla.gnome.org/show_bug.cgi?id=748452)**
## Description
Right now, the first time a user runs a gstreamer program, it's slowed down by generating the regis...## Submitted by Dan Nicholson
**[Link to original bug (#748452)](https://bugzilla.gnome.org/show_bug.cgi?id=748452)**
## Description
Right now, the first time a user runs a gstreamer program, it's slowed down by generating the registry cache file. Gstreamer should be able to try a system registry cache file if the user's cache file doesn't exist. See previous discussion here:
http://lists.freedesktop.org/archives/gstreamer-devel/2015-March/052181.htmlhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/109bufferpool: in renegotation, bufferpool can be given to element while another...2021-09-24T11:10:53ZBugzilla Migration Userbufferpool: in renegotation, bufferpool can be given to element while another one still uses it## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#748344)](https://bugzilla.gnome.org/show_bug.cgi?id=748344)**
## Description
Suppose the following pipeline:
source ! filter ! sink
Initially i...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#748344)](https://bugzilla.gnome.org/show_bug.cgi?id=748344)**
## Description
Suppose the following pipeline:
source ! filter ! sink
Initially it works in passthrough mode so source gets a bufferpool from sink and uses it.
At some point when filter gets a buffer it decides it can't do passthrough anymore (the user might have set a property to it, for example).
Filter will request a bufferpool from sink. If the caps in the request are the same as source have been using the sink might return the same bufferpool. It sets the bufferpool to active (it already was active) and will use it to push a buffer. In this process filter also sent a reconfigure upstream to make source realize it isn't in passthrough anymore and that it should request a new bufferpool.
At the next source loop it will do the reconfigure and as part of the acquisition of a new bufferpool, set the old one to inactive.
Now filter receives the new buffer from source and tries to get a buffer from the pool to use. This same pool has been stopped by source in its renegotiation and filter will fail because its pool is now unexpectedly flushing.
Adding queues to the pipeline can make this racy as well.
I have an unfinished work that triggers this issue and I'll try to make it into an application so others can easily reproduce it. (Likely uploading it tomorrow)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/108GstObject: add support for setting uniquely numbered names for simplicity, e....2021-09-24T11:10:54ZBugzilla Migration UserGstObject: add support for setting uniquely numbered names for simplicity, e.g. videoqueue-%u## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#748233)](https://bugzilla.gnome.org/show_bug.cgi?id=748233)**
## Description
Created attachment 302051
gstobject: Add support for a format-specifier suffix
...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#748233)](https://bugzilla.gnome.org/show_bug.cgi?id=748233)**
## Description
Created attachment 302051
gstobject: Add support for a format-specifier suffix
Similar to how the default name for an element is automatically assigned to be unique, it would be useful to be able to pass a custom name that can be automatically made unique.
For instance, if I have a program with a complex pipeline with queues in several different contexts (after decoders, after tees, etc), I want to be able to specify a context-specific name such as "video-decoder-queue-%u", "tee-queue-%u", etc which will become "video-decoder-queue-0", "video-decoder-queue-1", and so on. This makes parsing debug logs much easier when you see "video-decoder-queue-12" instead of "queue34".
The attached patch implements this.
gst_element_factory_make (queue, "somequeue-%u");
will create "some-queue-0", "some-queue-1", etc using the same infrastructure as the code that does the default name generation.
~~**Patch 302051**~~, "gstobject: Add support for a format-specifier suffix":
[0001-gstobject-Add-support-for-a-format-specifier-suffix.patch](/uploads/4391d5cb14d70507f0d0d8de9a6ad0e2/0001-gstobject-Add-support-for-a-format-specifier-suffix.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/107buffer: minimize memory copy in _memory_add()2022-11-10T09:20:45ZBugzilla Migration Userbuffer: minimize memory copy in _memory_add()## Submitted by Prashant Gotarne
**[Link to original bug (#747959)](https://bugzilla.gnome.org/show_bug.cgi?id=747959)**
## Description
If all the slots for the memory blocks are full, instead of merging all block to single memory b...## Submitted by Prashant Gotarne
**[Link to original bug (#747959)](https://bugzilla.gnome.org/show_bug.cgi?id=747959)**
## Description
If all the slots for the memory blocks are full, instead of merging all block to single memory block, merge only best consecutive blocks to make a room for new memory block.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/106gstutils: silence clang's -Wcast-align2021-09-24T11:10:56ZBugzilla Migration Usergstutils: silence clang's -Wcast-align## Submitted by Michael Catanzaro `@mcatanzaro`
**[Link to original bug (#747869)](https://bugzilla.gnome.org/show_bug.cgi?id=747869)**
## Description
gstutils.h triggers clang's -Wcast-align warning in every file that includes it. ...## Submitted by Michael Catanzaro `@mcatanzaro`
**[Link to original bug (#747869)](https://bugzilla.gnome.org/show_bug.cgi?id=747869)**
## Description
gstutils.h triggers clang's -Wcast-align warning in every file that includes it. Looks like this code is only compiled when GST_HAVE_UNALIGNED_ACCESS is true, so might as well silence it.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/105osx test failures: cerbero check gstreamer-1.02021-09-24T11:43:33ZBugzilla Migration Userosx test failures: cerbero check gstreamer-1.0## Submitted by Joe Gorse
**[Link to original bug (#747663)](https://bugzilla.gnome.org/show_bug.cgi?id=747663)**
## Description
FAIL: gst/gstvalue
FAIL: pipelines/simple-launch-lines
FAIL: gst/gstbin
FAIL: elements/multiqueue...## Submitted by Joe Gorse
**[Link to original bug (#747663)](https://bugzilla.gnome.org/show_bug.cgi?id=747663)**
## Description
FAIL: gst/gstvalue
FAIL: pipelines/simple-launch-lines
FAIL: gst/gstbin
FAIL: elements/multiqueue
OS X 10.10.2
# Custom cerbero config file for "uninstalled" style build:
from cerbero.config import Architecture
target_arch=Architecture.X86_64
prefix='/Users/jhg/work/Library/Frameworks/GStreamer.framework/Versions/1.0'
allow_parallel_build = True
# Test command:
./cerbero-uninstalled -c osx-x86-64.cbc check gstreamer-1.0
===================================================
GStreamer 1.5.0.1: tests/check/test-suite.log
===================================================
# TOTAL: 96
# PASS: 92
# SKIP: 0
# XFAIL: 0
# FAIL: 4
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: gst/gstvalue
==================
Running suite(s): GstValue
97%: Checks: 35, Failures: 1, Errors: 0
gst/gstvalue.c:490:F:general:test_deserialize_bitmask:0: could not deserialize 0xffffffffffffffff (0)
FAIL gst/gstvalue (exit status: 1)
FAIL: pipelines/simple-launch-lines
===================================
Running suite(s): Pipelines
50%: Checks: 4, Failures: 0, Errors: 2
pipelines/simple-launch-lines.c:55:E:linear:test_2_elements:0: (after this point) Received signal 11 (Segmentation fault: 11)
pipelines/simple-launch-lines.c:55:E:linear:test_typefind_force_sink_caps:0: (after this point) Received signal 11 (Segmentation fault: 11)
FAIL pipelines/simple-launch-lines (exit status: 2)
FAIL: gst/gstbin
================
Running suite(s): GstBin
95%: Checks: 20, Failures: 0, Errors: 1
gst/gstbin.c:184:E:bin tests:test_eos:0: (after this point) Received signal 11 (Segmentation fault: 11)
FAIL gst/gstbin (exit status: 1)
FAIL: elements/multiqueue
=========================
FIXME: skipping test test_output_order because it's broken
Running suite(s): multiqueue
88%: Checks: 9, Failures: 0, Errors: 1
elements/multiqueue.c:151:E:general:test_simple_shutdown_while_running:0: (after this point) Received signal 11 (Segmentation fault: 11)
FAIL elements/multiqueue (exit status: 1)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/104test: filesink: add test to verify append mode2021-09-24T11:10:57ZBugzilla Migration Usertest: filesink: add test to verify append mode## Submitted by Prashant Gotarne
**[Link to original bug (#747435)](https://bugzilla.gnome.org/show_bug.cgi?id=747435)**
## Description
Add testcase to verify append mode property for filesink element## Submitted by Prashant Gotarne
**[Link to original bug (#747435)](https://bugzilla.gnome.org/show_bug.cgi?id=747435)**
## Description
Add testcase to verify append mode property for filesink elementhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/103basesrc: Enable pushing frames from OS thread2021-09-24T11:10:58ZBugzilla Migration Userbasesrc: Enable pushing frames from OS thread## Submitted by Ilya Konstantinov
**[Link to original bug (#747414)](https://bugzilla.gnome.org/show_bug.cgi?id=747414)**
## Description
Current GstBaseSrc in push-mode calls into element code whenever it expects element to yield da...## Submitted by Ilya Konstantinov
**[Link to original bug (#747414)](https://bugzilla.gnome.org/show_bug.cgi?id=747414)**
## Description
Current GstBaseSrc in push-mode calls into element code whenever it expects element to yield data. It's desired to have a mode of operation where GstBaseSrc is called-into when data is available (i.e. inversion of control in relation to our current mode).
There are OS frameworks that deliver data, as it becomes available, through a callback called on an OS thread. It would be desirable, therefore, to push data from this OS thread, rather than having to deliver it (e.g. via GAsyncQueue) back to the GstTask thread.
The rationale -- "solving" this with a GAsyncQueue has two problems:
- with a small queue, latency, perf will suffer due to blocking on kernel lock
- with a big queue, latency can grow too large
Both problems can cause frame-drops -- the first at the source (due to buffer overrun), the later at the sink (due to too-late frames)
Both problems can be avoided by simply not doing it in the first place.
Also, each element that's currently in this situation ends up rolling its own solution -- GAsyncQueue etc. -- complicating the code.
ELEMENTS THAT COULD BENEFIT
Basically, a lot of Apple elements:
* osxaudiosrc
* avfvideosrc
* vtenc_h264
* vtdec
ANSWERS TO POSSIBLE CONCERNS
Such OS frameworks typically implement their own buffering, and their callbacks shouldn't be treated as strictly as - say - interrupts in the kernel. In other words, one shouldn't rush to copy the data aside from the OS buffer and finish the operation in another thread. In fact, usually zero-copy is possible.
Elements don't expect each other to be on the same thread (e.g. due to GstQueue elements), so switching elements mid-pipeline is not expected to upset anybody.
Since things expect a GstTask to associate with, the original GstTask can be used. The original task's open and close (or lock / unlock?) will ensure that the OS framework callback is enabled/disabled.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/102basetransform: Add buffer list support2021-09-24T11:10:58ZBugzilla Migration Userbasetransform: Add buffer list support## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746544)](https://bugzilla.gnome.org/show_bug.cgi?id=746544)**
## Description
Currently basetransform has no buffer list support at all. At least for elements that do...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#746544)](https://bugzilla.gnome.org/show_bug.cgi?id=746544)**
## Description
Currently basetransform has no buffer list support at all. At least for elements that don't do much, like capsfilter and identity, this would be really useful to have. OTOH for elements that do actual processing, it can reduce latency to split the buffer list into separate buffers and even can make the difference between buffers arriving in time or too late inside the sink.
I would propose to add a transform_list() and transform_list_ip() vfunc to basetransform for this, and let the default do what is happening right now already. And inside identity and capsfilter it just passes through the list.
Thoughts?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/101queue: Add property to allow pushing all queued buffers together2021-09-24T11:10:58ZBugzilla Migration Userqueue: Add property to allow pushing all queued buffers together## Submitted by Jose Antonio Santos Cadenas
**[Link to original bug (#746524)](https://bugzilla.gnome.org/show_bug.cgi?id=746524)**
## Description
Created attachment 299946
queue: Add property to allow pushing all queued buffers t...## Submitted by Jose Antonio Santos Cadenas
**[Link to original bug (#746524)](https://bugzilla.gnome.org/show_bug.cgi?id=746524)**
## Description
Created attachment 299946
queue: Add property to allow pushing all queued buffers together
Attached patch adds a property that allows queue to send a buffer list with all the
queued buffers currently in the queue. If there are other kind of data in the queue order is preserved I mean, buffer list only contains buffers up to an event or a query.
~~**Patch 299946**~~, "queue: Add property to allow pushing all queued buffers together":
[0001-queue-Add-property-to-allow-pushing-all-queued-buffe.patch](/uploads/61fe2cbbf12d2ecaa921030735cfa91e/0001-queue-Add-property-to-allow-pushing-all-queued-buffe.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/100Can't set flags on Gst.Pad2021-09-24T11:10:59ZBugzilla Migration UserCan't set flags on Gst.Pad## Submitted by Andrew
**[Link to original bug (#746320)](https://bugzilla.gnome.org/show_bug.cgi?id=746320)**
## Description
There's no way to set flags on Gst.Pad.
Gst.Pad.flags is also an int, not an instance of Gst.PadFlags
V...## Submitted by Andrew
**[Link to original bug (#746320)](https://bugzilla.gnome.org/show_bug.cgi?id=746320)**
## Description
There's no way to set flags on Gst.Pad.
Gst.Pad.flags is also an int, not an instance of Gst.PadFlags
Version: 1.2.1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/99gstpad: relinking outside streaming thread sometimes results in events gettin...2021-09-24T11:10:59ZBugzilla Migration Usergstpad: relinking outside streaming thread sometimes results in events getting lost## Submitted by Matej `@Knopp`
**[Link to original bug (#746302)](https://bugzilla.gnome.org/show_bug.cgi?id=746302)**
## Description
Created attachment 299530
Patch
The problem that's quite racy and difficult to reproduce. B...## Submitted by Matej `@Knopp`
**[Link to original bug (#746302)](https://bugzilla.gnome.org/show_bug.cgi?id=746302)**
## Description
Created attachment 299530
Patch
The problem that's quite racy and difficult to reproduce. Basically we are relinking element outside streaming thread, which occasionally results in some sticky events getting lost.
The problem is in push_sticky. While the gst_pad_push_event_unchecked call is in progress, the pad peer changes. But regardless of that, ev->received is set to TRUE.
Patch corrects this by checking if the peerpad really has received the event. If not, it will be resend in next check_sticky.
~~**Patch 299530**~~, "Patch":
[0001-gstpad-check-if-peer-pad-really-received-event-befor.patch](/uploads/51d70166dad71eedc292308f5acfb751/0001-gstpad-check-if-peer-pad-really-received-event-befor.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/98[2.0] allocation query: Minimum should become global to the query rather then...2022-04-19T06:37:32ZBugzilla Migration User[2.0] allocation query: Minimum should become global to the query rather then per pool## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746213)](https://bugzilla.gnome.org/show_bug.cgi?id=746213)**
## Description
The minimum as found in allocation pool is the minimum buffer required by a segment...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746213)](https://bugzilla.gnome.org/show_bug.cgi?id=746213)**
## Description
The minimum as found in allocation pool is the minimum buffer required by a segment of a pipeline to function. Having this minimum spread across the allocation pool array is inconvenient. In 2.0 we should most likely make this field global to the query so updating it is easier.
Version: 2.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/97allocation query: Add API to increase and update the minimum require buffers2022-04-07T06:00:01ZBugzilla Migration Userallocation query: Add API to increase and update the minimum require buffers## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746212)](https://bugzilla.gnome.org/show_bug.cgi?id=746212)**
## Description
As it goes, the minimum buffers in an allocation pool has a special meaning. It rep...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#746212)](https://bugzilla.gnome.org/show_bug.cgi?id=746212)**
## Description
As it goes, the minimum buffers in an allocation pool has a special meaning. It represent the minimum amount of buffers required in order for a segment of a pipeline to function. Element that retain buffers must update this value in order to ensure the pool will function.
Unfortunately this value is not exposed globally, but rather per allocation pool. This means that to update/increase this value, one need to iterate over the pool list, remove pool which have a maximum too small and update minimum. In order to make this task easier, we could add utilities in the core API. Currently this is implemented by videorate only, but queues with minimum threshold should implement that too, deinterlace element, and many others may also need to do so.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/94queue/queue2/multiqueue: LATENCY query handling could be improved2022-11-10T09:20:45ZBugzilla Migration Userqueue/queue2/multiqueue: LATENCY query handling could be improved## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#744337)](https://bugzilla.gnome.org/show_bug.cgi?id=744337)**
## Description
+++ This bug was initially created as a clone of [Bug 744106](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#744337)](https://bugzilla.gnome.org/show_bug.cgi?id=744337)**
## Description
+++ This bug was initially created as a clone of [Bug 744106](https://bugzilla.gnome.org/show_bug.cgi?id=744106) +++
queue should try to use the CONVERT query, or estimate the buffer/byte rate over time and update its min/max latencies from its max-size-* and min-size-* properties.
queue2 and multiqueue should do the same, but currently they don't even do that for the time limits.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/93bufferpool: Don't free GstBuffer if memory isn't writable2022-11-10T09:20:45ZBugzilla Migration Userbufferpool: Don't free GstBuffer if memory isn't writable## Submitted by kevin
**[Link to original bug (#744303)](https://bugzilla.gnome.org/show_bug.cgi?id=744303)**
## Description
GstBuffer will be freed if memory isn't writable. The reason of the memory can't writable is gst_buffer_cop...## Submitted by kevin
**[Link to original bug (#744303)](https://bugzilla.gnome.org/show_bug.cgi?id=744303)**
## Description
GstBuffer will be freed if memory isn't writable. The reason of the memory can't writable is gst_buffer_copy_into() will increase the ref count of the memory. The expect is reuse video buffer without free it. The buffer will writable later. Do we have some general solution for it?
I have asked the question in gstreamer-dev mail list:
http://lists.freedesktop.org/archives/gstreamer-devel/2015-January/051137.html
Version: 1.4.1