GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-09-08T09:05:18Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/102Integrating Latest GLib in GStreamer2022-09-08T09:05:18ZGokila MIntegrating Latest GLib in GStreamerHi Team,
We have a Voice Mail server application integrated with GStreamer1.12 to transcode audio data. The software is running fine since few years without any major issues. Recently, one of our customer reported Memory leak in the app...Hi Team,
We have a Voice Mail server application integrated with GStreamer1.12 to transcode audio data. The software is running fine since few years without any major issues. Recently, one of our customer reported Memory leak in the application.
On reviewing the UMDH (memory leak tool) logs, we notice that it is pointing to Glib function. In this regard we have posted a query here (g_source_remove method call is getting stuck (leading corresponding thread to get stuck) (#96) · Issues · GStreamer / gstreamer-project · GitLab ) .
As per your suggestion, we are trying to upgrade to latest 1.20 from GStreamer 1.12.
Since the issue is pointing to Glib, we have posted query in GNome forum and they suggested to use the latest Glib (2.72.3) version which has memory leak fix pertaining to the area of interest.
On looking at the GStreamer 1.20 release; we understand that it has Glib 2.62.6 version integrated with it. However, the memory leak fix is given in Glib 2.72.3 version.
Thus, we took help from GNOME community and built latest Glib and tried replacing the latest Glib 2.72.3 in GStreamer1.20 folder and tested it.
We have compiled our application using GStreamer 1.20 headers and libs (replaced with latest Glib dll’s).
Also in GStreamer installation folder, we have replaced the latest Glib’s.
But our application is failing to integrate with G-Streamer when we process the call. This looks to be pure library mis-match issue.
Please help us with the procedure to include latest Glib’s in GStreamer 1.20 version.
Do the GStreamer need to be compiled with the latest Glib version? If yes, kindly point us with the procedure on how to do the same?
Our Application is built on Visual Studio 2012 and runs on Windows. Please let us know the correct G-streamer that we need to download i.e., MSVC or MinGW as we have used GStreamer 1.12 which did not have the MSVC or MinGW version?
The software levels we are using as below,
1. Our Media server application built in VS 2012 and runs on Windows-2016 Server.
2. GStreamer 1.20 MinGW 32 bit. Please correct us based on the information provided above.
3. Required latest Glib version 2.72.3.
- We have compiled Glib 2.72.3 in VS2019 and tried integrating Glib and GObject with GStreamer 1.20 MSVC version. When we tried to run call, it fails.
Does the Glib 2.72.3 and GObject works well with GStreamer 1.20 MSVC version?
Please advise us how to proceed on using the latest Glib in GStreamer.
Thanks in Advance,
Gokilahttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/384Unable to install on Apple M1 without Rosetta2022-09-22T13:11:39ZRuslan KhamidullinUnable to install on Apple M1 without Rosetta**Reproduce:**
1. Boot a clean enough macOS (without Rosetta) on a M1 device (e.g. M1 Mini 2020).
2. [Download](https://gstreamer.freedesktop.org/download/) the latest stable installer: [v1.20.3](https://gstreamer.freedesktop.org/data/pk...**Reproduce:**
1. Boot a clean enough macOS (without Rosetta) on a M1 device (e.g. M1 Mini 2020).
2. [Download](https://gstreamer.freedesktop.org/download/) the latest stable installer: [v1.20.3](https://gstreamer.freedesktop.org/data/pkg/osx/1.20.3/gstreamer-1.0-1.20.3-universal.pkg).
3. Open the package from Finder (or by the `open` command from Terminal).
**Expected:** the installer runs normally, the same as on x86_64 Mac machines.
**Actual:** the installer suggests to install Rosetta which should not be necessary to run (and hence install) the fat binaries; if I refuse it, the installation fails:
![image](/uploads/08c421645827c801d6c0f3744bccbb3c/image.png) ![image](/uploads/ac7bc42b9e9390291b2c20a9030de12c/image.png)
**Technical note:** our release engineer told that to fix this it is necessary to add the following line to the `Distribution.dist` source file of the the installer:
```xml
<options customize="allow" require-scripts="true" hostArchitectures="arm64,x86_64"/>
```
**Cosmetic note:** the version `1.0` seen on the screenshots above seems wrong. I'd expect to see `1.20` or `1.20.3`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1416Unable to install on Apple M1 without Rosetta2022-09-05T05:39:52ZRuslan KhamidullinUnable to install on Apple M1 without Rosetta**Reproduce:**
1. Boot a clean enough macOS (without Rosetta) on a M1 device (e.g. M1 Mini 2020).
2. [Download](https://gstreamer.freedesktop.org/download/) the latest stable installer: [v1.20.3](https://gstreamer.freedesktop.org/data/pk...**Reproduce:**
1. Boot a clean enough macOS (without Rosetta) on a M1 device (e.g. M1 Mini 2020).
2. [Download](https://gstreamer.freedesktop.org/download/) the latest stable installer: [v1.20.3](https://gstreamer.freedesktop.org/data/pkg/osx/1.20.3/gstreamer-1.0-1.20.3-universal.pkg).
3. Open the package from Finder (or by the `open` command from Terminal).
**Expected:** the installer runs normally, the same as on x86_64 Mac machines.
**Actual:** the installer suggests to install Rosetta which should not be necessary to run (and hence install) the fat binaries; if I refuse it, the installation fails:
![prompt to install Rosetta](/uploads/6a2446bfa20b7666adad4898b14fa161/image.png) ![installation error](/uploads/39840c56292782f26bf2b09c1e6b305e/image.png)
**Technical note:** our release engineer told that to fix this it is necessary to add the following line to the `Distribution.dist` source file of the the installer:
```xml
<options customize="allow" require-scripts="true" hostArchitectures="arm64,x86_64"/>
```
**Cosmetic note:** the version `1.0` seen on the screenshots above seems wrong. I'd expect to see `1.20` or `1.20.3`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1415SRT: srt client cannot view video after a period of time or access another time2022-09-04T08:52:03ZsprhawkSRT: srt client cannot view video after a period of time or access another timeIf I connect from client to server second time or connect after server started a period of time, client side cannot show up video, client reports discont detected.
```
# Server end command:
GST_DEBUG=srt*:5 gst-launch-1.0 v4l2src ! vid...If I connect from client to server second time or connect after server started a period of time, client side cannot show up video, client reports discont detected.
```
# Server end command:
GST_DEBUG=srt*:5 gst-launch-1.0 v4l2src ! videoconvert ! video/x-raw ! nvh265enc zerolatency=0 preset=low-latency-hq ! video/x-h265 ! mpegtsmux ! srtsink uri=srt://:7001/ mode=listener latency=0 wait-for-connection=true
#Client end command:
GST_DEBUG=srt*:5 gst-launch-1.0 srtsrc mode=caller uri=srt://127.0.0.1:7001/ ! tsdemux latency=0 ! h265parse ! msdkh265dec ! videoconvert ! autovideosink sync=false
```
Server Log:
```
0:00:00.267970046 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:266:gst_srt_object_new:<GstSRTSink@0x5647d7682820> Starting up SRT
0:00:00.268029452 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:704:gst_srt_object_set_uri:<GstSRTSink@0x5647d7682820> set uri to (host: 127.0.0.1, port: 7001) with 0 query strings
0:00:00.268042558 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:704:gst_srt_object_set_uri:<srtsink0> set uri to (host: (null), port: 7001) with 0 query strings
Setting pipeline to PAUSED ...
0:00:00.269183269 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:1116:gst_srt_object_open_internal:<srtsink0> Given uri doesn't have hostname or address. Use any (0.0.0.0) and setting listener mode
0:00:00.269193812 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:1123:gst_srt_object_open_internal:<srtsink0> Opening SRT socket with parameters: application/x-srt-params, poll-timeout=(int)-1, latency=(int)0, mode=(GstSRTConnectionMode)listener, localaddress=(string)0.0.0.0, localport=(uint)7001;
0:00:00.269234766 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:167:gst_srt_object_resolve:<srtsink0> IP address for host 0.0.0.0 is 0.0.0.0
0:00:00.269243179 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:167:gst_srt_object_resolve:<srtsink0> IP address for host 0.0.0.0 is 0.0.0.0
0:00:00.269266457 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:892:gst_srt_object_wait_connect:<srtsink0> Binding to 0.0.0.0 (port: 7001)
0:00:00.269315822 890307 0x5647d71ad150 DEBUG srtobject gstsrtobject.c:908:gst_srt_object_wait_connect:<srtsink0> Starting to listen on bind socket
0:00:00.269356542 890307 0x5647d71a29e0 DEBUG srtobject gstsrtobject.c:774:thread_func:<srtsink0> Waiting a request from caller
Pipeline is live and does not need PREROLL ...
Got context from element 'nvh265enc0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(int)0;
Got context from element 'nvh265enc0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:01.358090528 890307 0x5647d71a2c00 DEBUG srtsink gstsrtsink.c:230:gst_srt_sink_set_caps:<srtsink0> setcaps video/mpegts, systemstream=(boolean)true, packetsize=(int)188
0:00:01.358103470 890307 0x5647d71a2c00 DEBUG srtsink gstsrtsink.c:238:gst_srt_sink_set_caps:<srtsink0> 'streamheader' field not present
0:00:01.358108134 890307 0x5647d71a2c00 DEBUG srtsink gstsrtsink.c:267:gst_srt_sink_set_caps:<srtsink0> Collected streamheaders: 0 buffers
0:00:01.358171178 890307 0x5647d71a2c00 DEBUG srtsink gstsrtsink.c:230:gst_srt_sink_set_caps:<srtsink0> setcaps video/mpegts, systemstream=(boolean)true, packetsize=(int)188, streamheader=(buffer)< 47400031a600ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000b00d0001c100000001e020a2c32941, 47402031a100ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0002b0120001c10000e041f00024e041f00093dfabf9 >
0:00:01.358178242 890307 0x5647d71a2c00 DEBUG srtsink gstsrtsink.c:246:gst_srt_sink_set_caps:<srtsink0> 'streamheader' field holds array
0:00:01.358183379 890307 0x5647d71a2c00 DEBUG srtsink gstsrtsink.c:267:gst_srt_sink_set_caps:<srtsink0> Collected streamheaders: 2 buffers
0:00:01.358689121 890307 0x5647d71a2c00 INFO srtobject gstsrtobject.c:1238:gst_srt_object_wait_caller:<srtsink0> Waiting for connection
0:00:06.430542807 890307 0x7fc73c0044a0 DEBUG srtlib queue.cpp:1345:worker_ProcessConnectionRequest: : PASSING request from: 127.0.0.1:42944 to agent:361027369
0:00:06.430606596 890307 0x7fc73c0044a0 DEBUG srtlib queue.cpp:1365:worker_ProcessConnectionRequest: : Listener managed the connection request from: 127.0.0.1:42944 result:waveahand
0:00:06.430636232 890307 0x7fc73c0044a0 DEBUG srtlib queue.cpp:1345:worker_ProcessConnectionRequest: : PASSING request from: 127.0.0.1:42944 to agent:361027369
0:00:06.430806914 890307 0x7fc73c0044a0 DEBUG srtlib core.cpp:2541:processSrtMsg_HSREQ: : HSREQ/rcv: cmd=1(HSREQ) len=12 vers=0x10402 opts=0xbf delay=125
0:00:06.430829593 890307 0x7fc73c0044a0 DEBUG srtlib core.cpp:10567:processConnectRequest: : listen ret: -1 - conclusion
0:00:06.430833934 890307 0x7fc73c0044a0 DEBUG srtlib queue.cpp:1365:worker_ProcessConnectionRequest: : Listener managed the connection request from: 127.0.0.1:42944 result:waveahand
0:00:06.430863144 890307 0x5647d71a29e0 DEBUG srtobject gstsrtobject.c:822:thread_func:<srtsink0> Accept to connect 361027368
0:00:06.430876182 890307 0x5647d71a29e0 DEBUG srtobject gstsrtobject.c:774:thread_func:<srtsink0> Waiting a request from caller
0:00:06.430881945 890307 0x5647d71a2c00 DEBUG srtobject gstsrtobject.c:1243:gst_srt_object_wait_caller:<srtsink0> Got a connection
0:00:06.430893722 890307 0x5647d71a2c00 DEBUG srtobject gstsrtobject.c:1407:gst_srt_object_send_headers:<srtsink0> Sending 2 stream headers
0:00:09.683059011 890307 0x5647d71a2c00 WARN srtobject gstsrtobject.c:1488:gst_srt_object_write_to_callers:<srtsink0> Dropping caller 361027368: Connection was broken
0:00:09.683117400 890307 0x5647d71a2c00 INFO srtobject gstsrtobject.c:1238:gst_srt_object_wait_caller:<srtsink0> Waiting for connection
0:00:11.997486867 890307 0x7fc73c0044a0 DEBUG srtlib queue.cpp:1345:worker_ProcessConnectionRequest: : PASSING request from: 127.0.0.1:32936 to agent:361027369
0:00:11.997523224 890307 0x7fc73c0044a0 DEBUG srtlib queue.cpp:1365:worker_ProcessConnectionRequest: : Listener managed the connection request from: 127.0.0.1:32936 result:waveahand
0:00:11.997633245 890307 0x7fc73c0044a0 DEBUG srtlib queue.cpp:1345:worker_ProcessConnectionRequest: : PASSING request from: 127.0.0.1:32936 to agent:361027369
0:00:11.997776633 890307 0x7fc73c0044a0 DEBUG srtlib core.cpp:2541:processSrtMsg_HSREQ: : HSREQ/rcv: cmd=1(HSREQ) len=12 vers=0x10402 opts=0xbf delay=125
0:00:11.997799388 890307 0x7fc73c0044a0 DEBUG srtlib core.cpp:10567:processConnectRequest: : listen ret: -1 - conclusion
0:00:11.997804137 890307 0x7fc73c0044a0 DEBUG srtlib queue.cpp:1365:worker_ProcessConnectionRequest: : Listener managed the connection request from: 127.0.0.1:32936 result:waveahand
0:00:11.997873656 890307 0x5647d71a29e0 DEBUG srtobject gstsrtobject.c:822:thread_func:<srtsink0> Accept to connect 361027367
0:00:11.997885926 890307 0x5647d71a29e0 DEBUG srtobject gstsrtobject.c:774:thread_func:<srtsink0> Waiting a request from caller
0:00:11.997889928 890307 0x5647d71a2c00 DEBUG srtobject gstsrtobject.c:1243:gst_srt_object_wait_caller:<srtsink0> Got a connection
0:00:11.997905067 890307 0x5647d71a2c00 DEBUG srtobject gstsrtobject.c:1407:gst_srt_object_send_headers:<srtsink0> Sending 2 stream headers
0:01:13.790101739 890307 0x5647d71a2c00 WARN srtobject gstsrtobject.c:1488:gst_srt_object_write_to_callers:<srtsink0> Dropping caller 361027367: Connection was broken
0:01:13.790159327 890307 0x5647d71a2c00 INFO srtobject gstsrtobject.c:1238:gst_srt_object_wait_caller:<srtsink0> Waiting for connection
```
Client Log:
```
0:00:00.008767670 890498 0x55ab30985150 DEBUG srtobject gstsrtobject.c:266:gst_srt_object_new:<GstSRTSrc@0x55ab30b08160> Starting up SRT
0:00:00.008826069 890498 0x55ab30985150 DEBUG srtobject gstsrtobject.c:704:gst_srt_object_set_uri:<GstSRTSrc@0x55ab30b08160> set uri to (host: 127.0.0.1, port: 7001) with 0 query strings
0:00:00.008847044 890498 0x55ab30985150 DEBUG srtobject gstsrtobject.c:704:gst_srt_object_set_uri:<srtsrc0> set uri to (host: 127.0.0.1, port: 7001) with 0 query strings
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
Setting pipeline to PAUSED ...
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
0:00:00.018372298 890498 0x55ab30985150 DEBUG srtobject gstsrtobject.c:1123:gst_srt_object_open_internal:<srtsrc0> Opening SRT socket with parameters: application/x-srt-params, poll-timeout=(int)-1, latency=(int)125, mode=(GstSRTConnectionMode)caller;
0:00:00.018439716 890498 0x55ab30985150 DEBUG srtobject gstsrtobject.c:167:gst_srt_object_resolve:<srtsrc0> IP address for host 127.0.0.1 is 127.0.0.1
Pipeline is live and does not need PREROLL ...
Got context from element 'msdkh265dec0': gst.msdk.Context=context, gst.msdk.Context=(GstMsdkContext)"\(GstMsdkContext\)\ msdkcontext1";
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.019205379 890498 0x7f69380078a0 DEBUG srtlib core.cpp:5044:postConnect: : @51072215:Connection established to: 127.0.0.1:7001
0:00:00.144681659 890498 0x55ab30b7b4c0 WARN srtsrc gstsrtsrc.c:188:gst_srt_src_fill:<srtsrc0> discont detected 1008407833 (expected: 0)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/237Add a WebRTC WHEP source element2022-12-05T11:08:44ZSebastian DrögeAdd a WebRTC WHEP source elementSee https://datatracker.ietf.org/doc/html/draft-murillo-whep-00
This is basically the same as the newly added WHIP sink but in reverse. CC @arun @tkanakamallaSee https://datatracker.ietf.org/doc/html/draft-murillo-whep-00
This is basically the same as the newly added WHIP sink but in reverse. CC @arun @tkanakamallahttps://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/166Play audio at test-onvif-backchannel.c2023-10-17T17:10:52ZElampooranan SPlay audio at test-onvif-backchannel.cI have compiled the unmodified test-onvif.c (gst-plugins-good/tests/examples/rtsp/test-onvif.c ) and the test-onvif-backchannel.c( gst-rtsp-server/examples/test-onvif-backchannel.c ).
I am able to connect the two together(rtsp://127.0.0...I have compiled the unmodified test-onvif.c (gst-plugins-good/tests/examples/rtsp/test-onvif.c ) and the test-onvif-backchannel.c( gst-rtsp-server/examples/test-onvif-backchannel.c ).
I am able to connect the two together(rtsp://127.0.0.1:8554/test) and I can verify that the audio is being sent back to the server.
But how does one play the audio received by the server. The code in test-onvif-backchannel.c doesnt seem to have that facility.
Thanks.
Elam.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1414ttmlrender / ttmlparser: mp4-container: no subtitles rendered after seek (net...2022-11-10T09:21:15ZJuergen Sachsttmlrender / ttmlparser: mp4-container: no subtitles rendered after seek (network source)### Description
When playing a mp4-Container with TTML subtitles from http-location, subtitles disappear after seek.
### To reproduce
- copy the attached streams to network server (I'm using a "actual" Apache at Windows 10)
- run the ...### Description
When playing a mp4-Container with TTML subtitles from http-location, subtitles disappear after seek.
### To reproduce
- copy the attached streams to network server (I'm using a "actual" Apache at Windows 10)
- run the command "`export GST_TTML_AUTOPLUG=1 && gst-play-1.0 http://192.168.0.252/media/.../1280x720-h264-ttml-de.mp4`"
- subtitles are visible
- Use "right"-Key to jump 10s foreward
- subtitles disappear -> error
Reproduced with GStreamer 1.16, 1.20.3 (Ubuntu 22.04.1 LTS) (and with other local GStreamer installation)
### Additional Info:
1. The problem occurs
- with TTML subtitles from network source.
- with playbin2 and playbin3 (`gst-play-1.0 --use-playbin3 ...`)
2. The problem does **not** occur
- MP4 container with **SRT** subtitles (1280x720-h264-srt-de.mp4)
- MP4 container with TTML subtitles from **local** file source (`gst-play-1.0 file://.../1280x720-h264-ttml-de.mp4`)
Attachments:
- test streams:
- [1280x720-h264-ttml-de](/uploads/893367b5cabd76f7e370da26bc6499fa/1280x720-h264-ttml-de.mp4)
- [1280x720-h264-srt-de](/uploads/813c9b4844258454cec083d03dbcb99d/1280x720-h264-srt-de.mp4)
- pipelines:
- [ttml-http](/uploads/fae3e6b997f86aa9bf4ab511b325623e/ttml-http.png)
- [ttmp-file](/uploads/09a4274ab8b069878cfe65618f67cecf/ttmp-file.png)
- [srt-http](/uploads/b34da057322059d20018449b6b95e4ec/srt-http.png)
-----
I'm not sure if this is really a TTML problem. The difference between http an file is also pull- vs push-mode in upstream parts of pipeline (source -> qtdemux). So also may be typefinder or qtdemux is involved.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1731ttmlrender / ttmlparser: mp4-container: no subtitles rendered after seek (net...2022-09-02T09:34:13ZJuergen Sachsttmlrender / ttmlparser: mp4-container: no subtitles rendered after seek (network source)### Description
When playing a mp4-Container with TTML subtitles from http-location, subtitles disappear after seek.
### To reproduce
- copy the attached streams to network server (I'm using a "actual" Apache at Windows 10)
- run the ...### Description
When playing a mp4-Container with TTML subtitles from http-location, subtitles disappear after seek.
### To reproduce
- copy the attached streams to network server (I'm using a "actual" Apache at Windows 10)
- run the command "`export GST_TTML_AUTOPLUG=1 && gst-play-1.0 http://192.168.0.252/media/.../1280x720-h264-ttml-de.mp4`"
- subtitles are visible
- Use "right"-Key to jump 10s foreward
- subtitles disappear -> error
Reproduced with GStreamer 1.16, 1.20.3 (Ubuntu 22.04.1 LTS) (and with other local GStreamer installation)
### Additional Info:
1. The problem occurs
- with TTML subtitles from network source.
- with playbin3 (`gst-play-1.0 --use-playbin3 ...`)
2. The problem does **not** occur
- MP4 container with **SRT** subtitles (1280x720-h264-srt-de.mp4)
- MP4 container with TTML subtitles from **local** file source (`gst-play-1.0 file://.../1280x720-h264-ttml-de.mp4`)
Attachments:
- test streams:
- [1280x720-h264-ttml-de](/uploads/2c4f3408fb13d98ae9f4dbc3d1092221/1280x720-h264-ttml-de.mp4)
- [1280x720-h264-srt-de](/uploads/6d90089f57cefce66c370cdeee683a5c/1280x720-h264-srt-de.mp4)
- pipelines:
- [ttml-http.png](/uploads/bde9e78cd6a754df792862d47813abbd/ttml-http.png)
- [ttmp-file.png](/uploads/e3299ff6270c8b9723f2170a2828c89b/ttmp-file.png)
- [srt-http.png](/uploads/f64ed34655cd0e6ab4f4687beb63e7d7/srt-http.png)
-----
I'm not sure if this is really a TTML problem. The difference between http an file is also pull- vs push-mode in upstream parts of pipeline (source -> qtdemux). So also may be typefinder or qtdemux is involved.https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/165test-onvif.c and test-onvif-backchannel.c2022-09-02T09:21:14ZElampooranan Stest-onvif.c and test-onvif-backchannel.cI have compiled the unmodified test-onvif.c (gst-plugins-good/tests/examples/rtsp/test-onvif.c ) and the test-onvif-backchannel.c( gst-rtsp-server/examples/test-onvif-backchannel.c ).
They just wont connect with each other(rtsp://127.0...I have compiled the unmodified test-onvif.c (gst-plugins-good/tests/examples/rtsp/test-onvif.c ) and the test-onvif-backchannel.c( gst-rtsp-server/examples/test-onvif-backchannel.c ).
They just wont connect with each other(rtsp://127.0.0.1:8554/test).
_The server side reports this:_
0:00:31.430817259 19095 0x55e41e091460 WARN rtspmedia rtsp-media.c:3272:wait_preroll: failed to preroll pipeline
0:00:31.430875624 19095 0x55e41e091460 WARN rtspmedia rtsp-media.c:3652:gst_rtsp_media_prepare: failed to preroll pipeline
0:00:31.569528214 19095 0x55e41e091460 ERROR rtspclient rtsp-client.c:1077:find_media: client 0x55e41e099390: can't prepare media
0:00:31.569879789 19095 0x55e41e091460 ERROR rtspclient rtsp-client.c:2963:handle_describe_request: client 0x55e41e099390: no media
_On the client side, it is:_
0:00:20.033329145 22992 0x55daa1740f00 WARN rtspsrc gstrtspsrc.c:6323:gst_rtsp_src_receive_response:<r> error: Could not receive message. (Timeout while waiting for server response)
0:00:20.033470427 22992 0x55daa1740f00 WARN rtspsrc gstrtspsrc.c:6421:gst_rtspsrc_try_send:<r> error: Could not receive message. (Timeout while waiting for server response)
0:00:20.033655957 22992 0x55daa1740f00 WARN rtspsrc gstrtspsrc.c:7973:gst_rtspsrc_open:<r> can't get sdp
0:00:20.033705720 22992 0x55daa1740f00 WARN rtspsrc gstrtspsrc.c:8512:gst_rtspsrc_play:<r> failed to open stream
0:00:20.033739176 22992 0x55daa1740f00 WARN rtspsrc gstrtspsrc.c:6032:gst_rtspsrc_loop:<r> we are not connected
I am using Gstreamer version: GStreamer 1.16.3 on Ubuntu 20.04 LTS.
Can anyone suggest why this wont work?
Thanks
Elam.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1412decodebin2 sometimes deadlocks on EOS from an HLS stream2022-11-10T09:21:15ZAlexander Slobodeniukdecodebin2 sometimes deadlocks on EOS from an HLS stream**How to reproduce the error:**
1. run next HLS stream
`gst-play-1.0 "https://content-dtci.uplynk.com/channel/3324f2467c414329b3b0cc5cd987b6be.m3u8?ad.tfcd=0&ad.is_lat=0&ad.rdid=VENUE_ID&ad.pp=datg-live-vdms&ad.npa=0&ad.scor=TIMESTAMP&a...**How to reproduce the error:**
1. run next HLS stream
`gst-play-1.0 "https://content-dtci.uplynk.com/channel/3324f2467c414329b3b0cc5cd987b6be.m3u8?ad.tfcd=0&ad.is_lat=0&ad.rdid=VENUE_ID&ad.pp=datg-live-vdms&ad.npa=0&ad.scor=TIMESTAMP&ad.cust_params=vdm%3Dlive%26chan%3Dabcnews%26plt%3Dott%26refDomain%3Dhttps%3A%2F%2Fabcnews.go.com%26vps%3D640x480%26ppid%3DVENUE_ID%26beacTyp%3Dssai%26sp%3Dvdms%26ait%3Dssai%26var%3D16x9&ad.correlator=TIMESTAMP&ad.ppid=VENUE_ID&ad.cmsid=2494279&ad.networkID=21783347309&ad.vast3=1&ad=abcnews_live&ad.vid=CHANNEL_ID&ad.description_url=https%3A%2F%2Fabcnews.go.com&ad.idtype=rida&ad.adUnit=/abc-news/rockbot/ott&ad.us_privacy=0"`
2. it may require to wait for a while, around 30 minutes. An error occurs after the advertisement finishes playing (but not always). Playback just stops and doesn't recover anymore.
---
**Error analysis**
connecting with gdb shows next deadlock:
Thread 18 is waiting for a "cleanup thread to finish", and blocks the pad 0x7f05c0017a00 (frame 27,28)
```
Thread 18 (Thread 0x7f063d7fa700 (LWP 2045419)):
#0 __pthread_clockjoin_ex (threadid=139662538569472, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
#1 0x00007f06489fd54b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f06489d9faf in g_thread_join () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f0647788a4a in gst_decode_chain_start_free_hidden_groups_thread (chain=0x7f0640005690) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3743
#4 0x00007f064778a7bd in drain_and_switch_chains (chain=0x7f0640005690, drainpad=0x0, last_group=0x7f063d7f8420, drained=0x7f063d7f8428, switched=0x7f063d7f8424) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4223
#5 0x00007f064778c9b5 in gst_decode_bin_expose (dbin=0x7f0638040090) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4730
--Type <RET> for more, q to quit, c to continue without paging--
#6 0x00007f064778aceb in gst_decode_pad_handle_eos (pad=0x7f0638040350) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4298
#7 0x00007f064778dc0a in source_pad_event_probe (pad=0x7f0638040350, info=0x7f063d7f8770, user_data=0x7f0638040350) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:5034
#8 0x00007f0648c4b3f8 in probe_hook_marshal (hook=0x7f0600025ac0, data=0x7f063d7f8640) at ../subprojects/gstreamer/gst/gstpad.c:3664
#9 0x00007f064899f996 in g_hook_list_marshal () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007f0648c4bb23 in do_probe_callbacks (pad=0x7f0638040350, info=0x7f063d7f8770, defaultval=GST_FLOW_OK) at ../subprojects/gstreamer/gst/gstpad.c:3848
#11 0x00007f0648c5252a in gst_pad_push_event_unchecked (pad=0x7f0638040350, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5509
#12 0x00007f0648c4c545 in push_sticky (pad=0x7f0638040350, ev=0x7f063d7f8860, user_data=0x7f063d7f88b0) at ../subprojects/gstreamer/gst/gstpad.c:4047
#13 0x00007f0648c41a78 in events_foreach (pad=0x7f0638040350, func=0x7f0648c4c42c <push_sticky>, user_data=0x7f063d7f88b0) at ../subprojects/gstreamer/gst/gstpad.c:608
#14 0x00007f0648c4c90e in check_sticky (pad=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:4106
#15 0x00007f0648c52f79 in gst_pad_push_event (pad=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:5675
#16 0x00007f0648c49cc1 in event_forward_func (pad=0x7f0638040350, data=0x7f063d7f8a70) at ../subprojects/gstreamer/gst/gstpad.c:3125
#17 0x00007f0648c49aab in gst_pad_forward (pad=0x7f060c010360, forward=0x7f0648c49b96 <event_forward_func>, user_data=0x7f063d7f8a70) at ../subprojects/gstreamer/gst/gstpad.c:3079
#18 0x00007f0648c49e80 in gst_pad_event_default (pad=0x7f060c010360, parent=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:3176
#19 0x00007f0648c53e91 in gst_pad_send_event_unchecked (pad=0x7f060c010360, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5900
#20 0x00007f0648c5270e in gst_pad_push_event_unchecked (pad=0x7f05c0017310, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5544
#21 0x00007f0648c4c545 in push_sticky (pad=0x7f05c0017310, ev=0x7f063d7f8ca0, user_data=0x7f063d7f8cf0) at ../subprojects/gstreamer/gst/gstpad.c:4047
#22 0x00007f0648c41a78 in events_foreach (pad=0x7f05c0017310, func=0x7f0648c4c42c <push_sticky>, user_data=0x7f063d7f8cf0) at ../subprojects/gstreamer/gst/gstpad.c:608
#23 0x00007f0648c4c90e in check_sticky (pad=0x7f05c0017310, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:4106
#24 0x00007f0648c52f79 in gst_pad_push_event (pad=0x7f05c0017310, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:5675
#25 0x00007f0648d70421 in gst_video_decoder_push_event (decoder=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1119
#26 0x00007f0648d723e9 in gst_video_decoder_sink_event_default (decoder=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1655
#27 0x00007f0648d725b5 in gst_video_decoder_sink_event (pad=0x7f05c0017a00, parent=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1691
#28 0x00007f0648c53e91 in gst_pad_send_event_unchecked (pad=0x7f05c0017a00, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5900
```
Meanwhile the cleanup thread is blocked trying to deactivate this pad 0x7f05c0017a00
```
Thread 34 (Thread 0x7f05b7fff700 (LWP 2045448)):
#0 __lll_lock_wait (futex=futex@entry=0x7f0620004140, private=0) at lowlevellock.c:52
#1 0x00007f0648507131 in __GI___pthread_mutex_lock (mutex=0x7f0620004140) at ../nptl/pthread_mutex_lock.c:115
#2 0x00007f0648c42f0f in post_activate (pad=0x7f05c0017a00, new_mode=GST_PAD_MODE_NONE) at ../subprojects/gstreamer/gst/gstpad.c:1045
#3 0x00007f0648c4376e in activate_mode_internal (pad=0x7f05c0017a00, parent=0x7f0620011a00, mode=GST_PAD_MODE_PUSH, active=0) at ../subprojects/gstreamer/gst/gstpad.c:1223
#4 0x00007f0648c432df in gst_pad_set_active (pad=0x7f05c0017a00, active=0) at ../subprojects/gstreamer/gst/gstpad.c:1114
#5 0x00007f0648c1fdb0 in activate_pads (vpad=0x7f05b7ffe960, ret=0x7f05b7ffe9c0, active=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstelement.c:3171
#6 0x00007f0648c3617b in gst_iterator_fold (it=0x7f0640353db0, func=0x7f0648c1fd6d <activate_pads>, ret=0x7f05b7ffe9c0, user_data=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstiterator.c:617
#7 0x00007f0648c1fe57 in iterator_activate_fold_with_resync (iter=0x7f0640353db0, func=0x7f0648c1fd6d <activate_pads>, user_data=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstelement.c:3195
#8 0x00007f0648c1ff9d in gst_element_pads_activate (element=0x7f0620011a00, active=0) at ../subprojects/gstreamer/gst/gstelement.c:3240
#9 0x00007f0648c2029c in gst_element_change_state_func (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gstreamer/gst/gstelement.c:3305
#10 0x00007f0648d77c04 in gst_video_decoder_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:2878
#11 0x00007f0648c1f8a8 in gst_element_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gstreamer/gst/gstelement.c:3083
#12 0x00007f0648c1eddc in gst_element_continue_state (element=0x7f0620011a00, ret=GST_STATE_CHANGE_SUCCESS) at ../subprojects/gstreamer/gst/gstelement.c:2791
#13 0x00007f0648c1fbd2 in gst_element_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at ../subprojects/gstreamer/gst/gstelement.c:3122
#14 0x00007f0648c1f632 in gst_element_set_state_func (element=0x7f0620011a00, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:3037
#15 0x00007f0648c1f22d in gst_element_set_state (element=0x7f0620011a00, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:2938
#16 0x00007f06477881ea in gst_decode_chain_free_internal (chain=0x7f05c036a1b0, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3509
#17 0x00007f0647788738 in gst_decode_group_free_internal (group=0x7f0614002400, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3627
#18 0x00007f0647787aff in gst_decode_chain_free_internal (chain=0x7f06081c46c0, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3386
#19 0x00007f0647788738 in gst_decode_group_free_internal (group=0x7f0600422450, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3627
#20 0x00007f064778894e in gst_decode_group_free (group=0x7f0600422450) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3681
#21 0x00007f06477889a6 in gst_decode_chain_free_hidden_groups (old_groups=0x7f063800f780 = {...}) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3723
#22 0x00007f06489d9ad1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007f0648504609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#24 0x00007f06486dc133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
So,
- thread 18 blocks the pad 0x7f05c0017a00 (src pad of avdec_h264) and waits for the thread 34 to finish.
- thread 34 blocks trying to deactivate this pad 0x7f05c0017a00.
**Hipothesis about the root cause**
I was tracing the error and from what I've seen, it seems that handling EOS have walked an unexpected path:
- First **gst_decode_pad_handle_eos**() steps into **drain_and_switch_chains**() that switches the active decoding group to the next one and at this moment things seem to go well, the decoder we are blocking is now a part of an "old grop", that have been hidden and is going to be freed in another thread.
- Then it steps into **gst_decode_bin_expose**(), because it thinks that the new active group has "deadend" chains inside. The chains contain just a tsdemux and parsers inside.
So, **gst_decode_bin_expose**() starts to hide and free the "new"(not anymore) active group too, and at this moment deadlocks: it has to wait for a cleanup thread that it blocks.
So, as I suppose there's unexpected code path:
1. **gst_decode_pad_handle_eos**() --> **drain_and_switch_chains**() , it launches a cleanup thread for the group that was active (and blocks the thread therefore). This part is ok.
2. **gst_decode_pad_handle_eos**() --> **gst_decode_bin_expose**(). Here the code decides to free the next group too. And this can't not to lead to the deadlock, because it has to wait for the cleanup thread first.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/977decodebin2 sometimes deadlocks on EOS from an HLS stream2022-08-31T16:00:51ZAlexander Slobodeniukdecodebin2 sometimes deadlocks on EOS from an HLS stream**How to reproduce the error:**
1. run next HLS stream
`gst-play-1.0 "https://content-dtci.uplynk.com/channel/3324f2467c414329b3b0cc5cd987b6be.m3u8?ad.tfcd=0&ad.is_lat=0&ad.rdid=VENUE_ID&ad.pp=datg-live-vdms&ad.npa=0&ad.scor=TIMESTAMP&a...**How to reproduce the error:**
1. run next HLS stream
`gst-play-1.0 "https://content-dtci.uplynk.com/channel/3324f2467c414329b3b0cc5cd987b6be.m3u8?ad.tfcd=0&ad.is_lat=0&ad.rdid=VENUE_ID&ad.pp=datg-live-vdms&ad.npa=0&ad.scor=TIMESTAMP&ad.cust_params=vdm%3Dlive%26chan%3Dabcnews%26plt%3Dott%26refDomain%3Dhttps%3A%2F%2Fabcnews.go.com%26vps%3D640x480%26ppid%3DVENUE_ID%26beacTyp%3Dssai%26sp%3Dvdms%26ait%3Dssai%26var%3D16x9&ad.correlator=TIMESTAMP&ad.ppid=VENUE_ID&ad.cmsid=2494279&ad.networkID=21783347309&ad.vast3=1&ad=abcnews_live&ad.vid=CHANNEL_ID&ad.description_url=https%3A%2F%2Fabcnews.go.com&ad.idtype=rida&ad.adUnit=/abc-news/rockbot/ott&ad.us_privacy=0"`
2. it may require to wait for a while, around 30 minutes. An error occurs after the advertisement finishes playing (but not always). Playback just stops and doesn't recover anymore.
---
**Error analysis**
connecting with gdb shows next deadlock:
Thread 18 is waiting for a "cleanup thread to finish", and blocks the pad 0x7f05c0017a00 (frame 27,28)
```
Thread 18 (Thread 0x7f063d7fa700 (LWP 2045419)):
#0 __pthread_clockjoin_ex (threadid=139662538569472, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
#1 0x00007f06489fd54b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f06489d9faf in g_thread_join () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f0647788a4a in gst_decode_chain_start_free_hidden_groups_thread (chain=0x7f0640005690) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3743
#4 0x00007f064778a7bd in drain_and_switch_chains (chain=0x7f0640005690, drainpad=0x0, last_group=0x7f063d7f8420, drained=0x7f063d7f8428, switched=0x7f063d7f8424) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4223
#5 0x00007f064778c9b5 in gst_decode_bin_expose (dbin=0x7f0638040090) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4730
--Type <RET> for more, q to quit, c to continue without paging--
#6 0x00007f064778aceb in gst_decode_pad_handle_eos (pad=0x7f0638040350) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:4298
#7 0x00007f064778dc0a in source_pad_event_probe (pad=0x7f0638040350, info=0x7f063d7f8770, user_data=0x7f0638040350) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:5034
#8 0x00007f0648c4b3f8 in probe_hook_marshal (hook=0x7f0600025ac0, data=0x7f063d7f8640) at ../subprojects/gstreamer/gst/gstpad.c:3664
#9 0x00007f064899f996 in g_hook_list_marshal () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007f0648c4bb23 in do_probe_callbacks (pad=0x7f0638040350, info=0x7f063d7f8770, defaultval=GST_FLOW_OK) at ../subprojects/gstreamer/gst/gstpad.c:3848
#11 0x00007f0648c5252a in gst_pad_push_event_unchecked (pad=0x7f0638040350, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5509
#12 0x00007f0648c4c545 in push_sticky (pad=0x7f0638040350, ev=0x7f063d7f8860, user_data=0x7f063d7f88b0) at ../subprojects/gstreamer/gst/gstpad.c:4047
#13 0x00007f0648c41a78 in events_foreach (pad=0x7f0638040350, func=0x7f0648c4c42c <push_sticky>, user_data=0x7f063d7f88b0) at ../subprojects/gstreamer/gst/gstpad.c:608
#14 0x00007f0648c4c90e in check_sticky (pad=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:4106
#15 0x00007f0648c52f79 in gst_pad_push_event (pad=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:5675
#16 0x00007f0648c49cc1 in event_forward_func (pad=0x7f0638040350, data=0x7f063d7f8a70) at ../subprojects/gstreamer/gst/gstpad.c:3125
#17 0x00007f0648c49aab in gst_pad_forward (pad=0x7f060c010360, forward=0x7f0648c49b96 <event_forward_func>, user_data=0x7f063d7f8a70) at ../subprojects/gstreamer/gst/gstpad.c:3079
#18 0x00007f0648c49e80 in gst_pad_event_default (pad=0x7f060c010360, parent=0x7f0638040350, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:3176
#19 0x00007f0648c53e91 in gst_pad_send_event_unchecked (pad=0x7f060c010360, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5900
#20 0x00007f0648c5270e in gst_pad_push_event_unchecked (pad=0x7f05c0017310, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5544
#21 0x00007f0648c4c545 in push_sticky (pad=0x7f05c0017310, ev=0x7f063d7f8ca0, user_data=0x7f063d7f8cf0) at ../subprojects/gstreamer/gst/gstpad.c:4047
#22 0x00007f0648c41a78 in events_foreach (pad=0x7f05c0017310, func=0x7f0648c4c42c <push_sticky>, user_data=0x7f063d7f8cf0) at ../subprojects/gstreamer/gst/gstpad.c:608
#23 0x00007f0648c4c90e in check_sticky (pad=0x7f05c0017310, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:4106
#24 0x00007f0648c52f79 in gst_pad_push_event (pad=0x7f05c0017310, event=0x7f05a40fd9c0) at ../subprojects/gstreamer/gst/gstpad.c:5675
#25 0x00007f0648d70421 in gst_video_decoder_push_event (decoder=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1119
#26 0x00007f0648d723e9 in gst_video_decoder_sink_event_default (decoder=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1655
#27 0x00007f0648d725b5 in gst_video_decoder_sink_event (pad=0x7f05c0017a00, parent=0x7f0620011a00, event=0x7f05a40fd9c0) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1691
#28 0x00007f0648c53e91 in gst_pad_send_event_unchecked (pad=0x7f05c0017a00, event=0x7f05a40fd9c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5900
```
Meanwhile the cleanup thread is blocked trying to deactivate this pad 0x7f05c0017a00
```
Thread 34 (Thread 0x7f05b7fff700 (LWP 2045448)):
#0 __lll_lock_wait (futex=futex@entry=0x7f0620004140, private=0) at lowlevellock.c:52
#1 0x00007f0648507131 in __GI___pthread_mutex_lock (mutex=0x7f0620004140) at ../nptl/pthread_mutex_lock.c:115
#2 0x00007f0648c42f0f in post_activate (pad=0x7f05c0017a00, new_mode=GST_PAD_MODE_NONE) at ../subprojects/gstreamer/gst/gstpad.c:1045
#3 0x00007f0648c4376e in activate_mode_internal (pad=0x7f05c0017a00, parent=0x7f0620011a00, mode=GST_PAD_MODE_PUSH, active=0) at ../subprojects/gstreamer/gst/gstpad.c:1223
#4 0x00007f0648c432df in gst_pad_set_active (pad=0x7f05c0017a00, active=0) at ../subprojects/gstreamer/gst/gstpad.c:1114
#5 0x00007f0648c1fdb0 in activate_pads (vpad=0x7f05b7ffe960, ret=0x7f05b7ffe9c0, active=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstelement.c:3171
#6 0x00007f0648c3617b in gst_iterator_fold (it=0x7f0640353db0, func=0x7f0648c1fd6d <activate_pads>, ret=0x7f05b7ffe9c0, user_data=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstiterator.c:617
#7 0x00007f0648c1fe57 in iterator_activate_fold_with_resync (iter=0x7f0640353db0, func=0x7f0648c1fd6d <activate_pads>, user_data=0x7f05b7ffe9f4) at ../subprojects/gstreamer/gst/gstelement.c:3195
#8 0x00007f0648c1ff9d in gst_element_pads_activate (element=0x7f0620011a00, active=0) at ../subprojects/gstreamer/gst/gstelement.c:3240
#9 0x00007f0648c2029c in gst_element_change_state_func (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gstreamer/gst/gstelement.c:3305
#10 0x00007f0648d77c04 in gst_video_decoder_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:2878
#11 0x00007f0648c1f8a8 in gst_element_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at ../subprojects/gstreamer/gst/gstelement.c:3083
#12 0x00007f0648c1eddc in gst_element_continue_state (element=0x7f0620011a00, ret=GST_STATE_CHANGE_SUCCESS) at ../subprojects/gstreamer/gst/gstelement.c:2791
#13 0x00007f0648c1fbd2 in gst_element_change_state (element=0x7f0620011a00, transition=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at ../subprojects/gstreamer/gst/gstelement.c:3122
#14 0x00007f0648c1f632 in gst_element_set_state_func (element=0x7f0620011a00, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:3037
#15 0x00007f0648c1f22d in gst_element_set_state (element=0x7f0620011a00, state=GST_STATE_NULL) at ../subprojects/gstreamer/gst/gstelement.c:2938
#16 0x00007f06477881ea in gst_decode_chain_free_internal (chain=0x7f05c036a1b0, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3509
#17 0x00007f0647788738 in gst_decode_group_free_internal (group=0x7f0614002400, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3627
#18 0x00007f0647787aff in gst_decode_chain_free_internal (chain=0x7f06081c46c0, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3386
#19 0x00007f0647788738 in gst_decode_group_free_internal (group=0x7f0600422450, hide=0) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3627
#20 0x00007f064778894e in gst_decode_group_free (group=0x7f0600422450) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3681
#21 0x00007f06477889a6 in gst_decode_chain_free_hidden_groups (old_groups=0x7f063800f780 = {...}) at ../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c:3723
#22 0x00007f06489d9ad1 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007f0648504609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#24 0x00007f06486dc133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
So,
- thread 18 blocks the pad 0x7f05c0017a00 (src pad of avdec_h264) and waits for the thread 34 to finish.
- thread 34 blocks trying to deactivate this pad 0x7f05c0017a00.
**Hipothesis about the root cause**
I was tracing the error and from what I've seen, it seems that handling EOS have walked an unexpected path:
- First **gst_decode_pad_handle_eos**() steps into **drain_and_switch_chains**() that switches the active decoding group to the next one and at this moment things seem to go well, the decoder we are blocking is now a part of an "old grop", that have been hidden and is going to be freed in another thread.
- Then it steps into **gst_decode_bin_expose**(), because it thinks that the new active group has "deadend" chains inside. The chains contain just a tsdemux and parsers inside.
So, **gst_decode_bin_expose**() starts to hide and free the "new"(not anymore) active group too, and at this moment deadlocks: it has to wait for a cleanup thread that it blocks.
So, as I suppose there's unexpected code path:
1. **gst_decode_pad_handle_eos**() --> **drain_and_switch_chains**() , it launches a cleanup thread for the group that was active (and blocks the thread therefore). This part is ok.
2. **gst_decode_pad_handle_eos**() --> **gst_decode_bin_expose**(). Here the code decides to free the next group too. And this can't not to lead to the deadlock, because it has to wait for the cleanup thread first.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/400ci: Check that the autogenerated code matches the versions of code generator,...2022-09-04T18:32:10ZSebastian Drögeci: Check that the autogenerated code matches the versions of code generator, Gir.tomls and .gir filesShould probably be a separate job and just needs to run `./generator.py` and then `git diff` to check if there are any changes. gtk-rs also does this.Should probably be a separate job and just needs to run `./generator.py` and then `git diff` to check if there are any changes. gtk-rs also does this.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1411playbin3: usage of "Decoder-Sinks" (hardware decoder)2023-01-20T12:42:28ZJuergen Sachsplaybin3: usage of "Decoder-Sinks" (hardware decoder)When using _playbin3_ instead of _playbin_ the pipeline with "decoding" sink
elements no longer setup properly. This works perfectly with playbin.
I get an error message like:
```
Missing element: H.264 (High Profile) decoder
ERROR: fr...When using _playbin3_ instead of _playbin_ the pipeline with "decoding" sink
elements no longer setup properly. This works perfectly with playbin.
I get an error message like:
```
Missing element: H.264 (High Profile) decoder
ERROR: from element /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0: Your GStreamer installation is missing a plug-in.
Additional debug info:
../../../../../../Media/GST-1.0/gstreamer/subprojects/gst-plugins-base/gst/playback/gstparsebin.c(3494): gst_parse_bin_expose (): /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0:
no suitable plugins found:
Missing parser: H.264 (High Profile) (video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3.2, profile=(string)high, codec_data=(buffer)01640020ffe1001e67640020acd9405005bb016e04040b4a000003000200000300c81e30632c01000668ebe3cb22c0, width=(int)1280, height=(int)720, framerate=(fraction)50/1, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, colorimetry=(string)1:4:0:0, parsed=(boolean)true)
```
#### Background
We are using GStreamer on a SOC with integrated hardware decoders for audio and
video. This decoders are fed directly with "video/x-h264..." or "audio/mpeg..."
(and other "encoded" media formats).
So we have created sink elements with respective sink caps. The elements
are classified as "Sink/Video/Hardware" rsp. "Sink/Audio/Hardware". Obviously
"playbin3" is looking for "Decoders" for this stream caps that are not found
(We have removed the SW decoders for all caps that are supported by our hardware
from the GStreamer packages)
I also have tried to classify my Sinks as "Decoder". In this case they are built
in the pipeline (in decodebin3), but the pipeline remains paused. And there are
an unused pipes from decodebin3 (see attachment)
#### Expectation
* Can you help to understand whether this is a playbin3 issue or a problem with
our "Decoder-Sink" Elements?
* What needs to be changed in the sink to get working with playbin3
#### How to reproduce
To reproduce the problem I have attached sources for a simple "Decoder-Sink"
Element that provides `video/x-h264` capabilities on its sink pad.
Tested on GStreamer Release 1.20.3
- create local branch at 1.20.3
- apply the attached patch
- build gstreamer with (disable default h264 decoders):
```
meson -Dlibav=disabled -Dgst-plugins-bad:openh264=disabled -Dtest=enabled build
ninja -C build
```
- Enter devenv (`ninja -C build/ devenv`)
- Some test commands:
```
gstreamer/build$ export GST_DEBUG=h264sink:6,playbin*:3
gstreamer/build$ gst-inspect-1.0 h264sink
gstreamer/build$ gst-launch-1.0 playbin uri=http://192.168.0.252/media/h264sink/1280x720-h264.mp4
gstreamer/build$ gst-launch-1.0 playbin3 uri=http://192.168.0.252/media/h264sink/1280x720-h264.mp4
```
attached:
* patchfile: [0001-added-subproject-gst-test-with-h264sink.patch.tar.gz](/uploads/eb65aeaf616547a04a4c52dfb2351b4a/0001-added-subproject-gst-test-with-h264sink.patch.tar.gz)
* logfile and pipeline for both cases: [results.zip](/uploads/e6b25432ed03d70224d9031fc9e40088/results.zip)
* sample media: [1280x720-h264](/uploads/67d6caedfc3a52344ca7746a246cc0a6/1280x720-h264.mp4)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/976playbin3: usage of "Decoder-Sinks" (hardware decoder)2022-08-31T09:05:43ZJuergen Sachsplaybin3: usage of "Decoder-Sinks" (hardware decoder)When using _playbin3_ instead of _playbin_ the pipeline with "decoding" sink
elements no longer setup properly. This works perfectly with playbin.
I get an error message like:
```
Missing element: H.264 (High Profile) decoder
ERROR: fr...When using _playbin3_ instead of _playbin_ the pipeline with "decoding" sink
elements no longer setup properly. This works perfectly with playbin.
I get an error message like:
```
Missing element: H.264 (High Profile) decoder
ERROR: from element /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0: Your GStreamer installation is missing a plug-in.
Additional debug info:
../../../../../../Media/GST-1.0/gstreamer/subprojects/gst-plugins-base/gst/playback/gstparsebin.c(3494): gst_parse_bin_expose (): /GstPlayBin3:playbin3-0/GstURIDecodeBin3:uridecodebin3-0/GstDecodebin3:decodebin3-0/GstParseBin:parsebin0:
no suitable plugins found:
Missing parser: H.264 (High Profile) (video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3.2, profile=(string)high, codec_data=(buffer)01640020ffe1001e67640020acd9405005bb016e04040b4a000003000200000300c81e30632c01000668ebe3cb22c0, width=(int)1280, height=(int)720, framerate=(fraction)50/1, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, colorimetry=(string)1:4:0:0, parsed=(boolean)true)
```
#### Background
We are using GStreamer on a SOC with integrated hardware decoders for audio and
video. This decoders are fed directly with "video/x-h264..." or "audio/mpeg..."
(and other "encoded" media formats).
So we have created sink elements with respective sink caps. The elements
are classified as "Sink/Video/Hardware" rsp. "Sink/Audio/Hardware". Obviously
"playbin3" is looking for "Decoders" for this stream caps that are not found
(We have removed the SW decoders for all caps that are supported by our hardware
from the GStreamer packages)
I also have tried to classify my Sinks as "Decoder". In this case they are built
in the pipeline (in decodebin3), but the pipeline remains paused. And there are
an unused pipes from decodebin3 (see attachment)
#### Expectation
* Can you help to understand whether this is a playbin3 issue or a problem with
our "Decoder-Sink" Elements?
* What needs to be changed in the sink to get working with playbin3
#### How to reproduce
To reproduce the problem I have attached sources for a simple "Decoder-Sink"
Element that provides `video/x-h264` capabilities on its sink pad.
Tested on GStreamer Release 1.20.3
- create local branch at 1.20.3
- apply the attached patch
- build gstreamer with (disable default h264 decoders):
```
meson -Dlibav=disabled -Dgst-plugins-bad:openh264=disabled -Dtest=enabled build
ninja -C build
```
- Enter devenv (`ninja -C build/ devenv`)
- Some test commands:
```
gstreamer/build$ export GST_DEBUG=h264sink:6,playbin*:3
gstreamer/build$ gst-inspect-1.0 h264sink
gstreamer/build$ gst-launch-1.0 playbin uri=http://192.168.0.252/media/h264sink/1280x720-h264.mp4
gstreamer/build$ gst-launch-1.0 playbin3 uri=http://192.168.0.252/media/h264sink/1280x720-h264.mp4
```
attached:
* patchfile: [0001-added-subproject-gst-test-with-h264sink.patch.tar.gz](/uploads/bbe52e4543e24991a31606fa7d199dc2/0001-added-subproject-gst-test-with-h264sink.patch.tar.gz)
* logfile and pipeline for both cases: [results.zip](/uploads/0e9d2d621b32f814b57942a4bffbc35d/results.zip)
* sample media: [1280x720-h264.mp4](/uploads/5af58aeb8d73ac17355e69141dc30915/1280x720-h264.mp4)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1410Memory leak of videoscale & videoconvert2023-06-01T17:05:40Zdandre430Memory leak of videoscale & videoconvertHi, the speed of memory increase is about 40MB per hour,when i use these two pipeline in my app to transfer video by rtmp:
```
···
GstElement *pipeline0 = gst_parse_launch("v4l2src device=/dev/video0 io-mode=dmabuf ! video/x-raw,format=(...Hi, the speed of memory increase is about 40MB per hour,when i use these two pipeline in my app to transfer video by rtmp:
```
···
GstElement *pipeline0 = gst_parse_launch("v4l2src device=/dev/video0 io-mode=dmabuf ! video/x-raw,format=(string)YUY2,width=1280,height=720 ! videoscale! video/x-raw,width=640,height=360,framerate=(fraction)25/1 ! videoconvert ! v4l2h264enc output-io-mode=dmabuf ! rtph264pay ! udpsink port=26369 buffer-size=5000000
", NULL);
GstElement *pipeline1 = gst_parse_launch("udpsrc address=localhost buffer-size=5000000 port=26369 ! application/x-rtp,encoding-name=H264 ! rtph264depay ! flvmux streamable=true ! rtmpsink location=rtmp://192.168.1.100:6012/livertmp", NULL);
···
```
I think the reason of memory increasing is videoscale&videoconvert because i have done some test. For example, the memory will be very stable when i remove videoscale and videoconvert, using “queue” to connect v4l2src and v4l2h264enc, and "h264parse" to connect v4l2h264enc and rtph264pay. Like this:
```
GstElement *pipeline0 = gst_parse_launch("v4l2src device=/dev/video0 io-mode=dmabuf ! video/x-raw,format=(string)YUY2,width=1280,height=720 ! queue ! v4l2h264enc output-io-mode=dmabuf ! h264parse ! rtph264pay ! udpsink port=26369 buffer-size=5000000", NULL);
```
Can it proves that the reason for memory growth is the using of videoscale&videoconvert in the pipeline? What can i do to fix this?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/975Memory leak of videoscale & videoconvert2022-08-31T08:21:51Zdandre430Memory leak of videoscale & videoconvertHi, the speed of memory increase is about 40MB per hour,when i use these two pipeline in my app to transfer video by rtmp:
```
···
GstElement *pipeline0 = gst_parse_launch("v4l2src device=/dev/video0 io-mode=dmabuf ! video/x-raw,format=(...Hi, the speed of memory increase is about 40MB per hour,when i use these two pipeline in my app to transfer video by rtmp:
```
···
GstElement *pipeline0 = gst_parse_launch("v4l2src device=/dev/video0 io-mode=dmabuf ! video/x-raw,format=(string)YUY2,width=1280,height=720 ! videoscale! video/x-raw,width=640,height=360,framerate=(fraction)25/1 ! videoconvert ! v4l2h264enc output-io-mode=dmabuf ! rtph264pay ! udpsink port=26369 buffer-size=5000000
", NULL);
GstElement *pipeline1 = gst_parse_launch("udpsrc address=localhost buffer-size=5000000 port=26369 ! application/x-rtp,encoding-name=H264 ! rtph264depay ! flvmux streamable=true ! rtmpsink location=rtmp://192.168.1.100:6012/livertmp", NULL);
···
```
I think the reason of memory increasing is videoscale&videoconvert because i have done some test. For example, the memory will be very stable when i remove videoscale and videoconvert, using “queue” to connect v4l2src and v4l2h264enc, and "h264parse" to connect v4l2h264enc and rtph264pay. Like this:
```
GstElement *pipeline0 = gst_parse_launch("v4l2src device=/dev/video0 io-mode=dmabuf ! video/x-raw,format=(string)YUY2,width=1280,height=720 ! queue ! v4l2h264enc output-io-mode=dmabuf ! h264parse ! rtph264pay ! udpsink port=26369 buffer-size=5000000", NULL);
```
Can it proves that the reason for memory growth is the using of videoscale&videoconvert in the pipeline? What can i do to fix this?https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/399Unexpected behaviour with Newtype and gst::pipeline2022-09-12T19:47:56Zeden-parallelUnexpected behaviour with Newtype and gst::pipelineHello.
I am having issues creating a newtype with a gst::pipeline and could really use some insight as to what is happening.
I have a video saving pipeline that I set to NULL in one callback that later is set back to PLAYING through an...Hello.
I am having issues creating a newtype with a gst::pipeline and could really use some insight as to what is happening.
I have a video saving pipeline that I set to NULL in one callback that later is set back to PLAYING through another callback. This works fine when setting the state directly using gst::pipeline. However, I would like to create a newtype for gst::pipeline that limits the functionality to prevent possible memory leaks. I create a struct that wraps the pipeline as below:
```
/// Wrapper around the pipeline to prevent an accidental memory leak
#[derive(Debug)]
#[repr(transparent)]
pub struct Pipeline(
/// The gstreamer pipeline.
gst::Pipeline,
);
```
and change the state of the pipeline like this:
```
impl Pipeline {
...
pub fn set_state(&self, state: gst::State) -> Result<gst::StateChangeSuccess> {
Ok(self.0.set_state(state)?)
}
```
I am getting errors when trying Stop and Start the pipeline dynamically. Specifically, these are only present when restarting the pipeline using my Pipeline newtype:
```
0:00:07.894205774 10264 0x5585c48de0 WARN GST_PADS gstpad.c:4351:gst_pad_peer_query:<sink_pipeline_interpipesrc:src> could not send sticky events
(minimal:10264): GStreamer-CRITICAL **: 23:20:11.461: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
0:00:07.903435749 10264 0x5584cb2d30 ERROR GST_BUS gstbus.c:1075:gst_bus_remove_watch:<bus4> no bus watch was present
```
Is this a ref count issue or some undefined behavior with the wrapper?
Here is my attempt at a minimal example, `omxvideoenc` gives some warnings but it seems to work well enough to get the point across:[minimal.zip](/uploads/1a51e733761bc12bf7489b7fa3253252/minimal.zip)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1409libav support static register plugin2022-08-30T02:24:05Zseanchann.zhoulibav support static register pluginthe `libav` of the subproject did not support the static register plugin. that broken build with `-Ddefault_library=static` optionthe `libav` of the subproject did not support the static register plugin. that broken build with `-Ddefault_library=static` optionhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1408audioconvert mix-matrix mixing issue2023-02-03T20:53:50ZÁdám Balázsaudioconvert mix-matrix mixing issueI expected audioconvert with a mix-matrix and audiomixmatrix to be replaceable.
The following pipeline plays a single channel audio on one of my speakers:
`gst-launch-1.0 audiotestsrc ! capsfilter caps=audio/x-raw,format=S16LE,rate=160...I expected audioconvert with a mix-matrix and audiomixmatrix to be replaceable.
The following pipeline plays a single channel audio on one of my speakers:
`gst-launch-1.0 audiotestsrc ! capsfilter caps=audio/x-raw,format=S16LE,rate=16000,channels=1,layout=interleaved ! audiomixmatrix in-channels=1 out-channels=2 channel-mask=3 matrix="<<0.0>,<1.0>>" ! alsasink`
If I try to replace audiomixmatrix with an audioconvert the audio is played on both of my speakers:
`gst-launch-1.0 audiotestsrc ! capsfilter caps=audio/x-raw,format=S16LE,rate=16000,channels=1,layout=interleaved ! audioconvert mix-matrix="<<0.0>,<1.0>>" ! alsasink`
Do I misuse the audioconvert component or it is a bug?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/974audioconvert mix-matrix mixing issue2022-08-29T10:28:58ZÁdám Balázsaudioconvert mix-matrix mixing issueI expected audioconvert with a mix-matrix and audiomixmatrix to be replaceable.
The following pipeline plays a single channel audio on one of my speakers:
`gst-launch-1.0 audiotestsrc ! capsfilter caps=audio/x-raw,format=S16LE,rate=160...I expected audioconvert with a mix-matrix and audiomixmatrix to be replaceable.
The following pipeline plays a single channel audio on one of my speakers:
`gst-launch-1.0 audiotestsrc ! capsfilter caps=audio/x-raw,format=S16LE,rate=16000,channels=1,layout=interleaved ! audiomixmatrix in-channels=1 out-channels=2 channel-mask=3 matrix="<<0.0>,<1.0>>" ! alsasink`
If I try to replace audiomixmatrix with an audioconvert the audio is played on both of my speakers:
`gst-launch-1.0 audiotestsrc ! capsfilter caps=audio/x-raw,format=S16LE,rate=16000,channels=1,layout=interleaved ! audioconvert mix-matrix="<<0.0>,<1.0>>" ! alsasink`
Do I misuse the audioconvert component or it is a bug?