gstreamer-project issueshttps://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues2022-06-24T10:48:46Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/99Dynamic removing webrtcbin from GstTee cause total pipeline paused2022-06-24T10:48:46ZZhuChaselDynamic removing webrtcbin from GstTee cause total pipeline pausedI use one tee for maybe 5 webrtcbins as receiver, and one appsrc as sender. Between appsrc and tee, I have GstQueue, named queue1. I try to remove one webrtcbin frequently. Then i found queue1 paused sometimes, then block all the pipelin...I use one tee for maybe 5 webrtcbins as receiver, and one appsrc as sender. Between appsrc and tee, I have GstQueue, named queue1. I try to remove one webrtcbin frequently. Then i found queue1 paused sometimes, then block all the pipeline.
I even use GST_PAD_PROBE_TYPE_IDLE to unlink teepad using gst_pad_unlink before removing webrtcbin, code like,
gst_pad_add_probe(sink->teepad, GST_PAD_PROBE_TYPE_IDLE, unlink_cb, sink, (GDestroyNotify)g_free);
But I can still produce pipeline block, queue1 paused. I dig into the source code, when peer(chrome) leaves, I find teepad change to GST_FLOW_FLUSHING(-2) state even without removing webrtcbin from pipeline, I think changing to GST_FLOW_FLUSHING state is inevitable. Below is the state related log:
tee gsttee.c:940:gst_tee_handle_data:<videotee:src_4> Starting to push buffer 0000027DC865E000
0:00:03.219030000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4860:gst_pad_push_data:<videotee:src_4> error pushing events, return flushing
0:00:03.219759000 9820 0000027DC5905800 INFO tee gsttee.c:945:gst_tee_handle_data:<videotee:src_4> Pushing item 0000027DC865E000 yielded result flushing pad src_4
0:00:03.220583000 9820 0000027DC5905800 INFO tee gsttee.c:1013:gst_tee_handle_data:<videotee> received error flushing
0:00:03.222496000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4468:gst_pad_chain_data_unchecked:<videotee> chainfunc return2 queue videotee return -2 funcname gst_tee_chain pad sink
0:00:03.223200000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4478:gst_pad_chain_data_unchecked:<videotee:sink> called chainfunction &gst_tee_chain with buffer 0000027DC865E000, returned flushing
0:00:03.223904000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<videotee> chainfunc return queue videotee pad sink return -2
0:00:03.227789000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4478:gst_pad_chain_data_unchecked:<caps:sink> called chainfunction &gst_base_transform_chain with buffer 0000027DC865E000, returned flushing
0:00:03.228397000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<caps> chainfunc return queue caps pad sink return -2
0:00:03.228885000 9820 0000027DC5905800 INFO GST_SCHEDULING gstpad.c:4500:gst_pad_chain_data_unchecked:<caps:sink> called chainlistfunction &gst_pad_chain_list_default, returned flushing ret -2
0:00:03.229151000 9820 0000027DC5905800 INFO GST_PADS gstpad.c:4511:gst_pad_chain_data_unchecked:<caps> chainfunc return queue caps pad sink return -2
0:00:03.229579000 9820 0000027DC5905800 INFO task gsttask.c:733:gst_task_set_state_unlocked:<queuebb:src> Changing task 0000027DC5907290 to state 2
0:00:03.230532000 9820 0000027DC5905800 INFO queue_dataflow gstqueue.c:1660:gst_queue_loop:<queuebb> pause task, reason: flushing
0:00:03.231669000 9820 0000027DC5905800 INFO task gsttask.c:369:gst_task_func:<queuebb:src> Task 0000027DC5907290 going to paused
from function gst_tee_handle_data,
while (pads) {
GstPad *pad;
/* stop pushing more buffers when we have a fatal error */
if (G_UNLIKELY (ret != GST_FLOW_OK && ret != GST_FLOW_NOT_LINKED))
goto error;
pads = g_list_next (pads);
}
if one pad is not OK, then all pads will be affected. How about move goto error out? So, what can I do to dynamically remove webrtcbin from tee without affect other webrtcbin? Please advise.
Thanks.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/95iOS App crashes when calling g_tls_file_database_new2022-06-04T03:21:45Zsamanta-ramijaniOS App crashes when calling g_tls_file_database_newHi!
I want to update the GStreamer version of my iOS App from 1.16.3 to 1.18.6.
What I did:
I downloaded the installer from here: https://gstreamer.freedesktop.org/data/pkg/ios/1.18.6/gstreamer-1.0-devel-1.18.6-ios-universal.pkg I upd...Hi!
I want to update the GStreamer version of my iOS App from 1.16.3 to 1.18.6.
What I did:
I downloaded the installer from here: https://gstreamer.freedesktop.org/data/pkg/ios/1.18.6/gstreamer-1.0-devel-1.18.6-ios-universal.pkg I updated the gst_ios_init.h file to use openssl instead of gnutls, by replacing the `#define GST_IOS_GIO_MODULE_GNUTLS` line with `#define GST_IOS_GIO_MODULE_OPENSSL`
The App is now crashing (iOS 15.4.1) when calling the `g_tls_file_database_new (ca_certificates, NULL)` on the `gst_ios_init.m` file. I am getting a `EXC_BAD_ACCESS` exception, which is weird because I didn't change the certificate location.
This is a snippet of the code where the App is crashing, it only crashes if there is a file where `ca_certificates` points to. If there isn't then the `gst_ios_init` call runs properly, but then I cannot use encryption, which I really need to!!
```
const gchar *resources_dir = [resources UTF8String];
const gchar *tmp_dir = [tmp UTF8String];
const gchar *cache_dir = [cache UTF8String];
const gchar *docs_dir = [docs UTF8String];
const gchar *library_dir = [libraryString UTF8String];
gchar *ca_certificates;
g_setenv ("TMP", tmp_dir, TRUE);
g_setenv ("TEMP", tmp_dir, TRUE);
g_setenv ("TMPDIR", tmp_dir, TRUE);
g_setenv ("XDG_RUNTIME_DIR", resources_dir, TRUE);
g_setenv ("XDG_CACHE_HOME", cache_dir, TRUE);
g_setenv ("HOME", docs_dir, TRUE);
g_setenv ("XDG_DATA_DIRS", resources_dir, TRUE);
g_setenv ("XDG_CONFIG_DIRS", resources_dir, TRUE);
g_setenv ("XDG_CONFIG_HOME", cache_dir, TRUE);
g_setenv ("XDG_DATA_HOME", resources_dir, TRUE);
g_setenv ("FONTCONFIG_PATH", resources_dir, TRUE);
ca_certificates = g_build_filename (library_dir, "ca.pem", NULL);
g_setenv ("CA_CERTIFICATES", ca_certificates, TRUE);
#if defined(GST_IOS_GIO_MODULE_OPENSSL)
GST_G_IO_MODULE_LOAD(openssl);
#endif
if (ca_certificates) {
GTlsBackend *backend = g_tls_backend_get_default ();
if (backend) {
GTlsDatabase *db = g_tls_file_database_new (ca_certificates, NULL);
if (db)
g_tls_backend_set_default_database (backend, db);
}
}
g_free (ca_certificates);
gst_init (NULL, NULL);
```
Here's also an screenshot of the crash.
![Screen_Shot_2022-05-27_at_2.05.07_PM](/uploads/00667d212f59854a9bbb9aa066389825/Screen_Shot_2022-05-27_at_2.05.07_PM.png)
Thank you!https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/93Python Application Crash Streaming Audiobook on 32-bit Raspberry Pi OS2022-11-17T11:21:55ZJordan WilliamsPython Application Crash Streaming Audiobook on 32-bit Raspberry Pi OSFor details about the original issue, see [Mopidy Issue #2030](https://github.com/mopidy/mopidy/issues/2030).
When streaming an M4B/AAC audiobook from my Jellyfin server, Mopidy crashes with the following error output while using GStrea...For details about the original issue, see [Mopidy Issue #2030](https://github.com/mopidy/mopidy/issues/2030).
When streaming an M4B/AAC audiobook from my Jellyfin server, Mopidy crashes with the following error output while using GStreamer's Python API.
While Mopidy crashes and it's no longer to pause playback, playback does start and continue playing indefinitely.
There are no problems if the file is downloaded and played back locally.
```
Nov 29 17:23:30 zero2 mopidy[3743]: INFO [MainThread] mopidy.__main__ Starting Mopidy 3.2.0
Nov 29 17:23:30 zero2 mopidy[3743]: INFO [MainThread] mopidy.config Loading config from builtin defaults
Nov 29 17:23:30 zero2 mopidy[3743]: INFO [MainThread] mopidy.config Loading config from file:///usr/share/mopidy/conf.d/mopidy.conf
Nov 29 17:23:30 zero2 mopidy[3743]: INFO [MainThread] mopidy.config Loading config from file:///etc/mopidy/mopidy.conf
Nov 29 17:23:30 zero2 mopidy[3743]: INFO [MainThread] mopidy.config Loading config from command line options
Nov 29 17:23:30 zero2 mopidy[3743]: WARNING [MainThread] mopidy.config Ignoring config section 'mpd' because no matching extension was found
Nov 29 17:23:31 zero2 mopidy[3743]: INFO [MainThread] mopidy.__main__ Enabled extensions: m3u, softwaremixer, stream, http, jellyfin, file
Nov 29 17:23:31 zero2 mopidy[3743]: INFO [MainThread] mopidy.__main__ Disabled extensions: none
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [MainThread] mopidy.commands Starting Mopidy mixer: SoftwareMixer
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [MainThread] mopidy.commands Mixer volume set to 100
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [MainThread] mopidy.commands Starting Mopidy audio
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [MainThread] mopidy.commands Starting Mopidy backends: JellyfinBackend, FileBackend, M3UBackend, StreamBackend
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [Audio-2] mopidy.audio.actor Audio output set to "audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! filesink location=/tmp/snapfifo"
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [MainThread] mopidy.commands Starting Mopidy core
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [MainThread] mopidy.commands Starting Mopidy frontends: EventMonitorFrontend, HttpFrontend
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [HttpFrontend-12] mopidy.http.actor HTTP server running at [::]:6680
Nov 29 17:23:32 zero2 mopidy[3743]: INFO [MainThread] mopidy.commands Starting GLib mainloop
Nov 29 17:29:04 zero2 mopidy[3743]: OverflowError: Python int too large to convert to C long
Nov 29 17:29:04 zero2 mopidy[3743]: The above exception was the direct cause of the following exception:
Nov 29 17:29:04 zero2 mopidy[3743]: Traceback (most recent call last):
Nov 29 17:29:04 zero2 mopidy[3743]: File "/usr/lib/python3/dist-packages/mopidy/audio/actor.py", line 212, in on_message
Nov 29 17:29:04 zero2 mopidy[3743]: elif msg.type == Gst.MessageType.BUFFERING:
Nov 29 17:29:04 zero2 mopidy[3743]: SystemError: <built-in method get_value of gi.FieldInfo object at 0x74541608> returned a result with an error set
```
GStreamer version: 1.18.4
OS: 32-bit Raspberry Pi OS (Debian Bullseye)
Note that this issue does not occur when using 64-bit Raspberry Pi OS.
Hardware: Raspberry Pi Zero 2 W, also occurs on Raspberry Pi Compute Module 4
My Jellyfin Server is running on a 64-bit Arm device, if that's important.
[gstreamer-dbg.log.xz](/uploads/d567ce2e795c1a4762ab4c81a275a424/gstreamer-dbg.log.xz)
I'm not sure which component to file this bug under, so your help is appreciated.
Thanks.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/86Start using generic copyright headers in source code2021-02-18T17:17:24ZGuillaume DesmottesStart using generic copyright headers in source codeAs [discussed here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1029#note_805587) I'd like to propose to start using generic copyright headers such as `Copyright The GStreamer Contributors` in new source fi...As [discussed here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1029#note_805587) I'd like to propose to start using generic copyright headers such as `Copyright The GStreamer Contributors` in new source files instead of listing individuals.
This is pattern is now [recommended by the Linux Foundation](https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/) (see also their [Open Source Licensing Basics for Software Developers training](https://training.linuxfoundation.org/training/open-source-licensing-basics-for-software-developers/) training) and will save us copyright bikeshedding discussions when doing updates.
If we go with this, which phrasing should we use?
- Copyright The GStreamer Authors.
- Copyright The GStreamer Contributors.
- Copyright Contributors to the GStreamer project.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/76Should add -Wimplicit-fallthrough to all repositories2022-04-13T08:12:48ZNirbheek Chauhannirbheek.chauhan@gmail.comShould add -Wimplicit-fallthrough to all repositorieshttps://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-fallthrough
CC: @slomohttps://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-fallthrough
CC: @slomoNirbheek Chauhannirbheek.chauhan@gmail.comNirbheek Chauhannirbheek.chauhan@gmail.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/74Add machine-readable SPDX license identifiers to all files2023-11-16T22:32:55ZSebastian DrögeAdd machine-readable SPDX license identifiers to all filesSee https://spdx.dev/ids/#how
This makes it easier to know the exact license information of everything in an automated way and potentially makes it easier for companies to ship GStreamer and comply with the licenses.See https://spdx.dev/ids/#how
This makes it easier to know the exact license information of everything in an automated way and potentially makes it easier for companies to ship GStreamer and comply with the licenses.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/39Matrix/Riot: Give #gstreamer a nice title/logo2020-05-31T15:22:13ZNiels De Graefnielsdegraef@gmail.comMatrix/Riot: Give #gstreamer a nice title/logoWhen using Matrix.org (for example, using [Riot](https://riot.im/) or [Fractal](https://flathub.org/apps/details/org.gnome.Fractal)) to connect to IRC, it synchronizes a Matrix room to an IRC one. This gives people with moderators access...When using Matrix.org (for example, using [Riot](https://riot.im/) or [Fractal](https://flathub.org/apps/details/org.gnome.Fractal)) to connect to IRC, it synchronizes a Matrix room to an IRC one. This gives people with moderators access (automatically synced to the list of chanops) the opportunity to give a fancy title and logo to a channel.
GNOME does this for several of its channels. See for example a screenshot I took in Fractal:
![matrix-channels](/uploads/a1203601946c5039e6c5b2f95251a084/matrix-channels.png)
It's a small change, but it's a nice one for people who use Matrix (especially given that GNOME links to it https://wiki.gnome.org/Community/GettingInTouch/IRC).
This requires not a lot of effort:
* log into Matrix (for example using Riot)
* Register with NickServ (see also https://medium.com/@agathver/staying-always-online-in-irc-using-riot-the-right-way-d4c4ff2f43d0) if you're having difficulties
* join the matrix room #freenode_#GStreamer:matrix.org
* Change the title and logo
The change will persist after you loghttps://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/38Merge Request reviews and approvals2019-06-11T18:40:58ZAndoni Morales AlastrueyMerge Request reviews and approvalsIt's been a while since I don't contribute to GStreamer so I don't know if this has already been discussed, I can't find it anywhere. The ["How to contribute to GStreamer"](https://gstreamer.freedesktop.org/documentation/contribute/index...It's been a while since I don't contribute to GStreamer so I don't know if this has already been discussed, I can't find it anywhere. The ["How to contribute to GStreamer"](https://gstreamer.freedesktop.org/documentation/contribute/index.html) docs explains how contributions should be made for "non-developers" (without the "developer" badge in the project) but it doesn't explain the workflow for "developers", assuming that anyone with developer access can merge freely. Even though CI's are doing a good job in ensuring quality in the MR's (the changes in that branches at least build and tests, if any, are passing), there should be an approval step prior to the merge to ensure an extra bit in code's quality. My situation, for example, is that I have 4 MR's opened in cerbero, with CI's passing, and even though I have been working on that project for several years, I feel all of them needs a reviewer. There are so many variables in play that a review is always needed to improve the overall quality of the code and the project.
I would like to propose that Merge Requests should have at least an approval from another developer in the project. This [feature](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html) is available in GitLab's Starter or EE but since this is a private instance I don't think this it's enabled by default. If this feature is not available we can do it with comments.
## Proposed workflow
* A developer opens a MR
* The MR is reviewed by at least another developer
* Comments in the MR are processed
* A developer approves the MR using the MR approval feature or commenting on the MR.
* The developer that opened the MR merges it.
## Tools to help the review process.
* A bot that listen for "Needs reviewer" comments and posts to #gstreamerhttps://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/26Fast-forward & squash does not seem to work2020-06-22T13:41:35ZSebastian DrögeFast-forward & squash does not seem to workSee https://gitlab.freedesktop.org/gstreamer/gstreamer/merge_requests/3#note_74856
Should test that again in a throw-away branch and otherwise report to GitLab.
@alatiera found https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/203...See https://gitlab.freedesktop.org/gstreamer/gstreamer/merge_requests/3#note_74856
Should test that again in a throw-away branch and otherwise report to GitLab.
@alatiera found https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20375
@daniels did some other project report a similar problem?