GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T10:46:35Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer-sharp/-/issues/60Struct bindings are broken when they iinclude a boxed type or a struct mapped...2021-09-24T10:46:35ZAndoni Morales AlastrueyStruct bindings are broken when they iinclude a boxed type or a struct mapped to a GLib.OpaqueGstVideoFrame's first field is a GstVideoInfo.
VideoFrame is bindinded like a struct and it's first field is generated as an IntPtr, because VideoInfo is binded using a GLib.Opaque class.
```
StructLayout(LayoutKind.Sequential)]
publi...GstVideoFrame's first field is a GstVideoInfo.
VideoFrame is bindinded like a struct and it's first field is generated as an IntPtr, because VideoInfo is binded using a GLib.Opaque class.
```
StructLayout(LayoutKind.Sequential)]
public partial struct VideoFrame : IEquatable<VideoFrame> {
private IntPtr _info;
public Gst.Video.VideoInfo Info {
get {
return _info == IntPtr.Zero ? null : (Gst.Video.VideoInfo) GLib.Opaque.GetOpaque (_info, typeof (Gst.Video.VideoInfo), false);
}
set {
_info = value == null ? IntPtr.Zero : value.Handle;
}
}
```
The memory layout of the VideoFrame class does not matches the one of GstVideoFrame, the first field will has the size of a pointer and not the one of a VideoInfo.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/911multifilesink generates several small unviewable files when stream recovers a...2023-07-04T16:31:24ZMatthew Zeleninmultifilesink generates several small unviewable files when stream recovers after being downI am streaming a sample TS file (from https://tsduck.io/streams/?name=brazil-isdb-tb) with the following pipeline:
`gst-launch-1.0 multifilesrc location=/home/scientia/Videos/TS1globo.ts ! tsparse alignment=7 set-timestamps=true ! udpsi...I am streaming a sample TS file (from https://tsduck.io/streams/?name=brazil-isdb-tb) with the following pipeline:
`gst-launch-1.0 multifilesrc location=/home/scientia/Videos/TS1globo.ts ! tsparse alignment=7 set-timestamps=true ! udpsink host=239.5.35.1 port=16400`
I then record the outgoing UDP stream to files using multifilesink:
`gst-launch-1.0 udpsrc address=239.5.35.1 port=16400 ! multifilesink location=segment_%d.ts next-file=2`
The multifilesink generates files as expected, separating them by the closest keyframe to a 10-second duration for each file. However, if I terminate the first pipeline, wait several minutes, and restart it, multifilesink will generate several small files, each of size ~1.3K approximately, and then continue recording files starting at the next available index. It seems that for every 10 seconds the UDP stream is down, multifilesink generates one additional small file. These files are unviewable and create issues with playback using multifilesrc.
Please advise as to what may be the issue here. Thank you.https://gitlab.freedesktop.org/gstreamer/gstreamer-project/-/issues/90http://gstreamer-devel.966125.n4.nabble.com/ offline?2021-09-17T17:55:15ZMarianna Smidth Buschlehttp://gstreamer-devel.966125.n4.nabble.com/ offline?For several days I can't access http://gstreamer-devel.966125.n4.nabble.com/
Is it down?For several days I can't access http://gstreamer-devel.966125.n4.nabble.com/
Is it down?https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/912matroskademux: subrip subtitles can be rendered with XML tags2022-10-17T11:17:25ZAlexander Slobodeniukmatroskademux: subrip subtitles can be rendered with XML tags**About the issue:**
---------------
We have a file, it's muxed with ffmpeg, and contains SubRip subtitles (from an srt file)
[SampleVideo_640x480_1mb.mkv](/uploads/0d66c18801a84c5290c0b3da92eb5ec1/SampleVideo_640x480_1mb.mkv)
VLC can ...**About the issue:**
---------------
We have a file, it's muxed with ffmpeg, and contains SubRip subtitles (from an srt file)
[SampleVideo_640x480_1mb.mkv](/uploads/0d66c18801a84c5290c0b3da92eb5ec1/SampleVideo_640x480_1mb.mkv)
VLC can play this file without issues
![mkv-vlc](/uploads/bb3ae16d0a8f118c8333b047a00833a7/mkv-vlc.jpg)
But if we play it with gst-play-1.0, we can see the XML tags rendered together with the subtitle text
![mkv-gst](/uploads/0c0af63bbcc00ad32f922d2bd872cbe6/mkv-gst.jpg)
---
Subtitles are correctly muxed and have codec id of the SubRip format: [S_TEXT/UTF8](https://tools.ietf.org/id/draft-ietf-cellar-codec-04.html#name-srt-subtitles)
When matroskademux element opens this file, for subtitles stream it [exposes pango-markup caps](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/blob/master/gst/matroska/matroska-demux.c#L7295)
```c
...
if (!strcmp (codec_id, GST_MATROSKA_CODEC_ID_SUBTITLE_UTF8)) {
/* well, plain text simply does not have a lot of markup ... */
caps = gst_caps_new_simple ("text/x-raw", "format", G_TYPE_STRING,
"pango-markup", NULL);
context->postprocess_frame = gst_matroska_demux_check_subtitle_buffer;
subtitlecontext->check_markup = TRUE;
...
```
This particular action (saying that SubRip is a pango markup) is wrong: SubRip has it's own markup, and it's not always compatible with pango, and the file attached is the case.
**About a fix:**
---
If we open with GStreamer an srt file with same subtitles, it doesn't have described issue, because the input is handled by a **subparse** element, that converts different subtitle formats to pango-markup and also throws away unknown markups.
Idea of fix that is going to be proposed in the MRs is to make **subparse** element autoplug after **matroskademux** and make the convertion SubRip --> pango-markup.
To do that we do 2 things:
1. Instead of "pango-markup" expose from **matroskademux** some new format, let's call it "text/x-subrip-muxed" (do you know, maybe there's already some existing format for it?).
NOTE: We can't use "application/x-subtitle" that is used for srt files, because it's a little bit different: data of such format is supposed to have number and timestamp inside of the text.
[MR to matroskademux element, (gst-plugins-good)](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1045/diffs)
2. Make **subparse** element handle "text/x-subrip-muxed". [MR to subparse element (gst-plugins-base)](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1248/diffs)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/930playbin2 hangs on "about-to-finish" signal with audio/video media2021-09-30T08:11:12ZStéphane Cerveauscerveau@igalia.complaybin2 hangs on "about-to-finish" signal with audio/video media### Describe your issue
Playing a playlist of A/V media with gst-play-1.0 hangs on first media change (about-to-finish). The bug does not happen with video only media.
#### Expected Behavior
Play the next media.
#### Observed Behavior...### Describe your issue
Playing a playlist of A/V media with gst-play-1.0 hangs on first media change (about-to-finish). The bug does not happen with video only media.
#### Expected Behavior
Play the next media.
#### Observed Behavior
The playback hangs on first "about-to-finish" using gst-play-1.0 with a media composed of a video track **AND** an audio track
#### Setup
- **Operating System:** Linux
- **Device:** Computer
- **GStreamer Version:** Master
- **Command line:**
### Steps to reproduce the bug
```
$ gst-play-1.0 file1.mov file2.mov --gapless
```
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
The bug happens on any GStreamer version since 1.16https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/745playbin2 hangs on "about-to-finish" signal with audio/video media2023-02-16T14:46:25ZStéphane Cerveauscerveau@igalia.complaybin2 hangs on "about-to-finish" signal with audio/video media### Describe your issue
Playing a playlist of A/V media with gst-play-1.0 hangs on first media change (about-to-finish). The bug does not happen with video only media.
#### Expected Behavior
Play the next media.
#### Observed Behavior...### Describe your issue
Playing a playlist of A/V media with gst-play-1.0 hangs on first media change (about-to-finish). The bug does not happen with video only media.
#### Expected Behavior
Play the next media.
#### Observed Behavior
The playback hangs on first "about-to-finish" using gst-play-1.0 with a media composed of a video track **AND** an audio track
#### Setup
- **Operating System:** Linux
- **Device:** Computer
- **GStreamer Version:** Master
- **Command line:**
### Steps to reproduce the bug
```
$ gst-play-1.0 file1.mov file2.mov --gapless
```
### How reproducible is the bug?
Always
### Screenshots if relevant
### Solutions you have tried
### Related non-duplicate issues
### Additional Information
The bug happens on any GStreamer version since 1.16https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/931gl: Need to add modifier support for glupload and gldownload2023-07-27T11:30:05ZHe Junyangl: Need to add modifier support for glupload and gldownloadThe new platform export the DRM's modifier to users now. For example, the GPU surface with the X tiling have the modifier of I915_FORMAT_MOD_X_TILED on Intel platforms. We need to set this kind of modifiers correctly when we share the DM...The new platform export the DRM's modifier to users now. For example, the GPU surface with the X tiling have the modifier of I915_FORMAT_MOD_X_TILED on Intel platforms. We need to set this kind of modifiers correctly when we share the DMA surfaces between different module, such as VA->3D. On old platform, this modifier stored inside libdrm but now we need to explicitly specify it.
We already have some patch for VA part: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2032
and according to @ndufresne , all the video-format/modifier should have "format:modifier" in caps, like:
```
video/x-raw(memory:DMABuf)
width: [ 16, 16384 ]
height: [ 16, 16384 ]
format: { (string)NV12:0x0100000000000002, (string)I420, (string)YV12, (string)YUY2:0x0100000000000002, (string)P010_10LE:0x0100000000000002, (string)BGRA:0x0100000000000002, (string)RGBA:0x0100000000000002, (string)BGR10A2_LE:0x0100000000000002, (string)VUYA:0x0100000000000002 }
```
We also need to add this to gl's DMA part.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2860gl: Need to add modifier support for glupload and gldownload2024-02-12T23:29:11ZHe Junyangl: Need to add modifier support for glupload and gldownloadThe new platform export the DRM's modifier to users now. For example, the GPU surface with the X tiling have the modifier of I915_FORMAT_MOD_X_TILED on Intel platforms. We need to set this kind of modifiers correctly when we share the DM...The new platform export the DRM's modifier to users now. For example, the GPU surface with the X tiling have the modifier of I915_FORMAT_MOD_X_TILED on Intel platforms. We need to set this kind of modifiers correctly when we share the DMA surfaces between different module, such as VA->3D. On old platform, this modifier stored inside libdrm but now we need to explicitly specify it.
We already have some patch for VA part: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2032
and according to @ndufresne , all the video-format/modifier should have "format:modifier" in caps, like:
```
video/x-raw(memory:DMABuf)
width: [ 16, 16384 ]
height: [ 16, 16384 ]
format: { (string)NV12:0x0100000000000002, (string)I420, (string)YV12, (string)YUY2:0x0100000000000002, (string)P010_10LE:0x0100000000000002, (string)BGRA:0x0100000000000002, (string)RGBA:0x0100000000000002, (string)BGR10A2_LE:0x0100000000000002, (string)VUYA:0x0100000000000002 }
```
We also need to add this to gl's DMA part.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1638SRT stats send-duration-us duplicated2021-09-24T14:39:33ZSektor van SkijlenSRT stats send-duration-us duplicatedThe `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is send...The `send-duration-us` field is defined twice, and each time with a different type.
File `ext/srt/gstsrtobject.c` function `get_stats_for_srtsock`, in the `is_sender` section there is:
```
...
/* time duration when UDT is sending data (idle time exclusive) */
"send-duration-us", G_TYPE_INT64, stats.usSndDuration,
...
/* busy sending time (i.e., idle time exclusive) */
"send-duration-us", G_TYPE_UINT64, stats.usSndDuration,
"negotiated-latency-ms", G_TYPE_INT, stats.msSndTsbPdDelay, NULL);
```
Another minor problem is `*bytes += stats.byteSent;` for `is_sender` section, but `stats.byteRecvTotal` for else section. As you don't request clearing the stats in the `srt_bstats` call it shouldn't make a difference, but formally it's wrong.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/352`extern "C"` functions called from C code should guard against unwinding2021-08-11T09:10:24ZSimonas Kazlauskas`extern "C"` functions called from C code should guard against unwindingAs far as I can tell https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/log.rs#L342-377 is called directly from GStreamer and then calls arbitrary Rust code. However it does not catch the unwinding that hap...As far as I can tell https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/blob/master/gstreamer/src/log.rs#L342-377 is called directly from GStreamer and then calls arbitrary Rust code. However it does not catch the unwinding that happens from the Rust end, therefore being (I believe) unsound especially with versions of Rust that don't mitigate this by introducing trampolines that abort in these kinds of situations.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/335Pattern for files_devel provided in libunwind.recipe results in build error o...2021-08-10T20:09:25ZSteve McDanielPattern for files_devel provided in libunwind.recipe results in build error on LinuxExtra dash prevents libunwind.pc from getting included in files_devel.
Cebero devel package is missing libunwind.pc because the pattern "libunwind-*.pc" is used to populate files_devel.
The missing libunwind.pc file results in pkg-co...Extra dash prevents libunwind.pc from getting included in files_devel.
Cebero devel package is missing libunwind.pc because the pattern "libunwind-*.pc" is used to populate files_devel.
The missing libunwind.pc file results in pkg-config failing to resolve dependencies for gstreamer-1.0.pc.
Fixed in Merge Request: https://gitlab.freedesktop.org/gstreamer/cerbero/-/merge_requests/722https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/913splitmuxsink creates files that are too large when using mpegtsmux2023-07-04T16:28:56Zkoreysplitmuxsink creates files that are too large when using mpegtsmuxWhen using mpegtsmux with splitmuxsink it will write the file fine but staying within the parameters the size of file seems to go bigger than set. If I use mp4mux it will at least stay within the max size file.
Gstreamer 1.18.4When using mpegtsmux with splitmuxsink it will write the file fine but staying within the parameters the size of file seems to go bigger than set. If I use mp4mux it will at least stay within the max size file.
Gstreamer 1.18.4https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/721Erroneous pipeline: no element "rtspsrc"2021-08-11T06:42:03Zmehul-rigynErroneous pipeline: no element "rtspsrc"Hello, when I try to run a rtsp stream with following launch command I get an error
**gst-launch-1.0 -v playbin uri="rtsp://link-to-rtsp-feed"**
Error:
```
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
/GstURI...Hello, when I try to run a rtsp stream with following launch command I get an error
**gst-launch-1.0 -v playbin uri="rtsp://link-to-rtsp-feed"**
Error:
```
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
/GstURIDecodeBin:uridecodebin0: ring-buffer-max-size = 0
/GstURIDecodeBin:uridecodebin0: buffer-size = -1
/GstURIDecodeBin:uridecodebin0: buffer-duration = -1
/GstURIDecodeBin:uridecodebin0: use-buffering = false
/GstURIDecodeBin:uridecodebin0: download = false
/GstURIDecodeBin:uridecodebin0: uri = rtsp://link-to-rtsp-feed
/GstURIDecodeBin:uridecodebin0: connection-speed = 0
Missing element: Real Time Streaming Protocol (RTSP) source
ERROR: from element /GstURIDecodeBin:uridecodebin0: No URI handler implemented for "rtsp".
Additional debug info:
gsturidecodebin.c(1409): gen_source_element (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0
Setting pipeline to NULL ...
Freeing pipeline ...
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/722RTSP Issue with gstreamer2021-08-13T12:40:26Zmehul-rigynRTSP Issue with gstreamerHello , I tried to play an RTSP stream with Gstreame with
gst-launch-1.0 --gst-debug=rtspsrc:5 rtspsrc location="rtsp://user:pass@ip.add.dest.serv:554/H264?ch=3&subtype=0" ! decodebin ! fakesink
but I got following error log
[gsterror...Hello , I tried to play an RTSP stream with Gstreame with
gst-launch-1.0 --gst-debug=rtspsrc:5 rtspsrc location="rtsp://user:pass@ip.add.dest.serv:554/H264?ch=3&subtype=0" ! decodebin ! fakesink
but I got following error log
[gsterrorlog.txt](/uploads/c0ffbb4f4d1e85a400941257da1ed0aa/gsterrorlog.txt)
I am able to run the rtsp stream in VLC player ir in ffplay.https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/160fallbacksrc with stream HTTP/MJPEG2022-08-30T06:18:42ZAlexfallbacksrc with stream HTTP/MJPEGHi all!!
I am testing plugin fallbacksrc (0.7.0), for RSTP/H264 streaming work fine. However, I have problems with HTTP/MJPEG.
To simplify the example, I am using the uri property, where I indicate the address of the stream.
`gst-lau...Hi all!!
I am testing plugin fallbacksrc (0.7.0), for RSTP/H264 streaming work fine. However, I have problems with HTTP/MJPEG.
To simplify the example, I am using the uri property, where I indicate the address of the stream.
`gst-launch-1.0 fallbacksrc uri=http://192.168.0.231/video.mjpg ! videoconvert ! waylandsink`
The problem is that it does not link to the streaming and when the timeout ends it switches to the black image.
Is it possible to use HTTP/MJPEG streams with the fallbacksrc plugin?
Is it necessary to use any extra plugins?
[Attach log](/uploads/e3ece317e45ce38caa79f39a35d61beb/gst.log).
Usual pipeline that I used for HTTP is:
`gst-launch-1.0 -v souphttpsrc is-live=true location=http://192.168.0.231/video.mjpg ! multipartdemux ! jpegparse ! avdec_mjpeg ! waylandsink`
and pipeline with playbin work.
`gst-launch-1.0 -v playbin uri=http://192.168.0.231/video.mjpg`
Thanks!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/723Gst_video_meta_set_alignment() passes argument by value2021-08-11T19:43:34ZStefanSalewskiGst_video_meta_set_alignment() passes argument by value https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. A... https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. At least I can currently not remember a function which passes structs by value. For language bindings one has to be a bit carefully in this case.
Comment of Sebastian Dröge GNOME Team:
>That seems like an oversight. It should really be passed by reference to make automated bindings happy. Please create an issue
References: https://discourse.gnome.org/t/gst-video-meta-set-alignment-passes-argument-by-value/7258https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/932Gst_video_meta_set_alignment() passes argument by value2021-09-24T13:26:31ZStefanSalewskiGst_video_meta_set_alignment() passes argument by value https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. A... https://gstreamer.freedesktop.org/documentation/video/gstvideometa.html?gi-language=c#gst_video_meta_set_alignment
No that is not wrong, but a bit surprising. As most GTK related functions seems to pass structs always as references. At least I can currently not remember a function which passes structs by value. For language bindings one has to be a bit carefully in this case.
Comment of Sebastian Dröge GNOME Team:
>That seems like an oversight. It should really be passed by reference to make automated bindings happy. Please create an issue
References: https://discourse.gnome.org/t/gst-video-meta-set-alignment-passes-argument-by-value/7258https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/933gl: memory leak in gstglwindow_eagl.m2023-07-27T11:22:55Zezero9gl: memory leak in gstglwindow_eagl.mI'm faced with a memory leak in gst-libs/gst/gl/eagl/gstglwindow_eagl.m in iOS.
I cleaned the pipeline, but the `priv->internal_view` was not freed.
How to release the 'priv->internal_view'?
![memory_leak](/uploads/61d8393f24793b245887...I'm faced with a memory leak in gst-libs/gst/gl/eagl/gstglwindow_eagl.m in iOS.
I cleaned the pipeline, but the `priv->internal_view` was not freed.
How to release the 'priv->internal_view'?
![memory_leak](/uploads/61d8393f24793b245887bd2a59e78097/memory_leak.png)
please refer to My clean up code below.
`
pipeline = gst_parse_launch(pipeline_str, NULL);
videosink = gst_bin_get_by_interface(GST_BIN(pipeline), GST_TYPE_VIDEO_OVERLAY);
main_loop = g_main_loop_new(NULL, FALSE);
gst_video_overlay_set_window_handle(GST_VIDEO_OVERLAY(videosink), (guintptr) preview);
gst_element_set_state(pipeline, GST_STATE_PLAYING);
g_main_loop_run(main_loop);
gst_element_set_state (pipeline, GST_STATE_NULL);
gst_object_unref (pipeline);
gst_object_unref(videosink);`https://gitlab.freedesktop.org/gstreamer/orc/-/issues/37ppc64le segfaults2021-09-22T06:39:13ZVítppc64le segfaultsI am observing issues with ORC on ppc64le when running active storage (part of Ruby on Rails) test suite via VIPS:
~~~
Thread 10 "worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc77ef0e0 (LWP 80455)]
0x00...I am observing issues with ORC on ppc64le when running active storage (part of Ruby on Rails) test suite via VIPS:
~~~
Thread 10 "worker" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc77ef0e0 (LWP 80455)]
0x00007ffff0010344 in ?? ()
#0 0x00007ffff0010344 in ?? ()
No symbol table info available.
#1 0x00007ffff0622428 in orc_executor_run () from /lib64/liborc-0.4.so.0
No symbol table info available.
#2 0x00007fffc77eaee0 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 10 "worker" received signal SIGSEGV, Segmentation fault.
0x00007ffff7d3d148 in check_stack_overflow () from /lib64/libruby.so.3.0
#0 0x00007ffff7d3d148 in check_stack_overflow () from /lib64/libruby.so.3.0
No symbol table info available.
#1 0x00007ffff7d3d278 in sigsegv () from /lib64/libruby.so.3.0
No symbol table info available.
#2 <signal handler called>
No locals.
#3 0x00007ffff0010344 in ?? ()
No symbol table info available.
#4 0x00007ffff0622428 in orc_executor_run () from /lib64/liborc-0.4.so.0
No symbol table info available.
#5 0x00007fffc77eaee0 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
~~~
Stopping GDB on `orc_executor_run`, this is the backtrace:
~~~
Thread 10 "worker" hit Breakpoint 1, 0x00007ffff05b2404 in orc_executor_run () from /lib64/liborc-0.4.so.0
#0 0x00007ffff05b2404 in orc_executor_run () from /lib64/liborc-0.4.so.0
No symbol table info available.
#1 0x00007ffff13ee108 in vips_executor_run () from /lib64/libvips.so.42
No symbol table info available.
#2 0x00007ffff11fc83c in vips_reducev_vector_gen(_VipsRegion*, void*, void*, void*, int*) () from /lib64/libvips.so.42
No symbol table info available.
#3 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#4 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#5 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#6 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#7 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#8 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#9 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#10 0x00007ffff128e548 in vips_copy_gen.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#11 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#12 0x00007ffff13f7144 in vips_region_prepare_to_generate () from /lib64/libvips.so.42
No symbol table info available.
#13 0x00007ffff13f7454 in vips_region_prepare_to () from /lib64/libvips.so.42
No symbol table info available.
#14 0x00007ffff1299084 in vips_embed_base_gen () from /lib64/libvips.so.42
No symbol table info available.
#15 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#16 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#17 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#18 0x00007ffff11f2188 in vips_reduceh_gen(_VipsRegion*, void*, void*, void*, int*) () from /lib64/libvips.so.42
No symbol table info available.
#19 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#20 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#21 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#22 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#23 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#24 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#25 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#26 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#27 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#28 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#29 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#30 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#31 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#32 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#33 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#34 0x00007ffff13cb798 in vips_image_write_gen () from /lib64/libvips.so.42
No symbol table info available.
#35 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#36 0x00007ffff13df8b8 in vips_region_fill () from /lib64/libvips.so.42
No symbol table info available.
#37 0x00007ffff13f2efc in vips_region_prepare () from /lib64/libvips.so.42
No symbol table info available.
#38 0x00007ffff128e548 in vips_copy_gen.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#39 0x00007ffff13d8788 in vips_region_generate.lto_priv () from /lib64/libvips.so.42
No symbol table info available.
#40 0x00007ffff13f7144 in vips_region_prepare_to_generate () from /lib64/libvips.so.42
No symbol table info available.
#41 0x00007ffff13f7454 in vips_region_prepare_to () from /lib64/libvips.so.42
No symbol table info available.
#42 0x00007ffff13d7f78 in wbuffer_work_fn () from /lib64/libvips.so.42
No symbol table info available.
#43 0x00007ffff13ef50c in vips_thread_main_loop () from /lib64/libvips.so.42
No symbol table info available.
#44 0x00007ffff13f00a8 in vips_thread_run () from /lib64/libvips.so.42
No symbol table info available.
#45 0x00007ffff1994c30 in g_thread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#46 0x00007ffff19c5448 in linux_pthread_proxy () from /lib64/libglib-2.0.so.0
No symbol table info available.
#47 0x00007ffff7839c10 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#48 0x00007ffff7a0d310 in clone () from /lib64/libc.so.6
No symbol table info available.
~~~
~~~
$ cat /etc/system-release
Fedora release 35 (Rawhide)
$ rpm -q orc
orc-0.4.31-5.fc35.ppc64le
~~~
https://bugzilla.redhat.com/show_bug.cgi?id=1917540https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/914rtpjitterbuffer: rtx-next-seqnum=true causes packets discarded although they ...2024-03-20T11:35:52ZSebastian Drögertpjitterbuffer: rtx-next-seqnum=true causes packets discarded although they arrive in timeThe sequence of events is as follows
1. packet 1 arrives, expected timer for packet 2 is scheduled based on some packet rate estimate
2. expected timer triggers and goes into the "reschedule as LOST timer" case, effectively updating...The sequence of events is as follows
1. packet 1 arrives, expected timer for packet 2 is scheduled based on some packet rate estimate
2. expected timer triggers and goes into the "reschedule as LOST timer" case, effectively updating `next_in_seqnum`
3. packet 2 arrives in time (maybe the sender shortly stopped capturing, skipped a frame before its encoder, or ...) but is discarded because `next_in_seqnum` was already updated
This might've been introduced by 63c7a9ae430db991746dc4b13d26d4f7945b2dc1 but I can't really test that because the change is entangled with lots of other changes, and my application won't work with a jitterbuffer before that version because it requires newer features.
The commit itself looks correct to me though, however I think there somewhere needs to be a distinction between RTX timers based on estimations and RTX timers that are set when a packet with a higher seqnum is arriving (and we actually *know* that the missing packet should've arrived by now).
Converting expected timers to lost timers before seeing a higher seqnum is wrong in any case.
----
Independent of that we should probably consider changing the default for `rtx-next-seqnum` to `false` as the code is quite dubious, and Pexip for example disable it because it causes more problems than it solves.
CC @hgr @ndufresne