gstreamer issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues2021-09-24T11:10:47Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/121ptp: Get required privileges on OS X with a OS X specific mechanism2021-09-24T11:10:47ZBugzilla Migration Userptp: Get required privileges on OS X with a OS X specific mechanism## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#752105)](https://bugzilla.gnome.org/show_bug.cgi?id=752105)**
## Description
+++ This bug was initially created as a clone of [Bug 750367](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#752105)](https://bugzilla.gnome.org/show_bug.cgi?id=752105)**
## Description
+++ This bug was initially created as a clone of [Bug 750367](https://bugzilla.gnome.org/show_bug.cgi?id=750367) +++
setuid root is not the state of the art on OS X either AFAIU, something else should be used. Maybe it should be done via launchd, someone needs to do some research :)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/120dataqueue: Make it understand buffers, segments, gaps2022-11-10T09:20:45ZBugzilla Migration Userdataqueue: Make it understand buffers, segments, gaps## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#751918)](https://bugzilla.gnome.org/show_bug.cgi?id=751918)**
## Description
In practice, every queue in GStreamer is buffers and synchronized events/queries, so it d...## Submitted by Olivier Crête `@ocrete`
**[Link to original bug (#751918)](https://bugzilla.gnome.org/show_bug.cgi?id=751918)**
## Description
In practice, every queue in GStreamer is buffers and synchronized events/queries, so it doesn't make sense to have a GstDataQueue that tries to abstract them, then re-implement the processing every it's used. As we integrate queues in more elements (like in demuxers), we can reduce duplication.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/119baseparse: Calculates bitrates for the complete stream instead of windowed av...2021-09-24T11:10:48ZBugzilla Migration Userbaseparse: Calculates bitrates for the complete stream instead of windowed average## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#751889)](https://bugzilla.gnome.org/show_bug.cgi?id=751889)**
## Description
See summary. Problem with that is that it will not react properly to bitrate changes cur...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#751889)](https://bugzilla.gnome.org/show_bug.cgi?id=751889)**
## Description
See summary. Problem with that is that it will not react properly to bitrate changes currently.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/118Pull mode element downstream hogs the pad stream lock2021-09-24T11:10:49ZBugzilla Migration UserPull mode element downstream hogs the pad stream lock## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#751637)](https://bugzilla.gnome.org/show_bug.cgi?id=751637)**
## Description
With the example pipeline:
filesrc ! wavparse ! fakesink
wavparse will sw...## Submitted by Vincent Penquerc'h `@vincent`
**[Link to original bug (#751637)](https://bugzilla.gnome.org/show_bug.cgi?id=751637)**
## Description
With the example pipeline:
filesrc ! wavparse ! fakesink
wavparse will switch to pull mode, and create a pad task which will pull till EOS. The pad task calls:
task->func (task->user_data);
in a loop, while holding the pad stream lock, which is therefore not released at all until the element goes flushing, stops, etc.
While this goes on, if there is a event going downstream that reaches wavparse (eg, sink-message), the gstpad.c code will lock the stream lock before pushing the event. It will then wait an arbitrary long time before being able to do so.
This proof of concept:
diff --git a/gst/gsttask.c b/gst/gsttask.c
index d9e5697..47d3e6f 100644
--- a/gst/gsttask.c
+++ b/gst/gsttask.c
@@ -329,6 +329,11 @@ gst_task_func (GstTask * task)
}
task->func (task->user_data);
+
+ /* Allow something else to use the lock. Still a lot of contention though */
+ g_rec_mutex_unlock (lock);
+g_usleep (1000);
+ g_rec_mutex_lock (lock);
}
g_rec_mutex_unlock (lock);
shows that this is indeed the problem, as my code works as expected with this bodge in.
There doesn't seem to be any reason why the lock can't be released between calls to the pad task function. A possible fix for this would be passing a condition variable along with the lock, but this would need changing a substantial amount of elements.
Any better way to fix ? Or is this as intended, and the lock really should not be released (why, then ?) ?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/117gst_debug_remove_log_function exposes a potential race condition w. LogFuncEn...2021-09-24T11:10:49ZBugzilla Migration Usergst_debug_remove_log_function exposes a potential race condition w. LogFuncEntry's user_data/notify## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#751440)](https://bugzilla.gnome.org/show_bug.cgi?id=751440)**
## Description
In gst/gstinfo.c, gst_debug_remove_with_compare_func copies and leaks the list __l...## Submitted by Heinrich Fink `@heinrich.fink`
**[Link to original bug (#751440)](https://bugzilla.gnome.org/show_bug.cgi?id=751440)**
## Description
In gst/gstinfo.c, gst_debug_remove_with_compare_func copies and leaks the list __log_functions in order to avoid locking in gst_debug_log_valist to make it thread-safe. However, gst_debug_remove_with_compare_func also executes the destroy-notifier on the LogFuncEntry's user_data, and this could actually still be used by a logging action while it is deleted.
To make this fully thread-safe, we could use a reader/writer lock ("shared" mutex), where the gst_debug_log_valist acquires a read-lock, and the add/remove functions of the debug handler acquire a write-lock.
With the current implementation, we should at least document that gst_debug_remove_log_function and gst_debug_remove_log_function_by_date are not thread-safe (with respect to the user-data of installed log functions).https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/116baseparse: drain on stream-start2021-09-24T11:10:50ZBugzilla Migration Userbaseparse: drain on stream-start## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#751105)](https://bugzilla.gnome.org/show_bug.cgi?id=751105)**
## Description
When handling stream-start events, baseparse should drain its current data a...## Submitted by Thiago Sousa Santos `@thiagossantos`
**[Link to original bug (#751105)](https://bugzilla.gnome.org/show_bug.cgi?id=751105)**
## Description
When handling stream-start events, baseparse should drain its current data and then reset itself as a new stream is about to start, no data from previous stream should be reused.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/115clock: Add gst_clock_abort_wait() function2021-09-24T11:10:50ZBugzilla Migration Userclock: Add gst_clock_abort_wait() function## Submitted by Carlos Rafael Giani
**[Link to original bug (#750633)](https://bugzilla.gnome.org/show_bug.cgi?id=750633)**
## Description
As mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=749391#c10 , the newly introduced ...## Submitted by Carlos Rafael Giani
**[Link to original bug (#750633)](https://bugzilla.gnome.org/show_bug.cgi?id=750633)**
## Description
As mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=749391#c10 , the newly introduced gst_clock_wait_for_sync() function issues a blocking wait. If this function is used inside elements for example, it is important to be able to abort the wait, for example during a PAUSED->READY state change. A gst_clock_abort_wait() function is needed that aborts the blocking wait.
To that end, also extend the description of gst_clock_wait_for_sync(). It shall return FALSE if either a timeout happened or the wait was aborted.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2936tsdemux: Not able to play HEVC video clip in pull mode2023-08-25T09:25:43ZBugzilla Migration Usertsdemux: Not able to play HEVC video clip in pull mode## Submitted by ris..@..il.com
**[Link to original bug (#750341)](https://bugzilla.gnome.org/show_bug.cgi?id=750341)**
## Description
Not able to play any big buck bunny HEVC video clip using tsdemux from video clip with file format...## Submitted by ris..@..il.com
**[Link to original bug (#750341)](https://bugzilla.gnome.org/show_bug.cgi?id=750341)**
## Description
Not able to play any big buck bunny HEVC video clip using tsdemux from video clip with file format MPEG-TS.
System: Feodra 21 64bit
Video clip URL: http://www.elecard.com/en/download/videos.html
Under Big Buck Bunny - SD, 720p and 1080p HEVC video clip
msg:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstTSDemux:tsdemux0: Internal data stream error.
Additional debug info:
mpegtsbase.c(1342): mpegts_base_loop (): /GstPipeline:pipeline0/GstTSDemux:tsdemux0:
stream stopped, reason not-linked
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...https://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/2693asfdemux: add support for trick play in push mode2023-06-20T17:14:05ZBugzilla Migration Userasfdemux: add support for trick play in push mode## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Fo...## Submitted by Rajesh Singh
**[Link to original bug (#749956)](https://bugzilla.gnome.org/show_bug.cgi?id=749956)**
## Description
Current implementation of ASFDemux, does not support the push mode Trick Play.
Trick Play means Forward(1/2X, 2X, 4X) and Rewind (-1/2X, -2X, -4X).
Version: 1.4.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2770mpeg4videoparse: Need detect picture coding type when drain2023-07-06T09:54:03ZBugzilla Migration Usermpeg4videoparse: Need detect picture coding type when drain## Submitted by kevin
**[Link to original bug (#749617)](https://bugzilla.gnome.org/show_bug.cgi?id=749617)**
## Description
our use case is demuxer only output key frame when backward playback. every frame is DISCONT and KEY frame....## Submitted by kevin
**[Link to original bug (#749617)](https://bugzilla.gnome.org/show_bug.cgi?id=749617)**
## Description
our use case is demuxer only output key frame when backward playback. every frame is DISCONT and KEY frame. mpeg4videoparse will detect coding type when detect start code after VOP. our use case will drain after VOP and can't detect start code after VOP. Add check coding type code when drain.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)