GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2020-12-01T18:48:01Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/840dma-buf heaps: develop GStreamer memory allocator based on dma-buf heaps2020-12-01T18:48:01ZKevin Songdma-buf heaps: develop GStreamer memory allocator based on dma-buf heapsKernel implement dma-buf heaps to replace ION memory allocator. Is there GStreamer memory allocator based on dma-buf heaps? If no, I will develop it.Kernel implement dma-buf heaps to replace ION memory allocator. Is there GStreamer memory allocator based on dma-buf heaps? If no, I will develop it.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/809ximagesrc use-damage=false stutters, use-damage=true uses too much CPU2020-12-01T20:21:24ZAmbareesh "Amby" Balajiximagesrc use-damage=false stutters, use-damage=true uses too much CPUHi, I'm stuck in this conundrum where `ximagesrc` is misbehaving by performing suboptimally. Initially, I had `use-damage` set to `false` and noticed a lot of recurring stutter. After inspecting my pipeline, I finally discovered that `us...Hi, I'm stuck in this conundrum where `ximagesrc` is misbehaving by performing suboptimally. Initially, I had `use-damage` set to `false` and noticed a lot of recurring stutter. After inspecting my pipeline, I finally discovered that `use-damage=false` was the culprit and hence I changed it to `true`. Now it's even worse since `ximagesrc` now uses 50% CPU, which is way too high for me. I'm running of both `gstreamer` and `gst-plugins-good` 1.18.1, installed from the Arch Linux repository.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/808pulsesink | gst_pulseringbuffer_commit2021-02-13T10:24:16ZDaniel Langbeinpulsesink | gst_pulseringbuffer_commitHi there, I hope this is the correct place to report this.
I'm not sure how to debug this further, but if you need more information I will try my best to help you.
Note: I had previously opened an [issue at lollipop](https://gitlab.gno...Hi there, I hope this is the correct place to report this.
I'm not sure how to debug this further, but if you need more information I will try my best to help you.
Note: I had previously opened an [issue at lollipop](https://gitlab.gnome.org/World/lollypop/-/issues/2630) and was redirected here ;)
### Environment
- Lollypop version: 1.4.5-1 (Arch Linux)
- GTK+ version: gtk3-mobile 3.24.23-4 (Arch-Linux)
- pulseaudio version: 14.0-1 (Arch-Linux)
- gstreamer version: 1.18.1-1 (Arch-Linux)
- Operating system: [Arch Linux ARM](https://github.com/dreemurrs-embedded/Pine64-Arch/releases/tag/20201112)
### Bug
After some time while playing a song on my PinePhone with [Lollypop](https://gitlab.gnome.org/World/lollypop), it stops playing. This happens over and over again. Note: This happens even if my screen is powered on.
<details>
<summary>Log: At 18:24:26 and later on at 18:44:43 playback stopped</summary>
```
[INFO] 2020-11-22 18:21:24 Scan started
[INFO] 2020-11-22 18:21:24 lollypop.collection_scanner::__get_objects_for_uris: execution time 0:0.020113
[INFO] 2020-11-22 18:21:24 lollypop.collection_scanner::__scan: execution time 0:0.255572
[INFO] 2020-11-22 18:21:24 Scan finished
[INFO] 2020-11-22 18:24:26 Player::_on_bus_error(): ../gst-plugins-good/ext/pulse/pulsesink.c(1750): gst_pulseringbuffer_commit (): /GstPlayBin:player/GstPlaySink:playsink/GstBin:abin/GstBin:bin0/GstAutoAudioSink:autoaudiosink0/GstPulseSink:autoaudiosink0-actual-sink-pulse
[INFO] 2020-11-22 18:44:43 Player::_on_bus_error(): ../gst-plugins-good/ext/pulse/pulsesink.c(1750): gst_pulseringbuffer_commit (): /GstPlayBin:player/GstPlaySink:playsink/GstBin:abin/GstBin:bin0/GstAutoAudioSink:autoaudiosink0/GstPulseSink:autoaudiosink0-actual-sink-pulse
```
</details>https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/298gstreamer-base/adapter: Check arguments before calling adapter functions2020-12-06T18:29:54ZSebastian Drögegstreamer-base/adapter: Check arguments before calling adapter functionsThere are various pre-conditions on the state of the adapter, e.g. it will give an assertion in the C code to try taking more bytes than are available.
These should be checked at the bindings level and be converted into panics or return...There are various pre-conditions on the state of the adapter, e.g. it will give an assertion in the C code to try taking more bytes than are available.
These should be checked at the bindings level and be converted into panics or returning a reasonable "empty"/default value.Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/297gstreamer/datetime: Handle argument checks correctly2020-12-06T17:41:23ZSebastian Drögegstreamer/datetime: Handle argument checks correctlySee https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/706
For compatibility with older versions than 1.20 we should implement the same checks in the bindings layer and return `None`/etc accordingly.See https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/706
For compatibility with older versions than 1.20 we should implement the same checks in the bindings layer and return `None`/etc accordingly.Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/839Query on usage of gl-headers on Linux2020-11-28T23:56:29ZSeppo Yli-Olliseppo.yliolli@gmail.comQuery on usage of gl-headers on LinuxWe had a follow-up from https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/786 to find out whether gl-headers is a real dependency on this project for all platforms (including Linux). And if not, whether it can be avoided to sup...We had a follow-up from https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/786 to find out whether gl-headers is a real dependency on this project for all platforms (including Linux). And if not, whether it can be avoided to supply it in sources root in favour of system GL headers.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/838GstVideoMeta fixed-size arrays arguments are not properly documented2020-12-01T09:45:17ZXavier Claessensxclaesse@gmail.comGstVideoMeta fixed-size arrays arguments are not properly documentedSee documentation of gst_buffer_add_video_meta_full(), gst_video_meta_get_plane_height() and gst_video_meta_get_plane_size(): https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html
stride and offset arguments are shown ...See documentation of gst_buffer_add_video_meta_full(), gst_video_meta_get_plane_height() and gst_video_meta_get_plane_size(): https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html
stride and offset arguments are shown as `gsize * offset` while the old gtk-doc shows them as `gsize offset[GST_VIDEO_MAX_PLANES]`. There is thus no indication that those arrays must be fixed size, giving smaller array (e.g. the actual n_planes value) crash.
gst_video_meta_get_plane_height/size() are also missing `(array fixed-size=4)` annotation.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/807mp4mux: Generated doc is missing most properties2020-11-27T12:27:35ZPhilippe Normandmp4mux: Generated doc is missing most propertieshttps://gstreamer.freedesktop.org/documentation/isomp4/mp4mux.html?gi-language=c
Only mentions the mp4mux `streamable` property, it should also list the parent class properties, as gst-inspect correctly does.https://gstreamer.freedesktop.org/documentation/isomp4/mp4mux.html?gi-language=c
Only mentions the mp4mux `streamable` property, it should also list the parent class properties, as gst-inspect correctly does.https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/125imagefreeze pipeline failing with RTSPServer2020-11-28T04:08:10ZNed Letcherimagefreeze pipeline failing with RTSPServerI have a gstreamer pipeline that uses [imagefreeze](https://gstreamer.freedesktop.org/documentation/imagefreeze/index.html) to stream frames from a PNG file. It works fine with `gst-launch-1.0`:
gst-launch-1.0 -v filesrc location=te...I have a gstreamer pipeline that uses [imagefreeze](https://gstreamer.freedesktop.org/documentation/imagefreeze/index.html) to stream frames from a PNG file. It works fine with `gst-launch-1.0`:
gst-launch-1.0 -v filesrc location=test.png ! decodebin ! videoconvert ! imagefreeze ! autovideosink
However when I run with gst-rtsp-server (using Python bindings) the stream is not working:
```python
import sys
import gi
gi.require_version("Gst", "1.0")
gi.require_version("GstRtspServer", "1.0")
from gi.repository import Gst, GstRtspServer, GLib
PIPELINE = f"filesrc location=test.png ! pngdec ! videoconvert ! imagefreeze ! autovideosink"
class MediaFactory(GstRtspServer.RTSPMediaFactory):
def do_create_element(self, _url):
return Gst.parse_launch(PIPELINE)
def run_server():
server = GstRtspServer.RTSPServer()
factory = MediaFactory()
factory.set_shared(True)
server.get_mount_points().add_factory("/stream", factory)
server.attach(None)
if __name__ == "__main__":
Gst.init(None)
run_server()
GLib.MainLoop().run()
```
When I run with `GST_DEBUG=2 python test.py` and hit the endpoint with `vlc rtsp://127.0.0.1:8554/stream`, I get the following error:
```
1:04:19.631279626 4187713 0x55c27bebb460 ERROR rtspclient rtsp-client.c:3017:handle_setup_request: client 0x55c27bec43b0: no control in path '/stream'
```
The below test pipeline works fine in the Python script, so it makes me wonder if there's an issue with RTSPServer and my imagefreeze pipeline, or maybe something to do with my environment.
videotestsrc ! video/x-raw,width=1920,height=1080 ! x264enc ! h264parse ! rtph264pay name=pay0 config-interval=1
My environment:
- Ubuntu 20.10
- gst-rtsp-server 1.18.0-2
- PyGObject==3.38.0
- gobject==0.1.0
- Linux Kernel: 5.9.8
Edit: I've also reproduced this on MacOS Catalina.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1476dxgiscreencapsrc: Plugin stops with an error when the desktop is locked2020-12-22T19:46:32ZVishesh Bhartiyadxgiscreencapsrc: Plugin stops with an error when the desktop is lockedIf I start a pipeline with the `dxgiscreencapsrc` and then lock the computer (eg. using Windows Key + L) the pipeline stops. Using `gst-launch` I get the following error:
```
ERROR: from element /GstPipeline:pipeline0/GstDXGIScreenCapSr...If I start a pipeline with the `dxgiscreencapsrc` and then lock the computer (eg. using Windows Key + L) the pipeline stops. Using `gst-launch` I get the following error:
```
ERROR: from element /GstPipeline:pipeline0/GstDXGIScreenCapSrc:dxgiscreencapsrc0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstDXGIScreenCapSrc:dxgiscreencapsrc0:
streaming stopped, reason error (-5)
```https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/124need gstreamer-1.0 >=1.19.02020-11-25T07:40:32Zguangxin.zhouneed gstreamer-1.0 >=1.19.0my system ubuntu 18.04 server ...
```
meson buildir
The Meson build system
Version: 0.56.0
Source dir: /gds/gits/gst-rtsp-server
Build dir: /gds/gits/gst-rtsp-server/buildir
Build type: native build
Project name: gst-rtsp-server
Projec...my system ubuntu 18.04 server ...
```
meson buildir
The Meson build system
Version: 0.56.0
Source dir: /gds/gits/gst-rtsp-server
Build dir: /gds/gits/gst-rtsp-server/buildir
Build type: native build
Project name: gst-rtsp-server
Project version: 1.19.0.1
C compiler for the host machine: cc (gcc 7.5.0 "cc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0")
C linker for the host machine: cc ld.bfd 2.30
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports link arguments -Wl,-Bsymbolic-functions: YES
Compiler for C supports arguments -fvisibility=hidden: YES
Compiler for C supports arguments -fno-strict-aliasing: YES
Message: Disabling deprecated GLib API
Compiler for C supports arguments -Wmissing-declarations: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Wredundant-decls: YES
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wwrite-strings: YES
Compiler for C supports arguments -Wformat: YES
Compiler for C supports arguments -Wformat-nonliteral: YES
Compiler for C supports arguments -Wformat-security: YES
Compiler for C supports arguments -Wold-style-definition: YES
Compiler for C supports arguments -Waggregate-return: YES
Compiler for C supports arguments -Winit-self: YES
Compiler for C supports arguments -Wmissing-include-dirs: YES
Compiler for C supports arguments -Waddress: YES
Compiler for C supports arguments -Wno-multichar: YES
Compiler for C supports arguments -Wdeclaration-after-statement: YES
Compiler for C supports arguments -Wvla: YES
Compiler for C supports arguments -Wpointer-arith: YES
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Run-time dependency glib-2.0 found: YES 2.56.4
Dependency gstreamer-1.0 found: NO found 1.14.5 but need: '>= 1.19.0'
Found CMake: /usr/bin/cmake (3.10.2)
Run-time dependency gstreamer-1.0 found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency gstreamer-1.0
meson.build:138:0: ERROR: Neither a subproject directory nor a gstreamer.wrap file was found.
A full log can be found at /gds/gits/gst-rtsp-server/buildir/meson-logs/meson-log.txt
```https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/296Add bindings for GstOpenSLESSink2020-11-24T09:25:58ZSirius WuAdd bindings for GstOpenSLESSinkIn my android project I need to inherit from GstOpenSLESSink. I have some questions:
* How could I generate bindings for it? Which document should I read? Which files should I change?
* Should I add the bindings to gstreamer-audio, or j...In my android project I need to inherit from GstOpenSLESSink. I have some questions:
* How could I generate bindings for it? Which document should I read? Which files should I change?
* Should I add the bindings to gstreamer-audio, or just put it in my own project?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/805v4l2videodec: use v4l2 capture buffer pool when link v4l2 video decoder with ...2020-11-30T12:40:28ZKevin Songv4l2videodec: use v4l2 capture buffer pool when link v4l2 video decoder with fakesinkv4l2 video decoder will copy video decoded frame when link with fakesink. It cause harder to check performance with fakesink. Below code cause the issue. Can we avoid it?
gboolean
gst_v4l2_object_decide_allocation (GstV4l2Object * obj, ...v4l2 video decoder will copy video decoded frame when link with fakesink. It cause harder to check performance with fakesink. Below code cause the issue. Can we avoid it?
gboolean
gst_v4l2_object_decide_allocation (GstV4l2Object * obj, GstQuery * query)
{
can_share_own_pool = (has_video_meta || !obj->need_video_meta);
}https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/77GstSrtpDec documentation error2021-02-02T13:45:01ZJochen JungGstSrtpDec documentation errorHello,
I'm posting this after resolving the following problem: [GSrtpDec: request-key-callback results in app crash](https://lists.freedesktop.org/archives/gstreamer-devel/2020-November/076733.html)
The documentation for the [request-...Hello,
I'm posting this after resolving the following problem: [GSrtpDec: request-key-callback results in app crash](https://lists.freedesktop.org/archives/gstreamer-devel/2020-November/076733.html)
The documentation for the [request-key-callback](https://gstreamer.freedesktop.org/documentation/srtp/srtpdec.html?gi-language=c#srtpdec::request-key) has the following signature:
GstCaps request_key_callback (GstElement gstsrtpdec, guint ssrc, gpointer udata)
This should be corrected to
GstCaps* request_key_callback (GstElement* gstsrtpdec, guint ssrc, gpointer udata)
Regards,
Jochen Junghttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1474GstSrtpDec documentation error2020-11-24T02:00:59ZJochen JungGstSrtpDec documentation errorHello,
I'm posting this after resolving the following problem: [GSrtpDec: request-key-callback results in app crash](https://lists.freedesktop.org/archives/gstreamer-devel/2020-November/076733.html)
The documentation for the [request-...Hello,
I'm posting this after resolving the following problem: [GSrtpDec: request-key-callback results in app crash](https://lists.freedesktop.org/archives/gstreamer-devel/2020-November/076733.html)
The documentation for the [request-key-callback](https://gstreamer.freedesktop.org/documentation/srtp/srtpdec.html?gi-language=c#srtpdec::request-key) has the following signature:
GstCaps request_key_callback (GstElement gstsrtpdec, guint ssrc, gpointer udata)
This should be corrected to
GstCaps* request_key_callback (GstElement* gstsrtpdec, guint ssrc, gpointer udata)
Regards,
Jochen Junghttps://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg/-/issues/22Index error in libavutil/version.py on meson-4.3 branch2021-02-01T10:09:06ZMyaamoriIndex error in libavutil/version.py on meson-4.3 branch```py
old_revision = f.readlines()[3].strip().split('"')[1]
```
The index after `readlines()` should be 2 after the change in 3ad44f90.```py
old_revision = f.readlines()[3].strip().split('"')[1]
```
The index after `readlines()` should be 2 after the change in 3ad44f90.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/134IsA<gstreamer_base::BaseSink> not satisfied while extending BaseSink2020-11-23T11:00:53ZSirius WuIsA<gstreamer_base::BaseSink> not satisfied while extending BaseSinkI'm working on a plugin using Android Oboe Library here: [gst-oboe-rs](https://gitlab.freedesktop.org/ccwu660601/gst-oboe-rs).
I've an error message which I could not figure out:
```
error[E0599]: no method named `get_segment` found fo...I'm working on a plugin using Android Oboe Library here: [gst-oboe-rs](https://gitlab.freedesktop.org/ccwu660601/gst-oboe-rs).
I've an error message which I could not figure out:
```
error[E0599]: no method named `get_segment` found for reference `&sink::imp::OboeSink` in the current scope
--> src/sink/imp.rs:100:26
|
12 | pub struct OboeSink {}
| -------------------
| |
| doesn't satisfy `_: glib::IsA<gstreamer_base::BaseSink>`
| doesn't satisfy `_: gstreamer_base::BaseSinkExtManual`
...
100 | let start = self.get_segment().get_start();
| ^^^^^^^^^^^ method not found in `&sink::imp::OboeSink`
|
= note: the method `get_segment` exists but the following trait bounds were not satisfied:
`sink::imp::OboeSink: glib::IsA<gstreamer_base::BaseSink>`
which is required by `sink::imp::OboeSink: gstreamer_base::BaseSinkExtManual`
`&sink::imp::OboeSink: glib::IsA<gstreamer_base::BaseSink>`
which is required by `&sink::imp::OboeSink: gstreamer_base::BaseSinkExtManual`
warning: unused import: `gst_base::prelude::BaseSinkExtManual`
--> src/sink/imp.rs:7:5
|
7 | use gst_base::prelude::BaseSinkExtManual;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
I've compared my code with gst-plugin-rs/video/cdg/src/cdgdec, which also uses a `VideoDecoderExtManual`. I have extended the OboeSink in mod.rs with gst_base::BaseSink, but still got this error.https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/123RTSP server not working with cellular client2023-06-13T16:11:29ZMax LauRTSP server not working with cellular clientI am currently using gst-rtsp-server to build a RTSP in Nvidia Jetson Xavier NX and it has been working fine.
However, whenever I try to retrieve the video feed using a phone / laptop behind a cellular router (4G or 5G), the RTSP does no...I am currently using gst-rtsp-server to build a RTSP in Nvidia Jetson Xavier NX and it has been working fine.
However, whenever I try to retrieve the video feed using a phone / laptop behind a cellular router (4G or 5G), the RTSP does not accept any other new incoming clients after that.
I would like to see if anyone has seen the same using gst-rtsp-server.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/804Major version upgrade appears to break due to not purging the cache2023-07-06T11:13:55ZRaphael BertocheMajor version upgrade appears to break due to not purging the cacheI've been using gstreamer-plugins-good elements. After upgrading the package a while ago some of them stopped working and gst-inspect wouldn't list them. Also trying to instantiate them would fail. The ones that gave me errors were ximag...I've been using gstreamer-plugins-good elements. After upgrading the package a while ago some of them stopped working and gst-inspect wouldn't list them. Also trying to instantiate them would fail. The ones that gave me errors were ximagesink and xvimagesink.
After purging ~/.cache/gstreamer they started working again. I don't know if a reboot or something else would fix it, because I had this problem before and so I just tried it again.
Probably the invalidation of the cache is missing or didn't succeed for some reason.
I was running at 1.16.2 and did the update to version 1.18.0, in an openSUSE TW system if it's relevant in some way. [Downstream issue](https://bugzilla.opensuse.org/show_bug.cgi?id=1178563)
I'll be happy to downgrade again if I'm able to find the old packages and try to reproduce the problem if that's necessary.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1471dxgiscreencapsrc: Capturing from the same Monitor twice2020-12-22T19:46:32ZErian Russelldxgiscreencapsrc: Capturing from the same Monitor twiceHi,
I would like it if we could use the `dxgiscreencapsrc` to capture from the same monitor twice. There is a limitation with the the DXGI API.
https://docs.microsoft.com/en-us/windows/win32/api/dxgi1_2/nf-dxgi1_2-idxgioutput1-duplic...Hi,
I would like it if we could use the `dxgiscreencapsrc` to capture from the same monitor twice. There is a limitation with the the DXGI API.
https://docs.microsoft.com/en-us/windows/win32/api/dxgi1_2/nf-dxgi1_2-idxgioutput1-duplicateoutput#remarks
>By default, only four processes can use a IDXGIOutputDuplication interface at the same time within a single session. A process can have only one desktop duplication interface on a single desktop output; however, that process can have a desktop duplication interface for each output that is part of the desktop.
This might not be desirable as the caps might not be configurable from the `dxgiscreencapsrc` plugin but could still be configured using other plugins attached (`videocrop` etc).
The use case is we would like to use `dxgiscreencapsrc` across 2 separate pipelines.