GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-04-05T13:27:55Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1030[HLS] Micro-freeze issue when refreshing live playlist2022-04-05T13:27:55ZJuan Ramírez[HLS] Micro-freeze issue when refreshing live playlistI am getting "micro-freezes" (meaning video stops for a fraction of a seconds and the resumes) at regular intervals, and those intervals coincide with the length of the playlist (given that the usual .m3u8 file contains 3 .ts segments to...I am getting "micro-freezes" (meaning video stops for a fraction of a seconds and the resumes) at regular intervals, and those intervals coincide with the length of the playlist (given that the usual .m3u8 file contains 3 .ts segments totaling between 10 and 15 seconds of video). It happens with most of the HLS streams I've tested with (a list is available below).
I tried adding buffering between hlsdemux and tsdemux and managed to increase performance, but the micro-freeze issue is still present. I also tried several property values (connection-speed for hlsdemux, sizes and thresholds of the queues etc) with no improvement.
I wrote to the mailing list and got this response from Charles Turner, which I think is worth quoting here:
> This is definitely a QoS bug, which isn't that unusual for elements in gst-plugins-bad. I had a quick peek at what might be going wrong and one hunch is that adaptivedemux isn't giving itself enough time, or is somehow stalling in updates_loop during the playlist updating logic. Maybe the target_duration wait times and/or the update timer cond bits need some adjustments.
Some of the workflows I've tried are the following:
```sh
gst-launch-1.0 playbin uri=$URL
```
```sh
gst-launch-1.0 souphttpsrc location="$URL" ! hlsdemux ! queue ! tsdemux name=demux \
demux. ! queue ! aacparse ! avdec_aac ! audioconvert ! autoaudiosink \
demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! autovideosink
```
With `URL` being one of the following:
* http://video3.earthcam.com/fecnetwork/hdtimes10.flv/.m3u8
* http://video3.earthcam.com/fecnetwork/9974.flv/.m3u8
* http://dwstream4-lh.akamaihd.net/i/dwstream4_live@131329/master.m3u8 (DW)
* https://5c21f7ec1999d.streamlock.net/8054/8054/playlist.m3u8 (TC, Ecuador)
* http://video.oct.dc.gov/out/u/DCN.m3u8 (DCN, provides various streams, use connection-speed to stick to one)
* http://unlimited2-us.dps.live/nettv/nettv.smil/playlist.m3u8 (NETTV, Argentina)
Streams that are not live, for example, [the ones at bitmovin.com](https://bitmovin.com/mpeg-dash-hls-examples-sample-streams) work ok (in the worst case you just have to set the appropriate bit rate).https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/629qtmux (mp4mux) deadlock in 1.14.4 and 1.14.52019-08-06T07:42:43ZAlexander Lebedevqtmux (mp4mux) deadlock in 1.14.4 and 1.14.5I have a problem with using gstreamer plugin named 'qtmux' in my high-loaded recording application. It seems that in some cases this plugin causes a deadlock:
pipeline: appsrc name=video_in ! videoscale ! video/x-raw,width=1280,height=3...I have a problem with using gstreamer plugin named 'qtmux' in my high-loaded recording application. It seems that in some cases this plugin causes a deadlock:
pipeline: appsrc name=video_in ! videoscale ! video/x-raw,width=1280,height=360 ! vaapih264enc rate-control=cbr keyframe-period=300 bitrate=1000 max-bframes=0 name=hrencoder ! h264parse config-interval=-1 ! muxer.video_0 appsrc name=audio_in ! audioresample ! audioconvert ! voaacenc ! muxer.audio_0 qtmux name=muxer ! filesink name=recorder_out
gdb thread info:
```
...
383 Thread 0x7fffb11b0700 (LWP 380) "freeswitch" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103
...
429 Thread 0x7fff7747c700 (LWP 426) "audio_in:src" syscall () at ../sysdeps/unix/sysv/linux/x86_64
/syscall.S:38
...
```
thr 383:
```
#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103
#1 0x00007ffff79de2a3 in __GI___pthread_mutex_lock (mutex=0x7fffdc462760) at ../nptl/pthread_mutex_lock.c:115
#2 0x00007fffe5e3b0f8 in g_rec_mutex_lock (mutex=<optimized out>) at /usr/src/debug/dev-libs/glib-2.58.3/glib-
2.58.3/glib/gthread-posix.c:308
#3 0x00007fffe58d586d in gst_base_src_send_event (element=0x7fffdc0d8d10, event=0x7fffd8334420) at /usr/src/debug/media-libs/gstreamer-1.14.5/gstreamer-1.14.5/libs/gst/base/gstbasesrc.c:1859
#4 0x00007fffe5cc389f in gst_element_send_event (element=element@entry=0x7fffdc0d8d10, event=event@entry=0x7fffd8334420) at /usr/src/debug/media-libs/gstreamer-1.14.5/gstreamer-1.14.5
/gst/gstelement.c:1857
```
I got owner of the mutex:
```
(gdb) f 1
#1 0x00007ffff79de2a3 in __GI___pthread_mutex_lock (mutex=0x7fffdc462760) at ../nptl/pthread_mutex_lock.c:115
115 LLL_MUTEX_LOCK (mutex);
(gdb) p *mutex
$3418 = {__data = {__lock = 2, __count = 1, __owner = 426, __nusers = 1, __kind = 1, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\002\000\000\000\001\000\000\000\252\001\000\000\001\000\000\000\001", '\000' <repeats 22 times>, __align = 4294967298}
```
As you can see, the owner of this mutex __owner == 426 (audio_in:src)
```
thr 429 (LWP 426):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007fffe5e3b95f in g_cond_wait (cond=0x7fffe031e220, mutex=0x7fffe031e218) at /usr/src/debug/dev-libs/glib-2.58.3/glib-2.58.3/glib/gthread-posix.c:1402
#2 0x00007fffe58e7843 in gst_collect_pads_chain (pad=0x7fffc009e8d0, parent=<optimized out>, buffer=0x7fffdc0b4d40) at /usr/src/debug/media-libs/gstreamer-1.14.5/gstreamer-1.14.5/libs/gst/base/gstcollectpads.c:2252
#3 0x00007fffe5cdd87a in gst_pad_chain_data_unchecked (data=0x7fffdc0b4d40, type=4112, pad=0x7fffc009e8d0) at /usr/src/debug/media-libs/gstreamer-1.14.5/gstreamer-1.14.5/gst/gstpad.c:4322
#4 gst_pad_push_data (pad=pad@entry=0x7fffd45fb430, type=type@entry=4112, data=data@entry=0x7fffdc0b4d40) at /usr/src/debug/media-libs/gstreamer-1.14.5/gstreamer-1.14.5/gst/gstpad.c:4578
#5 0x00007fffe5ce5b62 in gst_pad_push (pad=0x7fffd45fb430, buffer=0x7fffdc0b4d40) at /usr/src/debug/media-libs/gstreamer-1.14.5/gstreamer-1.14.5/gst/gstpad.c:4697
```
I found this place in gstreamer code:
```
/* wait to be collected, this must happen from another thread triggered
* by the _chain function of another pad. We release the lock so we
* can get stopped or flushed as well. We can however not get EOS
* because we still hold the STREAM_LOCK.
*/
GST_COLLECT_PADS_STREAM_UNLOCK (pads);
**GST_COLLECT_PADS_EVT_WAIT (pads, cookie);**
GST_COLLECT_PADS_STREAM_LOCK (pads);
`
And we hang in the muxer's chain:
`
(gdb) f 3
#3 0x00007fffe5cdd87a in gst_pad_chain_data_unchecked (data=0x7fffdc0b4d40, type=4112, pad=0x7fffc009e8d0) at /usr/src/debug/media-libs/gstreamer-1.14.5/gstreamer-1.14.5/gst/gstpad.c:4322
4322 ret = chainfunc (pad, parent, GST_BUFFER_CAST (data));
(gdb) p *pad->object->parent
$3422 = {object = {g_type_instance = {g_class = 0x7fffd43164f0}, ref_count = 5, qdata = 0x7fffdc0da1d0}, lock = {p = 0x0, i = {0, 0}}, name = 0x7fffdc4995e0 "muxer", parent = 0x7fffdc09cda0, flags = 0, control_bindings = 0x0, control_rate = 100000000, last_sync = 18446744073709551615, _gst_reserved = 0x0
```
GST_COLLECT_PADS_EVT_WAIT (pads, cookie) never released in some cases when it waits for the muxer. It seems that it depends on cpu or thread load (incorrect sending of signal by using gst_collectpads_... function?)
Here is code to reproduce problem (reproduces very rarely, some latency to g_cond_broadcast with correct cond, e.g. in gdb, may help)
```c
#include <stdio.h>
#include <gst/gst.h>
#include <gst/gstparse.h>
#include <glib.h>
#include <glib/gerror.h>
#include <pthread.h>
#include <unistd.h>
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
void *start_new_pipeline(void *data) {
GError * error = NULL;
pthread_t pself = pthread_self();
char pipe_str[4096] = {0};
sprintf(pipe_str, "videotestsrc do-timestamp=TRUE is-live=TRUE num-buffers=-1 !"
"videoscale !"
" video/x-raw,width=1280,height=360 !"
" vaapih264enc rate-control=cbr keyframe-period=300 bitrate=1000 max-bframes=0 name=hrencoder !"
" h264parse config-interval=-1 !"
" muxer.video_0 "
//
" audiotestsrc do-timestamp=TRUE is-live=TRUE num-buffers=-1 ! "
" audio/x-raw, format=S16LE, rate=8000, channels=1 !"
" audioresample !"
" audioconvert !"
" voaacenc !"
" muxer.audio_0"
//
" qtmux name=muxer ! filesink location=%zu.mp4", pself);
GstElement * pipeline = gst_parse_launch(pipe_str, &error);
if(!pipeline || error) {
printf("Cannot create pipeline (%d): %s\n", error->code, error->message);
exit(1);
}
GstBus * bus = gst_pipeline_get_bus(GST_PIPELINE(pipeline));
if(!bus) {
printf("Cannot get bus\n");
exit(2);
}
GstStateChangeReturn state = gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_PLAYING);
if(state == GST_STATE_CHANGE_FAILURE) {
printf("State change failure\n");
exit(3);
}
pthread_mutex_lock(&mutex);
int ret = pthread_cond_wait(&cond, &mutex);
//printf("condwait ret = %d\n", ret);
pthread_mutex_unlock(&mutex);
// problem here >>>> eos stucks sometimes due to collect pads (muxer)
gboolean eret = gst_element_send_event(pipeline, gst_event_new_eos());
if(!eret) {
printf("Cannot send eos message\n");
exit(5);
}
GstMessage * message = gst_bus_poll(bus, GST_MESSAGE_EOS, GST_SECOND * 5);
if(!message) {
printf("Cannot get EOS message\n");
exit(6);
} else {
printf("eos succesfully received, all ok with %lu\n", pthread_self());
}
gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_NULL);
sleep(1);
gst_message_unref(message);
gst_object_unref(bus);
gst_object_unref(pipeline);
return NULL;
}
int main()
{
gst_init(0, 0);
const size_t thrs = 30;
const size_t timeout = 2;
pthread_t thr[thrs];
// make 5 threads 5 times
size_t t = 0;
while(1) {
printf("Try #%zu\n", t);
for(size_t i = 0; i < thrs; ++i) {
pthread_create(&thr[i], NULL, start_new_pipeline, NULL);
}
printf("Some work %zu sec\n", timeout);
sleep(timeout);
printf("Signaling threads to raise eos\n");
pthread_mutex_lock(&mutex);
pthread_cond_broadcast(&cond);
pthread_mutex_unlock(&mutex);
printf("Awaiting threads done eos\n");
int * tret;
for(size_t j = 0; j < thrs; ++j) {
pthread_join(thr[j], (void **)&tret);
}
memset(thr, 0, sizeof(pthread_t) * thrs);
++t;
}
printf("This time problem not occured, try one more time\n");
}
```
very rarely, this code hangs in sending eos to the pipeline.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/641meson: check for `HAVE_ARM_NEON` for audio resampler support on ARM2019-09-03T07:04:19ZTim-Philipp Müllertim@centricular.commeson: check for `HAVE_ARM_NEON` for audio resampler support on ARMSeems like we don't check/set it.Seems like we don't check/set it.1.17.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/640egl: Might leak displays2022-09-16T06:20:43ZSebastian Drögeegl: Might leak displaysThe following discussion from !314 should be addressed:
- [ ] @ystreet started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/314#note_193724): (+1 comment)
> This is not always true. An E...The following discussion from !314 should be addressed:
- [ ] @ystreet started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/314#note_193724): (+1 comment)
> This is not always true. An EGLDisplay can be non-foreign from a foreign native display and in such cases, `eglTerminate` will not be called and thus can cause leaks.1.17.90https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/628udpsrc: Blocks entire pipeline until first packet arrives2019-07-24T00:36:02ZWayne Piekarskiudpsrc: Blocks entire pipeline until first packet arrivesI'm using gstreamer 1.14.4 on Debian Linux and I've noticed a problem where if I have multiple gstreamer pipelines in a single command, they all block until the udpsrc receives its first UDP packet.
For example, the videotestsrc ! aut...I'm using gstreamer 1.14.4 on Debian Linux and I've noticed a problem where if I have multiple gstreamer pipelines in a single command, they all block until the udpsrc receives its first UDP packet.
For example, the videotestsrc ! autovideosink is paused in this example:
` gst-launch-1.0 videotestsrc ! autovideosink sync=false udpsrc port=5600 timeout=1 ! fakesink sync=false`
If you run the following command, then the videotestsrc starts animating forever after that, even though no new packets are arriving:
` echo hello | nc -u localhost 5600`
I've tried workarounds like injecting a fake packet on the side (filesrc location=/etc/hostname ! udpsink port=5600 host=localhost), but it doesn't work when I pipe the udpsrc into an rtpjitterbuffer.
Is there some kind of workaround that I can add to udpsrc to make it not block everything, or is this a bug that needs to be fixed in udpsrc? This is part of a much larger problem that I'm having and I need to have multiple udpsrc's going and some of them may not receive any packets for a while.
Thanks.https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/42basic tutorial 13: code doesn't work as written2021-09-24T16:20:00ZAdam Di Carlobasic tutorial 13: code doesn't work as writtenAfter running basic-tutorial-13, then interacting to do 'p'ause, 'd'irection, and then 'n'ext frame, the movie still moves forward rather than backwards.
An example session:
~~~~
./basic-tutorial-13
USAGE: Choose one of the following o...After running basic-tutorial-13, then interacting to do 'p'ause, 'd'irection, and then 'n'ext frame, the movie still moves forward rather than backwards.
An example session:
~~~~
./basic-tutorial-13
USAGE: Choose one of the following options, then press enter:
'P' to toggle between PAUSE and PLAY
'S' to increase playback speed, 's' to decrease playback speed
'D' to toggle playback direction
'N' to move to next frame (in the current direction, better in PAUSE)
'Q' to quit
p
Setting state to PAUSE
d
Current rate: -1
n
Stepping one frame
n
Stepping one frame
n
~~~~
I've tested this against gstreamer 1.14 and 1.16, both simply step forward one frame at a time.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1028No sound when encoding video with H2642019-08-08T19:30:28ZAdrien RouhèteNo sound when encoding video with H264Hello,
I stumbled upon a problem when changing codec from VP8 to H264. With H264 no sound is sent, while it works as expected with VP8. Also I only got this bug with Gstreamer 1.15 and above. With Gstreamer 1.14.4, I have sound both wi...Hello,
I stumbled upon a problem when changing codec from VP8 to H264. With H264 no sound is sent, while it works as expected with VP8. Also I only got this bug with Gstreamer 1.15 and above. With Gstreamer 1.14.4, I have sound both with VP8 and H264.
In order to reproduce this, I modified the [webrtc demo](https://github.com/centricular/gstwebrtc-demos) (the rust one) and changed the video source.
Here is the changes I made:
```rust
fn add_h264_video_source(&self) -> Result<(), Error> {
let videotestsrc = gst::ElementFactory::make("videotestsrc", None).unwrap();
videotestsrc.set_property_from_str("pattern", "ball");
videotestsrc.set_property("is-live", &true).unwrap();
let videoconvert = gst::ElementFactory::make("videoconvert", None).unwrap();
let videoconvertcaps = gst::Caps::new_simple("video/x-raw", &[("format", &"NV12")]);
let queue = gst::ElementFactory::make("queue", None).unwrap();
let x264enc = gst::ElementFactory::make("x264enc", None).unwrap();
x264enc.set_property_from_str("tune", "zerolatency");
x264enc.set_property_from_str("speed-preset", "superfast");
x264enc.set_property_from_str("bitrate", &"3000");
x264enc.set_property_from_str("key-int-max", &"7");
x264enc.set_property_from_str("pass", "cbr");
let x264enc_caps = gst::Caps::new_simple("video/x-h264", &[("profile", &"constrained-baseline")]);
let queue2 = gst::ElementFactory::make("queue", None).unwrap();
let h264parse = gst::ElementFactory::make("h264parse", None).unwrap();
h264parse.set_property_from_str("config-interval", "-1");
let h264parse_caps = gst::Caps::new_simple("video/x-h264", &[("split-packetized", &true)]);
let rtph264pay = gst::ElementFactory::make("rtph264pay", None).unwrap();
let queue3 = gst::ElementFactory::make("queue", None).unwrap();
self.0
.pipeline
.add_many(&[
&videotestsrc,
&videoconvert,
&queue,
&x264enc,
&queue2,
&h264parse,
&rtph264pay,
&queue3,
])
.unwrap();
videotestsrc.link(&videoconvert).unwrap();
videoconvert.link_filtered(&queue, Some(&videoconvertcaps)).unwrap();
queue.link(&x264enc).unwrap();
x264enc.link_filtered(&queue2, Some(&x264enc_caps)).unwrap();
queue2.link(&h264parse).unwrap();
h264parse.link_filtered(&rtph264pay, Some(&h264parse_caps)).unwrap();
rtph264pay.link(&queue3).unwrap();
let rtp_caps_h264 = gst::Caps::new_simple(
"application/x-rtp",
&[
("media", &"video"),
("encoding-name", &"H264"),
("payload", &96i32),
("config-interval", &-1),
("mtu", &1468),
]
);
queue3.link_filtered(&self.0.webrtcbin, Some(&rtp_caps_h264))?;
Ok(())
}
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1027check.gst-plugins-bad.elements_netsim.netsim_stress_delayed: Sometimes fails ...2019-08-05T13:59:27ZSebastian Drögecheck.gst-plugins-bad.elements_netsim.netsim_stress_delayed: Sometimes fails with "Got data flow before stream-start event"See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/jobs/440022
> ``` bash
> GST_STATE_IGNORE_ELEMENTS='' GST_PLUGIN_PATH_1_0='/builds/gstreamer/gst-plugins-bad/gst-build/build' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plu...See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/jobs/440022
> ``` bash
> GST_STATE_IGNORE_ELEMENTS='' GST_PLUGIN_PATH_1_0='/builds/gstreamer/gst-plugins-bad/gst-build/build' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-ugly:gst-libav:gst-plugins-bad@/builds/gstreamer/gst-plugins-bad/gst-build/build' GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT='20' GST_CHECKS='netsim_stress_delayed' GST_REGISTRY='/builds/gstreamer/gst-plugins-bad/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_netsim.registry' /builds/gstreamer/gst-plugins-bad/gst-build/build/subprojects/gst-plugins-bad/tests/check/elements_netsim
> ```
>
> ## elements_netsim output
>
> ```
> Running suite(s): netsim
>
>
> Unexpected critical/warning: ../subprojects/gstreamer/gst/gstpad.c:4299:gst_pad_chain_data_unchecked:<bin0:sink> Got data flow before stream-start event
>
> Stack trace:
> gst_debug_get_stack_trace (gstinfo.c:2932)
> gst_check_log_critical_func (gstcheck.c:281)
> g_logv (gmessages.c:1350)
> g_log (gmessages.c:1413)
> gst_pad_push_data (gstpad.c:4297)
> gst_pad_push (gstpad.c:4708)
> gst_harness_stress_buffer_func (gstharness.c:2960)
> g_thread_proxy (gthread.c:784)
> start_thread (pthread_create.c:486)
> __clone (clone.S:93)
>
> 0%: Checks: 1, Failures: 1, Errors: 0
> ../subprojects/gstreamer/libs/gst/check/gstcheck.c:286:F:general:netsim_stress_delayed:0: Unexpected critical/warning: ../subprojects/gstreamer/gst/gstpad.c:4299:gst_pad_chain_data_unchecked:<bin0:sink> Got data flow before stream-start event
> Check suite netsim ran in 0.592s (tests failed: 1)
>
> ```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1026dtls: Documentation needs to be improved2021-09-24T14:37:34ZFurkan Davulcudtls: Documentation needs to be improvedCurrent documentation of dtls plugin is very insufficient to understand how this plugin can be used in an application. A clearer example with a detailed explanation would make this plugin much more accessible and usable.Current documentation of dtls plugin is very insufficient to understand how this plugin can be used in an application. A clearer example with a detailed explanation would make this plugin much more accessible and usable.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/414sys:1: Warning: ../../../gobject/gsignal.c:2641: has no handler with id when...2019-07-23T11:05:47ZДориан Грейsys:1: Warning: ../../../gobject/gsignal.c:2641: has no handler with id when using multisocketsink on high loadHi!
I have a program in python which distributes rtsp sources between network clients using basic pipeline:
rtspsrc - h264depay - h264parse - mpegtsmux - multisocketsink.
Every client uses different socket and connection uses client-a...Hi!
I have a program in python which distributes rtsp sources between network clients using basic pipeline:
rtspsrc - h264depay - h264parse - mpegtsmux - multisocketsink.
Every client uses different socket and connection uses client-add and client-socket-disconnected signals. It was stable under very heavy load on gstreamer 1.8 on opensuse 13.2 distro. However when I switched distro to ubuntu-18.04 with gstreamer 1-14 program began spamming errors when more than 2 clients are connected.
sys:1: Warning: ../../../gobject/gsignal.c:2641: instance '0x561d5f61dc10' has no handler with id '3503'
sys:1: Warning: ../../../gobject/gsignal.c:2641: instance '0x561d5f61dc10' has no handler with id '3503'
The error states 'Warning', but it results in process crush and client signal loss. The same error persists in ubuntu 18.10, 19.04 with gstreamer 1.15.90.
Can something be done with this issue in upstream or in a patch ?
Thanks in advance!https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/-/issues/74check.gst-rtsp-server.gst_media.test_media_seek_one_active_stream: Sometimes ...2021-09-24T11:03:42ZSebastian Drögecheck.gst-rtsp-server.gst_media.test_media_seek_one_active_stream: Sometimes fails with "Assertion 'play_range->min.seconds == range->min.seconds' failed"See https://gitlab.freedesktop.org/slomo/gst-plugins-bad/-/jobs/436751
> ``` bash
> GST_PLUGIN_SYSTEM_PATH_1_0='' GST_CHECKS='test_media_seek_one_active_stream' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good:g...See https://gitlab.freedesktop.org/slomo/gst-plugins-bad/-/jobs/436751
> ``` bash
> GST_PLUGIN_SYSTEM_PATH_1_0='' GST_CHECKS='test_media_seek_one_active_stream' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good:gst-plugins-bad:gst-rtsp-server' GST_PLUGIN_PATH_1_0='/builds/slomo/gst-plugins-bad/gst-build/build' CK_DEFAULT_TIMEOUT='120' GST_STATE_IGNORE_ELEMENTS='' GST_REGISTRY='/builds/slomo/gst-plugins-bad/gst-build/build/subprojects/gst-rtsp-server/tests/check/gst/media.registry' /builds/slomo/gst-plugins-bad/gst-build/build/subprojects/gst-rtsp-server/tests/check/gst_media
> ```
>
> ## gst_media output
>
> ```
>
> Running suite(s): rtspmedia
> 0%: Checks: 1, Failures: 1, Errors: 0
> ../subprojects/gst-rtsp-server/tests/check/gst/media.c:205:F:general:test_media_seek_one_active_stream:0: Assertion 'play_range->min.seconds == range->min.seconds' failed
> Check suite rtspmedia ran in 0.024s (tests failed: 1)
>
> ```
CC @mehhttps://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/41Application development manual/Appendix/Compiling/Embedding static elements i...2021-09-24T16:20:00ZSebastian DrögeApplication development manual/Appendix/Compiling/Embedding static elements in your application: Needlessly recommends using gst_plugin_register_static()https://gstreamer.freedesktop.org/documentation/application-development/appendix/compiling.html?gi-language=c#page-description
There's no point in doing so, simply calling `gst_element_register()` from the application has the same effec...https://gstreamer.freedesktop.org/documentation/application-development/appendix/compiling.html?gi-language=c#page-description
There's no point in doing so, simply calling `gst_element_register()` from the application has the same effect for all practical purposes and requires less boilerplate.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1025av1enc: AV1E_SET_ROW_MT not available since libaom 1.0.02019-07-27T08:47:22ZSebastian Drögeav1enc: AV1E_SET_ROW_MT not available since libaom 1.0.0CC @wonchul
We need to conditionally enable it based on the libaom version used.CC @wonchul
We need to conditionally enable it based on the libaom version used.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/627check.gst-plugins-good.elements_splitmux.test_splitmuxsrc_format_location: So...2020-05-05T14:12:52ZSebastian Drögecheck.gst-plugins-good.elements_splitmux.test_splitmuxsrc_format_location: Sometimes times out in valgrindSee https://gitlab.freedesktop.org/knut.tidemann/gst-plugins-good/-/jobs/436630
> ``` bash
> GST_CHECKS='test_splitmuxsrc_format_location' CK_TIMEOUT_MULTIPLIER='20' GST_REGISTRY='/builds/knut.tidemann/gst-plugins-good/gst-build/build/s...See https://gitlab.freedesktop.org/knut.tidemann/gst-plugins-good/-/jobs/436630
> ``` bash
> GST_CHECKS='test_splitmuxsrc_format_location' CK_TIMEOUT_MULTIPLIER='20' GST_REGISTRY='/builds/knut.tidemann/gst-plugins-good/gst-build/build/subprojects/gst-plugins-good/tests/check/elements_splitmux.registry' GST_PLUGIN_PATH_1_0='/builds/knut.tidemann/gst-plugins-good/gst-build/build' G_SLICE='always-malloc' GST_VALIDATE_CONFIG='/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-devtools/validate/data/valgrind.config' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good@/builds/knut.tidemann/gst-plugins-good/gst-build/build' G_DEBUG='gc-friendly' ORC_CODE='backup' GST_STATE_IGNORE_ELEMENTS='aasink autoaudiosrc autoaudiosink autovideosrc
> autovideosink cacasink cairotextoverlay gtkglsink gtksink jackaudiosrc
> jackaudiosink osssrc osssink osxaudiosink osxaudiosrc osxvideosrc osxvideosink
> pulsesink pulsesrc pulsemixer v4l2src' CK_DEFAULT_TIMEOUT='20' GST_PLUGIN_SYSTEM_PATH_1_0='' valgrind --trace-children=yes --tool=memcheck --leak-check=full --leak-resolution=high --errors-for-leak-kinds=definite,indirect --show-leak-kinds=definite,indirect --show-possibly-lost=no --num-callers=20 --error-exitcode=20 --gen-suppressions=all --log-file=/builds/knut.tidemann/gst-plugins-good/validate-logs/check/gst-plugins-good/elements_splitmux/test_splitmuxsrc_format_location.valgrind --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-devtools/validate/data/gstvalidate.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gstreamer/tests/check/gstreamer.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-plugins-base/tests/check/gst-plugins-base.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-plugins-good/tests/check/gst-plugins-good.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-plugins-bad/tests/check/gst-plugins-bad.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-plugins-ugly/tests/check/gst-plugins-ugly.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-libav/tests/check/gst-libav.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-devtools/validate/data/gstvalidate.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/libnice/tests/libnice.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/libsoup/tests/libsoup.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/glib/glib.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-python/testsuite/gstpython.supp --suppressions=/builds/knut.tidemann/gst-plugins-good/gst-build/subprojects/gst-python/testsuite/python.supp /builds/knut.tidemann/gst-plugins-good/gst-build/build/subprojects/gst-plugins-good/tests/check/elements_splitmux
> ```
>
> ## elements_splitmux output
>
> ```
>
> Running suite(s): splitmux
> 0%: Checks: 1, Failures: 0, Errors: 1
> ../subprojects/gst-plugins-good/tests/check/elements/splitmux.c:282:E:general:test_splitmuxsrc_format_location:0: (after this point) Test timeout expired
> Check suite splitmux ran in 400.072s (tests failed: 1)
>
> ```
>
>
> **You can mark the issues as 'known' by adding the following lines to the list of known issues**
>
>
> ``` python
> "FIXME 'check.gst-plugins-good.elements_splitmux.test_splitmuxsrc_format_location' issues [REPORT A BUG in https://gitlab.freedesktop.org/gstreamer/ or use a proper bug description]": {
> "tests": [
> "check.gst-plugins-good.elements_splitmux.test_splitmuxsrc_format_location"
> ],
> "issues": [
> {
> 'returncode': 1,
> 'sometimes': True,
> },
> ],
> },
>
> ```
Seems also like something new, CC @thaytanhttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/212'gst_plugin_register_static' is missing2019-07-22T09:30:16ZZeno Sebastian Endemann'gst_plugin_register_static' is missingAs the title says, gst_plugin_register_static seems to be missing from the Rust API. Or is there an alternative that should be used instead?As the title says, gst_plugin_register_static seems to be missing from the Rust API. Or is there an alternative that should be used instead?https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/184Can not encode the vp9 10bits streams correctly2019-12-17T11:32:55ZHe JunyanCan not encode the vp9 10bits streams correctlyvideotestsrc pattern=ball num-buffers=300 ! capsfilter caps=video/x-raw,format=P010_10LE,width=800,height=600 ! vaapivp9enc tune=low-power ! matroskamux ! filesink location=vp9.mkv
Failed on icelake and using iHD driver.videotestsrc pattern=ball num-buffers=300 ! capsfilter caps=video/x-raw,format=P010_10LE,width=800,height=600 ! vaapivp9enc tune=low-power ! matroskamux ! filesink location=vp9.mkv
Failed on icelake and using iHD driver.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/626check.gst-plugins-good.elements_splitmux.test_splitmuxsink: Sometimes times o...2020-05-05T14:12:39ZSebastian Drögecheck.gst-plugins-good.elements_splitmux.test_splitmuxsink: Sometimes times out in valgrindSee https://gitlab.freedesktop.org/ndufresne/gstreamer/-/jobs/434606
> ``` bash
> G_DEBUG='gc-friendly' GST_STATE_IGNORE_ELEMENTS='aasink autoaudiosrc autoaudiosink autovideosrc
> autovideosink cacasink cairotextoverlay gtkglsink g...See https://gitlab.freedesktop.org/ndufresne/gstreamer/-/jobs/434606
> ``` bash
> G_DEBUG='gc-friendly' GST_STATE_IGNORE_ELEMENTS='aasink autoaudiosrc autoaudiosink autovideosrc
> autovideosink cacasink cairotextoverlay gtkglsink gtksink jackaudiosrc
> jackaudiosink osssrc osssink osxaudiosink osxaudiosrc osxvideosrc osxvideosink
> pulsesink pulsesrc pulsemixer v4l2src' GST_CHECKS='test_splitmuxsink' GST_PLUGIN_LOADING_WHITELIST='gstreamer:gst-plugins-base:gst-plugins-good@/builds/ndufresne/gstreamer/gst-build/build' CK_TIMEOUT_MULTIPLIER='20' G_SLICE='always-malloc' GST_REGISTRY='/builds/ndufresne/gstreamer/gst-build/build/subprojects/gst-plugins-good/tests/check/elements_splitmux.registry' GST_PLUGIN_PATH_1_0='/builds/ndufresne/gstreamer/gst-build/build' GST_VALIDATE_CONFIG='/builds/ndufresne/gstreamer/gst-build/subprojects/gst-devtools/validate/data/valgrind.config' CK_DEFAULT_TIMEOUT='20' GST_PLUGIN_SYSTEM_PATH_1_0='' ORC_CODE='backup' valgrind --trace-children=yes --tool=memcheck --leak-check=full --leak-resolution=high --errors-for-leak-kinds=definite,indirect --show-leak-kinds=definite,indirect --show-possibly-lost=no --num-callers=20 --error-exitcode=20 --gen-suppressions=all --log-file=/builds/ndufresne/gstreamer/validate-logs/check/gst-plugins-good/elements_splitmux/test_splitmuxsink.valgrind --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-devtools/validate/data/gstvalidate.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gstreamer/tests/check/gstreamer.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-plugins-base/tests/check/gst-plugins-base.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-plugins-good/tests/check/gst-plugins-good.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-plugins-bad/tests/check/gst-plugins-bad.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-plugins-ugly/tests/check/gst-plugins-ugly.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-libav/tests/check/gst-libav.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-devtools/validate/data/gstvalidate.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/libnice/tests/libnice.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/libsoup/tests/libsoup.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/glib/glib.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-python/testsuite/gstpython.supp --suppressions=/builds/ndufresne/gstreamer/gst-build/subprojects/gst-python/testsuite/python.supp /builds/ndufresne/gstreamer/gst-build/build/subprojects/gst-plugins-good/tests/check/elements_splitmux
> ```
>
> ## elements_splitmux output
>
> ```
>
> Running suite(s): splitmux
> 0%: Checks: 1, Failures: 0, Errors: 1
> ../subprojects/gst-plugins-good/tests/check/elements/splitmux.c:228:E:general:test_splitmuxsink:0: (after this point) Test timeout expired
> Check suite splitmux ran in 400.063s (tests failed: 1)
>
> ```
CC @thaytan. I think this is a new one.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/625dvdemux date stamp tag only emitted on pad add2022-07-13T13:22:45ZColin Kinlochdvdemux date stamp tag only emitted on pad addA dv stream has date stamps per frame, this data is useful to split a dv by section date.
Currently the date is only retrieved on pad addition.
Date stamp retrieval is done by the function [`gst_dvdemux_create_global_tag_event`](https:...A dv stream has date stamps per frame, this data is useful to split a dv by section date.
Currently the date is only retrieved on pad addition.
Date stamp retrieval is done by the function [`gst_dvdemux_create_global_tag_event`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/ext/dv/gstdvdemux.c#L298-318) and is only called in [`gst_dvdemux_add_pad`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/ext/dv/gstdvdemux.c#L354).
I don't know whether tag events should be sent each frame, when the value changes, or whether this data should not use the event system.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/413basesrc: Seek in READY state causes start() to be called without the subclass...2021-09-24T11:09:08ZSajeer Ahamedbasesrc: Seek in READY state causes start() to be called without the subclass knowing about the seek and the seek being forwarded only afterwardsThe problem here is that `basesrc` caches the `SEEK` event if it happens before `start()` was called (e.g. in `READY` state). Then it will call `start()` without having told the subclass that there was a specific seek, and only then it f...The problem here is that `basesrc` caches the `SEEK` event if it happens before `start()` was called (e.g. in `READY` state). Then it will call `start()` without having told the subclass that there was a specific seek, and only then it forwards the `SEEK` event.
In the case of HTTP sources, this causes the sources to do an HTTP request for `Range: 0-` in `start()` just to have that very request be cancelled immediately again afterwards for doing the seek HTTP request with `Range: X-Y`.
We should find a way to let the subclass know about the seek event before/during `start()` somehow, other than intercepting it in the event handler outside `basesrc`'s seek handling code.
See also https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/merge_requests/142#note_193072https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/624The rglimiter documentation points to an incorrect site2019-08-23T12:38:32ZJuan PabloThe rglimiter documentation points to an incorrect siteThe documentation for the rglimiter plugin has a link to the "ReplayGain" standard in its description, that points to [replaygain.org](https://replaygain.org). This site _does not_ seem to be the real thing, and for all I can tell, the r...The documentation for the rglimiter plugin has a link to the "ReplayGain" standard in its description, that points to [replaygain.org](https://replaygain.org). This site _does not_ seem to be the real thing, and for all I can tell, the real site is [this wiki](http://wiki.hydrogenaud.io/index.php?title=ReplayGain_specification).