GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2019-09-09T07:07:17Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/598gstrtspsrc command thread may get stuck in gst_rtspsrc_loop2019-09-09T07:07:17ZTobias Rongegstrtspsrc command thread may get stuck in gst_rtspsrc_loopWhen a new command is received and the command thread is in gst_rtspsrc_loop, the other thread will interrupt the command thread by calling gst_rtspsrc_connection_flush. This only works, however, if the command thread is currently busy r...When a new command is received and the command thread is in gst_rtspsrc_loop, the other thread will interrupt the command thread by calling gst_rtspsrc_connection_flush. This only works, however, if the command thread is currently busy receiving. If it is not, the thread will keep looping and never leave gst_rtspsrc_loop.
The issue was found when performing teardown and a pause command was sent followed by a stop command. When the test passes, the pause command gets interrupted before it has finished. When the test fails (rarely), the pause command finishes before the stop command begins, which results in the command thread getting stuck in gst_rtspsrc_loop.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/594meson build error missing gstglconfig.h for gtkdoc helper script2019-05-22T08:04:27ZRobert Rosengrenmeson build error missing gstglconfig.h for gtkdoc helper scriptTried meson build for first time, but had following issue upon running ninja install:
```
In file included from /mnt/storage/trunks/gst-plugins-base/gst-libs/gst/gl/gstgl_fwd.h:26:0, ...Tried meson build for first time, but had following issue upon running ninja install:
```
In file included from /mnt/storage/trunks/gst-plugins-base/gst-libs/gst/gl/gstgl_fwd.h:26:0,
from /mnt/storage/trunks/gst-plugins-base/gst-libs/gst/gl/gl.h:24,
from gst-plugins-base-libs-scan.c:14:
/mnt/storage/trunks/gst-plugins-base/gst-libs/gst/gl/gstglapi.h:24:32: fatal error: gst/gl/gstglconfig.h: No such file or directory
#include <gst/gl/gstglconfig.h>
^
compilation terminated.
```
In this setup I'm building without gl, but the missing file seems to come from gst-libs/gst/gl/meson.build
```
configure_file(input : 'gstglconfig.h.meson',
output : 'gstglconfig.h',
install_dir : get_option('libdir') + '/gstreamer-1.0/include/gst/gl',
configuration : glconf)
```
How to solve this?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/597rtspsrc: client does not honour client ports in SETUP reply2019-04-29T15:22:36ZMarc Leemanrtspsrc: client does not honour client ports in SETUP replyDuring the negotiation of the connection in the SETUP phase, the client suggests a pair of streaming ports to the server. The server can either accept this or it can return other ports that the client should use.
In version 1.14.4 (at...During the negotiation of the connection in the SETUP phase, the client suggests a pair of streaming ports to the server. The server can either accept this or it can return other ports that the client should use.
In version 1.14.4 (at least), the client (rtspsrc) sends a number of ports and in some cases, the server rejects them and returns another port combination. These are not accepted by the client, instead it uses the ones it suggested. This leads to a situation where the server sends media to one port combination, while the client listens to another.
```
2019-04-26T17:14:17.756253 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8819:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
2019-04-26T17:14:17.756281 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8822:gst_rtspsrc_print_rtsp_message:<rtspsrc0> RTSP request message 0x7fbf5f780960
2019-04-26T17:14:17.756307 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8823:gst_rtspsrc_print_rtsp_message:<rtspsrc0> request line:
2019-04-26T17:14:17.756335 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8825:gst_rtspsrc_print_rtsp_message:<rtspsrc0> method: 'SETUP'
2019-04-26T17:14:17.756361 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8826:gst_rtspsrc_print_rtsp_message:<rtspsrc0> uri: 'rtsp://10.238.68.111:554/mgs-video/stream=Tfb0ae9bf0c5443548148a0ccc929ebad-Wf7c411cd768b419286df5e0fc64d0c46'
2019-04-26T17:14:17.756389 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8828:gst_rtspsrc_print_rtsp_message:<rtspsrc0> version: '1.0'
2019-04-26T17:14:17.756415 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8829:gst_rtspsrc_print_rtsp_message:<rtspsrc0> headers:
2019-04-26T17:14:17.756443 [9092/18250] 0x55a6d4297320 LOG rtspsrc gstrtspsrc.c:8803:dump_key_value:<rtspsrc0> key: 'User-Agent', value: 'GStreamer/1.14.4'
2019-04-26T17:14:17.756471 [9092/18250] 0x55a6d4297320 LOG rtspsrc gstrtspsrc.c:8803:dump_key_value:<rtspsrc0> key: 'Transport', value: 'RTP/AVP;unicast;client_port=37838-37839'
2019-04-26T17:14:17.756497 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8831:gst_rtspsrc_print_rtsp_message:<rtspsrc0> body:
2019-04-26T17:14:17.756523 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8911:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
2019-04-26T17:14:17.761350 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8819:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
2019-04-26T17:14:17.761402 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8841:gst_rtspsrc_print_rtsp_message:<rtspsrc0> RTSP response message 0x7fbf5f7809c0
2019-04-26T17:14:17.761437 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8842:gst_rtspsrc_print_rtsp_message:<rtspsrc0> status line:
2019-04-26T17:14:17.761472 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8843:gst_rtspsrc_print_rtsp_message:<rtspsrc0> code: '200'
2019-04-26T17:14:17.761504 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8844:gst_rtspsrc_print_rtsp_message:<rtspsrc0> reason: 'OK'
2019-04-26T17:14:17.761535 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8846:gst_rtspsrc_print_rtsp_message:<rtspsrc0> version: '1.0
2019-04-26T17:14:17.761566 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8847:gst_rtspsrc_print_rtsp_message:<rtspsrc0> headers:
2019-04-26T17:14:17.762626 [9092/18250] 0x55a6d4297320 LOG rtspsrc gstrtspsrc.c:8803:dump_key_value:<rtspsrc0> key: 'CSeq', value: '3'
2019-04-26T17:14:17.762672 [9092/18250] 0x55a6d4297320 LOG rtspsrc gstrtspsrc.c:8803:dump_key_value:<rtspsrc0> key: 'Transport', value: 'RTP/AVP;unicast;client_port=59464-59465;mode="PLAY"'
2019-04-26T17:14:17.762707 [9092/18250] 0x55a6d4297320 LOG rtspsrc gstrtspsrc.c:8803:dump_key_value:<rtspsrc0> key: 'Server', value: 'Barco EMS RTSP Server (EMS-0060E05E203E)'
2019-04-26T17:14:17.762740 [9092/18250] 0x55a6d4297320 LOG rtspsrc gstrtspsrc.c:8803:dump_key_value:<rtspsrc0> key: 'Session', value: 'plrqgkprdkwvpotf;timeout=60'
2019-04-26T17:14:17.762772 [9092/18250] 0x55a6d4297320 LOG rtspsrc gstrtspsrc.c:8803:dump_key_value:<rtspsrc0> key: 'Date', value: 'Fri, 26 Apr 2019 17:14:17 +0200'
2019-04-26T17:14:17.762804 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8850:gst_rtspsrc_print_rtsp_message:<rtspsrc0> body: length 0
2019-04-26T17:14:17.762835 [9092/18250] 0x55a6d4297320 FIXME rtspsrc gstrtspsrc.c:8911:gst_rtspsrc_print_rtsp_message:<rtspsrc0> --------------------------------------------
[0.01.10.286851269-mgs-worker-stop.dot](/uploads/bb32fc64a34db1cbdf7e75a3f8268632/0.01.10.286851269-mgs-worker-stop.dot)
[0.01.10.281885179-mgs-worker-sigint.dot](/uploads/7a0fba4fb8300217fa5209a8e7758edc/0.01.10.281885179-mgs-worker-sigint.dot)
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/388--disable-option-parsing changes semantics of gst_init_get_option_group() and...2020-08-20T19:53:55ZW. Michael Petullo--disable-option-parsing changes semantics of gst_init_get_option_group() and breaks applicationsIt seems that --disable-option-parsing changes semantics of gst_init_get_option_group() and thus breaks applications. With --disable-option-parsing, gst_init_get_option_group() returns NULL without initializing GStreamer. Examples such a...It seems that --disable-option-parsing changes semantics of gst_init_get_option_group() and thus breaks applications. With --disable-option-parsing, gst_init_get_option_group() returns NULL without initializing GStreamer. Examples such as "The GOption interface" example at https://gstreamer.freedesktop.org/documentation/application-development/basics/init.html rely on the idea that gst_init_get_option_group() always initializes GStreamer.
Should we modify the implementation of gst_init_get_option_group() to initialize GStreamer even with --disable-option-parsing specified, albeit without GOptions? Or, perhaps should we more clearly document that it is the application's responsibility to call gst_init() if gst_init_get_option_group() returns NULL? The former seems more reasonable and robust, especially since gst_init_get_option_group() starts with "gst_init."
I suppose I might be missing something, but what I have found seems to leave things unclear.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/593Support FMPS tags2021-09-24T13:25:03ZBenoit BrummerSupport FMPS tagsFMPS tags are used to store a float rating between 0 and 1 and some useful information such as play count.
This feature request is similar to #64 , but more relevant in my opinion since FMPS tags apply to multiple audio file formats (as...FMPS tags are used to store a float rating between 0 and 1 and some useful information such as play count.
This feature request is similar to #64 , but more relevant in my opinion since FMPS tags apply to multiple audio file formats (as opposed to mp3) and they are specified by freedesktop.org ([https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/](https://www.freedesktop.org/wiki/Specifications/free-media-player-specs/)).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/596meson doesn't build the gtk-doc2019-04-28T11:09:59ZPierre-Yvesmeson doesn't build the gtk-docWith version 1.16.0, the meson build is considered as feature complete, however it seems it's missing the gtk-doc build for plugins good, bad, ugly (I haven't built all the packages yet, but gtk-doc is there for main gstreamer and for pl...With version 1.16.0, the meson build is considered as feature complete, however it seems it's missing the gtk-doc build for plugins good, bad, ugly (I haven't built all the packages yet, but gtk-doc is there for main gstreamer and for plugin base).
Is this intentional or is it an omission?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/387#386 followup, mingw/msys compiler is the real cause2019-06-26T14:51:39ZJ#386 followup, mingw/msys compiler is the real causeSebastian,
FYI, just because you wrote "we should probably document that somewhere" at the end of #386, so here it goes,
At the end of #386 you pointed out that cygwin gcc is incompatible with Win10 C headers, glib and etc
After our con...Sebastian,
FYI, just because you wrote "we should probably document that somewhere" at the end of #386, so here it goes,
At the end of #386 you pointed out that cygwin gcc is incompatible with Win10 C headers, glib and etc
After our conversation in #386, I switched back to msys/mingw gcc, which I had tried to use before cygwin gcc.
as per recommended link on the gstreamer site,
https://gstreamer.freedesktop.org/documentation/installing/building-from-source-using-cerbero.html
I had installed gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
The moment I switched back to msys/mingw gcc from cygwin gcc, I recalled why I switched to cygwin gcc in the first place.
Because the msys/mingw gcc doesn't work with gstreamer. It always give the following error,
===============================================================
libgcc.a: error adding symbols: File format not recognized
collect2.exe: error: ld returned 1 exit status
================================================================
After having struggled with this gcc problem for 2 days again, I switched to
gcc version 8.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project), the one I installed way back.
And it just works right away.
I'm no compiler developer, and I could only guess the msys/mingw gcc is 32-bit.
So both cygwin gcc & msys/mingw gcc(MingW.org) don't work with gstreamer on Win10.
Regards,https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/68Adding lots of clips is extremely slow with auto_transitions enabled2021-09-24T12:17:14ZMart RaudseppAdding lots of clips is extremely slow with auto_transitions enabledIf adding clips to a layer that has auto_transitions enabled, the per-clip adding time seems to start to grow with some exponential properties.
[clip-auto-transition-slow.c](/uploads/38a9c4b076954ee0d4c344c7dab8be89/clip-auto-transition...If adding clips to a layer that has auto_transitions enabled, the per-clip adding time seems to start to grow with some exponential properties.
[clip-auto-transition-slow.c](/uploads/38a9c4b076954ee0d4c344c7dab8be89/clip-auto-transition-slow.c)
This test case demonstrates it with 800 clips, which takes over 6 minutes for me.
1200 clips takes over 21 minutes already for me with this code.
The code where I noticed the problem is a bit different (using the file backed asset for an URIClip audio), and is actually for some reason much faster, but still in the minutes territory.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/197"Signal not found" on emitting create-data-channel2019-08-05T13:59:06ZTobias Morell"Signal not found" on emitting create-data-channelI'm using the webrtcbin to stream RGB video from gstreamer. I have succeeded in getting the video through and would like to add a data channel to the connection as well. I have taken inspiration from [this example in C](https://github.co...I'm using the webrtcbin to stream RGB video from gstreamer. I have succeeded in getting the video through and would like to add a data channel to the connection as well. I have taken inspiration from [this example in C](https://github.com/ystreet/gstwebrtc-demos/blob/data-channel/datachannel/gst/webrtc-datachannel.c), which yielded the following code:
```rust
let data_channel = webrtc.emit("create-data-channel", &[&"channel"]).unwrap();
match data_channel {
Some(channel) => {
let g_channel = channel.get::<gst::Object>().unwrap();
connect_data_channel_signals(&g_channel.clone()).unwrap_err();
}
_ => {
println!("Data channel creation failed :(")
}
}
webrtc.connect("on-data-channel", false, move |values| {
let channel = values[1].get::<gst::Object>().unwrap();
connect_data_channel_signals(&channel.clone()).unwrap_err();
None
})?;
```
The `webrtc` variable has been created with `gst::ElementFactory::make("webrtcbin", "webrtc")` and `connect_data_channel_signals` sets up the signals associated with the data channel, that is "on-error", "on-open", "on-close" and "on-message-string".
Problem is that the `webrtc.emit` function results in a panic with the description *"Signal not found"*. Similarly, if I comment out the first part, the call to `webrtc.connect` will result in the same error. Am I doing something wrong or is it because data channels are simply not supported in Rust yet?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/386GstPadProbeInfo seems to show inconsistent structure field length or location...2019-06-26T14:51:39ZJGstPadProbeInfo seems to show inconsistent structure field length or location - gulong / crashHi, I started learning gstreamer a week ago by following the tutorial programs on gstreamer.freedesktop.org.
This exact program I basically copied and pasted the one from "Pipe Manipulation" tutorial sample program.
However, I always r...Hi, I started learning gstreamer a week ago by following the tutorial programs on gstreamer.freedesktop.org.
This exact program I basically copied and pasted the one from "Pipe Manipulation" tutorial sample program.
However, I always run into problem with pad_proble - not able to access the appropriate GstPadProbeInfo internal fields when receiving a signal back and crash my apps. I was using v1.15.90 and started the problem. Today I upgraded to 1.16, still problem.
So I dump the content of GstPadProbeInfo received in callback with this function,
Windows 10, X86_64, G_LITTLE_ENDIAN
See app16.txt for the dump() function codes & output.
[app16.txt](/uploads/2eb2c95aedb2340d0a11ac48195a2ea8/app16.txt)
Somehow the text cut & paste from Windows keep losing carriage-return, so I put the codes & output in app16.txt - easier to read.
Here is my humble view, please comment or correct me please,
1. The pad_proble ID is 1, but application read 324d480 bcs id field is gulong (8-byte) in apps.
But from mem dump, the "1" is stored as uint (4-byte). So the gstreamer dll treats id field as uint?
2. the data field
reference with gst_pad_probe_info_get_buffer (info) gives correct 324d480 (by dll)
reference with info->data, gives FFFFFFFFFFFFFFFF, by application, which is also kinda correct - 3rd 64-bits field
So is it possible that somehow the dll was compiled with sizeof(gulong) == 4 or something?
or, I need to #define memory compacting since this is a CISC processor?
The gstreamer I installed are[app16.txt](/uploads/704b5b42735adb1be7a2d7a4718c4114/app16.txt)
gstreamer-1.0-mingw-x86_64-1.16.0.msi
gstreamer-1.0-devel-mingw-x86_64-1.16.0.msi
earlier was
gstreamer-1.0-mingw-x86_64-1.15.90.msi
Thanks,
p.s. I closed the #385, bcs the posted text keep getting condensed.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/384Segfault since 1.162019-08-07T20:01:35ZYan PashkovskySegfault since 1.16Noticed using clementine: https://github.com/clementine-player/Clementine/issues/6337
backtrace
```
Thread 22 "id3demux0:sink" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa1ffb700 (LWP 473)]
0x00007ffff6811e...Noticed using clementine: https://github.com/clementine-player/Clementine/issues/6337
backtrace
```
Thread 22 "id3demux0:sink" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa1ffb700 (LWP 473)]
0x00007ffff6811e5c in gst_date_time_new () from /usr/lib/libgstreamer-1.0.so.0
(gdb) bt
#0 0x00007ffff6811e5c in gst_date_time_new () at /usr/lib/libgstreamer-1.0.so.0
#1 0x00007ffff73b8f29 in gst_tag_list_new_from_id3v1 () at /usr/lib/libgsttag-1.0.so.0
#2 0x00007fffe21bb46f in () at /usr/lib/gstreamer-1.0/libgstid3demux.so
#3 0x00007ffff73a0e44 in () at /usr/lib/libgsttag-1.0.so.0
#4 0x00007ffff73a1bb5 in () at /usr/lib/libgsttag-1.0.so.0
#5 0x00007ffff67c91d3 in () at /usr/lib/libgstreamer-1.0.so.0
#6 0x00007ffff6940cc6 in () at /usr/lib/libglib-2.0.so.0
#7 0x00007ffff6947c21 in () at /usr/lib/libglib-2.0.so.0
#8 0x00007ffff6b2ba92 in start_thread () at /usr/lib/libpthread.so.0
#9 0x00007ffff45c2cd3 in clone () at /usr/lib/libc.so.6
```https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/196examples/glupload: Segfault on close with Wayland backend2019-05-03T19:54:26ZSebastian Drögeexamples/glupload: Segfault on close with Wayland backendCC @vjaquez @ystreet @nielsdg
Code in question can be found here: https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/blob/bf96e264c933acadbd00e846f4184e7b9ec9b309/examples/src/bin/glupload.rs
Segfault happens in the `finalize` func...CC @vjaquez @ystreet @nielsdg
Code in question can be found here: https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/blob/bf96e264c933acadbd00e846f4184e7b9ec9b309/examples/src/bin/glupload.rs
Segfault happens in the `finalize` function of `GstGLDisplayWayland` in
```c
g_clear_pointer (&display_wayland->shell, wl_shell_destroy);
```
Leaking the display from the example code works around this:
```diff
diff --git a/examples/src/bin/glupload.rs b/examples/src/bin/glupload.rs
index 4c5deb4..462ee8e 100644
--- a/examples/src/bin/glupload.rs
+++ b/examples/src/bin/glupload.rs
@@ -418,6 +418,8 @@ impl App {
let gl_context = shared_context.clone();
let events_proxy = events_loop.create_proxy();
+ std::mem::forget(gl_display.clone());
+
#[allow(clippy::single_match)]
bus.set_sync_handler(move |_, msg| {
match msg.view() {
```
My guess is that the problem here is that glutin is disconnecting the wayland display before the last reference to the `GstGLDisplayWayland` is released. We then destroy those interfaces without the underlying display still being there and that simply crashes.
Or maybe we're not supposed to keep/destroy these interfaces if it is a foreign display?
How do lifetimes work in Wayland for these things? :)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/156vaapimpeg2dec + vaapisink + cc708overlay: CEA 608 CCs are garbled2021-09-24T12:23:18ZAaron Boxervaapimpeg2dec + vaapisink + cc708overlay: CEA 608 CCs are garbledPipeline:
```
gst-launch-1.0 -v filesrc location=test.ts ! tsdemux ! mpegvideoparse ! vaapimpeg2dec! deinterlace ! ccextractor name=ce ! queue ! videoconvert ! cc708overlay name=o !vaapisink ce. ! queue ! o.
```
Test file:
...Pipeline:
```
gst-launch-1.0 -v filesrc location=test.ts ! tsdemux ! mpegvideoparse ! vaapimpeg2dec! deinterlace ! ccextractor name=ce ! queue ! videoconvert ! cc708overlay name=o !vaapisink ce. ! queue ! o.
```
Test file:
[test.ts](/uploads/55bc6d2e06f1beb32591760a8eb67c64/test.ts)
One symptom of the problem is buffer overflow errors when running this pipeline.
Changing `vaapisink` to `gtksink` makes the problem go away.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/955webrtcbin recvonly answer to recvonly offer2021-08-13T22:19:07ZAdrien Rouhètewebrtcbin recvonly answer to recvonly offerI'm trying to stream a video from a peer that didn't make the offer.
The sender is a C code that is inspired from the [gstwebrtc demo](https://github.com/centricular/gstwebrtc-demos), and the receiver is a js code in a browser using Si...I'm trying to stream a video from a peer that didn't make the offer.
The sender is a C code that is inspired from the [gstwebrtc demo](https://github.com/centricular/gstwebrtc-demos), and the receiver is a js code in a browser using SimplePeer.
The browser is generating this recvonly SDP (as expected): [Offer sdp](https://hastebin.com/lapuruqeci)
But the webrtcbin generated answer also have a recvonly SDP (we would expect sendonly) :
[Answer sdp](https://hastebin.com/nutajaqecu)
Consequently the program abort with this error :
`** ERROR:gstwebrtcbin.c:3369:_connect_rtpfunnel: assertion failed: (stream)`
This is probably due to the fact that no stream exists because neither peer create it as both are waiting for the stream.
Here is the code that handles the offer sent by the browser.
```c
// 'sdp' has been retrieved from json sent by the browser
GstWebRTCSessionDescription *offer = gst_webrtc_session_description_new(GST_WEBRTC_SDP_TYPE_OFFER, sdp);
// Set remote description on our pipeline
g_signal_emit_by_name (webrtc1, "set-remote-description", offer, NULL);
// Create answer that we will send back to the peer
GstPromise *promise = gst_promise_new_with_change_func(on_answer_created, NULL, NULL);
g_signal_emit_by_name(webrtc1, "create-answer", NULL, promise);
gst_webrtc_session_description_free(offer);
```
The code that handle the answer created by webcrtcbin:
```c
static void on_answer_created(GstPromise *promise, gpointer user_data) {
GstWebRTCSessionDescription *answer;
const GstStructure *reply;
reply = gst_promise_get_reply(promise);
gst_structure_get(reply, "answer", GST_TYPE_WEBRTC_SESSION_DESCRIPTION, &answer, NULL);
gst_promise_unref(promise);
// Set local description on our pipeline
g_signal_emit_by_name(webrtc1, "set-local-description", answer, NULL);
send_sdp_to_peer(answer);
gst_webrtc_session_description_free(answer);
}
```
We only connect the ice candidate signal when creating the pipeline
```c
// pipe1 = gst_parse_launch("...");
webrtc1 = gst_bin_get_by_name (GST_BIN (pipe1), "sendrecv");
g_signal_connect (webrtc1, "on-ice-candidate", G_CALLBACK (send_ice_candidate_message), NULL);
gst_element_set_state (pipe1, GST_STATE_READY);
gst_object_unref (webrtc1);
```
Does anyone know why the generated answer is RECVONLY whereas the offer is already RECVONLY?
This might be related with #900.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/595Independent playable files2023-06-01T10:50:09ZKasper Steensig JensenIndependent playable filesSo, multifilesink is able to create multiple files but not able to play each of them.
It would be nice if multifilesink could do this.
multifilesink is nice because it can save multiple video streams to a file, unlike splitmuxsink.
split...So, multifilesink is able to create multiple files but not able to play each of them.
It would be nice if multifilesink could do this.
multifilesink is nice because it can save multiple video streams to a file, unlike splitmuxsink.
splitmuxsink can create independent playable files, but only with a single video stream.
I propose that it should be possible to create individual playable chunks with multiple video streams at once.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/594v4l2src: pts of the first frame is not correct2020-11-10T04:16:17ZDanila Yandushkinv4l2src: pts of the first frame is not correctHi,
I'm running the pipeline: gst-launch-1.0 -e v4l2src ! x264enc ! matroskamux ! filesink location=dump.mkv
with this camera: https://www.logitech.com/en-roeu/product/brio-stream-4k-hd-webcam. I'm capturing the video stream from th...Hi,
I'm running the pipeline: gst-launch-1.0 -e v4l2src ! x264enc ! matroskamux ! filesink location=dump.mkv
with this camera: https://www.logitech.com/en-roeu/product/brio-stream-4k-hd-webcam. I'm capturing the video stream from the camera, encoding and muxing it to a file. The camera captures with 30fps. The pts of the first frame is not always correct (approximately 1 out of 5-15 times):
The video file is the camera capture of the timer: https://www.timeanddate.com/stopwatch/
the PTS of the first 3 frames are:
v4l2src0:src pts: 961ms (961354643 ns)
v4l2src0:src pts: 1185ms (1185390192 ns)
v4l2src0:src pts: 1209ms (1209376552 ns)
but according to the video file the diff between the first and the second frame is 25ms.
Is it expected behavior of the v4l2src element or is it a bug?
The video file and logs attached.
[dump.mkv](/uploads/46711a0d8a964f965aa493926bd53ffb/dump.mkv)
[logs.txt](/uploads/ee0808480ec84701ba60bf5dfb5bfaa0/logs.txt)https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg/-/issues/8Generated header dependency issue with ffversion.h and ffprobe tool2021-04-09T11:30:12ZTim-Philipp Müllertim@centricular.comGenerated header dependency issue with ffversion.h and ffprobe toolJob [#259609](https://gitlab.freedesktop.org/tpm/ffmpeg/-/jobs/259609) failed for tpm/ffmpeg@eb84cba21d64a6ee297a964d42c4239ca4582d3f:
```
[59/1980] Compiling C object 'ffprobe@exe/fftools_ffprobe.c.o'.
FAILED: ffprobe@exe/fftools_ffprob...Job [#259609](https://gitlab.freedesktop.org/tpm/ffmpeg/-/jobs/259609) failed for tpm/ffmpeg@eb84cba21d64a6ee297a964d42c4239ca4582d3f:
```
[59/1980] Compiling C object 'ffprobe@exe/fftools_ffprobe.c.o'.
FAILED: ffprobe@exe/fftools_ffprobe.c.o
cc -Iffprobe@exe -I. -I../ -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O2 -g -D_ISOC99_SOURCE -D_GNU_SOURCE -D_LARGEFILE_SOURCE -DPIC -Wno-parentheses -Wno-pointer-sign -Wno-switch -Wno-format-truncation -Wno-deprecated-declarations -Wno-unused-function -Wno-maybe-uninitialized -Wno-discarded-qualifiers -Wno-unused-variable -Wno-bool-operation -Wno-incompatible-pointer-types -Wno-address -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -pthread -MD -MQ 'ffprobe@exe/fftools_ffprobe.c.o' -MF 'ffprobe@exe/fftools_ffprobe.c.o.d' -o 'ffprobe@exe/fftools_ffprobe.c.o' -c ../fftools/ffprobe.c
../fftools/ffprobe.c:27:10: fatal error: libavutil/ffversion.h: No such file or directory
#include "libavutil/ffversion.h"
^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
```
Works on retry.https://gitlab.freedesktop.org/gstreamer/orc/-/issues/19altivec backend broken on ppc64le2024-01-26T09:26:17ZDaniel Kolesaaltivec backend broken on ppc64leI came across this after the most recent release was merged in my distro, when something calls into orc with the altivec support enabled, it crashes with something like this:
```
Thread 65 "task3" received signal SIGILL, Illegal instruc...I came across this after the most recent release was merged in my distro, when something calls into orc with the altivec support enabled, it crashes with something like this:
```
Thread 65 "task3" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7ffeab7ef070 (LWP 80434)]
0x00007fff54560004 in ?? ()
(gdb) bt
#0 0x00007fff54560004 in ()
#1 0x00007fff9001583c in orc_memset (d1=0x7ffe9c037800, p1=<optimized out>, n=<optimized out>) at ../orc/orcfunctions.c:321
#2 0x00007fff901b4270 in gst_audio_format_fill_silence () at /usr/lib/libgstaudio-1.0.so.0
#3 0x00007fff901cd2c8 in gst_audio_ring_buffer_acquire () at /usr/lib/libgstaudio-1.0.so.0
```
This is on POWER8 little endian.0.4.30https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/593Direct show video source plugin2019-04-24T10:27:39ZDmitry AdzhievDirect show video source pluginNow I working on Android Emulator camera support and customer wants to use anything which is supported as input source by direct show.
I saw ds plugin for gstreamer but it depends from base classes and they are unavailable in SDK for Win...Now I working on Android Emulator camera support and customer wants to use anything which is supported as input source by direct show.
I saw ds plugin for gstreamer but it depends from base classes and they are unavailable in SDK for Windows 10.
So currently I use ds and ffmpeg but I want to switch code to gstreamer. For this I need this plugin.
If you will approve this plugin I'll implement this and contribute gstreamer.
The idea is:
Create plugin which enumerates video input devices list and store their number in property for example "devices-number". Next user able to get property and just get device name by reading property "device-name" by index. So device may be selected by index. For example property "source". And when plugin is in playing state plugin just reads data from video dev and send frames to next plugin.
Please let me know.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/383can't build gstreamer, gstenumtypes.h missing but required in gst.h2022-03-04T20:24:46ZA. Binzxxxxxxcan't build gstreamer, gstenumtypes.h missing but required in gst.hhow does your integration build it?
gstenumtypes.h is missing but required in gst.hhow does your integration build it?
gstenumtypes.h is missing but required in gst.h