GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-10-12T19:39:39Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/517Test Failure: check.gst-plugins-base.elements_multisocketsink.test_sending_bu...2021-10-12T19:39:39ZNicolas DufresneTest Failure: check.gst-plugins-base.elements_multisocketsink.test_sending_buffers_with_9_gstmemorieshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/jobs/60242
```
=================
Test name: check.gst-plugins-base.elements_multisocketsink.test_sending_buffers_with_9_gstmemories
Command: '/builds/gstreamer/gst-plugins-good...https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/jobs/60242
```
=================
Test name: check.gst-plugins-base.elements_multisocketsink.test_sending_buffers_with_9_gstmemories
Command: '/builds/gstreamer/gst-plugins-good/gst-build/build/subprojects/gst-plugins-base/tests/check/elements_multisocketsink'
=================
Running suite(s): multisocketsink
Unexpected critical/warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Stack trace:
gst_debug_get_stack_trace (gstinfo.c:2788)
gst_check_log_critical_func (gstcheck.c:281)
g_logv (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f5956b236db)
g_log (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f5956b238cf)
g_object_ref (/usr/lib64/libgobject-2.0.so.0.5800.1:0x7f5956a8ebb1)
g_cancellable_source_new (/usr/lib64/libgio-2.0.so.0.5800.1:0x7f595690f599)
g_socket_create_source (/usr/lib64/libgio-2.0.so.0.5800.1:0x7f5956952430)
ensure_condition (gstmultisocketsink.c:1003)
gst_multi_socket_sink_socket_condition (gstmultisocketsink.c:1041)
?? (/usr/lib64/libgio-2.0.so.0.5800.1:0x7f59569522a9)
g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f5956b1c269)
?? (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f5956b1c634)
g_main_context_iteration (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f5956b1c6cc)
gst_multi_socket_sink_thread (gstmultisocketsink.c:1164)
?? (/usr/lib64/libglib-2.0.so.0.5800.1:0x7f5956b45486)
start_thread (/usr/lib64/libpthread-2.28.so:0x7f59568b558a)
__clone (/usr/lib64/libc-2.28.so:0x7f59567e464f)
0%: Checks: 1, Failures: 1, Errors: 0
../subprojects/gstreamer/libs/gst/check/gstcheck.c:286:F:general:test_sending_buffers_with_9_gstmemories:0: Unexpected critical/warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Check suite multisocketsink ran in 0.021s (tests failed: 1)
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/528[API proposal] pad: Add a gst_pad_task_resume() helper2021-09-24T11:08:50ZNicolas Dufresne[API proposal] pad: Add a gst_pad_task_resume() helperThis is a proposal to also add a resume function for the pad task.
The following discussion from !361 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/361#note...This is a proposal to also add a resume function for the pad task.
The following discussion from !361 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/361#note_401407): (+2 comments)
> API-wise this makes sense to me, I didn't look at the implementation yet. Should the same API be added for pad tasks though?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/516hlsdemux: Fix segfault during bitrate switch2021-09-24T14:35:10ZBugzilla Migration Userhlsdemux: Fix segfault during bitrate switch## Submitted by Seungha Yang
**[Link to original bug (#778199)](https://bugzilla.gnome.org/show_bug.cgi?id=778199)**
## Description
Target variant stream can be updated in _updtae_playlist()## Submitted by Seungha Yang
**[Link to original bug (#778199)](https://bugzilla.gnome.org/show_bug.cgi?id=778199)**
## Description
Target variant stream can be updated in _updtae_playlist()https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/516rtpfunnel: Uses GLib 2.44 features2018-11-12T23:47:07ZSebastian Drögertpfunnel: Uses GLib 2.44 features`G_DECLARE_FINAL_TYPE` was added after 2.44 and we currently only require 2.40 for 1.16.`G_DECLARE_FINAL_TYPE` was added after 2.44 and we currently only require 2.40 for 1.16.1.15.1Mathieu DuponchelleMathieu Duponchellehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/518tests/examples/gl/gtk: build failure on Mac OS X2018-12-27T14:33:45ZJustin Kimtests/examples/gl/gtk: build failure on Mac OS XActually, I found this error while fixing https://gitlab.freedesktop.org/gstreamer/gst-build/issues/13
I guess it should be temporarily disabled.
```
In file included from ../subprojects/gst-plugins-base/tests/examples/gl/gtk/gstgtk.c:...Actually, I found this error while fixing https://gitlab.freedesktop.org/gstreamer/gst-build/issues/13
I guess it should be temporarily disabled.
```
In file included from ../subprojects/gst-plugins-base/tests/examples/gl/gtk/gstgtk.c:37:
In file included from /usr/local/Cellar/gtk+3/3.22.30/include/gtk-3.0/gdk/gdkquartz.h:23:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:512:1: error: expected identifier or '('
@class NSString, Protocol;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:514:9: error: unknown type name 'NSString'; did you mean 'GString'?
typedef NSString * NSExceptionName NS_EXTENSIBLE_STRING_ENUM;
^
/usr/local/Cellar/glib/2.58.1/include/glib-2.0/glib/gstring.h:39:33: note: 'GString' declared here
typedef struct _GString GString;
^
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/529Aggregator should not encourage direct GstElement->sinkpads access2021-09-24T11:08:50ZJan SchmidtAggregator should not encourage direct GstElement->sinkpads accessThe [GstAggregator docs](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/26ffe05ccdf715f401339e3c53a0d5b482543ec7/libs/gst/base/gstaggregator.h#L195) encourage sub-classes to directly iterator the GstElement->sinkpads list, whi...The [GstAggregator docs](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/26ffe05ccdf715f401339e3c53a0d5b482543ec7/libs/gst/base/gstaggregator.h#L195) encourage sub-classes to directly iterator the GstElement->sinkpads list, which is dangerous to do without holding the GST_OBJECT_LOCK(), as request pads could be added or removed at any time.
It would be better to encourage (and provide examples of) using `gst_element_iterate_sink_pads()` instead.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/517AVFVideoSource must post a latency message after it renegotiates caps2021-09-24T14:35:11ZBugzilla Migration UserAVFVideoSource must post a latency message after it renegotiates caps## Submitted by Nick Kallen
**[Link to original bug (#778273)](https://bugzilla.gnome.org/show_bug.cgi?id=778273)**
## Description
Background:
The AVFVideoSource represents the iphone front- and rear-facing cameras. The cameras...## Submitted by Nick Kallen
**[Link to original bug (#778273)](https://bugzilla.gnome.org/show_bug.cgi?id=778273)**
## Description
Background:
The AVFVideoSource represents the iphone front- and rear-facing cameras. The cameras can output at various frame-rates and putting a capsfilter downstream will trigger the frame-rate selection during caps negotiation. The frame-rate affects the latency, because for example 30fps leads to a latency of` ~33ms`.
The bug:
Adding an avfvideosrc to a pipeline in the NULL state works fine because PLAYING the pipeline will calculate latency after all the caps have been negotiated.
However, if you add an avfvideosrc to an already running pipeline, it will renegotiate caps but it will not trigger a latency event after deciding its frame-rate. If the pipeline already had a latency less than 1/frame-rate frames will be dropped.
The fix:
Post latency message after caps have been set.
Version: 1.11.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/517multiudpsink: should use netutils to set QoS DSCP2019-04-22T10:37:56ZRobert Rosengrenmultiudpsink: should use netutils to set QoS DSCPThe multiudpsink should use netutils function (`gst_net_utils_set_socket_dscp`) for QoS DSCP to reduce code duplicationThe multiudpsink should use netutils function (`gst_net_utils_set_socket_dscp`) for QoS DSCP to reduce code duplicationhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/519egl/gbm glimagesink: video picture has color is not correct, color is reddish2021-02-03T15:22:31ZDarcy Gongegl/gbm glimagesink: video picture has color is not correct, color is reddishDevelopment platform:
rtd1295/1296 soc aarch64 core A53x4 Mali-T820
Linux Kernel:
4.4.18
Mali:
Wayland Mode and Egl/GBM/DRM Mode
test GST GL:
gst-1.10.4 release, GstGL Wayland Mode Playback is normal.(need weston 3.0)
gst-1.1...Development platform:
rtd1295/1296 soc aarch64 core A53x4 Mali-T820
Linux Kernel:
4.4.18
Mali:
Wayland Mode and Egl/GBM/DRM Mode
test GST GL:
gst-1.10.4 release, GstGL Wayland Mode Playback is normal.(need weston 3.0)
gst-1.14.4 release, GstGL EGL/GBM/DRM Mode: The picture is fragmented and the data is misplaced.
gst-1.15.0 git last, GstGL EGL/GBM/DRM Mode: The video shows normal. The color is abnormal and the color is reddish.
I don't have any other development boards. I want to know if MESA's GBM driver display is normal?
I noticed a color anomaly in the color space of all GST outputs.
For example RGBA, YUY2, I420, NV12.
Is this related to GBM's YUV format setting?
![1555789686](/uploads/be6b252a77479dd0f365986301eb07ea/1555789686.jpg)
play log:
--------------------
```bash
root@rtd1295:~# gst-launch-1.0 -vv videotestsrc ! glupload ! glcolorconvert ! gl
imagesinkelement
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'glimagesink0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayGBM\)\ gldisplaygbm0";
/GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0.GstPad:src: caps = video/x-raw, format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstGLUploadElement:gluploadelement0.GstPad:src: caps = video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D
/GstPipeline:pipeline0/GstGLColorConvertElement:glcolorconvertelement0.GstPad:src: caps = video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D
/GstPipeline:pipeline0/GstGLImageSink:glimagesink0.GstPad:sink: caps = video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D
/GstPipeline:pipeline0/GstGLColorConvertElement:glcolorconvertelement0.GstPad:sink: caps = video/x-raw(memory:GLMemory), format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, texture-target=(string)2D
/GstPipeline:pipeline0/GstGLUploadElement:gluploadelement0.GstPad:sink: caps = video/x-raw, format=(string)RGBA, width=(int)320, height=(int)240, framerate=(fraction)30/1, multiview-mode=(string)mono, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
handling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:05:45.555294980
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
0:05:45.676991312 2873 0x86980a0 ERROR glwindow gstglwindow_gbm_egl.c:123:gst_gl_window_gbm_egl_close:<glwindowgbmegl0> Failed to restore previous CRTC mode: No such file or directory
Freeing pipeline ...
root@rtd1295:~#
```
other:
![webwxgetmsgimg](/uploads/8c39bd69828bb7aa3f2caa47c4e0817a/webwxgetmsgimg.jpg)
[err1play_rgba.log](/uploads/03599c5760875073a950de491a8c4a6f/err1play_rgba.log)
[err2play_nv12.log](/uploads/53962c53ec72518e15b8180fc3fcf703/err2play_nv12.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/530[regression] baseparse cache fix breaks h264parse and h265parse2022-11-10T09:21:01ZU. Artie Eoff[regression] baseparse cache fix breaks h264parse and h265parse```
gst-launch-1.0 -vf filesrc location=h264/alphaconformanceG.264 ! h264parse ! fakesink
```
`ERROR:../gst/videoparsers/gsth264parse.c:1315:gst_h264_parse_handle_frame: assertion failed: (current_off < size)`
Since !422, commit e90619...```
gst-launch-1.0 -vf filesrc location=h264/alphaconformanceG.264 ! h264parse ! fakesink
```
`ERROR:../gst/videoparsers/gsth264parse.c:1315:gst_h264_parse_handle_frame: assertion failed: (current_off < size)`
Since !422, commit e906197c622725e48b6250a71a922d45b006fb14 :
```
commit e906197c622725e48b6250a71a922d45b006fb14
Author: Jan Schmidt <jan@centricular.com>
Date: Wed Apr 1 02:36:40 2020 +1100
baseparse: Fix upstream read caching
When running in pull mode (for e.g. mp3 reading),
baseparse currently reads 64KB from upstream, then mp3parse
consumes typically around 417/418 bytes of it. Then
on the next loop, it will read a full fresh 64KB again,
which is a big waste.
Fix the read loop to use the available cache buffer first
before going for more data, until the cache drops to < 1KB.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/518
```
Reverting this commit fixes the regression.
Also seeing similar error with some `h265parse` use-cases.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/518tsdemux: Add GST_SEEK_FLAG_TRICKMODE_KEY_UNITS support2021-09-24T14:35:11ZBugzilla Migration Usertsdemux: Add GST_SEEK_FLAG_TRICKMODE_KEY_UNITS support## Submitted by yvonne.chen
**[Link to original bug (#778327)](https://bugzilla.gnome.org/show_bug.cgi?id=778327)**
## Description
Hello
How to tickmode play ts local stream?
I find none GST_SEEK_FLAG_TRICKMODE_KEY_UNITS in ts...## Submitted by yvonne.chen
**[Link to original bug (#778327)](https://bugzilla.gnome.org/show_bug.cgi?id=778327)**
## Description
Hello
How to tickmode play ts local stream?
I find none GST_SEEK_FLAG_TRICKMODE_KEY_UNITS in tsdemux.c version 1.8.3?
Can anyone tell me how to handle fastward and reverse playback with ts stream?
Version: 1.8.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/518aspectratiocrop sends its caps directly from the main thread2018-11-26T10:20:36ZAlexandru Băluțaspectratiocrop sends its caps directly from the main threadCan be seen in this Pitivi issue: https://gitlab.gnome.org/GNOME/pitivi/issues/2259Can be seen in this Pitivi issue: https://gitlab.gnome.org/GNOME/pitivi/issues/2259https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/520Playing short ogv file fails intermmittently fails with "Could not decode str...2021-09-27T13:38:41ZFernando Jiménez MorenoPlaying short ogv file fails intermmittently fails with "Could not decode stream" errorPlaying a short ogv file like https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/media/movie_5.ogv?raw=true sometimes fails with the following output (the first run works, the second fails):
```
❯ gst-play-1.0 "http...Playing a short ogv file like https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/media/movie_5.ogv?raw=true sometimes fails with the following output (the first run works, the second fails):
```
❯ gst-play-1.0 "https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/media/movie_5.ogv?raw=true"
Press 'k' to see a list of keyboard shortcuts.
Now playing https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/media/movie_5.ogv?raw=true
Prerolling...
Buffering... 100%
Redistribute latency...
0:00:00.8 / 0:00:02.8
❯ gst-play-1.0 "https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/media/movie_5.ogv?raw=true"
Press 'k' to see a list of keyboard shortcuts.
Now playing https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/media/movie_5.ogv?raw=true
Prerolling...
Buffering... 100%
Buffering... 100%
ERROR Could not decode stream. for https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/media/movie_5.ogv?raw=true
ERROR debug information: gsttheoradec.c(583): GstFlowReturn theora_handle_header_packet(GstTheoraDec *, ogg_packet *) (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTheoraDec:theoradec0:
couldn't read header packet
Reached end of play list.
```
Attached is a GST_DEBUG=3,*ogg:6 log. I couldn't reproduce the error with GST_DEBUG=6 :\...
[gst.ko.ogg.log](/uploads/7b5a00f413606ac5ae2c1b20662a97a5/gst.ko.ogg.log)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/531gst-launch-1.0 unable to play RTSP stream on windows 10 aws ec2 instance2022-11-10T09:21:01ZJordgst-launch-1.0 unable to play RTSP stream on windows 10 aws ec2 instanceThe RTSP is playable when streaming from VLC, but is returning an error when running gst-launch-1.0 to a fakesink (testing connectivity).
```
gst-launch-1.0 rtspsrc do-rtcp=TRUE location=rtsp://10.99.3.11:654/00000001-0000-babe-0000-acc...The RTSP is playable when streaming from VLC, but is returning an error when running gst-launch-1.0 to a fakesink (testing connectivity).
```
gst-launch-1.0 rtspsrc do-rtcp=TRUE location=rtsp://10.99.3.11:654/00000001-0000-babe-0000-accc8e4ebf43/live ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://10.99.3.11:654/00000001-0000-babe-0000-accc8e4ebf43/live
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource.
Additional debug info:
../gst-plugins-good-1.16.2/gst/rtsp/gstrtspsrc.c(5768): gst_rtspsrc_reconnect (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
Could not receive any UDP packets for 5.0000 seconds, maybe your firewall is blocking it. Retrying using a tcp connection.
```
The full debug log (GST_DEBUG=4) is below:
[gst_windows_instance_log.txt](/uploads/ba0493d9f8fb6d8d2d5ddf7d0774c060/gst_windows_instance_log.txt)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/519gstplayer: Add gst_player_get_state API2023-06-06T11:14:47ZBugzilla Migration Usergstplayer: Add gst_player_get_state API## Submitted by Lyon
**[Link to original bug (#778379)](https://bugzilla.gnome.org/show_bug.cgi?id=778379)**
## Description
For gstpalyer state, currently we can only get the state by state_change callback, when mainloop start runni...## Submitted by Lyon
**[Link to original bug (#778379)](https://bugzilla.gnome.org/show_bug.cgi?id=778379)**
## Description
For gstpalyer state, currently we can only get the state by state_change callback, when mainloop start running.
However, if we need to get the current state when mainloop has not started running. There is no way to get the gstplayer state.
So considering add this gst_player_get_state() API to get the current player state.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/519rtpmanager : rtpsession: Dubious total bytes calculation2023-06-02T06:13:56ZEdward Herveyrtpmanager : rtpsession: Dubious total bytes calculationWhile going over rtpsession code, I encountered this line:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/gst/rtpmanager/rtpsession.c#L2015
```
/* get packet size including header overhead */
pinfo->bytes += gst_...While going over rtpsession code, I encountered this line:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/gst/rtpmanager/rtpsession.c#L2015
```
/* get packet size including header overhead */
pinfo->bytes += gst_buffer_get_size (*buffer) + pinfo->header_len;
```
But this doesn't seem to make sense. A RTP/RTCP buffer size *will* contain the RTP header length also (it's part of the buffer). Digging back, it was already present in 0.10 (using `GST_BUFFER_SIZE`). Maybe it was a glitch that crept in the 1.0 porting ?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/521mix-matrix does not work in plugin audioconvert, if input and output channel ...2018-12-17T22:31:55ZMoritz Vielimix-matrix does not work in plugin audioconvert, if input and output channel count matchHi there
I have two test files:
- 4 channels: https://www.dropbox.com/s/bzw7c66d0asrcob/ok.wav?dl=0
- 2 channels: https://www.dropbox.com/s/yk1nbkied5se8xa/nok.wav?dl=0
The files are played with the following pipelines:
- ok.wav: gs...Hi there
I have two test files:
- 4 channels: https://www.dropbox.com/s/bzw7c66d0asrcob/ok.wav?dl=0
- 2 channels: https://www.dropbox.com/s/yk1nbkied5se8xa/nok.wav?dl=0
The files are played with the following pipelines:
- ok.wav: gst-launch-1.0 uridecodebin uri=file:///test/ok.wav ! audioconvert
mix-matrix="<<(float)0.0, (float)0.0, (float)0.0, (float)0.0>, <(float)0.0,
(float)0.0, (float)0.0, (float)0.0>>" ! audioresample ! osxaudiosink
- nok.wav: gst-launch-1.0 uridecodebin uri=file:///test/nok.wav !
audioconvert mix-matrix="<<(float)0.0, (float)0.0>, <(float)0.0,
(float)0.0>>" ! audioresample ! osxaudiosink
Now, I'd expect both files to be played completely silent. It works
perfectly for ok.wav, but unfortunately, the mix-matrix is completely ignored for nok.wav and the file is played in stereo.
It seems like there's a problem here:
https://github.com/GStreamer/gst-plugins-base/blob/master/gst/audioconvert/gstaudioconvert.c
--> /* same number of channels and no output layout: just use input layout */
This behaviour is reproducable: For files with a different channel count than the sink, the mix-matrix is applied as expected. The file above which does not have the mix-matrix applied on my 2-channel sink works as expected on a 4-channel sink.
This behaviour is not correct, as channel modifications may also be required with the same channel count. Example use cases:
- Switch the channels of a stereo-file on a stereo-sink
- Mute channels
This issue has been opened upon advice from here: http://gstreamer-devel.966125.n4.nabble.com/mix-matrix-in-audioconvert-plugin-ignored-for-some-files-td4689198.html
Thanks a lot for your investigations and best,
Moritzhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/532tsdemux sends gap event before segment event on sparse streams2022-11-10T09:21:01ZBenjamin Muzaltsdemux sends gap event before segment event on sparse streamstsdemux sends a new gap event on sparse streams with timesamp=0 in gst_ts_demux_update_program() and gst_ts_demux_program_started()
This happens before the segment event is sent out.
Downstream from tsdemux, this causes an ugly critical...tsdemux sends a new gap event on sparse streams with timesamp=0 in gst_ts_demux_update_program() and gst_ts_demux_program_started()
This happens before the segment event is sent out.
Downstream from tsdemux, this causes an ugly critical warning in GstAggregator based elements when they try to clip the event without a segment.
If streams always need a gap event at the beginning of sparse streams, maybe the gap event should be sent at the end of calculate_and_push_newsegment() using the start of the segment for the timestamp instead of a timestamp of 0?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2643gstplayer: Add gst_player_get_state API2023-06-12T14:47:59ZBugzilla Migration Usergstplayer: Add gst_player_get_state API## Submitted by Lyon
**[Link to original bug (#778379)](https://bugzilla.gnome.org/show_bug.cgi?id=778379)**
## Description
For gstpalyer state, currently we can only get the state by state_change callback, when mainloop start runni...## Submitted by Lyon
**[Link to original bug (#778379)](https://bugzilla.gnome.org/show_bug.cgi?id=778379)**
## Description
For gstpalyer state, currently we can only get the state by state_change callback, when mainloop start running.
However, if we need to get the current state when mainloop has not started running. There is no way to get the gstplayer state.
So considering add this gst_player_get_state() API to get the current player state.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/520gstplayer: Add gst_player play / stop in sync mode API2021-09-24T14:35:12ZBugzilla Migration Usergstplayer: Add gst_player play / stop in sync mode API## Submitted by Lyon
**[Link to original bug (#778390)](https://bugzilla.gnome.org/show_bug.cgi?id=778390)**
## Description
Currently the gst_player_play() / gst_player_stop() functions are in async mode. When return from _play/stop...## Submitted by Lyon
**[Link to original bug (#778390)](https://bugzilla.gnome.org/show_bug.cgi?id=778390)**
## Description
Currently the gst_player_play() / gst_player_stop() functions are in async mode. When return from _play/stop() function, the gstplayer state might not changed yet.
When in application side, we may want to seek after gst_player_play(), and need get seekable flag in media_info. however, as the gst_player_play() function is async, the media_info might not been created yet.
So we implement gst_player_play_sync() and gst_player_stop_sync() function to wait for the state change finished. So that it will be easy to handle for application.
Do you think add these API is reasonable. or Should these functions should be implement on application side.
Thanks
Lyon
Version: 1.x