gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2021-09-24T11:09:42Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/255query: Add new GstQueryInterleaving2021-09-24T11:09:42ZBugzilla Migration Userquery: Add new GstQueryInterleaving## Submitted by Seungha Yang
**[Link to original bug (#790257)](https://bugzilla.gnome.org/show_bug.cgi?id=790257)**
## Description
Most elements which have responsibility for posting buffering message
(queue2 or multiqueue) have ...## Submitted by Seungha Yang
**[Link to original bug (#790257)](https://bugzilla.gnome.org/show_bug.cgi?id=790257)**
## Description
Most elements which have responsibility for posting buffering message
(queue2 or multiqueue) have limited information of A/V stream interleaving.
So, if a container level stream is badly interleaved, the buffering message
posted by the element is unreliable. This "Interleaving" query
can be used for the elements to query actual interleaving of current stream.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/254basedemux: new base class for demux elements2021-09-24T11:09:42ZBugzilla Migration Userbasedemux: new base class for demux elements## Submitted by Seungha Yang
**[Link to original bug (#790047)](https://bugzilla.gnome.org/show_bug.cgi?id=790047)**
## Description
To all maintainers
Gstreamer has several base classes for core components such as
src/sink, p...## Submitted by Seungha Yang
**[Link to original bug (#790047)](https://bugzilla.gnome.org/show_bug.cgi?id=790047)**
## Description
To all maintainers
Gstreamer has several base classes for core components such as
src/sink, parse, decoder/encoder, etc. BUT demux elements are fragmented and has their flow. Actually demux's work flow is quite similar to each other.
Pushing input buffer to adapter, read header, expose src pads, feed demuxed ES streams, and so on.
Are there basedemux in backlog of maintainers, or even ongoing? Since we now might need to implement GstStream API to almost demux elements, right now seems to good timing to add the basedemux.... What do you think?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/250API: new API to retrieve the device unique ID2021-09-24T11:09:43ZBugzilla Migration UserAPI: new API to retrieve the device unique ID## Submitted by Philippe Normand `@philn`
**[Link to original bug (#789809)](https://bugzilla.gnome.org/show_bug.cgi?id=789809)**
## Description
Ideally the ID would be a string, like a UUID or something similar. Opinions?
This...## Submitted by Philippe Normand `@philn`
**[Link to original bug (#789809)](https://bugzilla.gnome.org/show_bug.cgi?id=789809)**
## Description
Ideally the ID would be a string, like a UUID or something similar. Opinions?
This would be needed in WebKit, for the "RealtimeMediaSourceCenter" and its friend the "CaptureDeviceManager", responsible for probing audio/video capture devices.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/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/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/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/229gst-stats: do stats on latency2022-11-10T09:20:48ZBugzilla Migration Usergst-stats: do stats on latency## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#781276)](https://bugzilla.gnome.org/show_bug.cgi?id=781276)**
## Description
I needed to do some stats on the latency information reported by the 'latency' tr...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#781276)](https://bugzilla.gnome.org/show_bug.cgi?id=781276)**
## Description
I needed to do some stats on the latency information reported by the 'latency' tracer. gst-stats seem to be the best place to do that.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/226GstUri: add function to parse uri and set properties to object2022-11-10T09:20:48ZBugzilla Migration UserGstUri: add function to parse uri and set properties to object## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779765)](https://bugzilla.gnome.org/show_bug.cgi?id=779765)**
## Description
Created attachment 347499
pick up properties and set to object
As some core devel...## Submitted by Marc Leeman `@den_erpel`
**[Link to original bug (#779765)](https://bugzilla.gnome.org/show_bug.cgi?id=779765)**
## Description
Created attachment 347499
pick up properties and set to object
As some core developers sometimes claim, we (Barco) do 'crazy' stuff with URIs.
This patch adds the functionality to pick up the key value pairs from a URI and set them to an object.
This allows to encode element properties into an URI and have an easy way to set it onto self.
e.g.
rtsp://.......?debug=true&protocols=2
This combines with a number of patches we've submitted in the past; I will refresh them in the following days based on this submission.
~~**Patch 347499**~~, "pick up properties and set to object":
[0001-gsturi-add-uri-parser-to-set-props-to-obj.patch](/uploads/9df140a811b23f9ba67f9b789279627c/0001-gsturi-add-uri-parser-to-set-props-to-obj.patch)
Version: 1.10.4
### Blocking
* [Bug 738608](https://bugzilla.gnome.org/show_bug.cgi?id=738608)
* [Bug 746818](https://bugzilla.gnome.org/show_bug.cgi?id=746818)
* [Bug 748042](https://bugzilla.gnome.org/show_bug.cgi?id=748042)
* [Bug 779850](https://bugzilla.gnome.org/show_bug.cgi?id=779850)
* [Bug 779855](https://bugzilla.gnome.org/show_bug.cgi?id=779855)
* [Bug 780033](https://bugzilla.gnome.org/show_bug.cgi?id=780033)
* [Bug 746762](https://bugzilla.gnome.org/show_bug.cgi?id=746762)
* [Bug 781441](https://bugzilla.gnome.org/show_bug.cgi?id=781441)
* [Bug 781442](https://bugzilla.gnome.org/show_bug.cgi?id=781442)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/213Playlist Support2022-11-10T09:20:47ZBugzilla Migration UserPlaylist Support## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#776613)](https://bugzilla.gnome.org/show_bug.cgi?id=776613)**
## Description
This is useful to support remote playlists and other formats than a simple
URI/filenam...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#776613)](https://bugzilla.gnome.org/show_bug.cgi?id=776613)**
## Description
This is useful to support remote playlists and other formats than a simple
URI/filename list. totem-plparser is rather small and doesn't do much more
than the name suggests.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/207Need new error code for signal loss2022-11-10T09:20:47ZBugzilla Migration UserNeed new error code for signal loss## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#774667)](https://bugzilla.gnome.org/show_bug.cgi?id=774667)**
## Description
+++ This bug was initially created as a clone of [Bug 774629](https://bugzilla.gnome.or...## Submitted by Vivia Nikolaidou `@vivia`
**[Link to original bug (#774667)](https://bugzilla.gnome.org/show_bug.cgi?id=774667)**
## Description
+++ This bug was initially created as a clone of [Bug 774629](https://bugzilla.gnome.org/show_bug.cgi?id=774629) +++
Tim-Philipp Müller changed [bug 774629](https://bugzilla.gnome.org/show_bug.cgi?id=774629)
What Removed Added
CC t.i.m@zen.co.uk
Comment # 5 on [bug 774629](https://bugzilla.gnome.org/show_bug.cgi?id=774629) from Tim-Philipp Müller
I think we should be making use of the new _WITH_DETAILS API for
error/warning/info messages here, since the error code itself is really quite
meaningless and the app can't rely on the error string (might be translated in
future) or the debug string (should not be looked at).
Or add a new error code for it.
Or use a different kind of message (maybe progress messages?)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/206streamcollection: Add gst_stream_collection_get_stream_list api2023-02-03T20:53:50ZBugzilla Migration Userstreamcollection: Add gst_stream_collection_get_stream_list api## Submitted by Wonchul Lee
**[Link to original bug (#774602)](https://bugzilla.gnome.org/show_bug.cgi?id=774602)**
## Description
Application seems to useful if the streamcollection provide a list of streams according to the type o...## Submitted by Wonchul Lee
**[Link to original bug (#774602)](https://bugzilla.gnome.org/show_bug.cgi?id=774602)**
## Description
Application seems to useful if the streamcollection provide a list of streams according to the type of stream when it counts number of audio/video/text streams or selecting one.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/204GstStream: need API to deactivate streams2022-11-10T09:20:47ZBugzilla Migration UserGstStream: need API to deactivate streams## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774321)](https://bugzilla.gnome.org/show_bug.cgi?id=774321)**
## Description
+++ This bug was initially created as a clone of [Bug 646638](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774321)](https://bugzilla.gnome.org/show_bug.cgi?id=774321)**
## Description
+++ This bug was initially created as a clone of [Bug 646638](https://bugzilla.gnome.org/show_bug.cgi?id=646638) +++
We now have new API to select and thus also deselect streams in form of the SELECT_STREAMS event.
We also want API that can be used to deactivate streams, which goes one step further, and would instruct the demuxer to not even read/demux/expose it.
This could be used for example in a thumbnailing application to deactivate decoding of all audio streams, or in GES which uses separate sources/decodebins for audio/video from the same input file.
Question is if we only want to be able to deactivate streams, or if we also want to allow re-activating them again later at runtime.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/203baseparse: do seek I/O in streaming thread and post progress messages for seek2021-09-24T11:09:59ZBugzilla Migration Userbaseparse: do seek I/O in streaming thread and post progress messages for seek## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774314)](https://bugzilla.gnome.org/show_bug.cgi?id=774314)**
## Description
+++ This bug was initially created as a clone of [Bug 613351](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#774314)](https://bugzilla.gnome.org/show_bug.cgi?id=774314)**
## Description
+++ This bug was initially created as a clone of [Bug 613351](https://bugzilla.gnome.org/show_bug.cgi?id=613351) +++
BaseParse (and other parsers/demuxers) should not do any I/O in the seek handler, as currently done in gst_base_parse_locate_time(). This should be
done from the streaming thread instead, and the element should maybe also post PROGRESS messages on the bus about seek started/finished/failed.
### Blocking
* [Bug 617905](https://bugzilla.gnome.org/show_bug.cgi?id=617905)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/201core(debug): hard to distinguish related log at multi-instance env2022-11-10T09:20:47ZBugzilla Migration Usercore(debug): hard to distinguish related log at multi-instance env## Submitted by Eunhae Choi
**[Link to original bug (#773463)](https://bugzilla.gnome.org/show_bug.cgi?id=773463)**
## Description
This is for debug env.
When we do debug with log message, it is hard to recoginize which element...## Submitted by Eunhae Choi
**[Link to original bug (#773463)](https://bugzilla.gnome.org/show_bug.cgi?id=773463)**
## Description
This is for debug env.
When we do debug with log message, it is hard to recoginize which element/object is included in which pipeline in multi-instance environment.
We've added family-id for grouping for each pipeline at downstream (I've attached the patch).
To get better idea and make it public, I registered this bug.
Please share your idea and suggest better solution.
Thank you.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/198element: bin: add flag to skip uniqueness checking2021-09-24T11:10:01ZBugzilla Migration Userelement: bin: add flag to skip uniqueness checking## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773095)](https://bugzilla.gnome.org/show_bug.cgi?id=773095)**
## Description
If a bin/element is sure that its children has unique name then skipping
the uniqness c...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773095)](https://bugzilla.gnome.org/show_bug.cgi?id=773095)**
## Description
If a bin/element is sure that its children has unique name then skipping
the uniqness check may be a significant optimization if there is a lot of
children.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/196paramspecs: Add int range2021-09-24T11:10:02ZBugzilla Migration Userparamspecs: Add int range## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773090)](https://bugzilla.gnome.org/show_bug.cgi?id=773090)**
## Description
Probably useful for someone else too.## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773090)](https://bugzilla.gnome.org/show_bug.cgi?id=773090)**
## Description
Probably useful for someone else too.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/195task: Add set_default_task_pool_type API.2023-02-03T20:53:50ZBugzilla Migration Usertask: Add set_default_task_pool_type API.## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773087)](https://bugzilla.gnome.org/show_bug.cgi?id=773087)**
## Description
API to set the default task pool is useful for applications that use
a custom task pool...## Submitted by Stian Selnes `@stianse`
**[Link to original bug (#773087)](https://bugzilla.gnome.org/show_bug.cgi?id=773087)**
## Description
API to set the default task pool is useful for applications that use
a custom task pool instead of GstTaskPool.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/194tracer: Allow outputting logs (in particular tracer logs) in Common Trace For...2021-09-24T11:10:04ZBugzilla Migration Usertracer: Allow outputting logs (in particular tracer logs) in Common Trace Format (ctf)## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#772936)](https://bugzilla.gnome.org/show_bug.cgi?id=772936)**
## Description
Currently we are going through the standard GStreamer logging subsystem to output ...## Submitted by Thibault Saunier `@thiblahute`
**[Link to original bug (#772936)](https://bugzilla.gnome.org/show_bug.cgi?id=772936)**
## Description
Currently we are going through the standard GStreamer logging subsystem to output the tracer logs, but it has several issues:
* it has not been designed to output structured data
* it is a plain text format which is not optimal at all in term of speed to write as well as size of the output
* it is not a standardized format and we need to write our own tools to analyze the traces
* we currently use a lock around each call to the debug function which is suboptimal
Starting from that I think many of us agree (from conversations we had during the hackfest) that a nice way to solve those issues would be to allow outputting our traces as Common Trace Format[0]. This format is used by the lttng[1] project and is the main tracing format outputted by the Linux kernel. Many tools are available from the LTTNG project and we can use the babeltrace[2] library to simplify CTF trace generation (the important part of the library is licenced under MIT[3] so we should not have any problem using it in GStreamer core ifaiu).
Also during the hackfest we talked about the possibility to use that same format to ouput our debug logs, but that work will be part of another bug.
This feature can currently be activated through the GST_DEBUG_FORMAT=ctf,directory=/some/dir environment variable, and this same variable should be used for any format (still supporting the GST_DEBUG_FILE var too).
I am attaching here the first iteration of the implementation.
[0] http://diamon.org/ctf/
[1] http://lttng.org/
[2] http://diamon.org/babeltrace/
[3] https://github.com/efficios/babeltrace/blob/master/LICENSEhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/192atomicqueue: Improve performance on push operations2021-09-24T11:10:05ZBugzilla Migration Useratomicqueue: Improve performance on push operations## Submitted by sancane
**[Link to original bug (#772747)](https://bugzilla.gnome.org/show_bug.cgi?id=772747)**
## Description
Created attachment 337414
Patch
We have detected that on big pipelines involving a great number of...## Submitted by sancane
**[Link to original bug (#772747)](https://bugzilla.gnome.org/show_bug.cgi?id=772747)**
## Description
Created attachment 337414
Patch
We have detected that on big pipelines involving a great number of elements and processes competing to post messages on the bus, the amount of time spent on single push operations rapidly increase, we have detected that it can even reach a magnitude of seconds. This issue is caused because the current algorithm forces processes to wait until previous writers finalize sequentially. This patch allow faster writers to finalize the push operation without waiting for slower writers. Those slow processes are responsible of updating the read index so that processes can pop data at the right position, never beyond the index imposed by the slowest writer.
This issue might be related to the bug reported by Miguel París Díaz (https://bugzilla.gnome.org/show_bug.cgi?id=768668opened) who detected a long busy-waiting with gdb.
~~**Patch 337414**~~, "Patch":
[0001-gstatomicqueue-Improve-performance-on-push-operation.patch](/uploads/c26a7c783037f8b05e5a99bbbe812d38/0001-gstatomicqueue-Improve-performance-on-push-operation.patch)