gst-plugins-good issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues2024-03-28T09:21:55Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/1042qml6glsink: impossible to render in parallel into 2 (or more) qml6glsinks2024-03-28T09:21:55ZRobert Guziolowskiqml6glsink: impossible to render in parallel into 2 (or more) qml6glsinksCreate a simple QML application with 2 (or more) qml6glsinks with 2 different pipelines (see attached files).
**Observed behavior**
The application crashes or shows only the stream attached to the first GstGLQt6VideoItem item from the ...Create a simple QML application with 2 (or more) qml6glsinks with 2 different pipelines (see attached files).
**Observed behavior**
The application crashes or shows only the stream attached to the first GstGLQt6VideoItem item from the .qml file (in the test application the _snow_ pattern.
**Expected behavior**
Two streams shown independently (_snow_ and _smpte_ patterns).
**Suggested correction**
I found the correction (in my case) for this problem changing the code of the destructor of GstQSGTexture (gstqsg6material.cc file) from
`delete m_texture;`
to
`m_texture->deleteLater();`
Edit: [merge request](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6467) ready.
~~I'll create a merge request soon.~~
[CMakeLists.txt](/uploads/205dbecbffd2f9bf6eaa2d27e699ed7b/CMakeLists.txt)
[main.cpp](/uploads/a8bc6bb2b07640b8c87e1d178e3436a2/main.cpp)
[Main.qml](/uploads/e6e90727abf79eaaae869be14d5435fb/Main.qml)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/691rtpmp2tdepay: should advertise clock-rate=90000 by default to avoid bogus neg...2024-03-16T10:10:47ZTim-Philipp Müllertim@centricular.comrtpmp2tdepay: should advertise clock-rate=90000 by default to avoid bogus negotiation to clock-rate=1 if rate is missing in udpsrc caps`gst-launch-1.0 udpsrc caps=application/x-rtp,media=video ! rtpjitterbuffer ! rtpmp2tdepay ! fakesink -v`
makes `udpsrc` negotiate the following caps by default:
> application/x-rtp, media=(string)video, **clock-rate=(int)1**, encoding...`gst-launch-1.0 udpsrc caps=application/x-rtp,media=video ! rtpjitterbuffer ! rtpmp2tdepay ! fakesink -v`
makes `udpsrc` negotiate the following caps by default:
> application/x-rtp, media=(string)video, **clock-rate=(int)1**, encoding-name=(string)MP2T
which leads to two problems:
1. `rtpjitterbuffer` doesn't warn any more that the clock-rate is absent from the input caps
2. constant `rtpjitterbuffer.c:572:calculate_skew: delta - skew: 0:49:59.966666351 too big, reset skew` because timestamp interpretation is bogus now.
I think `rtpmp2tdepay` should advertise the normal 90000 clock-rate in its caps by default (as per the spec). I will prepare an MR for that.
Secondly, the fact that `udpsrc` does intersection/fixation here with the downstream caps seems a bit dubious. I can see how it makes things work with depayloaders where there's a standard rate, but in this case it's really quite wrong. I wonder if we should filter out int ranges for the clock-rate field "somewhere" (probably in the depayloader base class or `rtpjitterbuffer`)?Tim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/581rtpulpfec: Not usable as a generic FEC mechanism2024-02-08T05:25:19ZSebastian Drögertpulpfec: Not usable as a generic FEC mechanismThis is a result of how ULPFEC works and how GStreamer works.
The problem here is that ULPFEC uses the same seqnum space for FEC packets as for non-FEC packets, so whenever you lost a packet you don't know if it was a FEC packet (uninte...This is a result of how ULPFEC works and how GStreamer works.
The problem here is that ULPFEC uses the same seqnum space for FEC packets as for non-FEC packets, so whenever you lost a packet you don't know if it was a FEC packet (uninteresting) or a non-FEC packet (problematic, needs to be recovered somehow).
This means that when `rtpjitterbuffer` notices a missing packet (FEC or not), it will send a lost packet event and will also mark the next buffer as a discontinuity. The lost packet event is already ignored in this case by the depayloader (it has a "might be FEC" flag).
The discont flag on the other hand will cause the following depayloader to drop any data it has currently queued up (e.g. to rebuild a fragmented frame from multiple packets), and also causes the next output to have a discont flag so this goes up to the sinks and e.g. baseaudiosink will resync its ringbuffer then (inserting silence or dropping samples as needed).
This means that with a higher FEC percentage (say 100%), you can get a theoretically higher recovery rate but nonetheless bad user experience due to data being dropped and resyncing because of the discont flag. Every lost FEC packet specifically will cause a discont flag, so the more FEC packets you have the more likely it is that one is lost and the more likely you drop data unnecessarily and cause resyncing.
I don't know how the ULPFEC designers envisioned this to be used, but I don't think it is possible to use ULPFEC as a generic FEC mechanism without further mechanisms to mitigate the above problem.
In my application I'm now adding another sequence number in an RTP header extension to distinguish between actually missing packets or only missing FEC packets or otherwise irrelevant packet loss (because recovered for example), and set the discont flag on buffers according to this second layer of sequence numbers.
Pexip (CC @hgr @fludkov) implemented a similar mechanism in the VP8/VP9 depayloaders based on actual bitstream parsing and taking: https://github.com/pexip/gst-plugins-good/commits/master
----
There are multiple things to do here
- Implement a non-stupid FEC mechanism like flexfec or whatever, and discourage usage of ULPFEC
- Document the uselessness of ULPFEC more visible so that people don't just try using it and then are disappointed that it does not improve anything or even worsens the situation
- Merge the Pexip patches in one form or another for making ULPFEC work at least for VP8/VP9
- Check if similar work can also be done for other codecs (or was done already? @hgr @fludkov)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/782gtkglsink: spurious X11 error2023-10-25T07:48:06ZIvan Molodetskikhgtkglsink: spurious X11 errorI have a Flatpak app which displays a video in a `GtkGlSink`: https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.VideoTrimmer
When running under a Ubuntu 18.04 VM under X11, it frequently, but not always, crashes with an X11 error...I have a Flatpak app which displays a video in a `GtkGlSink`: https://flathub.org/apps/details/org.gnome.gitlab.YaLTeR.VideoTrimmer
When running under a Ubuntu 18.04 VM under X11, it frequently, but not always, crashes with an X11 error upon opening the screen with the `GtkGlSink`:
```
(video-trimmer:2): Gdk-ERROR **: 14:57:15.591: The program 'video-trimmer' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 398 error_code 8 request_code 150 (GLX) minor_code 34)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
```
Sometimes this message is also printed:
```
Xlib: sequence lost (0x1027c > 0x27f) in reply type 0x0!
```
Doing as the error message suggests, I get this backtrace:
```
#0 0x00007ffff7625c80 in gdk_x_error (xdisplay=0x5555558e7440, error=0x7fff93ffe850) at gdkmain-x11.c:271
#1 0x00007ffff7ebb30b in _XError (dpy=0x5555558e7440, rep=0x7fff93ffe950) at ../../src/XlibInt.c:1489
#2 0x00007fffedd2f10f in () at /usr/lib/x86_64-linux-gnu/GL/default/lib/libGLX_mesa.so.0
#3 0x00007fffedd29030 in () at /usr/lib/x86_64-linux-gnu/GL/default/lib/libGLX_mesa.so.0
#4 0x00007fffeed1d44c in glXCreateContextAttribsARB (dpy=0x5555558e7440, config=0x555555d3c030, share_list=0x555555dcf7f0, direct=1, attrib_list=0x7fff93ffeaa0) at ../../../src/GLX/libglx.c:305
#5 0x00007fffeeea5b4d in _create_context_with_flags (contextFlags=1, profileMask=1, minor=<optimized out>, major=<optimized out>, share_context=0x555555dcf7f0, fbconfig=0x555555d3c030, dpy=0x5555558e7440, context_glx=0x555555b787b0 [GstGLContextGLX]) at ../gst-libs/gst/gl/x11/gstglcontext_glx.c:182
#6 0x00007fffeeea5b4d in gst_gl_context_glx_create_context (context=0x555555b787b0 [GstGLContextGLX], gl_api=65539, other_context=<optimized out>, error=0x7ffff4841290) at ../gst-libs/gst/gl/x11/gstglcontext_glx.c:263
#7 0x00007fffeee7e5de in gst_gl_context_create_thread (context=0x555555b787b0 [GstGLContextGLX]) at ../gst-libs/gst/gl/gstglcontext.c:1238
#8 0x00007ffff7111731 in g_thread_proxy (data=0x7fffe4003520) at ../glib/gthread.c:807
#9 0x00007ffff6f255e2 in start_thread (arg=<optimized out>) at pthread_create.c:479
#10 0x00007ffff6e38413 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
Full backtrace:
```
#0 0x00007ffff7625c80 in gdk_x_error (xdisplay=0x5555558e7440, error=0x7fff93ffe850) at gdkmain-x11.c:271
#1 0x00007ffff7ebb30b in _XError (dpy=0x5555558e7440, rep=0x7fff93ffe950) at ../../src/XlibInt.c:1489
rtn_val = <optimized out>
event = {type = 0, xany = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416}, xkey = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, root = 140735676410080, subwindow = 140735676410048, time = 93824995990688, x = -1811945288, y = 32767, x_root = -155382679, y_root = 32767, state = 636, keycode = 0, same_screen = -155382363}, xbutton = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, root = 140735676410080, subwindow = 140735676410048, time = 93824995990688, x = -1811945288, y = 32767, x_root = -155382679, y_root = 32767, state = 636, button = 0, same_screen = -155382363}, xmotion = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, root = 140735676410080, subwindow = 140735676410048, time = 93824995990688, x = -1811945288, y = 32767, x_root = -155382679, y_root = 32767, state = 636, is_hint = 0 '\000', same_screen = -155382363}, xcrossing = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, root = 140735676410080, subwindow = 140735676410048, time = 93824995990688, x = -1811945288, y = 32767, x_root = -155382679, y_root = 32767, mode = 636, detail = 0, same_screen = -155382363, focus = 32767, state = 4}, xfocus = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, mode = -1811945248, detail = 32767}, xexpose = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, x = -1811945248, y = 32767, width = -1811945280, height = 32767, count = 1435409568}, xgraphicsexpose = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, drawable = 140735661905416, x = -1811945248, y = 32767, width = -1811945280, height = 32767, count = 1435409568, major_code = 21845, minor_code = -1811945288}, xnoexpose = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, drawable = 140735661905416, major_code = -1811945248, minor_code = 32767}, xvisibility = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, state = -1811945248}, xcreatewindow = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, parent = 140735661905416, window = 140735676410080, x = -1811945280, y = 32767, width = 1435409568, height = 21845, border_width = -1811945288, override_redirect = 32767}, xdestroywindow = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080}, xunmap = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, from_configure = -1811945280}, xmap = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, override_redirect = -1811945280}, xmaprequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, parent = 140735661905416, window = 140735676410080}, xreparent = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, parent = 140735676410048, x = 1435409568, y = 21845, override_redirect = -1811945288}, xconfigure = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, x = -1811945280, y = 32767, width = 1435409568, height = 21845, border_width = -1811945288, above = 140737332972649, override_redirect = 636}, xgravity = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, x = -1811945280, y = 32767}, xresizerequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, width = -1811945248, height = 32767}, xconfigurerequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, parent = 140735661905416, window = 140735676410080, x = -1811945280, y = 32767, width = 1435409568, height = 21845, border_width = -1811945288, above = 140737332972649, detail = 636, value_mask = 140737332972965}, xcirculate = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, event = 140735661905416, window = 140735676410080, place = -1811945280}, xcirculaterequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, parent = 140735661905416, window = 140735676410080, place = -1811945280}, xproperty = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, atom = 140735676410080, time = 140735676410048, state = 1435409568}, xselectionclear = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, selection = 140735676410080, time = 140735676410048}, xselectionrequest = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, owner = 140735661905416, requestor = 140735676410080, selection = 140735676410048, target = 93824995990688, property = 140735676410040, time = 140737332972649}, xselection = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, requestor = 140735661905416, selection = 140735676410080, target = 140735676410048, property = 93824995990688, time = 140735676410040}, xcolormap = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, colormap = 140735676410080, new = -1811945280, state = 32767}, xclient = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, message_type = 140735676410080, format = -1811945280, data = {b = "\240\234\216UUU\000\000\270\350\377\223\377\177\000\000i\f\275", <incomplete sequence \366>, s = {-25440, 21902, 21845, 0, -5960, -27649, 32767, 0, 3177, -2371}, l = {93824995990688, 140735676410040, 140737332972649, 636, 140737332972965}}}, xmapping = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, request = -1811945248, first_keycode = 32767, count = -1811945280}, xerror = {type = 0, display = 0x5555558e7440, resourceid = 33554483, serial = 636, error_code = 8 '\b', request_code = 150 '\226', minor_code = 34 '"'}, xkeymap = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, window = 140735661905416, key_vector = "\340\350\377\223\377\177\000\000\300\350\377\223\377\177\000\000\240\234\216UUU\000\000\270\350\377\223\377\177\000"}, xgeneric = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, extension = -1826449912, evtype = 32767}, xcookie = {type = 0, serial = 93824995980352, send_event = 33554483, display = 0x27c, extension = -1826449912, evtype = 32767, cookie = 2483022048, data = 0x7fff93ffe8c0}, pad = {140733193388032, 93824995980352, 33554483, 636, 140735661905416, 140735676410080, 140735676410048, 93824995990688, 140735676410040, 140737332972649, 636, 140737332972965, 4, 0, 636, 140735676410080, 0, 0, 0, 0, 0, 0, 17179869184, 0}}
async = <optimized out>
next = <optimized out>
#2 0x00007fffedd2f10f in () at /usr/lib/x86_64-linux-gnu/GL/default/lib/libGLX_mesa.so.0
#3 0x00007fffedd29030 in () at /usr/lib/x86_64-linux-gnu/GL/default/lib/libGLX_mesa.so.0
#4 0x00007fffeed1d44c in glXCreateContextAttribsARB (dpy=0x5555558e7440, config=0x555555d3c030, share_list=0x555555dcf7f0, direct=1, attrib_list=0x7fff93ffeaa0) at ../../../src/GLX/libglx.c:305
context = 0x0
vendor = 0x555555c28c00
#5 0x00007fffeeea5b4d in _create_context_with_flags (contextFlags=1, profileMask=1, minor=<optimized out>, major=<optimized out>, share_context=0x555555dcf7f0, fbconfig=0x555555d3c030, dpy=0x5555558e7440, context_glx=0x555555b787b0 [GstGLContextGLX]) at ../gst-libs/gst/gl/x11/gstglcontext_glx.c:182
ret = <optimized out>
attribs = {8337, 4, 8338, 5, 8340, 1, 37158, 1, 0, 1, 8, 1, 9, 1, 10, 1, 12, 16, 5, 1}
x_error = 0
n = <optimized out>
profileMask = 1
contextFlags = 1
context_glx = 0x555555b787b0 [GstGLContextGLX]
window = 0x555555bbc8b0 [GstGLWindowX11]
window_x11 = 0x555555bbc8b0 [GstGLWindowX11]
display = 0x55555592a5f0 [GstGLDisplayX11]
create_context = <optimized out>
glx_exts = <optimized out>
device = 0x5555558e7440
external_gl_context = 93825001125872
__func__ = "gst_gl_context_glx_create_context"
#6 0x00007fffeeea5b4d in gst_gl_context_glx_create_context (context=0x555555b787b0 [GstGLContextGLX], gl_api=65539, other_context=<optimized out>, error=0x7ffff4841290) at ../gst-libs/gst/gl/x11/gstglcontext_glx.c:263
profileMask = 1
contextFlags = 1
context_glx = 0x555555b787b0 [GstGLContextGLX]
window = 0x555555bbc8b0 [GstGLWindowX11]
window_x11 = 0x555555bbc8b0 [GstGLWindowX11]
display = 0x55555592a5f0 [GstGLDisplayX11]
create_context = <optimized out>
glx_exts = <optimized out>
device = 0x5555558e7440
external_gl_context = 93825001125872
__func__ = "gst_gl_context_glx_create_context"
#7 0x00007fffeee7e5de in gst_gl_context_create_thread (context=0x555555b787b0 [GstGLContextGLX]) at ../gst-libs/gst/gl/gstglcontext.c:1238
context_class = 0x7fffe4008380
window_class = 0x7fffe4009540
compiled_api = 65539
user_api = GST_GL_API_ANY
gl_api = <optimized out>
display_api = GST_GL_API_ANY
api_string = <optimized out>
compiled_api_s = 0x7fffe40021a0 "opengl opengl3 gles2"
user_api_s = 0x7fffe4009900 "any"
display_api_s = 0x7fff88001360 "any"
user_choice = <optimized out>
error = 0x7ffff4841290
other_context = 0x555555b5c190 [GstGLWrappedContext]
__func__ = "gst_gl_context_create_thread"
#8 0x00007ffff7111731 in g_thread_proxy (data=0x7fffe4003520) at ../glib/gthread.c:807
thread = 0x7fffe4003520
__func__ = "g_thread_proxy"
#9 0x00007ffff6f255e2 in start_thread (arg=<optimized out>) at pthread_create.c:479
ret = <optimized out>
pd = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735676413696, -8133131588441933399, 140737295683806, 140737295683807, 140735676411008, 140735676413696, 8133052422939015593, 8133116158072781225}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
#10 0x00007ffff6e38413 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
Runtimes I'm using:
```
Application ID Version Branch
org.freedesktop.Platform.GL.default 19.08
org.freedesktop.Platform.ffmpeg-full 19.08
org.freedesktop.Platform.openh264 2.1.0 2.0
org.gnome.Platform 3.36
org.gnome.Sdk 3.36
org.gnome.gitlab.YaLTeR.VideoTrimmer 0.2.0 stable
org.gnome.gitlab.YaLTeR.VideoTrimmerDevel 0.2.0 master
org.gtk.Gtk3theme.Ambiance 3.22
```
I couldn't figure out what `.Debug` to install to get libGLX debug info.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/32rtspsrc: backward playback2023-10-13T23:43:34ZBugzilla Migration Userrtspsrc: backward playback## Submitted by Tibor Kocsis
**[Link to original bug (#626811)](https://bugzilla.gnome.org/show_bug.cgi?id=626811)**
## Description
Hi,
are you planning to implement the support of backward playback (seek with negative rate on ...## Submitted by Tibor Kocsis
**[Link to original bug (#626811)](https://bugzilla.gnome.org/show_bug.cgi?id=626811)**
## Description
Hi,
are you planning to implement the support of backward playback (seek with negative rate on the client side) in rtspsrc? Is there any proposed release date for that? What are the reasons it isn't ready yet, maybe there are technical issues?
Regards
Tibor2023-10-21https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/254videocrop: Access violation reading2023-10-13T15:38:48ZBugzilla Migration Uservideocrop: Access violation reading## Submitted by Zakhar
**[Link to original bug (#761163)](https://bugzilla.gnome.org/show_bug.cgi?id=761163)**
## Description
1. DESCRIPTION:
If set properties (left, top, right, bottom) for videocrop while pipeline playing, it cr...## Submitted by Zakhar
**[Link to original bug (#761163)](https://bugzilla.gnome.org/show_bug.cgi?id=761163)**
## Description
1. DESCRIPTION:
If set properties (left, top, right, bottom) for videocrop while pipeline playing, it crashes sometimes with "Access violation reading".
2. HOW TO REPRODUCE:
I ofen reproduce this bug with next several elements:
videotestsrc ! video/x-raw, framerate=25/1, width=1920, height=1088 ! videocrop ! autovideosink
When the pipeline is on PLAYING state I set random values for videocrop properties (left, top, right, bottom) several times per second. After some time program crashes with "Access violation reading".
It can be reproduced only with one setting while playing. But that rarely happens.
It is reproduced on RGB and YUV frame format both.
3. STACK
msvcrt.dll!000007fefea511be()
libgstvideocrop.dll!00000000150e1e1c()
libgstvideo-1.0-0.dll!000000006d41d61f()
libgstbase-1.0-0.dll!00000000198e6930()
libgstbase-1.0-0.dll!00000000198e63ba()
libgstreamer-1.0-0.dll!0000000061481054()
libgstbase-1.0-0.dll!00000000198e638d()
libgstreamer-1.0-0.dll!0000000061481054()
libgstbase-1.0-0.dll!00000000198e2436()
libgstreamer-1.0-0.dll!00000000614af514()
libglib-2.0-0.dll!00000000686154b5()
libglib-2.0-0.dll!0000000068614cc9()
libglib-2.0-0.dll!000000006863103a()
[External Code]
Version: 1.6.3https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/320rtpL16depay, rtpL24depay: support depayloading in place2023-10-12T18:26:04ZBugzilla Migration UserrtpL16depay, rtpL24depay: support depayloading in place## Submitted by Petr Kulhavy
**[Link to original bug (#773833)](https://bugzilla.gnome.org/show_bug.cgi?id=773833)**
## Description
It seems that rtpL16depay, rtpL24depay (and I guess also other rtp-depay functions) are failing to d...## Submitted by Petr Kulhavy
**[Link to original bug (#773833)](https://bugzilla.gnome.org/show_bug.cgi?id=773833)**
## Description
It seems that rtpL16depay, rtpL24depay (and I guess also other rtp-depay functions) are failing to depayload in place. It always allocates a new buffer and copies the payload.
This is the log I'm seeing:
```
0:00:13.489419481 1060 0x1ec5150 DEBUG rtpL16depay gstrtpL16depay.c:243:gst_rtp_L16_depay_process:`<rtpl16depay0>` got payload of 192 bytes
0:00:13.489596481 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:798:gst_buffer_new: new 0x75c05370
0:00:13.489760981 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:2038:gst_buffer_copy_region: new region copy 0x75c05370 of 0x75c054b0 12-192
0:00:13.490969772 1060 0x1ec5150 LOG GST_BUFFER gstbuffer.c:514:gst_buffer_copy_into: copy 0x75c054b0 to 0x75c05370, offset 12-192/204
--
0:00:13.493352979 1060 0x1ec5150 TRACE GST_LOCKING gstminiobject.c:177:gst_mini_object_lock: lock 0x1ecb690: state 00020000, access_mode 3
0:00:13.493546312 1060 0x1ec5150 DEBUG GST_LOCKING gstminiobject.c:212:gst_mini_object_lock: lock failed 0x1ecb690: state 00020000, access_mode 3
0:00:13.493717020 1060 0x1ec5150 DEBUG GST_MEMORY gstmemory.c:317:gst_memory_map: mem 0x1ecb690: lock 3 failed
0:00:13.493910270 1060 0x1ec5150 TRACE GST_REFCOUNTING gstobject.c:249:gst_object_ref:`<allocatorsysmem0>` 0x1ddc010 ref 6->7
0:00:13.494091270 1060 0x1ec5150 DEBUG GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0x1ecb578, maxsize:195 offset:0 size:192
0:00:13.494364978 1060 0x1ec5150 DEBUG GST_PERFORMANCE gstallocator.c:462:_sysmem_copy: memcpy 192 memory 0x1ecb690 -> 0x1ecb578
```
And this is the command:
`GST_DEBUG=9 gst-launch-1.0 audiotestsrc is-live=true wave=silence samplesperbuffer=48 ! "audio/x-raw,format=(string)S16BE,rate=(int)48000,channels=(int)2,channel-mask=(int)0x3" ! rtpL16pay ! rtpL16depay ! fakesink
2>&1 | grep -B 5 copy`
It happens in gst_audio_buffer_reorder_channels() when mapping the buffer read-write. It doesn't really matter what the source is, the same happens with udpsrc.
--
The other thing here is that if the channels don't require reordering (like in my case) the buffer shouldn't be remapped read-write. Otherwise the potential buffer copy is redundant.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/21[wavpack] correction file decoding support2023-10-06T13:25:10ZBugzilla Migration User[wavpack] correction file decoding support## Submitted by Kai-Chieh Ku
**[Link to original bug (#607835)](https://bugzilla.gnome.org/show_bug.cgi?id=607835)**
## Description
According to the mailing list (gstreamer-devel), a man told me that current wavpack plugin can not d...## Submitted by Kai-Chieh Ku
**[Link to original bug (#607835)](https://bugzilla.gnome.org/show_bug.cgi?id=607835)**
## Description
According to the mailing list (gstreamer-devel), a man told me that current wavpack plugin can not decode WavPack correction files. It can parse those files, though.
Correction files are need to be support because it is the most important feature that other major codecs (e.g. FLAC) don't support.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/18[PLUGIN-MOVE] Move assrender to gst-plugins-good2023-10-06T13:25:08ZBugzilla Migration User[PLUGIN-MOVE] Move assrender to gst-plugins-good## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#604067)](https://bugzilla.gnome.org/show_bug.cgi?id=604067)**
## Description
See summary. The plugin is mature now, and together with latest git of gst-plugins-base ...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#604067)](https://bugzilla.gnome.org/show_bug.cgi?id=604067)**
## Description
See summary. The plugin is mature now, and together with latest git of gst-plugins-base it will be automatically used for ASS/SSA subtitles and provides much better visual results because it supports all ASS/SSA features.
There's no test for it and I don't know how one should look, documentation will come in the next days but that won't contain much interesting information (because the element is meant to be automatically used).
### Depends on
* [Bug 610857](https://bugzilla.gnome.org/show_bug.cgi?id=610857)
* [Bug 610904](https://bugzilla.gnome.org/show_bug.cgi?id=610904)
* [Bug 610906](https://bugzilla.gnome.org/show_bug.cgi?id=610906)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/16[qtdemux] parse support for clean aperture2023-10-06T13:25:07ZBugzilla Migration User[qtdemux] parse support for clean aperture## Submitted by Philippe Normand `@philn`
**[Link to original bug (#596571)](https://bugzilla.gnome.org/show_bug.cgi?id=596571)**
## Description
The mov file in https://bugzilla.gnome.org/show_bug.cgi?id=596319 has clean aperture da...## Submitted by Philippe Normand `@philn`
**[Link to original bug (#596571)](https://bugzilla.gnome.org/show_bug.cgi?id=596571)**
## Description
The mov file in https://bugzilla.gnome.org/show_bug.cgi?id=596319 has clean aperture data too. It doesn't seem to be correctly parsed by qtdemux.
Extract of qtdump:
clean aperture (clap)
cleanApertureWidthN 41472
cleanApertureWidthD 59
cleanApertureHeightN 576
cleanApertureHeightD 1
horizOffN 0
horizOffD 1
vertOffN 0
vertOffD 1https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/15rtspsrc: (network) timeout behaviour inconsistent between TCP and UDP2023-10-06T13:25:04ZBugzilla Migration Userrtspsrc: (network) timeout behaviour inconsistent between TCP and UDP## Submitted by Mark Nauwelaerts `@mnauw`
**[Link to original bug (#588144)](https://bugzilla.gnome.org/show_bug.cgi?id=588144)**
## Description
rtspsrc's tcp_timeout property prevents rtspsrc from "hanging" if network timeout/inter...## Submitted by Mark Nauwelaerts `@mnauw`
**[Link to original bug (#588144)](https://bugzilla.gnome.org/show_bug.cgi?id=588144)**
## Description
rtspsrc's tcp_timeout property prevents rtspsrc from "hanging" if network timeout/interruption occurs during streaming (or interaction with RTSP server). However, no such (stringent) checks are performed when UDP happens to be selected (there may be some sender timeout detection in rtpbin/jitterbuffer, but the net overall effect/user experience is not quite the same).
Although this may or may not be intentional and/or related to UDP issues (e.g. inherently less reliable than TCP), possible patch follows anyway.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/13avimux: Support DivX subtitles2023-10-06T13:25:04ZBugzilla Migration Useravimux: Support DivX subtitles## Submitted by an unknown user
**[Link to original bug (#581296)](https://bugzilla.gnome.org/show_bug.cgi?id=581296)**
## Description
Seems DivX got a subtitle system for Avi files. Seems to break the AVI specification though so th...## Submitted by an unknown user
**[Link to original bug (#581296)](https://bugzilla.gnome.org/show_bug.cgi?id=581296)**
## Description
Seems DivX got a subtitle system for Avi files. Seems to break the AVI specification though so they refer to the new files as divx files.
Misc tools generating this format:
http://userxp.tripod.com/sub2divx.htm
http://projects.gdion.biz/guides/dmfwithxsub.html
http://labs.divx.com/DivXMuxGUI
There is a SDK with some documentation here:
http://download.divx.com/labs/DivXMediaFormat_SDK_r2.rar
### See also
* [Bug 628429](https://bugzilla.gnome.org/show_bug.cgi?id=628429)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/12Move DVB plugins to -good2023-10-06T13:25:03ZBugzilla Migration UserMove DVB plugins to -good## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#581011)](https://bugzilla.gnome.org/show_bug.cgi?id=581011)**
## Description
Otherwise we can't ship gnome-dvb-daemon in Fedora.## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#581011)](https://bugzilla.gnome.org/show_bug.cgi?id=581011)**
## Description
Otherwise we can't ship gnome-dvb-daemon in Fedora.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/10pulsesink: Add support for custom downmix matrizes2023-10-06T13:25:02ZBugzilla Migration Userpulsesink: Add support for custom downmix matrizes## Submitted by Ross Burton `@ross`
**[Link to original bug (#570791)](https://bugzilla.gnome.org/show_bug.cgi?id=570791)**
## Description
Playing a AC3 movie in Totem with PulseAudio results in bad mixing, meaning I can't hear the ...## Submitted by Ross Burton `@ross`
**[Link to original bug (#570791)](https://bugzilla.gnome.org/show_bug.cgi?id=570791)**
## Description
Playing a AC3 movie in Totem with PulseAudio results in bad mixing, meaning I can't hear the talking over the background noise of the rain.
thaytan helped me debug this: PulseAudio takes all 5 channels and then mixes them badly, when the mixing should happen in the gstreamer pipeline.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/9[qtdemux] detect sprite+tween video2023-10-06T13:25:01ZBugzilla Migration User[qtdemux] detect sprite+tween video## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#564053)](https://bugzilla.gnome.org/show_bug.cgi?id=564053)**
## Description
xine and mplayer think it's an MJPEG video stream.
Most likely a qtdemux problem.## Submitted by Bastien Nocera `@hadess`
**[Link to original bug (#564053)](https://bugzilla.gnome.org/show_bug.cgi?id=564053)**
## Description
xine and mplayer think it's an MJPEG video stream.
Most likely a qtdemux problem.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/6qtdemux cannot handle .mov file with multiple gif based streams2023-10-06T13:24:55ZBugzilla Migration Userqtdemux cannot handle .mov file with multiple gif based streams## Submitted by Gregory Simonian
**[Link to original bug (#546497)](https://bugzilla.gnome.org/show_bug.cgi?id=546497)**
## Description
Please describe the problem:
I am trying to play a movie ( http://www.shsu.edu/~chm_tgc/sounds...## Submitted by Gregory Simonian
**[Link to original bug (#546497)](https://bugzilla.gnome.org/show_bug.cgi?id=546497)**
## Description
Please describe the problem:
I am trying to play a movie ( http://www.shsu.edu/~chm_tgc/sounds/ruther.mov ) which is apparently a .mov encoded as a GIF with audio. I downloaded the video and tried to play it in Totem, but I instead got a "Could not decode stream" error. I have all of the codecs installed and the problem was confirmed by #gstreamer on FreeNode. I tried playing the file on Windows using Quicktime, and it played perfectly, so it couldn't be a problem with the file.
Steps to reproduce:
1. Download http://www.shsu.edu/~chm_tgc/sounds/ruther.mov
2. Open using Totem
Actual results:
A very brief frame of the video displays then Totem gives a "Could not decode stream" error.
Expected results:
Ideally, the whole video should play correctly. However, #gstreamer informed me that there's no decoder for the audio. However, the movie should at least display.
Does this happen every time?
yes
Other information:
I've tried playing it with Totem, Mplayer, and VLC. Totem doesn't work. Mplayer only plays about 20 seconds of the movie. And VLC gets the length of the movie, but doesn't actually play anything.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/759gstreamer pipeline cannot put tags into m4a file2023-08-14T07:59:56Zsezanzebgstreamer pipeline cannot put tags into m4a fileMaybe I'm just doing it wrong, but it somewhat looks like a bug to some nice people from the gstreamer irc and me. I had it posted on StackOverflow as well, but didn't get answers so far: https://stackoverflow.com/questions/62609411/gstr...Maybe I'm just doing it wrong, but it somewhat looks like a bug to some nice people from the gstreamer irc and me. I had it posted on StackOverflow as well, but didn't get answers so far: https://stackoverflow.com/questions/62609411/gstreamer-pipeline-cannot-put-tags-into-m4a-file
Using the following pipeline
```
gst-launch-1.0 filesrc location="/home/mango/Desktop/gst-test/input.mp3" name=src \
! decodebin \
! audioconvert \
! faac \
! mp4mux \
! filesink location="/home/mango/Desktop/gst-test/output.m4a" \
```
I get
`0:00:00.046300293 8742 0x7f4e340779e0 WARN audioencoder gstaudioencoder.c:965:gst_audio_encoder_finish_frame:<faac0> Can't copy metadata because input buffer disappeared`
It also happens with avenc_aac.
mp4mux is in plugins_good, decodebin in plugins_base and faac in plugins_bad according to gst-inspect-1.0, so I don't know which repo to use to post this issue.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/90rtspsrc: server closes the connection but pipelines got stuck2023-07-18T16:33:00ZBugzilla Migration Userrtspsrc: server closes the connection but pipelines got stuck## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#705912)](https://bugzilla.gnome.org/show_bug.cgi?id=705912)**
## Description
I have the following pipeline reading from a RTSP server:
gst-launch-1.0 rts...## Submitted by Guillaume Desmottes `@gdesmott`
**[Link to original bug (#705912)](https://bugzilla.gnome.org/show_bug.cgi?id=705912)**
## Description
I have the following pipeline reading from a RTSP server:
gst-launch-1.0 rtspsrc location="..." protocols=0x00000004 ! decodebin name=demux ! queue ! videoconvert ! vp8enc ! webmmux name=mux ! filesink location=videos/webm/20121123-1_bb_pl.webm demux. ! queue ! audioconvert ! audioresample ! vorbisenc ! mux.
Most of the time it works fine and keep transcoding until the video is done. But sometimes for some reason (the server stopping to send?) the pipeline got stuck blocking my whole script.
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
Redistribute latency...
Redistribute latency...
WARNING: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource.
Additional debug info:
gstrtspsrc.c(3776): gst_rtspsrc_loop_interleaved (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
The server closed the connection.
Shouldn't the element raise an error and so the pipeline can be terminated?
gstreamer1.0-plugins-good:amd64 1.0.7-1~bpo70+1
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/806fragmentation units type b (FU-B) are not supported in gstrtph264depay2023-07-08T10:03:19Zuharbandfragmentation units type b (FU-B) are not supported in gstrtph264depayin gstrtph264depay fu-b packets are not handled correctly. the DON (decoder order number) bytes are ignored
`case 29:
{
/* FU-A Fragmentation unit 5.8 */
/* FU-B Fragmentation unit ...in gstrtph264depay fu-b packets are not handled correctly. the DON (decoder order number) bytes are ignored
`case 29:
{
/* FU-A Fragmentation unit 5.8 */
/* FU-B Fragmentation unit 5.8 */
gboolean S, E;`
note that the bytes ARE taken into account in the STAB-B packet type though:
`case 25:
/* STAP-B Single-time aggregation packet 5.7.1 */
/* 2 byte extra header for DON */
header_len += 2;
/* fallthrough */`
this causes a stream with packetization-mode = 2 (interleaved mode) to fail with this pluignhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/957rtpsession: receiving own RTCP packet triggers SSRC reset (multicast)2023-01-02T16:08:01ZMarc Leemanrtpsession: receiving own RTCP packet triggers SSRC reset (multicast)When using multicast, rtpsession will handle the RTCP packets it receives from itself. As a result, it will conclude that a sender is on the network with the same SSRC (collission detection) and will trigger an SSRC rotation on the paylo...When using multicast, rtpsession will handle the RTCP packets it receives from itself. As a result, it will conclude that a sender is on the network with the same SSRC (collission detection) and will trigger an SSRC rotation on the payloader.
This was detected with rtpsink, but I remember fixing this issue some time ago with using rtpsrc too.
```
0:00:34.327905772 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:3035:rtp_session_process_rtcp: received RTCP packet
0:00:34.327952247 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:2424:rtp_session_process_sr: got SR packet: SSRC 5b942eaf, time 117:48:14.735605623
0:00:34.327975166 3455462 0x7f5c6c06b520 DEBUG rtpsession rtpsession.c:1703:check_collision: Collision for SSRC 5b942eaf from new incoming packet, change our sender ssrc
0:00:34.327997084 3455462 0x7f5c6c06b520 DEBUG rtpsource rtpsource.c:1300:rtp_source_mark_bye: marking SSRC 5b942eaf as BYE, reason: SSRC Collision
0:00:34.328074452 3455462 0x7f5c6c06b520 DEBUG GST_EVENT gstevent.c:310:gst_event_new_custom: creating new event 0x7f5c600054b0 custom-upstream 69121
```
Seems to be related to this issue:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/568