gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2021-11-26T08:24:43Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/40Clock estimation (aka: Forward QoS)2021-11-26T08:24:43ZBugzilla Migration UserClock estimation (aka: Forward QoS)## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#704331)](https://bugzilla.gnome.org/show_bug.cgi?id=704331)**
## Description
### Problems:
Currently elements that do remote clock estimation modify the values of ...## Submitted by Edward Hervey `@bilboed`
**[Link to original bug (#704331)](https://bugzilla.gnome.org/show_bug.cgi?id=704331)**
## Description
### Problems:
Currently elements that do remote clock estimation modify the values of the buffer timestamps they output.
This causes several problems:
* Loss of original information:
An original perfect 25fps video stream ends up having buffers no longer spaced by 1/25th of a second.
* Correction should only be applied when doing synchronzation in, and only in, the current pipeline and with the same clock. If the stream is stored in a file, the time corrections are stored with it and the resulting file ends up playing back faster/slower than targetted.
### Goal:
For live systems split the remote clock estimation/correction into two parts:
1) Remote clock estimation is done in elements that can do it
2) Elements capable of clock estimation do not modify the original values of in-band timing and instead only modify the segment values such that the running-time of buffers being outputted is coherent with the running-time of buffers it received.
3) Synchronization correction is only done in elements that actually wait against the clock.
### Proposal:
New event `GST_EVENT_CLOCK_CORRECTION` (in-band, sticky)
Fields:
* `GstClockTime time` : The running-time of the clock to which this correction applies.
* `GstClockTimeDiff offset` : The correction to apply to 'time' (can be negative)
* `gdouble rate` : The long-term rate correction.
``` c
GstEvent *gst_event_new_clock_correction (GstClockTime time,
GstClockTimeDiff offset,
gdouble rate);
gboolean gst_event_parse_clock_correction (GstEvent *event,
GstClockTime *time,
GstClockTimeDiff *offset,
gdouble *rate);
```
### Description
Over time the rate will stabilize. We get a more and more accurate estimation of the remote clock rate.
The rate might change if the nature of the remote source changes (such as changing from one participant in a RTP multi-participant conference to another). It does also appear to change on some DVB channels when the nature of the feed changes from pre-recorded to live (by a few parts-per-million (ppm). Finally it can also change when changing
DVB channels.
If rate == 1.0, this means that the remote provider is using a clock with the same exact rate as the clock locally used.
If rate > 1.0, this means that the remote provider is using a clock which has a slower rate than the clock locally used. Buffers end up being synchronized slower (we end up with a target synchronization running time bigger (and therefore later).
If rate < 1.0, this means that the remote provider is using a clock which has a higher rate than the clock locally used. Buffers end up being synchronized faster (we end up with a target synchronization running timer smaller (and therefore earlier).
The offset correponds to the exact correction that needs to be applied for a given running time.
Initially more corrections will be needed while the rate stabilizes, so this helps ensures that we can still get exact corrections instantly.
This also helps to do one-shot adjustments quickly. This could happen if there is a routing/networking change between the remote device and the local device which would affect the travel latency (but not the rate).
Rate of emission of the event is left up to the element providing them but an expected usage would be to:
* Assume an initial rate of 1.0 without any correction
* As soon as a new corrected timestamp diverges too much from the previous (or assumed) correction/rate, it send an update and remember the new correction/rate for future values.
Until a new correction is sent, any new running-time received will be corrected as such:
```
T : clock_correction.time
C : clock_correction.offset
R : clock_correction.rate
T2 : running-time > T
Corrected time for T2 = R * T2 + C
```
(and for those following, since the default values are R=1.0 and C=0.0, ... no correction is applied when no clock correction event was received).
#### Clarification needed:
What happens in the case where we have multiple clock estimation systems chaining each other, such as mpeg-ts over rtp ?
1) Second one "drops" the first observations ?
2) Second one disables its observation system ?
3) Second one uses it to fine-tune its own observations ?
What happens in the case where we multiplex streams with different
clock estimation, such as several different RTP sources into one
mpeg-ts program (with one clock/PCR) we want to transmit live ?
(Note: in the case where we multiplex into different mpeg-ts programs, the problem doesn't occur since we can use different PCR streams, with different clocks per program).
A new method for storing/calculating "corrected" running-time ? This shouldn't modify gst_segment_to_running_time() since that is used outside of clock-synchronized elements ?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/38HTML5 kind attribute (subtitles, captions, metadata, descriptions, chapters)2021-11-26T08:24:42ZBugzilla Migration UserHTML5 kind attribute (subtitles, captions, metadata, descriptions, chapters)## Submitted by Brendan Long
**[Link to original bug (#698853)](https://bugzilla.gnome.org/show_bug.cgi?id=698853)**
## Description
In HTML5, we need to mark text streams as subtitles, captions, metadata, descriptions or chapters, b...## Submitted by Brendan Long
**[Link to original bug (#698853)](https://bugzilla.gnome.org/show_bug.cgi?id=698853)**
## Description
In HTML5, we need to mark text streams as subtitles, captions, metadata, descriptions or chapters, but there doesn't seem to be a way to do this in GStreamer. For audio and video tracks, there are also kinds: alternative, captions (legacy), description, main, main-desc, sign, subtitles (legacy), translation, and commentary.
For metadata, the caps will probably be different, but for everything else the caps would be the same.
The simplest solution seems to be to add a GST_TAG_KIND, which can contain any of the kinds defined in HTML5.
See:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#text-track-kind
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-audiotrack-kindhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/833dashdemux: try all URLs in a UTCtiming element2021-10-20T08:21:53ZBugzilla Migration Userdashdemux: try all URLs in a UTCtiming element## Submitted by A Ashley
**[Link to original bug (#762739)](https://bugzilla.gnome.org/show_bug.cgi?id=762739)**
## Description
The UTCTiming element in a DASH manifest identifies a time synchronisation method and one or more URLs t...## Submitted by A Ashley
**[Link to original bug (#762739)](https://bugzilla.gnome.org/show_bug.cgi?id=762739)**
## Description
The UTCTiming element in a DASH manifest identifies a time synchronisation method and one or more URLs that can be contacted using the specified method.
Currently the gst_dash_demux_poll_clock_drift() function selects one server to poll and if that fails, it will wait 30 seconds before trying another server. If this error occurs when starting playback, dashdemux will start playback without achieving clock drift compensation, which can cause it to select the wrong starting segment. Selecting the wrong starting segment can cause requests for segments to fail with HTTP404 errors, as the chosen segment might have already been deleted from the origin or might not yet exist.
Also, when a manifest update occurs, gst_dash_demux_poll_clock_drift() does not check that the currently active URL is still valid.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/832dashdemux: Support cookies for DASH2021-10-20T08:19:07ZBugzilla Migration Userdashdemux: Support cookies for DASH## Submitted by Park Jun-soo
**[Link to original bug (#775920)](https://bugzilla.gnome.org/show_bug.cgi?id=775920)**
## Description
According to caluse 9.5 Stored Data Security of Freeview_Play_Technical_Specification, DASH Player s...## Submitted by Park Jun-soo
**[Link to original bug (#775920)](https://bugzilla.gnome.org/show_bug.cgi?id=775920)**
## Description
According to caluse 9.5 Stored Data Security of Freeview_Play_Technical_Specification, DASH Player shall support session cookie.
### Depends on
* [Bug 761099](https://bugzilla.gnome.org/show_bug.cgi?id=761099)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/824add support for DASH events2021-10-20T07:34:15ZBugzilla Migration Useradd support for DASH events## Submitted by A Ashley
**[Link to original bug (#796923)](https://bugzilla.gnome.org/show_bug.cgi?id=796923)**
## Description
Section 5.10.3 (Inband Event Signalling) of the MPEG DASH specification defines a new box type "emsg" th...## Submitted by A Ashley
**[Link to original bug (#796923)](https://bugzilla.gnome.org/show_bug.cgi?id=796923)**
## Description
Section 5.10.3 (Inband Event Signalling) of the MPEG DASH specification defines a new box type "emsg" that is used to convey events. These events can be used to signal changes in the DASH stream, convey metadata or provide application specific information.
Section 5.10.4 (DASH-specific events) defines a method for an in-band signal to indicate that a live DASH stream has finished.
Currently there is no support in qtdemux or dashdemux for these DASH events.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/756dvdread: Add device probe support2021-09-30T16:28:05ZBugzilla Migration Userdvdread: Add device probe support## Submitted by an unknown user
**[Link to original bug (#692553)](https://bugzilla.gnome.org/show_bug.cgi?id=692553)**
## Description
One Fedora the DVD player is not mounted as /dev/dvd. So when you call dvdread through uridecodeb...## Submitted by an unknown user
**[Link to original bug (#692553)](https://bugzilla.gnome.org/show_bug.cgi?id=692553)**
## Description
One Fedora the DVD player is not mounted as /dev/dvd. So when you call dvdread through uridecodebin for instance it is a pain to get dvdread to use the right device node. Once Oliviers GstDevice stuff is implemented the dvdread element should be made to use it.
### Depends on
* [Bug 678402](https://bugzilla.gnome.org/show_bug.cgi?id=678402)
### Blocking
* [Bug 687617](https://bugzilla.gnome.org/show_bug.cgi?id=687617)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/749dashsink: add webm support2021-09-29T09:32:14ZStéphane Cerveauscerveau@igalia.comdashsink: add webm supportThe dash sink should be able to generate a MPD with webm/vp8 content.
Here is documentation on how to generate this MPD/content with ffmpeg.
http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live-streaming-via-dashThe dash sink should be able to generate a MPD with webm/vp8 content.
Here is documentation on how to generate this MPD/content with ffmpeg.
http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live-streaming-via-dashStéphane Cerveauscerveau@igalia.comStéphane Cerveauscerveau@igalia.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/55Core could be more helpful with respect to event ordering2021-09-24T11:11:22ZBugzilla Migration UserCore could be more helpful with respect to event ordering## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#728138)](https://bugzilla.gnome.org/show_bug.cgi?id=728138)**
## Description
A precise sequence of events need to be sent before starting data flow. There's alread...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#728138)](https://bugzilla.gnome.org/show_bug.cgi?id=728138)**
## Description
A precise sequence of events need to be sent before starting data flow. There's already code that ensures ordering, could gst instead of throwing warnings and errors when the ordering is not respected provide vmethods in GstElement for handling that ?
ie we can find send_caps, send_stream_start and send_segment boolean fields variations in multiple element methods (videomixer / adder are the ones that come to mind), would be nice to delegate that to GstElement and have vmethods such as get_stream_id, get_segment etc ..
I have no API proposal, just starting the discussion :)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/58check: add chain list function on sinkpad2021-09-24T11:11:21ZBugzilla Migration Usercheck: add chain list function on sinkpad## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#730639)](https://bugzilla.gnome.org/show_bug.cgi?id=730639)**
## Description
In order to easily test their "chain_list" code path it would be useful to add a ...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#730639)](https://bugzilla.gnome.org/show_bug.cgi?id=730639)**
## Description
In order to easily test their "chain_list" code path it would be useful to add a chain_list hook on the test sink pad.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/59bytereader: SIMD-based optimization to find start code on H.264 and H.265 str...2021-09-24T11:11:21ZBugzilla Migration Userbytereader: SIMD-based optimization to find start code on H.264 and H.265 streams## Submitted by Sungho Bae
**[Link to original bug (#730783)](https://bugzilla.gnome.org/show_bug.cgi?id=730783)**
## Description
Created attachment 277253
001_gstbytereader_neon_improvement_patch
In the parse phase for video...## Submitted by Sungho Bae
**[Link to original bug (#730783)](https://bugzilla.gnome.org/show_bug.cgi?id=730783)**
## Description
Created attachment 277253
001_gstbytereader_neon_improvement_patch
In the parse phase for video streams, bytescanning is performed to find the start and end of each NAL unit. This implementation is to improve the performance of bytescanning for start code using both ARM NEON instructions and pointer access instead of indexed access.
The advantages are to reduce CPU usage and to enhance the scanning performance.
This patch assumes that '0x0000' is unlikely to appear and the zeros are part of the start code, that is, '0x010000'.
Our proposed idea is based on the assumption.
If we quickly know whether or not there exists '0x0000' in the scanning area to find the start code, we can skip the scanning process for the start code.
We thus implemented the preprocessing to know whether or not there exists '0x0000'.
Because the probability of zeros to appear is low, its performance dramatically improved.
~~**Patch 277253**~~, "001_gstbytereader_neon_improvement_patch":
[001_bytereader_improve_v1.0_baver.bae.patch](/uploads/bee61bab7bf965d77351d3c59ae5b818/001_bytereader_improve_v1.0_baver.bae.patch)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/60Specify, design and implement a base class for demuxers2021-09-24T11:11:20ZBugzilla Migration UserSpecify, design and implement a base class for demuxers## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#732616)](https://bugzilla.gnome.org/show_bug.cgi?id=732616)**
## Description
I open that bug report so we can gather requirements and design ideas for a base demux...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#732616)](https://bugzilla.gnome.org/show_bug.cgi?id=732616)**
## Description
I open that bug report so we can gather requirements and design ideas for a base demuxer class, hopefully it will end up RESOLVED FIXED :)
I don't have many ideas, only two requirements that I will detail in the following comment.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/63gst_element_state_* functions should read gst_state_*2021-09-24T11:11:20ZBugzilla Migration Usergst_element_state_* functions should read gst_state_*## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#733088)](https://bugzilla.gnome.org/show_bug.cgi?id=733088)**
## Description
It is inconsistent with respects to the rest of the API, it seems more intuitive to me...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#733088)](https://bugzilla.gnome.org/show_bug.cgi?id=733088)**
## Description
It is inconsistent with respects to the rest of the API, it seems more intuitive to me to write gst_state_get_name (GstState state);
That was my nitpick of the day :)
Version: 2.xhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/72[Proposal] adjustment of rank by command line option2021-09-24T11:11:16ZBugzilla Migration User[Proposal] adjustment of rank by command line option## Submitted by Justin Kim `@joykim`
**[Link to original bug (#735443)](https://bugzilla.gnome.org/show_bug.cgi?id=735443)**
## Description
In case of special element with rank zero, there's no way to deploy by gst-launch and autopl...## Submitted by Justin Kim `@joykim`
**[Link to original bug (#735443)](https://bugzilla.gnome.org/show_bug.cgi?id=735443)**
## Description
In case of special element with rank zero, there's no way to deploy by gst-launch and autoplugging.
If ranks can be set by an option, we can do test simply by command line tool even plugins has zero rank.
I suggest "--gst-rank" option for gst_init. However, I failed to find a proper location for this feature so I just modified "gst.c".https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/85gstpluginfeature: Properly expose the class.2021-09-24T11:11:08ZBugzilla Migration Usergstpluginfeature: Properly expose the class.## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#741260)](https://bugzilla.gnome.org/show_bug.cgi?id=741260)**
## Description
To allow external applications libraries to implement
their own factory.
+ Impl...## Submitted by Mathieu Duponchelle `@meh`
**[Link to original bug (#741260)](https://bugzilla.gnome.org/show_bug.cgi?id=741260)**
## Description
To allow external applications libraries to implement
their own factory.
+ Implements getters and setters for priv->plugin and priv->loaded.
### Blocking
* [Bug 742610](https://bugzilla.gnome.org/show_bug.cgi?id=742610)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/92gst-plugin-scanner should show the plugin emitting errors and warnings2021-09-24T11:11:05ZBugzilla Migration Usergst-plugin-scanner should show the plugin emitting errors and warnings## Submitted by Pacho Ramos
**[Link to original bug (#744134)](https://bugzilla.gnome.org/show_bug.cgi?id=744134)**
## Description
Created attachment 296333
build.log
On Gentoo we run compilations inside a sandbox system to p...## Submitted by Pacho Ramos
**[Link to original bug (#744134)](https://bugzilla.gnome.org/show_bug.cgi?id=744134)**
## Description
Created attachment 296333
build.log
On Gentoo we run compilations inside a sandbox system to prevent unwanted access to files and devices from "real" system. That way, we are getting now errors as gst-plugin-scanner wants to access to /dev/video0 directly.
Probably this access is due to a plugin loaded by gst-plugin-scanner but, as it doesn't show any more output than:
(gst-plugin-scanner:23320): Clutter-CRITICAL **: Unable to initialize Clutter: Unable to open display ':0'
(gst-plugin-scanner:23320): GStreamer-CRITICAL **: gst_structure_new_empty: assertion 'gst_structure_validate_name (name)' failed
* ACCESS DENIED: open_wr: /dev/video0
It's near impossible to know what plugin is causing this issue
The attached full build.log is from farstream-0.2.6, whose building calls gst-plugin-scanner and hits this problem
Thanks a lot
**Attachment 296333**, "build.log":
[farstream-0.2.6_20150207-171549.log](/uploads/793dc610dc437c8b596b22ebb20a1f13/farstream-0.2.6_20150207-171549.log)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/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/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/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/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)