GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T12:23:30Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/300Segfault in Intel video with all versions since somewhere after 1.14.42021-09-24T12:23:30ZAndré KjellstrupSegfault in Intel video with all versions since somewhere after 1.14.4Please see another great open project:
https://github.com/mavlink/qgroundcontrol/issues/9258#issuecomment-756635470
In short: gstreamer fails badly on Intel video using this application.Please see another great open project:
https://github.com/mavlink/qgroundcontrol/issues/9258#issuecomment-756635470
In short: gstreamer fails badly on Intel video using this application.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1964Segfault when GStreamer deinitalizes2023-02-26T15:32:47ZAlexandru BăluțSegfault when GStreamer deinitalizesWe have a Python3 unittest using GES and the unittest suceeds, prints "OK", but the process segfaults, see the attached `t a a bt`
```
(gdb) bt
#0 0x00007f5bb99bc6c6 in gst_transcoder_adjust_wait_time (sync_clock=<optimized out>, time=...We have a Python3 unittest using GES and the unittest suceeds, prints "OK", but the process segfaults, see the attached `t a a bt`
```
(gdb) bt
#0 0x00007f5bb99bc6c6 in gst_transcoder_adjust_wait_time (sync_clock=<optimized out>, time=<optimized out>, id=<optimized out>, self=0x55da5164c160) at ../subprojects/gst-plugins-bad/gst/transcode/gst-cpu-throttling-clock.c:97
#1 0x00007f5bfcf726b7 in gst_system_clock_async_thread (clock=0x55da520f5170) at ../subprojects/gstreamer/gst/gstsystemclock.c:847
#2 0x00007f5c011b3b49 in g_thread_proxy () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f5c0188f1da in start_thread () at /usr/lib/x86_64-linux-gnu/libc.so.6
#4 0x00007f5c01917f44 in clone () at /usr/lib/x86_64-linux-gnu/libc.so.6
```
[taabt.log](/uploads/95430dae382ca78f42841edfbbfe9121/taabt.log)https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/136segfault when reusing a Bin in RTSPMediaFactory2021-09-24T11:03:31ZMinijacksonsegfault when reusing a Bin in RTSPMediaFactoryHello and thank you for this awesome library!
I think I have a reproducible segmentation fault when misusing `RTSPMediaFactory` in a subclass. I'm not very knowledgable in GStreamer, but I think the misuse comes from reusing a previousl...Hello and thank you for this awesome library!
I think I have a reproducible segmentation fault when misusing `RTSPMediaFactory` in a subclass. I'm not very knowledgable in GStreamer, but I think the misuse comes from reusing a previously "consumed" `gst::Bin` by returning it from `RTSPMediaFactoryImpl::create_element`. Here is the code to reproduce it, adapted from the RTSP with subclass example:
<details>
<summary>Rust code</summary>
```rust
use gst::glib;
use gstreamer as gst;
use gstreamer_rtsp as gst_rtsp;
use gstreamer_rtsp_server as gst_rtsp_server;
use gst::prelude::*;
use gst_rtsp_server::prelude::*;
// Create the bin before the call to `create_element`
fn precreate_bin() -> gst::Bin {
let bin = gst::Bin::new(None);
let src = gst::ElementFactory::make("videotestsrc", None).unwrap();
let enc = gst::ElementFactory::make("vp8enc", None).unwrap();
let pay = gst::ElementFactory::make("rtpvp8pay", Some("pay0")).unwrap();
src.set_property("is-live", &true).unwrap();
enc.set_property("deadline", &1i64).unwrap();
bin.add_many(&[&src, &enc, &pay]).unwrap();
gst::Element::link_many(&[&src, &enc, &pay]).unwrap();
bin
}
fn main() {
gst::init().unwrap();
let main_loop = glib::MainLoop::new(None, false);
let server = gst_rtsp_server::RTSPServer::new();
let mounts = server.get_mount_points().unwrap();
let factory = media_factory::Factory::default();
mounts.add_factory("/test", &factory);
let id = server.attach(None).unwrap();
println!(
"Stream ready at rtsp://127.0.0.1:{}/test",
server.get_bound_port()
);
main_loop.run();
glib::source_remove(id);
}
mod media_factory {
use super::*;
use gst_rtsp_server::subclass::prelude::*;
mod imp {
use super::*;
pub struct Factory {
precreated_bin: gst::Bin,
}
impl Default for Factory {
fn default() -> Self {
Factory {
// Store the Bin so it can be reused
precreated_bin: precreate_bin(),
}
}
}
#[glib::object_subclass]
impl ObjectSubclass for Factory {
const NAME: &'static str = "RsRTSPMediaFactory";
type Type = super::Factory;
type ParentType = gst_rtsp_server::RTSPMediaFactory;
}
impl ObjectImpl for Factory {}
impl RTSPMediaFactoryImpl for Factory {
fn create_element(
&self,
_factory: &Self::Type,
_url: &gst_rtsp::RTSPUrl,
) -> Option<gst::Element> {
// Provide our stored bin
// From my understanding, `clone` doesn't
// actually clone the object, but shares ownership
Some(self.precreated_bin.clone().upcast())
}
}
}
glib::wrapper! {
pub struct Factory(ObjectSubclass<imp::Factory>) @extends gst_rtsp_server::RTSPMediaFactory;
}
impl Default for Factory {
fn default() -> Factory {
glib::Object::new(&[]).expect("Failed to create factory")
}
}
}
```
</details>
To reproduce the segfault, simply open the stream `rtsp://localhost:8554/test`, close it, and open it again.
<details>
<summary>Terminal output</summary>
```
Stream ready at rtsp://127.0.0.1:8554/test
(bla:32039): GStreamer-CRITICAL **: 14:41:59.939: gst_ghost_pad_new: assertion '!gst_pad_is_linked (target)' failed
(bla:32039): GStreamer-CRITICAL **: 14:41:59.939: gst_pad_set_active: assertion 'GST_IS_PAD (pad)' failed
(bla:32039): GStreamer-CRITICAL **: 14:41:59.939: gst_element_add_pad: assertion 'GST_IS_PAD (pad)' failed
** (bla:32039): CRITICAL **: 14:41:59.939: gst_rtsp_stream_new: assertion 'GST_IS_PAD (pad)' failed
** (bla:32039): CRITICAL **: 14:41:59.939: gst_rtsp_stream_set_multicast_iface: assertion 'GST_IS_RTSP_STREAM (stream)' failed
** (bla:32039): CRITICAL **: 14:41:59.939: gst_rtsp_stream_set_max_mcast_ttl: assertion 'GST_IS_RTSP_STREAM (stream)' failed
** (bla:32039): CRITICAL **: 14:41:59.939: gst_rtsp_stream_set_bind_mcast_address: assertion 'GST_IS_RTSP_STREAM (stream)' failed
** (bla:32039): CRITICAL **: 14:41:59.939: gst_rtsp_stream_set_profiles: assertion 'GST_IS_RTSP_STREAM (stream)' failed
** (bla:32039): CRITICAL **: 14:41:59.939: gst_rtsp_stream_set_protocols: assertion 'GST_IS_RTSP_STREAM (stream)' failed
[1] 32039 segmentation fault (core dumped) cargo run
```
</details>
<details>
<summary>Backtrace</summary>
```
#0 0x00007fcb1af7353d in gst_rtsp_stream_set_retransmission_time () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#1 0x00007fcb1af5dad8 in gst_rtsp_media_create_stream () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#2 0x00007fcb1af5e215 in gst_rtsp_media_collect_streams () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#3 0x00007fcb1af64106 in default_construct () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#4 0x000055ea43028109 in <T as gstreamer_rtsp_server::subclass::rtsp_media_factory::RTSPMediaFactoryImplExt>::parent_construct::{{closure}} (
f=0x7fcb1af64090 <default_construct>)
at /home/minijackson/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/cd3d114/gstreamer-rtsp-server/src/subclass/rtsp_media_factory.rs:141
#5 0x000055ea43026367 in core::option::Option<T>::map (self=..., f=...)
at /home/minijackson/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:453
#6 0x000055ea43029a76 in <T as gstreamer_rtsp_server::subclass::rtsp_media_factory::RTSPMediaFactoryImplExt>::parent_construct (self=0x55ea438b70c0, factory=0x7fcb0ae397a8,
url=0x7fcb0ae397b8) at /home/minijackson/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/cd3d114/gstreamer-rtsp-server/src/subclass/rtsp_media_factory.rs:138
#7 0x000055ea43029648 in gstreamer_rtsp_server::subclass::rtsp_media_factory::RTSPMediaFactoryImpl::construct (self=0x55ea438b70c0, factory=0x7fcb0ae397a8, url=0x7fcb0ae397b8)
at /home/minijackson/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/cd3d114/gstreamer-rtsp-server/src/subclass/rtsp_media_factory.rs:25
#8 0x000055ea43027bd9 in gstreamer_rtsp_server::subclass::rtsp_media_factory::factory_construct (ptr=0x55ea438b7190, url=0x7fcb00009690)
at /home/minijackson/.cargo/git/checkouts/gstreamer-rs-79e52a2d27eb91a3/cd3d114/gstreamer-rtsp-server/src/subclass/rtsp_media_factory.rs:287
#9 0x00007fcb1af63afc in gst_rtsp_media_factory_construct () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#10 0x00007fcb1af5015a in find_media () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#11 0x00007fcb1af53111 in handle_request () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#12 0x00007fcb1af568bb in gst_rtsp_client_handle_message () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#13 0x00007fcb1aa878cf in gst_rtsp_source_dispatch_read () from /nix/store/...-gst-plugins-base-1.16.2/lib/libgstrtsp-1.0.so.0
#14 0x00007fcb1acb833e in g_main_context_dispatch () from /nix/store/...-glib-2.64.6/lib/libglib-2.0.so.0
#15 0x00007fcb1acb86f0 in g_main_context_iterate.isra () from /nix/store/...-glib-2.64.6/lib/libglib-2.0.so.0
#16 0x00007fcb1acb89c3 in g_main_loop_run () from /nix/store/...-glib-2.64.6/lib/libglib-2.0.so.0
#17 0x00007fcb1af799cf in do_loop () from /nix/store/...-gst-rtsp-server-1.16.2/lib/libgstrtspserver-1.0.so.0
#18 0x00007fcb1ace1c54 in g_thread_pool_thread_proxy () from /nix/store/...-glib-2.64.6/lib/libglib-2.0.so.0
#19 0x00007fcb1ace13ed in g_thread_proxy () from /nix/store/...-glib-2.64.6/lib/libglib-2.0.so.0
#20 0x00007fcb1aa3cead in start_thread () from /nix/store/...-glibc-2.31-74/lib/libpthread.so.0
#21 0x00007fcb1a825caf in clone () from /nix/store/...-glibc-2.31-74/lib/libc.so.6
```
</details>https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/576segfault with gst_rtsp_connection_flush function during cleanup2021-09-24T13:24:58Zsilambarasansegfault with gst_rtsp_connection_flush function during cleanupwe stream multiple cameras( have around 32 cameras) and at a time the browser will display videos of 16 cameras(thumbnail view). we have the UI designed to switch the camera views. if user tries to switch, current plugin instance for the...we stream multiple cameras( have around 32 cameras) and at a time the browser will display videos of 16 cameras(thumbnail view). we have the UI designed to switch the camera views. if user tries to switch, current plugin instance for the viewing camera will get stopped and new instance gets created for next camera about to view. in this scenario we have a segfault in rtsp cleanup code.
could you please help us to find the cause of an issue.
Gstreamer version we use - 1.12.4
Below is the call stack for the crash:
```
[Switching to Thread 0x7f7e7acf4700 (LWP 17845)]
0x00007f7e89c9f4ad in gst_rtsp_connection_flush (conn=0xe5e5e5e5e5e5e5e5, flush=1) at gstrtspconnection.c:2552
2552 gstrtspconnection.c: No such file or directory.
(gdb) where
#0 0x00007f7e89c9f4ad in gst_rtsp_connection_flush (conn=0xe5e5e5e5e5e5e5e5, flush=1) at gstrtspconnection.c:2552
#1 0x00007f7e8a0e737c in gst_rtspsrc_connection_flush (src=0x7f7e0ea15820, flush=1) at gstrtspsrc.c:4271
#2 0x00007f7e8a0eb0a1 in gst_rtspsrc_loop_send_cmd (src=0x7f7e0ea15820, cmd=16, mask=127) at gstrtspsrc.c:5111
#3 0x00007f7e8a0f4749 in gst_rtspsrc_stop (src=0x7f7e0ea15820) at gstrtspsrc.c:7706
#4 0x00007f7e8a0f49ec in gst_rtspsrc_change_state (element=0x7f7e0ea15820, transition=GST_STATE_CHANGE_READY_TO_NULL) at gstrtspsrc.c:7798
#5 0x00007f7e923e055e in gst_element_change_state (element=0x7f7e0ea15820, transition=GST_STATE_CHANGE_READY_TO_NULL) at gstelement.c:2743
#6 0x00007f7e923e02ee in gst_element_set_state_func (element=0x7f7e0ea15820, state=GST_STATE_NULL) at gstelement.c:2697
#7 0x00007f7e923dfeea in gst_element_set_state (element=0x7f7e0ea15820, state=GST_STATE_NULL) at gstelement.c:2598
#8 0x00007f7e923af31e in gst_bin_element_set_state (bin=0x7f7e200422f0, element=0x7f7e0ea15820, base_time=3360335884438, start_time=0, current=GST_STATE_READY, next=GST_STATE_NULL) at gstbin.c:2595
#9 0x00007f7e923b09ab in gst_bin_change_state_func (element=0x7f7e200422f0, transition=GST_STATE_CHANGE_READY_TO_NULL) at gstbin.c:2937
#10 0x00007f7e924114e6 in gst_pipeline_change_state (element=0x7f7e200422f0, transition=GST_STATE_CHANGE_READY_TO_NULL) at gstpipeline.c:500
#11 0x00007f7e923e055e in gst_element_change_state (element=0x7f7e200422f0, transition=GST_STATE_CHANGE_READY_TO_NULL) at gstelement.c:2743
#12 0x00007f7e923dfaab in gst_element_continue_state (element=0x7f7e200422f0, ret=GST_STATE_CHANGE_SUCCESS) at gstelement.c:2451
#13 0x00007f7e923e08da in gst_element_change_state (element=0x7f7e200422f0, transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstelement.c:2782
#14 0x00007f7e923dfaab in gst_element_continue_state (element=0x7f7e200422f0, ret=GST_STATE_CHANGE_NO_PREROLL) at gstelement.c:2451
#15 0x00007f7e923e0945 in gst_element_change_state (element=0x7f7e200422f0, transition=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at gstelement.c:2789
#16 0x00007f7e923e02ee in gst_element_set_state_func (element=0x7f7e200422f0, state=GST_STATE_NULL) at gstelement.c:2697
#17 0x00007f7e923dfeea in gst_element_set_state (element=0x7f7e200422f0, state=GST_STATE_NULL) at gstelement.c:2598
#18 0x00007f7e92708604 in CM_pluginAPI::play() () from target:/usr/lib/mozilla/plugins/npCM_plugin.so
#19 0x00007f7e927093e2 in CM_pluginAPI::startThread(void*) () from target:/usr/lib/mozilla/plugins/npCM_plugin.so
#20 0x00007f7ea4c366db in start_thread (arg=0x7f7e7acf4700) at pthread_create.c:463
#21 0x00007f7e9ea0388f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
(edited stack trace for readability)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2421Segmentation fault in QtGLVideoItem::onSceneGraphInitialized (ext/qt/qtitem.c...2024-02-29T13:21:18ZVincas DargisSegmentation fault in QtGLVideoItem::onSceneGraphInitialized (ext/qt/qtitem.cc:695)I'm migrating from QtMultimedia to GstGLVideoItem. Using 1.22.1 on Debian 11 amd64.
I sometimes get this crash while, it seems, QML scene is being initialized?
```
#0 QtGLVideoItem::onSceneGraphInitialized (this=0x555ce25e29e0) at ../...I'm migrating from QtMultimedia to GstGLVideoItem. Using 1.22.1 on Debian 11 amd64.
I sometimes get this crash while, it seems, QML scene is being initialized?
```
#0 QtGLVideoItem::onSceneGraphInitialized (this=0x555ce25e29e0) at ../source_subfolder/ext/qt/qtitem.cc:695
#1 0x00007f2120d22ad9 in std::__invoke_impl<void, void (QtGLVideoItem::*&)(), QtGLVideoItem*&> (__f=@0x555ce24d3ec0: (void (QtGLVideoItem::*)(QtGLVideoItem * const)) 0x7f2120d20356 <QtGLVideoItem::onSceneGraphInitialized()>, __t=@0x555ce24d3ed0: 0x555ce25e29e0)
at /usr/include/c++/10/bits/invoke.h:73
#2 0x00007f2120d22a35 in std::__invoke<void (QtGLVideoItem::*&)(), QtGLVideoItem*&> (__fn=@0x555ce24d3ec0: (void (QtGLVideoItem::*)(QtGLVideoItem * const)) 0x7f2120d20356 <QtGLVideoItem::onSceneGraphInitialized()>) at /usr/include/c++/10/bits/invoke.h:95
#3 0x00007f2120d229be in std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0x555ce24d3ec0, __args=...) at /usr/include/c++/10/functional:416
#4 0x00007f2120d22950 in std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>::operator()<, void>() (this=0x555ce24d3ec0) at /usr/include/c++/10/functional:499
#5 0x00007f2120d2289c in std::__invoke_impl<void, std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>&>(std::__invoke_other, std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>&) (__f=...) at /usr/include/c++/10/bits/invoke.h:60
#6 0x00007f2120d22709 in std::__invoke_r<void, std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>&>(std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()>&) (__fn=...) at /usr/include/c++/10/bits/invoke.h:153
#7 0x00007f2120d22485 in std::_Function_handler<void (), std::_Bind<void (QtGLVideoItem::*(QtGLVideoItem*))()> >::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/10/bits/std_function.h:291
#8 0x00007f2120d21eb0 in std::function<void ()>::operator()() const (this=0x555ce3720c80) at /usr/include/c++/10/bits/std_function.h:622
#9 0x00007f2120d21c26 in RenderJob::run (this=0x555ce3720c70) at ../source_subfolder/ext/qt/gstqtglutility.h:37
#10 0x00007f2128ce6871 in QQuickWindowPrivate::runAndClearJobs(QList<QRunnable*>*) () from /home/user/myapp/lib/libQt5Quick.so.5
#11 0x00007f2128ce762a in QQuickWindowPrivate::syncSceneGraph() () from /home/user/myapp/lib/libQt5Quick.so.5
#12 0x00007f2128c8c5f5 in QSGRenderThread::sync(bool, bool) () from /home/user/myapp/lib/libQt5Quick.so.5
#13 0x00007f2128c8ea31 in QSGRenderThread::syncAndRender(QImage*) () from /home/user/myapp/lib/libQt5Quick.so.5
#14 0x00007f2128c9238b in QSGRenderThread::run() () from /home/user/myapp/lib/libQt5Quick.so.5
#15 0x00007f212633545d in QThreadPrivate::start(void*) () from /home/user/myapp/lib/libQt5Core.so.5
#16 0x00007f2128268ea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#17 0x00007f2125e7ba2f in clone () from /lib/x86_64-linux-gnu/libc.so.6
```
It happens here:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/3ab8a0bc3ef642f01fe7152cf08bb06d21419677/subprojects/gst-plugins-good/ext/qt/qtitem.cc#L695
But if I raise GST_DEBUG level, I get crash earlier, on the attempt to log message:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/3ab8a0bc3ef642f01fe7152cf08bb06d21419677/subprojects/gst-plugins-good/ext/qt/qtitem.cc#L692
So I assume that it's bug because case when `this->window()->openglContext()` is null is not handled?
This reproduces easily in our complex QML application (it's SwipeView with Repeater and Loaders...) on "weaker" Celeron-based machine, and rarer on i7 one. So I guess it's sort of race condition?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/278segment: Change back gst_segment_do_seek() to use gint642021-09-24T11:09:34ZBugzilla Migration Usersegment: Change back gst_segment_do_seek() to use gint64## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#794215)](https://bugzilla.gnome.org/show_bug.cgi?id=794215)**
## Description
During 0.11 dev at commit bdbc069348 the gst_segment_do_seek() was changed to accep...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#794215)](https://bugzilla.gnome.org/show_bug.cgi?id=794215)**
## Description
During 0.11 dev at commit bdbc069348 the gst_segment_do_seek() was changed to accept only unsigned start/stop. Though, the code will do direct comparision with -1 and also assumes negative values for GST_SEEK_TYPE_END:
start = segment->duration + start;
Additionally, the gst_event_new_seek() API along with the GstElement API uses signed integer. Demuxers will pass these value unchecked to that API in order to update their segment. Looking at the code, it will properly wrap around resulting in the same behaviour, but it's all a bit of a lie. As this does not affect the API, I think it's fine to switch it back to gint64.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/133segment: Make times signed and a fraction, and never return NONE for time con...2022-11-10T09:20:46ZBugzilla Migration Usersegment: Make times signed and a fraction, and never return NONE for time conversions for out-of-segment values## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757021)](https://bugzilla.gnome.org/show_bug.cgi?id=757021)**
## Description
+++ This bug was initially created as a clone of [Bug 756564](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#757021)](https://bugzilla.gnome.org/show_bug.cgi?id=757021)**
## Description
+++ This bug was initially created as a clone of [Bug 756564](https://bugzilla.gnome.org/show_bug.cgi?id=756564) +++
+++ This bug was initially created as a clone of [Bug 748316](https://bugzilla.gnome.org/show_bug.cgi?id=748316) +++
For 2.0, we should make the times signed and always return a value in those functions even if they are out of segment. gst_segment_to_running_time_full() already does this, but the same is needed in general for other situations too.
While at that, we should also reconsider making all times into a fraction.
Version: 2.xhttps://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/18SEND_ONLY RECV_ONLY with Janus Gateway VideoRoom2022-04-03T19:26:30ZmartinangelSEND_ONLY RECV_ONLY with Janus Gateway VideoRoomHi all,
As the repository from centricular has been moved here, I am moving this [issue](https://github.com/centricular/gstwebrtc-demos/issues/205) here. As I think that it is an interesting feature for the Gstreamer community.
I have ...Hi all,
As the repository from centricular has been moved here, I am moving this [issue](https://github.com/centricular/gstwebrtc-demos/issues/205) here. As I think that it is an interesting feature for the Gstreamer community.
I have been modifying sendrecv sample code to work with Janus Gateway Video Room.
Specifically, I have a Sender which sends Video and a Receiver joining/subscribing to the peerId available at the video room.
_Sender (sendonly) <-> Janus Gateway <-> Receiver (receiveonly)_
Essentially:
- I am developing the applications on top of Gstreamer v1.18 and Ubuntu 18.04.
- I have turned the soup calls to libwebsockets messages to the Janus API.
- I have kept sendrecv sample code for the Sender declaring SendOnly for the WebRtcBin transceivers.
- I have slightly changed the sendrecv sample code to wait until a peerID is on the videoroom to join/subscribe it for the Receiver declaring RecvOnly for the WebRtcBin transceivers.
- In any case, the SDP offers and answers from/to both peers and the ICE candidates are exchanged.
I can see the video and audio stream played at the VideoRoom website from Janus. So the Sender is working ok.
But the Receiver does not receive any stream from Janus. And no errors are coming from the Gstreamer logs.
SDP offer and answer and ICE candidates are exchanged.
After the ICE candidates are sent from the Receiver to Janus and ACKs are reported, the WebrtcUp message (as it happens at the WebBrowser player available in the VideoRoom sample when the streams run) is never received by the Receiver.
So it looks like no streams are being sent from Janus to the GSt-based Receiver.
_Samples provided by this repository are helpful and mean a great work. But my feeling is that they are designed to peer a Web-browser-based player/peer. As they communicate with another Gst-based peer, problems come into place._
There is a Janus videoroom example in the janus/subdirectory that does bi-directional media. It's in python rather than C, but it has provided some guidance to get signalling with Janus working.
Janus sends ICE candidates to the Receiver, before sending the SDP offer and before the WebRtcBin state is Playing.
```
# Extract ICE candidates from the SDP to work around a GStreamer
# limitation in (at least) 1.16.2 and below
self.extract_ice_from_sdp (sdp)
```
So, I have stored them and emit('add-ice-candidate' once SDP offer has been input to the WebRtcBin g_signal_emit_by_name(webrtc1, "set-remote-description", offer, promise);
Now I receive from Janus the webrtcup message, but nothing else happens. No streams are received. DtlsStrpDemux does not receive anything after the PEMs are exchanged and SSL handshake has been performed.
In the logs of Janus I can see in response to the recvonly:
```
[2684131696657477] The DTLS handshake has been completed [2684131696657477] Telling the plugin about it (JANUS VideoRoom plugin) [janus.plugin.videoroom-0x7faabc0065c0] WebRTC media is now available
```
The same way Janus answers to the sendonly.
I am uploading the code in the case you want to debug with your own Janus VideoRoom.
[webrtcTXRX.zip](/uploads/2345350fa36e144431afc81e052745c8/webrtcTXRX.zip)
Once compiled you run them by:
**Transmitter SENDONLY H264**
_TXid is peer-id_
`GST_DEBUG=3,webrtc*:5,dtls*:5 ./webrtcTXjanus --peer-id=1001 --server=127.0.0.1 --janus-port=8188 --room=1234 --token= --display-id=2002`
**Transmitter RECVONLY H264**
_RXid is display-id (looking for peer-id in the videoroom to request its stream)_
`GST_DEBUG=3,webrtc*:5,dtls*:5 ./webrtcRXjanus --peer-id=1001 --server=127.0.0.1 --janus-port=8188 --room=1234 --token= --display-id=2002`
The pipeline is TX Video 1001 -> Janus -> RX Video 2002.
The video comes from the TX to Janus, and the signalling and GST logs are OK from Janus to RX but on Wireshark I do not see any UDP packet from Janus to RX.
By the way, my conclusion is that bundle:max-compat and remove data channel make Janus to send webrtcup message, otherwise, ICE problems comes or other signaling messages never come from Janus.
After checking the logs (GST_DEBUG=3,webrtc*:5,dtls*:5,srtp*:5,rtp*:5,ice*:5), I think that, as python code underlines, there is a problem with the timing of ICE candidates.
In rx.txt [rx.txt](/uploads/8169ae75280b1c47389c82ec81b6ce90/rx.txt) you see the logs of a working receive_only GST App using the simple_server.py with room.
ICE candidates are sent and after the exchange of Keys and Certificates comes.
Then, srtpdec and rtpsession start to run. (~line 337)
In rxjanus.txt [rxjanus.txt](/uploads/ba11dca5eab859dd874749a60eda2a26/rxjanus.txt) you will see that everything is invoked the same way, but the slow and distant in time sending of ICE candidates makes that after the Keys and Certificates comes, new ICE candidates are sent and the Caps of srtpdec are never received and rtpsession receiving a stream never happens. (~line 728)
I do not know if the asynchronous sending of ICE candidates from receive_only Gst app to Janus, making Janus receiveing some extra candidates once everything is connected and established make that no stream is sent.
Thank you in advance.
Any hint?
Best,
Angelhttps://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/17SendRecv example: Received video is distorted2021-09-24T22:43:55ZGhost UserSendRecv example: Received video is distortedI ran the sendrecv example as is but the video stream returned is really distorted. See image and video file below.
Other examples worked well.
![Screenshot__30_a](/uploads/c4b5955e6d5f56e7cbf9d177c37949df/Screenshot__30_a.png)
![Dir...I ran the sendrecv example as is but the video stream returned is really distorted. See image and video file below.
Other examples worked well.
![Screenshot__30_a](/uploads/c4b5955e6d5f56e7cbf9d177c37949df/Screenshot__30_a.png)
![Direct3D11_renderer_2020-10-02_14-58-01](/uploads/2f8b5d628a5f7822b241c99adad68728/Direct3D11_renderer_2020-10-02_14-58-01.mp4)
What could have been the problem please?
Thanks.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/458serializing caps with one empty structure2021-09-24T11:09:02ZHenry Wilkesserializing caps with one empty structureThis is only a small niche issue:
if a `GstCaps *caps` contains a single *empty* `GstStructure *str` with no features, and the name `ANY`, then `gst_caps_to_string (caps)` will produce the string `ANY`. When this is read in by `gst_caps_...This is only a small niche issue:
if a `GstCaps *caps` contains a single *empty* `GstStructure *str` with no features, and the name `ANY`, then `gst_caps_to_string (caps)` will produce the string `ANY`. When this is read in by `gst_caps_from_string`, rather than recreating the original structure, it will create an any caps!
Similarly, if `str` was named `EMPTY` or `NONE`, then it would create an empty caps.
Maybe, in these three special cases, the caps should be serialized to `ANY;`, `EMPTY;` and `NONE;`, or some other way to distinguish them?https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/19Servers not supporting the RECORD command should not announce it in OPTIONS r...2021-09-24T11:03:54ZBugzilla Migration UserServers not supporting the RECORD command should not announce it in OPTIONS responses## Submitted by Branko Subasic
**[Link to original bug (#761123)](https://bugzilla.gnome.org/show_bug.cgi?id=761123)**
## Description
Currently the implementation of handle_options_request() in rtsp-client.c will unconditionally inc...## Submitted by Branko Subasic
**[Link to original bug (#761123)](https://bugzilla.gnome.org/show_bug.cgi?id=761123)**
## Description
Currently the implementation of handle_options_request() in rtsp-client.c will unconditionally include the RECORD and ANNOUNCE commands in the reply. But a server that does not support these commands does not want to announce them either. I think that it should be configurable whether they should be announced or not.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/245Set cabac as default entropy coder for h264.2021-09-24T12:23:23ZXu GuangxinSet cabac as default entropy coder for h264.Currently, we use CAVLC as the [default ](https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/blob/master/gst-libs/gst/vaapi/gstvaapiencoder_h264.c#L3905) entropy coder.
The CAVLC has 17% bdrate loss compare to CABAC in some typi...Currently, we use CAVLC as the [default ](https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/blob/master/gst-libs/gst/vaapi/gstvaapiencoder_h264.c#L3905) entropy coder.
The CAVLC has 17% bdrate loss compare to CABAC in some typical streams. ffmpeg vaapi already uses CABAC as the [default ](https://github.com/FFmpeg/FFmpeg/blob/20fed2f0ab197d60801280dfc844f6b29a397ff2/libavcodec/vaapi_encode_h264.c#L1263)coder.
Could we change the default to CABAC? or we can add an auto mode, let vaapi encoder choose the best coder type based on encoder profile.
thankshttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/980Set NULL state to queue results in deadlock2022-03-02T06:30:43ZMatteo FoglioSet NULL state to queue results in deadlockI am working on the attached pipeline created using the Python interface for Gstreamer. The pipeline uses some plugins from Nvidia Deepstream, but I believe the issue I am having in unrelated.
In brief: the pipeline ingests some rtsp v...I am working on the attached pipeline created using the Python interface for Gstreamer. The pipeline uses some plugins from Nvidia Deepstream, but I believe the issue I am having in unrelated.
In brief: the pipeline ingests some rtsp video streams, put them into a leaky queue, and then it sends the frames to some Deepstream custom plugins that will run some AI models on them (but I suspect Deepstream plugins are probably not important for this issue).
Sometime I need to stop processing a video frame. Therefore, I want to remove the elements in charge of processing the stream. Suppose I want to stop stream number `50` (first row in the pipeline attached). I'll start by setting its elements' state to `NULL`. What I do is the following:
- I set to `NULL` the state of the `GstBin` called `source-bin-50` (see pipeline). This bin contains the elements that decode the rtsp video stream.
- I set to `NULL` the state of the `queue` called `frame_queue_50`. The problem is that this sometime results in a deadlock during the the `set_state` function.
I read online that the issue could be caused by the queue still having some content and therefore not willing to move to `NULL` state. However, as of now, I haven't found a solution. Should I send any signal to the `queue`?
[pipeline.pdf](/uploads/c9cc089731f8ff3b1e478908a3b474a0/pipeline.pdf)https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/10Set profile on rtpsession as required2021-09-24T11:03:56ZBugzilla Migration UserSet profile on rtpsession as required## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#749630)](https://bugzilla.gnome.org/show_bug.cgi?id=749630)**
## Description
+++ This bug was initially created as a clone of [Bug 746543](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#749630)](https://bugzilla.gnome.org/show_bug.cgi?id=749630)**
## Description
+++ This bug was initially created as a clone of [Bug 746543](https://bugzilla.gnome.org/show_bug.cgi?id=746543) +++
Currently we don't check what profile a specific client requested in SETUP, but it would be beneficial to do that and then set that specific profile on the rtpsession.
Main problem here is that we have one rtpbin for multiple clients in case of shared media, which means that every client could in theory request a different profile.
What should be done about that?
### Depends on
* [Bug 746543](https://bugzilla.gnome.org/show_bug.cgi?id=746543)https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/192Set vaapih264dec latency according to DPB2021-09-24T12:23:20ZVíctor Manuel Jáquez LealSet vaapih264dec latency according to DPBThe internal decoder in the library sets a context with a surface pool with fixed size (which is related with https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/100) which is based in the dpb. The h264 decoder elemen...The internal decoder in the library sets a context with a surface pool with fixed size (which is related with https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/100) which is based in the dpb. The h264 decoder element should set its latency according the stream's dpb.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/28shapewipe, matroskademux, matroskaparse: post QoS messages when dropping buff...2021-09-24T13:29:50ZBugzilla Migration Usershapewipe, matroskademux, matroskaparse: post QoS messages when dropping buffers due to QoS## Submitted by Tim Müller `@tpm`
**[Link to original bug (#617022)](https://bugzilla.gnome.org/show_bug.cgi?id=617022)**
## Description
Subject says it all really. Should go through decoders that implement QoS and make them post Qo...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#617022)](https://bugzilla.gnome.org/show_bug.cgi?id=617022)**
## Description
Subject says it all really. Should go through decoders that implement QoS and make them post QoS messages on the bus when they drop stuff.
ext/dv/gstdvdemux.c: case GST_EVENT_QOS:
ext/jpeg/gstjpegdec.c: case GST_EVENT_QOS:{
gst/avi/gstavidemux.c: case GST_EVENT_QOS:
gst/deinterlace/gstdeinterlace.c: case GST_EVENT_QOS:{
gst/goom/gstgoom.c: case GST_EVENT_QOS:
gst/goom2k1/gstgoom.c: case GST_EVENT_QOS:
gst/interleave/interleave.c: case GST_EVENT_QOS:
gst/matroska/matroska-demux.c: case GST_EVENT_QOS:
gst/monoscope/gstmonoscope.c: case GST_EVENT_QOS:{
gst/qtdemux/qtdemux.c: case GST_EVENT_QOS:
gst/rtsp/gstrtspsrc.c: case GST_EVENT_QOS:
gst/rtsp/gstrtspsrc.c: case GST_EVENT_QOS:
gst/shapewipe/gstshapewipe.c: case GST_EVENT_QOS:{
gst/videomixer/videomixer.c: case GST_EVENT_QOS:{https://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/-/issues/1Shared Gst.Buffers make .Dispose() unusable2021-09-24T10:46:47ZBugzilla Migration UserShared Gst.Buffers make .Dispose() unusable## Submitted by Petteri Aimonen
**[Link to original bug (#677708)](https://bugzilla.gnome.org/show_bug.cgi?id=677708)**
## Description
GStreamer shares buffers between sinks to conserve memory. Gst-sharp returns the same managed obj...## Submitted by Petteri Aimonen
**[Link to original bug (#677708)](https://bugzilla.gnome.org/show_bug.cgi?id=677708)**
## Description
GStreamer shares buffers between sinks to conserve memory. Gst-sharp returns the same managed object when two sinks receive the buffer. If one sink disposes the object, the other sink gets NullReferenceException.
Obvious way to avoid this problem is not to call .Dispose(), and instead rely on garbage collection. However, this causes a lot of buffers to accumulate before GC kicks in. I measured 100 MB memory overhead on an otherwise 50 MB usage with a simple videotestsrc + appsink combination. With many streams and larger resolution/framerate it could be much worse.
(The same problem exists with shared Glib.Object references, but it is much less acute as they are not circulated as often as Gst.Buffers.)
There are two ways to fix this problem:
1) Make Gst.MiniObject not shared. This might have some implications if complex C# objects are built upon MiniObject, as there would be multiple managed instances referring a single unmanaged object. However, all the currently implemented MiniObject derivatives (Buffer, Event, Message, etc.) are simple wrappers with no managed data.
Implemented by this patch: http://code.google.com/p/ossbuild-vs2010/source/detail?r=cdcfefd5b9652a8910f0b27449cb5a7682aa69ce
2) Make Gst.MiniObject maintain a count of 'users', a bit like reference counting but not directly tied to the destruction of the underlying unmanaged object. This is less clean than 1, but on the other hand less intrusive.
Implemented by this patch: http://code.google.com/p/ossbuild-vs2010/source/detail?r=6ced992458f96e3b5bf8eb25d81a2ce8808081a9
I vote for 1).https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/62Share runtime between S3 plugins2019-08-05T13:34:59ZMarcin KolnyShare runtime between S3 pluginsBoth `s3sink` and `s3src` elements create their own `tokio::runtime::Runtime` to execute asynchronous networking operations. We should be able to share the runtime between those two plugins, so when they're used in one pipeline, only one...Both `s3sink` and `s3src` elements create their own `tokio::runtime::Runtime` to execute asynchronous networking operations. We should be able to share the runtime between those two plugins, so when they're used in one pipeline, only one runtime is created.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/915Sharpness property of videoscale element doesn't work2021-09-24T13:26:24ZAleksandr MuravjovSharpness property of videoscale element doesn't workWondered that sharpness doesn't work for a simple pipelines.
Gstreamer version - 1.18.4 as well as 1.14.5.
Pipelines:
```
gst-launch-1.0 videotestsrc ! videoscale sharpness=0.5 ! autovideosink
gst-launch-1.0 videotestsrc ! videoscale sha...Wondered that sharpness doesn't work for a simple pipelines.
Gstreamer version - 1.18.4 as well as 1.14.5.
Pipelines:
```
gst-launch-1.0 videotestsrc ! videoscale sharpness=0.5 ! autovideosink
gst-launch-1.0 videotestsrc ! videoscale sharpness=1 ! autovideosink
gst-launch-1.0 videotestsrc ! videoscale sharpness=1.5 ! autovideosink
```
produce the same image.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/93shm: Port shared memory plugin to Windows2023-05-23T18:03:57ZBugzilla Migration Usershm: Port shared memory plugin to Windows## Submitted by Joshua M. Doe
**[Link to original bug (#698657)](https://bugzilla.gnome.org/show_bug.cgi?id=698657)**
## Description
I've ported shmsink and shmsrc to Windows. I've used the simplest method possible, just #ifdef'ing ...## Submitted by Joshua M. Doe
**[Link to original bug (#698657)](https://bugzilla.gnome.org/show_bug.cgi?id=698657)**
## Description
I've ported shmsink and shmsrc to Windows. I've used the simplest method possible, just #ifdef'ing code to swap out Unix sockets for TCP sockets, and to use Windows shared memory functions CreateFileMapping/MapViewOfFile instead of shm_open/mmap. Permissions are much trickier on Windows, so I've opted to #ifdef that property out. I'll attach a patch as soon as I get release approval, but before then I'd like to know if my method is acceptable.