GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-05-21T12:01:23Zhttps://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/42Getting error nice_agent_parse_remote_candidate_sdp: assertion 'sdp != NULL' ...2021-05-21T12:01:23Zbharath rajaGetting error nice_agent_parse_remote_candidate_sdp: assertion 'sdp != NULL' failed"libnice checking for candidate in answer, instead of parsing candidate separately. I am trying to connect gstreamer webrtc with custom unity webrtc. I get the log as below. I am using gstreamer 1.18.0 in ubuntu 20.10. libnice is of versi...libnice checking for candidate in answer, instead of parsing candidate separately. I am trying to connect gstreamer webrtc with custom unity webrtc. I get the log as below. I am using gstreamer 1.18.0 in ubuntu 20.10. libnice is of version 0.1.16-1.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1596Problems when seeking on filesrc with TS file2021-05-21T12:38:59ZMarianna Smidth BuschleProblems when seeking on filesrc with TS fileI have generated the following test files:
```
gst-launch-1.0 videotestsrc is-live=true pattern=ball num-buffers=300 ! video/x-raw,framerate=30/1,format=NV12 ! timeoverlay ! x264enc key-int-max=30 speed-preset=1 tune=zerolatency ! video/...I have generated the following test files:
```
gst-launch-1.0 videotestsrc is-live=true pattern=ball num-buffers=300 ! video/x-raw,framerate=30/1,format=NV12 ! timeoverlay ! x264enc key-int-max=30 speed-preset=1 tune=zerolatency ! video/x-h264,profile=high ! mpegtsmux ! filesink location=test.ts -v -e
```
```
gst-launch-1.0 videotestsrc is-live=true pattern=ball num-buffers=300 ! video/x-raw,framerate=30/1,format=NV12 ! timeoverlay ! filesink location=test.raw -v
```
And then they are played in a python app using parse_launch:
```
"filesrc name=replay location=test.ts ! queue ! tsparse ! tsdemux ! h264parse ! avdec_h264 ! videoconvert ! ximagesink sync=1 "
```
```
"filesrc name=replay location=test.raw ! videoparse format=nv12 width=320 height=240 framerate=30/1 ! videoconvert ! ximagesink sync=1 "
```
I have however issues when trying to do seek operations in the H264 stream (with TS container).
Without the `queue` after the `filesrc` I get:
```
(gst_ctrl.py:183848): GStreamer-CRITICAL **: 11:08:08.431: pushing on pad replay:src but it was not activated in push mode
0:00:08.281698886 183848 0x7f21940098c0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<replay> error: Internal data stream error.
0:00:08.281735348 183848 0x7f21940098c0 WARN basesrc gstbasesrc.c:3127:gst_base_src_loop:<replay> error: streaming stopped, reason error (-5)
```
With the `queue` I'm able to do a single seek operation with:
```
self.pipeline.seek(1.0, Gst.Format.TIME,
(Gst.SeekFlags.FLUSH | Gst.SeekFlags.ACCURATE),
Gst.SeekType.SET, 0 , Gst.SeekType.NONE, -1)
```
But subsequent calls to seek give me:
```
0:00:10.778992854 183974 0x7f5e1c35d960 WARN tsdemux tsdemux.c:917:gst_ts_demux_do_seek: Couldn't convert start position to an offset
0:00:10.779094440 183974 0x7f5e1c35d960 WARN mpegtsbase mpegtsbase.c:1721:mpegts_base_handle_seek_event: seeking failed error
0:00:10.779115381 183974 0x7f5e1c35d960 WARN tsdemux tsdemux.c:974:gst_ts_demux_srcpad_event: seeking failed
0:00:10.779150565 183974 0x7f5e1c35d960 WARN tsdemux tsdemux.c:974:gst_ts_demux_srcpad_event: seeking failed
```
I have no issues with seeking on the raw stream.
Lastly, if I change the `filesrc` into `multifilesrc` I can perform multiple seeks in the H264 encoded file.
But It jumps to weird positions in the file instead of going to the start.
I have tried using Gst.SeekFlags.KEY_UNIT instead of Gst.SeekFlags.ACCURATE and trying seeking in BYTES instead of TIME, but seen no real difference...
See http://gstreamer-devel.966125.n4.nabble.com/seek-on-filesrc-with-TS-file-td4697440.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/906filesink file size2023-08-09T14:05:11ZGabriele-Vfilesink file sizeHello,
I'm capturing some audio stream with GStreamer on Windows, then encode to MP3 and export to file, the pipleline (for the involved part) is something like this:
`audioconvert ! lamemp3enc target=bitrate bitrate=192 ! filesink locat...Hello,
I'm capturing some audio stream with GStreamer on Windows, then encode to MP3 and export to file, the pipleline (for the involved part) is something like this:
`audioconvert ! lamemp3enc target=bitrate bitrate=192 ! filesink location=E:\TestGst\\Test.mp3`
Problem is that file size is 0kb for the entire "recording" and it gets his "real size" only at the end when gstreamer is stopped.
Is there a way to have the file size increasing, so I can understand if the recording is still running? I've tried with `buffer-mode` but without luck.
Thankshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/700RFC: Support for feature alias2021-09-24T11:08:19ZStéphane Cerveauscerveau@igalia.comRFC: Support for feature aliasAs some inconsistencies exist in the registry such as the couple mpegtsmux/tsdemux. It would be useful to keep a feature name and provide also aliases to instanciate it.
I proposed to add a list of feature's alias in GStPluginFeature an...As some inconsistencies exist in the registry such as the couple mpegtsmux/tsdemux. It would be useful to keep a feature name and provide also aliases to instanciate it.
I proposed to add a list of feature's alias in GStPluginFeature and to avoid adding a new GST_ELEMENT_REGISTER method, add a syntax to declare the element such as "feature_name(feature_alias1,feature_alias2):
```
GST_ELEMENT_REGISTER_DEFINE_WITH_CODE (tsdemux, "tsdemux(mpegtsdemux,tsd)",
GST_RANK_PRIMARY, GST_TYPE_TS_DEMUX, _do_element_init);
```https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/337gst-build rust doesn't compile2021-05-19T09:59:42ZWojciech Kapsagst-build rust doesn't compileOS: Ubuntu 20.04
git clone --branch 1.18.4 https://gitlab.freedesktop.org/gstreamer/gst-build.git
meson -Drs=enabled build
ninja -C build
Code doesn't compile. Maybe it's worth freezing a version for the rust just like the stabl...OS: Ubuntu 20.04
git clone --branch 1.18.4 https://gitlab.freedesktop.org/gstreamer/gst-build.git
meson -Drs=enabled build
ninja -C build
Code doesn't compile. Maybe it's worth freezing a version for the rust just like the stable releases of gstreamer? Master branch in gst-plugins-rs.wrap is problematic.
```
Updating crates.io index
Updating git repository `https://github.com/gtk-rs/gtk-rs-core`
Updating git repository `https://gitlab.freedesktop.org/gstreamer/gstreamer-rs`
Updating git repository `https://github.com/fengalin/tokio`
Updating git repository `https://github.com/gtk-rs/gtk3-rs`
Updating git repository `https://github.com/rust-av/flavors`
Compiling gst-plugin-version-helper v0.6.0 (/home/wk/workspace/gst-build/subprojects/gst-plugins-rs/version-helper)
Compiling gstreamer v0.17.0 (https://gitlab.freedesktop.org/gstreamer/gstreamer-rs#b1088a6d)
Compiling gst-plugin-lewton v0.6.0 (/home/wk/workspace/gst-build/subprojects/gst-plugins-rs/audio/lewton)
error[E0053]: method `try_from_glib` has an incompatible type for trait
--> /home/wk/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/b1088a6/gstreamer/src/enums.rs:63:13
|
63 | fn try_from_glib(val: ffi::$ffi_type) -> Result<$ok_type, $err_type> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected unsafe fn, found normal fn
...
109 | / impl_return_result_traits!(
110 | | GstStateChangeReturn,
111 | | StateChangeReturn,
112 | | StateChangeSuccess,
113 | | StateChangeError
114 | | );
| |__- in this macro invocation
|
= note: expected fn pointer `unsafe fn(_) -> Result<_, _>`
found fn pointer `fn(_) -> Result<_, _>`
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0053]: method `try_from_glib` has an incompatible type for trait
--> /home/wk/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/b1088a6/gstreamer/src/enums.rs:63:13
|
63 | fn try_from_glib(val: ffi::$ffi_type) -> Result<$ok_type, $err_type> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected unsafe fn, found normal fn
...
193 | impl_return_result_traits!(GstFlowReturn, FlowReturn, FlowSuccess, FlowError);
| ------------------------------------------------------------------------------ in this macro invocation
|
= note: expected fn pointer `unsafe fn(_) -> Result<_, _>`
found fn pointer `fn(_) -> Result<_, _>`
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0053]: method `try_from_glib` has an incompatible type for trait
--> /home/wk/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/b1088a6/gstreamer/src/enums.rs:63:13
|
63 | fn try_from_glib(val: ffi::$ffi_type) -> Result<$ok_type, $err_type> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected unsafe fn, found normal fn
...
247 | / impl_return_result_traits!(
248 | | GstPadLinkReturn,
249 | | PadLinkReturn,
250 | | PadLinkSuccess,
251 | | PadLinkError
252 | | );
| |__- in this macro invocation
|
= note: expected fn pointer `unsafe fn(_) -> Result<_, _>`
found fn pointer `fn(_) -> Result<_, _>`
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0053]: method `try_from_glib` has an incompatible type for trait
--> /home/wk/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/b1088a6/gstreamer/src/enums.rs:63:13
|
63 | fn try_from_glib(val: ffi::$ffi_type) -> Result<$ok_type, $err_type> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected unsafe fn, found normal fn
...
313 | impl_return_result_traits!(GstClockReturn, ClockReturn, ClockSuccess, ClockError);
| ---------------------------------------------------------------------------------- in this macro invocation
|
= note: expected fn pointer `unsafe fn(_) -> Result<_, _>`
found fn pointer `fn(_) -> Result<_, _>`
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to 4 previous errors
```https://gitlab.freedesktop.org/gstreamer/www/-/issues/36Add various older CVEs to the security section2021-05-19T07:02:01ZSebastian DrögeAdd various older CVEs to the security sectionSee https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gstreamer . At least the following are missing:
* CVE-2020-6095
* CVE-2019-9928
* CVE-2017-*
* all older except for CVE-2016-9634 CVE-2016-9635 CVE-2016-9636 CVE-2016-9807 CVE-2016...See https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=gstreamer . At least the following are missing:
* CVE-2020-6095
* CVE-2019-9928
* CVE-2017-*
* all older except for CVE-2016-9634 CVE-2016-9635 CVE-2016-9636 CVE-2016-9807 CVE-2016-9445 CVE-2016-9446https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/138set rtspclientsink state to "NULL" will block2023-06-14T09:45:51ZJieset rtspclientsink state to "NULL" will blockmy app is runs on android with gstreamer 1.16.2.
the pipline has two branch as follow:
rtspsrc -> rtph264depay -> tee -> queue -> amcviddec -> queue -> autovideosink
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n...my app is runs on android with gstreamer 1.16.2.
the pipline has two branch as follow:
rtspsrc -> rtph264depay -> tee -> queue -> amcviddec -> queue -> autovideosink
|
.--> queue -> rtspclientsink
link these two branches dynamically.
rtspsrc and rtspclientsink are useing different network.
when network unavailable for rtspclientsink, i get an error message from it.
and then set rtspclientsink state to NULL. the func gst_element_set_state will been blocked,
if i destroy the branch directly, the app will crash.
the func gst_element_set_state is blocked because RECORD CMD cannot be canncelled.
the rtspclientsink element thread will block in the following two lines (3603,4366):
gst/rtsp-sink/gstrtspclientsink.c:
````
3601 while (!context->prerolled && !sink->conninfo.flushing) {
3602 GST_DEBUG_OBJECT (sink, "Waiting for caps on stream %d", context->index);
3603 g_cond_wait (&sink->preroll_cond, &sink->preroll_lock);
3604 }
4363 /* Wait for streams to be blocked */
4364 while (sink->n_streams_blocked < g_list_length (sink->contexts)) {
4365 GST_DEBUG_OBJECT (sink, "waiting for streams to be blocked");
4366 g_cond_wait (&sink->block_streams_cond, &sink->block_streams_lock);
4367 }
````
my solution is as follows,clumsy but temporarily effective:
````
diff --git a/gst/rtsp-sink/gstrtspclientsink.c b/gst/rtsp-sink/gstrtspclientsink.c
index 9b87ea3..4712c86 100644
--- a/gst/rtsp-sink/gstrtspclientsink.c
+++ b/gst/rtsp-sink/gstrtspclientsink.c
@@ -2081,6 +2081,7 @@ gst_rtsp_client_sink_connection_flush (GstRTSPClientSink * sink, gboolean flush)
stream->conninfo.flushing = flush;
}
}
+ sink->conninfo.flushing = flush;
g_cond_broadcast (&sink->preroll_cond);
g_mutex_unlock (&sink->preroll_lock);
}
@@ -3571,6 +3572,7 @@ gst_rtsp_client_sink_collect_streams (GstRTSPClientSink * sink)
GstRTSPStreamContext *context;
GList *walk;
const gchar *base;
+ gint64 end_time;
gboolean has_slash;
GST_DEBUG_OBJECT (sink, "Collecting stream information");
@@ -3600,7 +3602,8 @@ gst_rtsp_client_sink_collect_streams (GstRTSPClientSink * sink)
g_mutex_lock (&sink->preroll_lock);
while (!context->prerolled && !sink->conninfo.flushing) {
GST_DEBUG_OBJECT (sink, "Waiting for caps on stream %d", context->index);
- g_cond_wait (&sink->preroll_cond, &sink->preroll_lock);
+ end_time = g_get_monotonic_time () + G_TIME_SPAN_MILLISECOND * 500;
+ g_cond_wait_until (&sink->preroll_cond, &sink->preroll_lock, end_time);
}
if (sink->conninfo.flushing) {
g_mutex_unlock (&sink->preroll_lock);
@@ -4343,6 +4346,7 @@ gst_rtsp_client_sink_record (GstRTSPClientSink * sink, gboolean async)
GInetAddress *ia;
GSocket *conn_socket;
GList *walk;
+ gint64 end_time;
g_mutex_lock (&sink->preroll_lock);
if (sink->state == GST_RTSP_STATE_PLAYING) {
@@ -4361,11 +4365,14 @@ gst_rtsp_client_sink_record (GstRTSPClientSink * sink, gboolean async)
g_mutex_lock (&sink->block_streams_lock);
/* Wait for streams to be blocked */
- while (sink->n_streams_blocked < g_list_length (sink->contexts)) {
+ while ((sink->n_streams_blocked < g_list_length (sink->contexts)) && ! sink->conninfo.flushing) {
GST_DEBUG_OBJECT (sink, "waiting for streams to be blocked");
- g_cond_wait (&sink->block_streams_cond, &sink->block_streams_lock);
+ end_time = g_get_monotonic_time () + G_TIME_SPAN_MILLISECOND * 500;
+ g_cond_wait_until (&sink->block_streams_cond, &sink->block_streams_lock, end_time);
}
g_mutex_unlock (&sink->block_streams_lock);
+ if (sink->conninfo.flushing)
+ return GST_RTSP_EINTR;
/* Send announce, then setup for all streams */
gst_sdp_message_init (&sink->cursdp);
````
any good ideas?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/905FTBFS with meson-0.58.02021-05-18T16:36:43ZStefan PoetterFTBFS with meson-0.58.0When building gst-plugins-base-1.17.4 with meson-0.58.0 get the following error:
`[230/788] Compiling C object gst-libs/gst/gl/libgstgl-1.0.so.0.1804.0.p/gstglwindow.c.o
FAILED: gst-libs/gst/gl/libgstgl-1.0.so.0.1804.0.p/gstglwindow.c.o...When building gst-plugins-base-1.17.4 with meson-0.58.0 get the following error:
`[230/788] Compiling C object gst-libs/gst/gl/libgstgl-1.0.so.0.1804.0.p/gstglwindow.c.o
FAILED: gst-libs/gst/gl/libgstgl-1.0.so.0.1804.0.p/gstglwindow.c.o
cc -Igst-libs/gst/gl/libgstgl-1.0.so.0.1804.0.p -I. -I.. -Igst-libs -I../gst-libs -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gudev-1.0 -I/usr/include/libdrm -I/usr/include/valgrind -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -fvisibility=hidden -fno-strict-aliasing -DG_DISABLE_CAST_CHECKS -Wmissing-declarations -Wredundant-decls -Wundef -Wwrite-strings -Wformat -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Wvla -Wpointer-arith -Wmissing-prototypes -Wdeclaration-after-statement -fPIC -pthread -DHAVE_CONFIG_H -DBUILDING_GST_GL -MD -MQ gst-libs/gst/gl/libgstgl-1.0.so.0.1804.0.p/gstglwindow.c.o -MF gst-libs/gst/gl/libgstgl-1.0.so.0.1804.0.p/gstglwindow.c.o.d -o gst-libs/gst/gl/libgstgl-1.0.so.0.1804.0.p/gstglwindow.c.o -c ../gst-libs/gst/gl/gstglwindow.c
In file included from ../gst-libs/gst/gl/gstglwindow.c:54:
../gst-libs/gst/gl/wayland/gstglwindow_wayland_egl.h:25:10: fatal error: xdg-shell-client-protocol.h: No such file or directory
25 | #include "xdg-shell-client-protocol.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.`
compared to a build with meson-0.56.0, the cc invocation is missing these includes:
-Igst-libs/gst/gl -Igst-libs/gst/video -Igst-libs/gst/allocators
I was able to build by removing:
implicit_include_directories : false
from gst-libs/gst/gl/meson.build line 1005.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1595webrtcbin: Bad error handling2021-06-24T11:30:28ZPhilippe Normandwebrtcbin: Bad error handlingAs part of the ongoing quest of getting jitsi to work in my WebKit gstwebrtc backend I am now hitting this:
```
0:00:06.303249622 69 0x1f4e860 ERROR default webrtcsdp.c:613:_get_final_setup: remote SDP has the sam...As part of the ongoing quest of getting jitsi to work in my WebKit gstwebrtc backend I am now hitting this:
```
0:00:06.303249622 69 0x1f4e860 ERROR default webrtcsdp.c:613:_get_final_setup: remote SDP has the same 'a=setup:actpass' attribute. This is not legal
0:00:06.303263102 69 0x1f4e860 TRACE webrtcbin gstwebrtcbin.c:4003:_find_transceiver_for_sdp_media:<webkit-webrtcbin-0> Found transceiver <webrtctransceiver1>
0:00:06.303271612 69 0x1f4e860 TRACE webrtcbin gstwebrtcbin.c:594:_find_transport_for_session:<webkit-webrtcbin-0> Found transport <transportstream0> for session 0
0:00:06.303280383 69 0x1f4e860 DEBUG webrtctransportsendbin transportsendbin.c:166:transport_send_bin_change_state:<transportsendbin0> changing state: PLAYING => PLAYING
0:00:06.303295696 69 0x1f4e860 DEBUG webrtctransportreceivebin transportreceivebin.c:213:transport_receive_bin_change_state: changing state: PLAYING => PLAYING
0:00:06.303323534 69 0x1f4e860 ERROR default webrtcsdp.c:613:_get_final_setup: remote SDP has the same 'a=setup:actpass' attribute. This is not legal
(WebKitWebProcess:69): GLib-WARNING **: 01:38:06.104: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Cannot intersect direction attributes for media 1
0:00:06.303554094 69 0x19e1550 DEBUG webkitmediastreamsrc GStreamerMediaStreamSource.cpp:439:webkitMediaStreamSrcChangeState:<webkitmediastreamsrc4> READY->PAUSED
** (MiniBrowser:21): WARNING **: 01:38:19.999: WebProcess CRASHED
```
The issue seems to be that `_update_transceiver_from_sdp_media()` sets the GError once but we don't exit from the loop it's called from in `_update_transceivers_from_sdp()` so that opens the door to have the error set more than once, which apparently is not allowed :)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/699Recording video with cheese: Internal GStreamer error: code not implemented2022-11-10T09:21:06ZDennis RitterRecording video with cheese: Internal GStreamer error: code not implementedWhenever I'm trying to record a video I'm getting these errors (it worked some time ago on Ubuntu 20.10). The timer starts at a seemingly random time and the first part of the video is only a green screen.
```
Mai 16 08:53:48 cheese[5745...Whenever I'm trying to record a video I'm getting these errors (it worked some time ago on Ubuntu 20.10). The timer starts at a seemingly random time and the first part of the video is only a green screen.
```
Mai 16 08:53:48 cheese[5745]: Internal GStreamer error: code not implemented. Please file a bug at https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/new.: ../gst-libs/gst/video/gstvideofilter.c(296): gst_video_filter_transform (): /GstCameraBin:camerabin/GstEncodeBin:video-encodebin/GstVideoConvert:videoconvert1:
invalid video buffer received
Mai 16 08:53:50 cheese[5745]: Can't record audio fast enough: ../gst-libs/gst/audio/gstaudiobasesrc.c(841): gst_audio_base_src_create (): /GstCameraBin:camerabin/GstAutoAudioSrc:audiosrc/GstPulseSrc:audiosrc-actual-src-puls:
Dropped 62181 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
```
Cheese version: 3.38.0-3 on Ubuntu 21.04https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1594alphadecodebin: incorrect rendering on lossless VP92021-05-31T13:15:40ZNazar Mokrynskyialphadecodebin: incorrect rendering on lossless VP9I found that VP9 with alpha channel encoded on lossless mode is not decoded correctly by both GStreamer on master branch and FFmpeg as well, but at the same time it is rendered correctly by Firefox and Chromium, so there must be somethin...I found that VP9 with alpha channel encoded on lossless mode is not decoded correctly by both GStreamer on master branch and FFmpeg as well, but at the same time it is rendered correctly by Firefox and Chromium, so there must be something GStreamer can do about it.
Visually it looks like if alpha channel is being effectively ignored in this case.
Example file: https://cdn.streamelements.com/uploads/187c102b-ac08-4843-8ac9-4e6be93688b9.webmhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/698multiqueue: Can return GST_FLOW_OK after returning GST_FLOW_EOS2021-09-24T11:08:20ZNicolas Dufresnemultiqueue: Can return GST_FLOW_OK after returning GST_FLOW_EOSUnlike the `queue`, the `multiqueue` do not remember that downstream have return GST_FLOW_EOS. As a side effect, it will propadate the FLOW_EOS, but only once. If the following buffers are simply queued, a FLOW_OK will arrive.
What `que...Unlike the `queue`, the `multiqueue` do not remember that downstream have return GST_FLOW_EOS. As a side effect, it will propadate the FLOW_EOS, but only once. If the following buffers are simply queued, a FLOW_OK will arrive.
What `queue` does, is that it remembers this state passed the queue being empty, keeps dropping, and convert all input data return value to EOS. And does that until one of the following occure, event EOS comes it, which enabled more dropping, event SEGMENT or STREAM-START.
The side effect is that upstream element that keeps pushing and uses GstFlowCombiner, may not converge into returning GST_FLOW_EOS, as that state endup lost by a sudden FLOW_OK.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/904textoverlay: shaded-background=true does not work on windows2021-09-24T13:26:20Zvt-smxtextoverlay: shaded-background=true does not work on windowsHy,
I tried on windows 10 x64 following command:
`gst-launch-1.0 videotestsrc ! textoverlay font-desc="Sans 24" text="TEST" shaded-background=true ! autovideosink`
The shaded background is not shown.
See screenshot:
![2021-05-14_08_4...Hy,
I tried on windows 10 x64 following command:
`gst-launch-1.0 videotestsrc ! textoverlay font-desc="Sans 24" text="TEST" shaded-background=true ! autovideosink`
The shaded background is not shown.
See screenshot:
![2021-05-14_08_40_41-Direct3D11_renderer](/uploads/8f556de04c672fb1f868e4df3fc3746e/2021-05-14_08_40_41-Direct3D11_renderer.png)https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/328cerbero v 1.18.4: msvc build fails with VS2019 version 16.9.42021-05-14T13:33:24ZAaron Boxercerbero v 1.18.4: msvc build fails with VS2019 version 16.9.4Error:
```
c:\Users\vdi\source\repos\cerbero\build\dist\msvc_x86_64\include\spandsp/fast_convert.h(320): error C2169: 'lrint': intrinsic function, cannot be defined
```
It appears that msvc version 16.9.x supplies its own intrinsic for...Error:
```
c:\Users\vdi\source\repos\cerbero\build\dist\msvc_x86_64\include\spandsp/fast_convert.h(320): error C2169: 'lrint': intrinsic function, cannot be defined
```
It appears that msvc version 16.9.x supplies its own intrinsic for `lrint`, where it didn't in previous versions. This conflicts with custom `lrint` implementation.
See this [audacity issue](https://forum.audacityteam.org/viewtopic.php?t=116165&start=10) for how this was dealt with on that project.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/697Cheese shows flickering2021-05-14T13:09:00ZMD IntisarCheese shows flickeringCheese shows flickering. Running it in the terminal shows the following.
```
Internal GStreamer error: code not implemented. Please file a bug at https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/new.: ../gst-plugins-base/gst-...Cheese shows flickering. Running it in the terminal shows the following.
```
Internal GStreamer error: code not implemented. Please file a bug at https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/new.: ../gst-plugins-base/gst-libs/gst/video/gstvideofilter.c(296): gst_video_filter_transform (): /GstCameraBin:camerabin/GstViewfinderBin:vf-bin/GstVideoConvert:vfbin-csp:
invalid video buffer received
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/696cheese-WARNING **: 11:11:42.653: Internal GStreamer error: code not implemented.2021-05-17T15:37:55ZCorrado Venturinicheese-WARNING **: 11:11:42.653: Internal GStreamer error: code not implemented.```
corrado@corrado-x6-ii-0501:~$ cheese
(cheese:4401): Gdk-WARNING **: 11:11:40.272: Native Windows taller than 65535 pixels are not supported
(cheese:4401): cheese-WARNING **: 11:11:42.653: Internal GStreamer error: code not implemen...```
corrado@corrado-x6-ii-0501:~$ cheese
(cheese:4401): Gdk-WARNING **: 11:11:40.272: Native Windows taller than 65535 pixels are not supported
(cheese:4401): cheese-WARNING **: 11:11:42.653: Internal GStreamer error: code not implemented. Please file a bug at https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/new.: ../gst-libs/gst/video/gstvideofilter.c(296): gst_video_filter_transform (): /GstCameraBin:camerabin/GstViewfinderBin:vf-bin/GstVideoConvert:vfbin-csp:
invalid video buffer received
corrado@corrado-x6-ii-0501:~$ apt policy cheese
cheese:
Installed: 3.38.0-3
Candidate: 3.38.0-3
Version table:
*** 3.38.0-3 500
500 http://archive.ubuntu.com/ubuntu impish/main amd64 Packages
100 /var/lib/dpkg/status
corrado@corrado-x6-ii-0501:~$ inxi -Fx
System: Host: corrado-x6-ii-0501 Kernel: 5.11.0-16-generic x86_64 bits: 64 compiler: gcc
v: 10.2.1 Desktop: GNOME 3.38.4 Distro: Ubuntu 21.10 (Impish Indri)
Machine: Type: Desktop Mobo: ASRock model: H110M-G/M.2 serial: <superuser required>
UEFI: American Megatrends v: P1.10 date: 05/11/2017
CPU: Info: Dual Core model: Intel Core i3-7100 bits: 64 type: MT MCP arch: Kaby Lake
rev: 9 L2 cache: 3 MiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31199
Speed: 800 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800
Graphics: Device-1: Intel HD Graphics 630 vendor: ASRock driver: i915 v: kernel
bus ID: 00:02.0
Device-2: ARC USB 2.0 Camera type: USB driver: uvcvideo bus ID: 1-2:3
Display: wayland server: X.Org 1.21.1.1 compositor: gnome-shell driver:
loaded: i915 note: n/a (using device driver) resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 630 (KBL GT2) v: 4.6 Mesa 21.0.1
direct render: Yes
Audio: Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASRock
driver: snd_hda_intel v: kernel bus ID: 00:1f.3
Device-2: Logitech QuickCam Pro 9000 type: USB driver: snd-usb-audio,uvcvideo
bus ID: 1-1:2
Sound Server: ALSA v: k5.11.0-16-generic
Network: Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: kernel port: f040
bus ID: 00:1f.6
IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: 70:85:c2:44:7b:86
Device-2: D-Link DWA-121 802.11n Wireless N 150 Pico Adapter [Realtek RTL8188CUS]
type: USB driver: rtl8192cu bus ID: 1-5:5
IF: wlx48ee0c2322b8 state: down mac: 48:ee:0c:23:22:b8
Drives: Local Storage: total: 2.05 TiB used: 8.21 GiB (0.4%)
ID-1: /dev/nvme0n1 vendor: Kingston model: SKC2000M8250G size: 232.89 GiB
temp: 28.9 C
ID-2: /dev/sda vendor: Toshiba model: DT01ACA100 size: 931.51 GiB
ID-3: /dev/sdb vendor: Hitachi model: HDS721010CLA332 size: 931.51 GiB
Partition: ID-1: / size: 31.25 GiB used: 8.2 GiB (26.3%) fs: ext4 dev: /dev/nvme0n1p6
ID-2: /boot/efi size: 252 MiB used: 5.2 MiB (2.1%) fs: vfat dev: /dev/nvme0n1p1
Swap: ID-1: swap-1 type: partition size: 8 GiB used: 0 KiB (0.0%) dev: /dev/sda2
Sensors: System Temperatures: cpu: 44.5 C mobo: N/A
Fan Speeds (RPM): N/A
Info: Processes: 232 Uptime: 4m Memory: 7.48 GiB used: 1.79 GiB (23.9%) Init: systemd
runlevel: 5 Compilers: gcc: N/A Packages: 1804 Shell: Bash v: 5.1.8 inxi: 3.3.01
corrado@corrado-x6-ii-0501:~$
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/695textoverlay: shaded-background=true does not work on windows2022-11-10T09:21:06Zvt-smxtextoverlay: shaded-background=true does not work on windowsHy,
I tried on windows 10 x64 following command:
`gst-launch-1.0 videotestsrc ! textoverlay font-desc="Sans 24" text="TEST" shaded-background=true ! autovideosink`
The shaded background is not shown.
See screenshot:
![2021-05-14_08_4...Hy,
I tried on windows 10 x64 following command:
`gst-launch-1.0 videotestsrc ! textoverlay font-desc="Sans 24" text="TEST" shaded-background=true ! autovideosink`
The shaded background is not shown.
See screenshot:
![2021-05-14_08_40_41-Direct3D11_renderer](/uploads/446fbc8b7a129bbff826d490474ca86d/2021-05-14_08_40_41-Direct3D11_renderer.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/886rtspsrc location length problem2023-07-02T16:43:56Z末末rtspsrc location length problem`gst-launch-1.0 rtspsrc location="rtsp://183.59.160.61/PLTV/88888895/224/3221226767/00000100000000060000000000268440_0.smil?rrsip=125.88.70.140,rrsip=125.88.104.45&zoneoffset=480&icpid=szmg&accounttype=1&limitflux=-1&limitdur=-1&accounti...`gst-launch-1.0 rtspsrc location="rtsp://183.59.160.61/PLTV/88888895/224/3221226767/00000100000000060000000000268440_0.smil?rrsip=125.88.70.140,rrsip=125.88.104.45&zoneoffset=480&icpid=szmg&accounttype=1&limitflux=-1&limitdur=-1&accountinfo=%7E%7EV2.0%7Ekws5JFgGn-zqVXihML1ujg%7E9rXSI7IeLpF-Iy8tIn5TfxK58x4Z8vevaDBINizpo5FcfEW667kl4l1Ui7NwFD0d09dwbRwtTeqi-3mg1V5El-iYjXauSVB_dL9sI8VG9wg~ExtInfoWNHSPSTb+3AG0FnUkYLPMw==%3A20190726130336%2C21858133%2C183.15.205.163%2C20190726130336%2C11000100000000050000000000000148%2C2185813320190726130335%2C-1%2C0%2C1%2C%2C%2C2%2C%2C%2C%2C2%2CEND&GuardEncType=2&tenantId=8601" ! queue ! rtph264depay ! h264parse ! mpegtsmux ! hlssink target-duration=2 playlist-length=20 max-files=20 playlist-location="/www/1/1.m3u8" location="/www/1/1_%05d.ts"`
The above command reports an error because the location is too long
![image](/uploads/d9c5178377322ccd79ecde1b015bd432/image.png)
When I reduce the length of the location, it is normal, because the missing parameter is reported as 403
`gst-launch-1.0 rtspsrc location="rtsp://183.59.160.61/PLTV/88888895/224/3221226767/00000100000000060000000000268440_0.smil?rrsip=125.88.70.140,rrsip=125.88.104.45&zoneoffset=480&icpid=szmg&accounttype=1&limitflux=-1&limitdur=-1&accountinfo=%7E%7EV2.0%7Ekws5JFgGn-zqVXihML1ujg%7E9rXSI7IeLpF-Iy8tIn5TfxK58x4Z8vevaDBINizpo5FcfEW667kl4l1Ui7NwFD0d09dwbRwtTeqi-3mg1V5El-iYjXauSVB_dL9sI8VG9wg~ExtInfoWNHSPSTb+3AG0FnUkYLPMw==%3A20190726130336%2C21858133%2C183.15.205.163%2C20190726130336%2C11000100000000050000000000000148%2C2185813320190726130335%2C-1%2C0%2C1%2C%2C%2C2%2C%2C%2C%2C2%2CEND&GuardEncType=" ! queue ! rtph264depay ! h264parse ! mpegtsmux ! hlssink target-duration=2 playlist-length=20 max-files=20 playlist-location="/www/1/1.m3u8" location="/www/1/1_%05d.ts"`
![image](/uploads/bedefc78111653d45f52fe7fda402fc4/image.png)
version:1.16.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1592hlsdemux(?): deadlock while buffering a specific HLS stream2023-07-04T17:11:59ZSamuel de Mourahlsdemux(?): deadlock while buffering a specific HLS streamI've noticed that sometimes a deadlock happens while trying to play a specific HLS stream, which I'm hosting [here](https://sample-medias.herokuapp.com/static/gst_hls_dl_audio/audio_dl.m3u8). To reproduce, simply play the media in a loop...I've noticed that sometimes a deadlock happens while trying to play a specific HLS stream, which I'm hosting [here](https://sample-medias.herokuapp.com/static/gst_hls_dl_audio/audio_dl.m3u8). To reproduce, simply play the media in a loop and eventually `gst-play-1.0` will get stuck displaying `Buffering...` in stdout. For example, I can reproduce with:
```bash
while true; do
gst-play-1.0 https://sample-medias.herokuapp.com/static/gst_hls_dl_audio/audio_dl.m3u8
done
```
### Brief investigation results
During my initial investigations I suspected that the problem was related to the values of the `BANDWIDTH` fields in the master HLS manifest, since I noticed that some specific values make it very difficult to reproduce. It also seems to tie into the variant change logic, since if I change `gst_hls_master_playlist_get_variant_for_bitrate` from `m3u8.c` to always return the same variant (`return current_variant ? current_variant : variant;`), the deadlock doesn't seem to happen at all.
While trying to fix this I also found another place where I can change some code to significantly decrease the chances of it happening: if I replace `gst_hls_demux_clear_all_pending_data` in `gsthlsdemux.c` with the version below, the deadlock becomes much harder to reproduce (although it still does happen):
```c
static void
gst_hls_demux_clear_all_pending_data (GstHLSDemux * hlsdemux)
{
GstAdaptiveDemux *demux = (GstAdaptiveDemux *) hlsdemux;
GList *walk;
for (walk = demux->streams; walk != NULL; walk = walk->next) {
GstHLSDemuxStream *hls_stream = GST_HLS_DEMUX_STREAM_CAST (walk->data);
gst_hls_demux_stream_clear_pending_data (hls_stream);
GstAdaptiveDemuxStream *stream = &hls_stream->adaptive_demux_stream;
g_mutex_lock (&hls_stream->adaptive_demux_stream.fragment_download_lock);
hls_stream->adaptive_demux_stream.cancelled = TRUE;
g_cond_signal (&hls_stream->adaptive_demux_stream.fragment_download_cond);
g_mutex_unlock (&hls_stream->adaptive_demux_stream.fragment_download_lock);
}
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/150meson reconfigure triggers a full GST Rust rebuild2021-06-01T13:01:51ZStéphane Cerveauscerveau@igalia.commeson reconfigure triggers a full GST Rust rebuildI first enabled GST rust plugin and start build everything from scratch (external traits and Gstreamer libs).
Then I changed something in on meson.build from gst-plugins-base (install a tool) and it triggers a full build of rust again.
...I first enabled GST rust plugin and start build everything from scratch (external traits and Gstreamer libs).
Then I changed something in on meson.build from gst-plugins-base (install a tool) and it triggers a full build of rust again.
It triggers a build of GStreamer rust libraries again.
It is something expected ?