gst-plugins-base issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues2021-09-24T13:26:12Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/855GstRTPHeaderExtension missing Since marker on the struct2021-09-24T13:26:12ZJeff ShanabGstRTPHeaderExtension missing Since marker on the structI grepped the installed directory and I installed both package and dev-package (Windows 10)
I cannot find the GstRTPHeaderExtension mentioned in the docs.
https://gstreamer.freedesktop.org/documentation/rtplib/gstrtphdrext.html#GstRTP...I grepped the installed directory and I installed both package and dev-package (Windows 10)
I cannot find the GstRTPHeaderExtension mentioned in the docs.
https://gstreamer.freedesktop.org/documentation/rtplib/gstrtphdrext.html#GstRTPHeaderExtensionhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/853textoverlay: shaded-background works on some systems but not on others2021-09-24T13:26:11ZAndy Robinsontextoverlay: shaded-background works on some systems but not on othersThe following pipeline:
gst-launch-1.0 \
textoverlay name=ov shaded-background=true ! autovideosink \
filesrc location=my-video.mp4 ! decodebin ! videoconvert ! videoscale ! ov.video_sink \
filesrc location=Test.srt ! subparse ...The following pipeline:
gst-launch-1.0 \
textoverlay name=ov shaded-background=true ! autovideosink \
filesrc location=my-video.mp4 ! decodebin ! videoconvert ! videoscale ! ov.video_sink \
filesrc location=Test.srt ! subparse ! ov.text_sink
[Test.srt](/uploads/54e37d6212a671370ffc60f3c283ece7/Test.srt)
produces a shaded background for the subtitles on some systems:
1.14.5 on Linux 64-bit
<br>1.14.2 on Windows 10 32-bit
and not on others:
1.14.2 on Mac Big Sur
<br>1.18.2 on Mac Big Sur
<br>1.18.2 on Windows 10 32-bithttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/851Encodebin? regression: WMV transcoding in Rygel does not work anymore2021-09-24T13:26:11ZJens GeorgEncodebin? regression: WMV transcoding in Rygel does not work anymoreIt looks like the transcoding to WMV in Rygel has stopped working somewhere between 1.14.5 (Ubuntu 18.04, works) and 1.18 (Ubuntu 20.04 and later, stopped working).
I'm not sure where exactly the problem lies or if that's even a change ...It looks like the transcoding to WMV in Rygel has stopped working somewhere between 1.14.5 (Ubuntu 18.04, works) and 1.18 (Ubuntu 20.04 and later, stopped working).
I'm not sure where exactly the problem lies or if that's even a change in behavior in GStreamer that I need to adapt to, I start at the toplevel, encodebin. Please move accordingly if unfitting.
Test input used: https://upload.wikimedia.org/wikipedia/commons/b/b3/Big_Buck_Bunny_Trailer_400p.ogv
Example program is attached [encode.c](/uploads/c200600601b02f96bd1977487949fda6/encode.c)
Pipeline on 1.18: ![foo](/uploads/6e295b0b787b7eaab5e5282aa232f7d3/foo.png)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/850glcolorconvert: Can't convert from YUY2 to I4202021-09-24T13:26:11ZGhost Userglcolorconvert: Can't convert from YUY2 to I420Hello! So, I have a project which sources video from a YUY2 camera. However, I want to create a h264 video from that, with a I420 pixel format. Using videoconvert works, but I was curious if I could get some more speed by using GL shader...Hello! So, I have a project which sources video from a YUY2 camera. However, I want to create a h264 video from that, with a I420 pixel format. Using videoconvert works, but I was curious if I could get some more speed by using GL shaders instead, however it seems like currently, it's unsupported. The pipeline is as follows:
gst-launch-1.0 \
videotestsrc ! \
video/x-raw,format=YUY2 ! \
glupload ! \
glcolorconvert ! \
'video/x-raw(memory:GLMemory),format=I420' ! \
fakesink
How can I go around implementing such thing?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/844Smart encoding re-encodes last GOP needlessly on a H.264 video2021-09-24T13:26:10ZIvan MolodetskikhSmart encoding re-encodes last GOP needlessly on a H.264 video![2020-09-28_19-55-45](/uploads/c4680ee4ddea8dc50e80b38411bc68e3/2020-09-28_19-55-45.mp4)
```
└─ env GST_DEBUG=4 ges-launch-1.0 +clip '2020-09-28 19-55-45.mp4' -o out.mp4 --smart-rendering 2>| grep 'gstsmartencoder.c'
Encoding details:...![2020-09-28_19-55-45](/uploads/c4680ee4ddea8dc50e80b38411bc68e3/2020-09-28_19-55-45.mp4)
```
└─ env GST_DEBUG=4 ges-launch-1.0 +clip '2020-09-28 19-55-45.mp4' -o out.mp4 --smart-rendering 2>| grep 'gstsmartencoder.c'
Encoding details:
================
-> Output file: out.mp4
-> Profile: (selected from input files format for efficient smart rendering
> ∋ Quicktime: auto-generated (Automatically generated from GstDiscovererInfo)
- ▶ /001 (H.264 (High Profile)) (1120x360@60/1fps)
- ♫ /002 (MPEG-4 AAC) (2 channels @ 48000hz)
**Mixing is disabled for smart rendering to work**
Timeline description:
====================
- Clip from: 'file:///home/yalter/2020-09-28%2019-55-45.mp4' [∋Quicktime, ♫MPEG-4 AAC, ▶H.264 (High Profile)]
start=0:00:00.000000000 duration=0:00:18.467000000
0:00:02.831054272 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:538:smart_encoder_sink_event:<smartencoder0> Pushing pending GOP on new segment
0:00:02.831084529 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:409:gst_smart_encoder_push_pending_gop:<smartencoder0> Empty gop!
0:00:02.831088702 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:554:smart_encoder_sink_event:<smartencoder0> Eating segment
0:00:02.837184726 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:436:gst_smart_encoder_push_pending_gop:<smartencoder0> GOP doesn't need to be modified, pushing downstream: 0:00:00.033333333 to 0:00:04.200000000
0:00:02.851891576 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:436:gst_smart_encoder_push_pending_gop:<smartencoder0> GOP doesn't need to be modified, pushing downstream: 0:00:04.200000000 to 0:00:08.366666666
0:00:02.865587270 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:436:gst_smart_encoder_push_pending_gop:<smartencoder0> GOP doesn't need to be modified, pushing downstream: 0:00:08.366666666 to 0:00:12.533333333
0:00:02.878726198 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:436:gst_smart_encoder_push_pending_gop:<smartencoder0> GOP doesn't need to be modified, pushing downstream: 0:00:12.533333333 to 0:00:16.700000000
0:00:02.885650027 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:429:gst_smart_encoder_push_pending_gop:<smartencoder0> GOP needs to be re-encoded from 0:00:16.700000000 to 0:00:18.500333333 - time segment start=0:00:00.033333333, offset=0:00:00.000000000, stop=0:00:18.500333333, rate=1.000000, applied_rate=1.000000, flags=0x01, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.033333333, duration 99:99:99.999999999
0:00:02.888334223 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:318:gst_smart_encoder_reencode_gop: Pushing Flush start/stop to clean decoder/encoder
0:00:02.888381352 52430 0x1b00520 INFO smartencoder gstsmartencoder.c:323:gst_smart_encoder_reencode_gop: Pushing segment_event segment event: 0x7f8580003030, time 99:99:99.999999999, seq-num 793, GstEventSegment, segment=(GstSegment)"segment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_RESET, rate=(double)1, applied-rate=(double)1, format=(GstFormat)time, base=(guint64)0, offset=(guint64)0, start=(guint64)33333333, stop=(guint64)18500333333, time=(guint64)0, position=(guint64)33333333, duration=(guint64)18446744073709551615;";
<position: 0:00:18.483333333 duration: 0:00:18.467000000 speed: 1.000000 />
Done
warning : Buffer didn't have expected DISCONT flag
Detected on <GESVideoUriSource:nlesource0:src>
Detected on <muxer:src>
Detected on <internal-encodebin:src>
Detected on <filesink0:sink, internal-encodebin:src, filesink0:sink>
Detected on <decodebin6:sink>
Detected on <typefind:sink, typefind:src, h264parse5:sink>
Description : Buffers after SEGMENT and FLUSH must have a DISCONT flag
warning : Query position reported a value superior than what query duration returned
Detected on <gespipeline0>
issue : SEGMENT events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <decodebin6:sink>
Detected on <typefind:sink, typefind:src>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
warning : received the same caps twice
Detected on <filesink0:sink>
Detected on <avdec_h264-1:sink>
Detected on <h264parse5:sink>
warning : received an unexpected flush stop event
Detected on <GESAudioUriSource:nlesource1:src>
Detected on <GESVideoUriSource:nlesource0:src>
issue : FLUSH_START events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <GESAudioUriSource:nlesource1:src>
Detected on <audio_nlecomposition1:src>
Detected on <GESVideoUriSource:nlesource0:src>
Detected on <video_nlecomposition0:src>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
issue : EOS events that are part of the same pipeline 'operation' should have the same seqnum
Detected on <decodebin6:sink>
Detected on <typefind:sink, typefind:src, h264parse5:sink, h264parse5:src, capsfilter15:sink, capsfilter15:src, avdec_h264-1:sink, avdec_h264-1:src>
Detected on <decodebin6:src_0>
Detected on <bin1:sink>
Detected on <videoconvert4:sink, videoconvert4:src, nvh264enc1:sink, nvh264enc1:src, h264parse3:sink, h264parse3:src, capsfilter9:sink, capsfilter9:src>
Detected on <bin1:src>
Detected on <capsfilter14:sink, capsfilter14:src>
Detected on <smartencoder0:src, streamcombiner2:passthroughsink, streamcombiner2:src, h264parse2:sink, h264parse2:src, capsfilter8:sink, capsfilter8:src, queue5:sink, queue5:src, muxer:video_0>
Description : when events/messages are created from another event/message, they should have their seqnums set to the original event/message seqnum
warning : EOS received without segment event before
Detected on <streamsplitter3:encodingsrc, audiorate1:sink, audiorate1:src, audioconvert3:sink, audioconvert3:src, audioresample2:sink, audioresample2:src, audioconvert4:sink, audioconvert4:src, capsfilter13:sink, capsfilter13:src, fakesink1:sink>
Detected on <streamsplitter2:encodingsrc, videoconvert5:sink, videoconvert5:src, videoscale1:sink, videoscale1:src, videoconvert6:sink, videoconvert6:src, videorate2:sink, videorate2:src, capsfilter11:sink, capsfilter11:src, nvh264enc2:sink, nvh264enc2:src, streamcombiner2:encodingsink>
Description : A segment event should always be sent before data flow EOS being some kind of data flow, there is no exception in that regard
warning : a serialized event received should be pushed in the same 'time' as it was received
Detected on <multiqueue1:src_0>
Detected on <queue6:src>
Detected on <avdec_h264-1:src>
Detected on <nvh264enc1:src>
Description : serialized events should be pushed in the same order they are received and serialized with buffers. If an event is received after a buffer with timestamp end 'X', it should be pushed right after buffers with timestamp end 'X'
warning : buffer timestamp is out of the received buffer timestamps' range
Detected on <nvh264enc1:src>
Description : a buffer leaving an element should have its timestamps in the range of the received buffers timestamps. i.e. If an element received buffers with timestamps from 0s to 10s, it can't push a buffer with a 11s timestamp, because it doesn't have data for that
warning : a new segment event has different value than the received one
Detected on <nvh264enc1:src>
Description : when receiving a new segment, an element should push an equivalent segment downstream
warning : We got a g_log warning
Detected on <gespipeline0>
Details : (../subprojects/gstreamer/gst/gstinfo.c:534):gst_debug_log_valist: runtime check failed: (object == NULL || G_IS_OBJECT (object))
Details : (../subprojects/gstreamer/gst/gstinfo.c:534):gst_debug_log_valist: runtime check failed: (object == NULL || G_IS_OBJECT (object))
Details : (../subprojects/gstreamer/gst/gstinfo.c:1270):gst_debug_log_default: runtime check failed: (object == NULL || G_IS_OBJECT (object))
Details : (../subprojects/gstreamer/gst/gstinfo.c:1270):gst_debug_log_default: runtime check failed: (object == NULL || G_IS_OBJECT (object))
backtrace :
gst_debug_get_stack_trace (gstinfo.c:3126)
gst_validate_report_new (gst-validate-report.c:840)
gst_validate_report_valist (gst-validate-reporter.c:189)
gst_validate_report (gst-validate-reporter.c:323)
g_logv (gmessages.c:1350)
g_log (gmessages.c:1415)
g_warn_message (gmessages.c:2806)
gst_debug_log_valist (gstinfo.c:534)
gst_debug_log (gstinfo.c:480)
autoplug_select_cb (ges-uri-source.c:106)
ffi_call_unix64 (unix64.S:73)
ffi_call (ffi64.c:525)
g_cclosure_marshal_generic (gclosure.c:1500)
g_closure_invoke (gclosure.c:810)
signal_emit_unlocked_R.isra.0 (gsignal.c:3738)
g_signal_emit_valist (gsignal.c:3504)
g_signal_emit (gsignal.c:3550)
proxy_autoplug_select_signal (gsturidecodebin.c:1775)
ffi_call_unix64 (unix64.S:73)
ffi_call (ffi64.c:525)
g_cclosure_marshal_generic (gclosure.c:1500)
g_closure_invoke (gclosure.c:810)
signal_emit_unlocked_R.isra.0 (gsignal.c:3738)
g_signal_emit_valist (gsignal.c:3504)
g_signal_emit (gsignal.c:3550)
connect_pad (gstdecodebin2.c:2283)
analyze_new_pad (gstdecodebin2.c:1850)
pad_added_cb (gstdecodebin2.c:2990)
g_closure_invoke (gclosure.c:810)
signal_emit_unlocked_R.isra.0 (gsignal.c:3738)
g_signal_emit_valist (gsignal.c:3494)
g_signal_emit (gsignal.c:3550)
gst_element_add_pad (gstelement.c:795)
gst_qtdemux_add_stream.constprop.0 (qtdemux.c:8784)
qtdemux_expose_streams (qtdemux.c:13155)
gst_qtdemux_loop (qtdemux.c:4571)
gst_task_func (gsttask.c:328)
g_thread_pool_thread_proxy.lto_priv.0 (gthreadpool.c:354)
g_thread_proxy (gthread.c:820)
start_thread (pthread_create.c:463)
__clone (clone.S:93)
Issues found: 15
```
Fedora 33, 1.18.1 as well as 6434db5298156ec41ddc21f18c8d57a02a9ce1c1https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/843The volume element has a maximum gain of 10 which is overly restrictive2021-09-24T13:26:10ZDavid IngThe volume element has a maximum gain of 10 which is overly restrictiveIn `gstvolume.c` we have the following.
```
#define VOLUME_MAX_DOUBLE 10.0
g_object_class_install_property (gobject_class, PROP_VOLUME,
g_param_spec_double ("volume", "Volume", "volume factor, 1.0=100%",
0....In `gstvolume.c` we have the following.
```
#define VOLUME_MAX_DOUBLE 10.0
g_object_class_install_property (gobject_class, PROP_VOLUME,
g_param_spec_double ("volume", "Volume", "volume factor, 1.0=100%",
0.0, VOLUME_MAX_DOUBLE, DEFAULT_PROP_VOLUME,
G_PARAM_READWRITE | GST_PARAM_CONTROLLABLE | G_PARAM_STATIC_STRINGS));
```
So we can only scale an audio waveform by a factor of `10`, no more. This is overly restrictive, especially considering the fact that the audio signals can have some large bit depths (even floating point) which implies a huge amount of dynamic range (for plenty of headroom).
Do we need to have a maximum value? Perhaps we should just set it to positive infinity (`1.0/0.0`) and let the user decide what a reasonable value is.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/842playsink: ts-offset of sink element is overwritten by update_av_offset() of p...2021-09-24T13:26:09ZJunsooParkplaysink: ts-offset of sink element is overwritten by update_av_offset() of playsink during reconfiguringI set ts-offset prop of audio and video sink element as a value at the callback invoked when the sink element is created, but this ts-offset is overwritten by update_av_offset() of playsink during reconfiguring. Is this expected behavior...I set ts-offset prop of audio and video sink element as a value at the callback invoked when the sink element is created, but this ts-offset is overwritten by update_av_offset() of playsink during reconfiguring. Is this expected behavior or just a bug?
What I want to do is just to delay presentation of buffers of audio and video against clock as much as I want.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst/playback/gstplaysink.c#L4016https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/831oggdemux: instant rate change support missing2021-09-24T13:26:09ZMikel Pérezoggdemux: instant rate change support missingcurrently non existantcurrently non existanthttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/828Gst.DeviceMonitor Crashes with v4l2 metadata devices (Segfault)2021-09-24T13:26:08ZRichard JeskeGst.DeviceMonitor Crashes with v4l2 metadata devices (Segfault)I tried to connect many v4l2 devices on my Suse 15.2 System and all are producing a Segfault:
```
$ gst-device-monitor-1.0
Probing devices...
[308:31:42.694645354] [11051] INFO Camera camera_manager.cpp:277 libcamera v0.0.0
Device f...I tried to connect many v4l2 devices on my Suse 15.2 System and all are producing a Segfault:
```
$ gst-device-monitor-1.0
Probing devices...
[308:31:42.694645354] [11051] INFO Camera camera_manager.cpp:277 libcamera v0.0.0
Device found:
name : USB2.0 Camera : USB2.0 Ca
class : Source/Video
caps : image/jpeg, width=(int)640, height=(int)480;
image/jpeg, width=(int)1280, height=(int)720;
image/jpeg, width=(int)1280, height=(int)960;
image/jpeg, width=(int)1920, height=(int)1080;
video/x-raw, format=(string)YUY2, width=(int)640, height=(int)480;
video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720;
video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)960;
video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080;
gst-launch-1.0 libcamerasrc camera-name="USB2.0\ Camera\ \ \ \ \ \ \ :\ USB2.0\ Ca" ! ...
Speicherzugriffsfehler (Speicherabzug geschrieben)
```
This seems to be caused by the introduction of v4l2 meta devices:
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=088ead25524583e2200aa99111bea2f66a86545a
* https://unix.stackexchange.com/questions/565320/prevent-metadata-webcam-device-to-be-enumerated
* https://unix.stackexchange.com/questions/512759/multiple-dev-video-for-one-physical-device
The issue is, that all of my devices are reporting, that they have the following capabilities (for both video and meta device):
```
v4l2-ctl --device=/dev/video1 --all
Driver Info (not using libv4l2):
Driver name : uvcvideo
Card type : USB2.0 Camera : USB2.0 Ca
Bus info : usb-0000: ...
Driver version: 5.3.18
Capabilities : 0x84A00001
Video Capture
Metadata Capture
```
I know, that this might be an issue of v4l2 or the device drivers, but the issue is, that any application using the device monitor with v4l2 will crash in this constellation. A device that could not be enumerated (properly) should not result in a Segfault
Versions:
```
gst-launch-1.0 version 1.16.2
GStreamer 1.16.2
cat /etc/SUSE-brand
openSUSE
VERSION = 15.2
uname -a
Linux sys 5.3.18-lp152.41-default #1 SMP Thu Sep 3 23:02:59 UTC 2020 (a4d139b) x86_64 x86_64 x86_64 GNU/Linux
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/824appsink: Mapping a buffer as READWRITE always copies the data2021-09-24T13:26:08ZMichael Grünermichael.gruner@ridgerun.comappsink: Mapping a buffer as READWRITE always copies the dataIt seems like after a combination of d00e0b612dd1a8f9ad15aa78282defc8df21a86a (@meh) by and [6fa35140](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/6fa351407a06593ace25e64602b7703d282bd5c7) (@slomo) no buffer pulled from a...It seems like after a combination of d00e0b612dd1a8f9ad15aa78282defc8df21a86a (@meh) by and [6fa35140](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/6fa351407a06593ace25e64602b7703d282bd5c7) (@slomo) no buffer pulled from an appsink can be mapped as READWRITE without copying the underlying data. Here's a minimal example to reproduce the problem:
```c
#include <gst/gst.h>
#include <gst/app/gstappsink.h>
int
main (int argc, char *argv[])
{
gst_init (&argc, &argv);
GstElement *pipe = gst_parse_launch ("videotestsrc ! "
"appsink name=sink enable-last-sample=false max-buffers=1 drop=false",
NULL);
gst_element_set_state (pipe, GST_STATE_PLAYING);
GstAppSink *app = gst_bin_get_by_name (pipe, "sink");
/* Free the ref of the preroll */
GstSample *s = gst_app_sink_pull_preroll (app);
gst_sample_unref (s);
s = gst_app_sink_pull_sample (app);
g_print ("Sample refcount: %d\n", GST_MINI_OBJECT_REFCOUNT_VALUE (s));
GstBuffer *b = gst_sample_get_buffer (s);
g_print ("Buffer 1 refcount: %d\n", GST_MINI_OBJECT_REFCOUNT_VALUE (b));
g_print ("Buffer 1 is writable: %d\n", gst_buffer_is_writable (b));
b = gst_buffer_make_writable (gst_buffer_ref (b));
g_print ("Buffer 2 refcount: %d\n", GST_MINI_OBJECT_REFCOUNT_VALUE (b));
g_print ("Buffer 2 is writable: %d\n", gst_buffer_is_writable (b));
GstMapInfo info = GST_MAP_INFO_INIT;
g_print ("Memcpy below\n");
gst_buffer_map (b, &info, GST_MAP_READWRITE);
g_print ("Memcpy above\n");
gst_buffer_unmap (b, &info);
gst_buffer_unref (b);
gst_sample_unref (s);
return 0;
}
```
Build and run as:
```bash
cc -o gst gst.c `pkg-config --cflags --libs gstreamer-1.0 gstreamer-app-1.0`
GST_DEBUG=2,GST_PERFORMANCE:9,GST_BUFFER:9,GST_MEMORY:9,GST_LOCKING:9 ./gst
```
My run shows as follows:
```bash
Sample refcount: 2
Buffer 1 refcount: 1
Buffer 1 is writable: 0
Buffer 2 refcount: 1. <———— Made the buffer writable
Buffer 2 is writable: 1
Memcpy below
…
0:00:00.059691000 33882 0x7f9c55e0e000 TRACE GST_LOCKING gstminiobject.c:221:gboolean gst_mini_object_lock(GstMiniObject *, GstLockFlags): lock 0x7f9c58000000: state 00020000, access_mode 3
0:00:00.059706000 33882 0x7f9c55e0e000 DEBUG GST_LOCKING gstminiobject.c:256:gboolean gst_mini_object_lock(GstMiniObject *, GstLockFlags): lock failed 0x7f9c58000000: state 00020000, access_mode 3
...
0:00:00.059753000 33882 0x7f9c55e0e000 DEBUG GST_PERFORMANCE gstallocator.c:461:GstMemorySystem *_sysmem_copy(GstMemorySystem *, gssize, gsize): memcpy 115200 memory 0x7f9c58000000 -> 0x7f9c5804b000
...
Memcpy above
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/822gst-play-1.0: reversing, playing, then reversing back jumps forward to origin...2021-09-24T13:26:08ZIvan Molodetskikhgst-play-1.0: reversing, playing, then reversing back jumps forward to original positionTest clip with frame numbers: [60.mp4](/uploads/06d4005a06cb889d00a7d3475f152c89/60.mp4)
1. `gst-play-1.0 60.mp4`
1. Let it play back a little.
1. Hit <kbd>Space</kbd> to pause.
1. Hit <kbd>d</kbd> to reverse.
1. Hit <kbd>Space</kbd> to...Test clip with frame numbers: [60.mp4](/uploads/06d4005a06cb889d00a7d3475f152c89/60.mp4)
1. `gst-play-1.0 60.mp4`
1. Let it play back a little.
1. Hit <kbd>Space</kbd> to pause.
1. Hit <kbd>d</kbd> to reverse.
1. Hit <kbd>Space</kbd> to play.
1. Hit <kbd>Space</kbd> to pause.
1. Hit <kbd>d</kbd> to reverse back.
1. It jumped back forward.
Example:
![2020-09-19_10-08-40](/uploads/614ba4bb71509a3f3f3c407a122c4d87/2020-09-19_10-08-40.mp4)
Hit this while testing https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/20.
gst-play-1.0 version 1.16.2, GStreamer 1.16.2, Fedora 32https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/821compositor: significant color issues with "special" resizing parameters2021-09-24T13:26:07ZNazar Mokrynskyicompositor: significant color issues with "special" resizing parametersConsider this example:
```
gst-launch-1.0 compositor name=comp background=transparent \
sink_1::width=906 sink_1::height=509 sink_1::xpos=36 sink_1::ypos=285 \
sink_2::width=906 sink_2::height=508 sink_2::xpos=978 sink_2::ypos=28...Consider this example:
```
gst-launch-1.0 compositor name=comp background=transparent \
sink_1::width=906 sink_1::height=509 sink_1::xpos=36 sink_1::ypos=285 \
sink_2::width=906 sink_2::height=508 sink_2::xpos=978 sink_2::ypos=285 ! \
videoconvert ! video/x-raw,width=1920,height=1080 ! autovideosink \
videotestsrc pattern=white ! video/x-raw,width=1920,height=1080,format=ARGB ! comp. \
videotestsrc pattern=white ! video/x-raw,width=1920,height=1080,format=I420 ! comp. \
videotestsrc pattern=white ! video/x-raw,width=360,height=202,format=I420 ! comp.
```
Expectation here is to get completely white image, since we draw 2 white rectangles on top of white background. In reality though left rectangle is a bit grey-ish and right while similarly gray-ish has red line on top of it:
<details>
![Знімок_екрана_з_2020-09-16_22-44-07](/uploads/8b8d8ad6b0715bb346cbac9fea5e2214/Знімок_екрана_з_2020-09-16_22-44-07.png)
</details>
Something isn't right for sure. In understand that compositor doesn't have anti-aliasing support, but this is really severe artifacting.
Happens on `1.18` stable and happened to me on `master` long before that.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/820video-convert: Add fast paths from/to NV122021-09-24T13:26:07ZSebastian Drögevideo-convert: Add fast paths from/to NV12It's a quite common format nowadays, on the level of I420, and we should probably add a few more fast paths for it. Like one between I420 and NV12, but maybe also all the others we already have for I420.It's a quite common format nowadays, on the level of I420, and we should probably add a few more fast paths for it. Like one between I420 and NV12, but maybe also all the others we already have for I420.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/819alsasink/audiobasesink: Always drops very first sample2021-09-24T13:26:07ZMatus Gajdosalsasink/audiobasesink: Always drops very first sampleWhen playing a 44.1 kHz MP3 file using pipeline:
```gst-launch-1.0 filesrc location="audio.mp3" ! mpegaudioparse ! mpg123audiodec ! audioconvert ! alsasink```
I noticed that it always drops the first sample:
```0:00:00.069347375 6832 0...When playing a 44.1 kHz MP3 file using pipeline:
```gst-launch-1.0 filesrc location="audio.mp3" ! mpegaudioparse ! mpg123audiodec ! audioconvert ! alsasink```
I noticed that it always drops the first sample:
```0:00:00.069347375 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:1897:gst_audio_base_sink_render:<alsasink0> time 0:00:00.000000000, start 0:00:00.000000000, samples 1152
0:00:00.069389500 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:1934:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:00.069426250 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:1997:gst_audio_base_sink_render:<alsasink0> running: start 0:00:00.000000000 - stop 0:00:00.026122448
0:00:00.069461125 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2039:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:00.000000000 - stop 0:00:00.026122448
0:00:00.069487000 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2080:gst_audio_base_sink_render:<alsasink0> Clipped start: 1151/1152 samples
0:00:00.069506125 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2103:gst_audio_base_sink_render:<alsasink0> resync after discont/resync
New clock: GstAudioSinkClock
0:00:00.069530375 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2138:gst_audio_base_sink_render:<alsasink0> rendering at 0 1151/1151
0:00:00.069632000 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2150:gst_audio_base_sink_render:<alsasink0> wrote 1151 of 1151
0:00:00.069659875 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2181:gst_audio_base_sink_render:<alsasink0> next sample expected at 1151
```
The same happens if I play a flac file using pipeline:
```gst-launch-1.0 uridecodebin uri="file:///tmp/audio.flac" ! audioconvert ! alsasink```
Log:
```0:00:00.081520750 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:1897:gst_audio_base_sink_render:<alsasink0> time 0:00:00.000000000, start 0:00:00.000000000, samples 4096
0:00:00.081562125 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:1934:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:00.081596250 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:1997:gst_audio_base_sink_render:<alsasink0> running: start 0:00:00.000000000 - stop 0:00:00.085333333
0:00:00.081631250 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2039:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:00.000000000 - stop 0:00:00.085333333
0:00:00.081656000 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2080:gst_audio_base_sink_render:<alsasink0> Clipped start: 4095/4096 samples
0:00:00.081675000 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2103:gst_audio_base_sink_render:<alsasink0> resync after discont/resync
0:00:00.081698750 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2138:gst_audio_base_sink_render:<alsasink0> rendering at 0 4095/4095
0:00:00.081749875 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2150:gst_audio_base_sink_render:<alsasink0> wrote 4095 of 4095
0:00:00.081773875 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2181:gst_audio_base_sink_render:<alsasink0> next sample expected at 4095
```
I think the problem causes converting samples to time and back cutting off the fractional part.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/816gl: rpi bcm_host dependency of gstgl is not automatically passed to dependent...2021-09-24T13:26:06ZRoman Valovgl: rpi bcm_host dependency of gstgl is not automatically passed to dependent binariesHi,
I'm cross-compiling GStreamer 1.18 for RPi board using sysroot directory.
In order to do that I'm using following stanzas in my cross-file:
```
...
[properties]
sys_root = '/opt/rpi/sysroot/'
pkg_config_libdir = ['/opt/rpi/sysroot...Hi,
I'm cross-compiling GStreamer 1.18 for RPi board using sysroot directory.
In order to do that I'm using following stanzas in my cross-file:
```
...
[properties]
sys_root = '/opt/rpi/sysroot/'
pkg_config_libdir = ['/opt/rpi/sysroot/usr/lib/pkgconfig/', '/opt/rpi/sysroot/usr/share/pkgconfig/', '/opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/pkgconfig/', '/opt/rpi/sysroot/opt/vc/lib/pkgconfig/']
...
```
The `.../opt/vc/lib/pkgconfig/` entry in cross-file lets [meson.build](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/gl/meson.build) to detect `bcm_host` library and link against it.
However `bcm_host` dependency is not explicitly passed to gstgl-dependent binaries.
Some of them check for `bcm_host_dep` explicitly, i.e. [opengl](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/ext/gl/meson.build) and [omx](https://gitlab.freedesktop.org/gstreamer/gst-omx/-/blob/master/examples/egl/meson.build).
But the approach used doesn't scale well and there are bunch of examples that failed to built due to missing `bcm_host` on link stage, i.e [3dvideo](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/tests/examples/gl/gtk/3dvideo/meson.build):
```
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: warning: libbcm_host.so, needed by subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0, not found (try using -rpath or -rpath-link)
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_display_open'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_element_remove'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `graphics_get_display_size'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_display_close'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_update_submit_sync'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_element_add'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_element_change_attributes'
/usr/lib/gcc-cross/arm-linux-gnueabihf/8/../../../../arm-linux-gnueabihf/bin/ld: subprojects/gst-plugins-base/gst-libs/gst/gl/libgstgl-1.0.so.0.1800.0: undefined reference to `vc_dispmanx_update_start'
collect2: error: ld returned 1 exit status
```
I've ended up with the patch: [bcm_host_dep.patch](/uploads/8109ac3f5154e87874e6d75fef344335/bcm_host_dep.patch) but I'm not sure it that's a best solution.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/929xvimagesink: X Error of failed request: BadAlloc on very basic example with ...2022-05-19T14:37:55ZChristoph Feinauerxvimagesink: X Error of failed request: BadAlloc on very basic example with gst-launch-1.0Hi,
I am trying to run the basic example from the tutorial `gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink` and it crashes:
```
$ gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink
Setting pipeline to PAUSED ...
Pip...Hi,
I am trying to run the basic example from the tutorial `gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink` and it crashes:
```
$ gst-launch-1.0 videotestsrc ! videoconvert ! autovideosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 150 (XVideo)
Minor opcode of failed request: 19 ()
Serial number of failed request: 66
Current serial number in output stream: 67
```
Same for `gst-launch-1.0 -v videotestsrc ! xvimagesink`. Changing to `gst-launch-1.0 -v videotestsrc ! ximagesink` works.
It seems to be a problem with X video extension: If I compile [this](http://bellet.info/XVideo/testxv.c), the same error appears. In that, code putting a `sleep` before `XvShmPutImage` fixes the problem.
I am on `5.7.14-1-MANJARO` with
```
gst-libav 1.16.2-2
gst-plugins-bad 1.16.2-13
gst-plugins-bad-libs 1.16.2-13
gst-plugins-base 1.16.2-2
gst-plugins-base-libs 1.16.2-2
gst-plugins-good 1.16.2-3
gst-plugins-ugly 1.16.2-4
gstreamer 1.16.2-2
lib32-gstreamer 1.16.2-1
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/812audioaggregator: audio aggregator subclasses might produce choppy sounds2021-09-24T13:26:05ZSeungha Yangseungha@centricular.comaudioaggregator: audio aggregator subclasses might produce choppy soundsFollow-up from "WIP: livevideorate, liveaudiorate: Add a new videorate and audiorate elements based on aggregator"
The following discussion from !1514 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop....Follow-up from "WIP: livevideorate, liveaudiorate: Add a new videorate and audiorate elements based on aggregator"
The following discussion from !1514 should be addressed:
- [ ] @slomo started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1514#note_599526): (+2 comments)
> Why is this not also a problem with `audiomixer`?https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/808gldifferrencematte: Doesn't load new bg pixmap in texture2021-09-24T13:26:05ZPhilippe Normandgldifferrencematte: Doesn't load new bg pixmap in textureIn this branch I've started a few fixes for `gldifferencematte`: https://gitlab.freedesktop.org/philn/gst-plugins-base/-/commits/gl-diff-matte
However I wonder if there's an issue with the shaders. This pipeline `gst-launch-1.0 videotes...In this branch I've started a few fixes for `gldifferencematte`: https://gitlab.freedesktop.org/philn/gst-plugins-base/-/commits/gl-diff-matte
However I wonder if there's an issue with the shaders. This pipeline `gst-launch-1.0 videotestsrc pattern=green ! glupload ! gldifferencematte location=/home/phil/Pictures/green-screen.png ! gtkglsink` outputs all blue, but I think it should render black, if I understood the differencematte concepts right... :)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/806appsrc does not negotiate caps and start stream until data is pushed2021-09-24T13:26:04ZAlex Hoenigappsrc does not negotiate caps and start stream until data is pushedIf you have multiple appsrc elements - one for video and one for KLV - and you push a video frame first, everything works properly. But if you push a KLV buffer first, you get the following errors:
- Sink pad caps were not set before pu...If you have multiple appsrc elements - one for video and one for KLV - and you push a video frame first, everything works properly. But if you push a KLV buffer first, you get the following errors:
- Sink pad caps were not set before pushing
- Could not create handler for stream
- Sticky event misordering, got 'segment' before 'stream-start'
- Sticky event misordering, got 'segment' before 'caps'
This can be worked-around in some cases by pushing a buffer of size 0 through the video appsrc firsthttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/803video-convert: Add fast-paths to v210 and maybe more fast-paths from v2102021-09-24T13:26:04ZSebastian Drögevideo-convert: Add fast-paths to v210 and maybe more fast-paths from v210See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/775 . v210 is expensive and slow otherwise.See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/775 . v210 is expensive and slow otherwise.