GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-09-21T08:09:55Zhttps://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/346MSVC x86 build is shipping x86_64 pkg-config.exe binary2022-09-21T08:09:55ZSeungha Yangseungha@centricular.comMSVC x86 build is shipping x86_64 pkg-config.exe binaryso installed `pkg-config` binary is unusable for x86 packageso installed `pkg-config` binary is unusable for x86 packagehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/760sysprof dependency (via libsoup) does not build on Meson 0.59.22021-12-19T19:46:34ZMichael Farrellsysprof dependency (via libsoup) does not build on Meson 0.59.2I am unable to build gstreamer on Meson 0.59.2, because `sysprof` (included via `libsoup`) reports it cannot locate `config.h`. This is because the version of `sysprof` in the version of `libsoup` used by gstreamer [uses a deprecated Me...I am unable to build gstreamer on Meson 0.59.2, because `sysprof` (included via `libsoup`) reports it cannot locate `config.h`. This is because the version of `sysprof` in the version of `libsoup` used by gstreamer [uses a deprecated Meson macro, `meson.build_root`](https://gitlab.gnome.org/GNOME/sysprof/-/commit/d6aabaf1ff9fc24c7754feb1dcbb4f4285d4da8b).
This was fixed in sysprof a year ago: https://gitlab.gnome.org/GNOME/sysprof/-/commit/d6aabaf1ff9fc24c7754feb1dcbb4f4285d4da8b
And then this commit was included when libsoup updated: https://gitlab.gnome.org/GNOME/libsoup/-/commit/7a98acbda55edd69762bf1c4e18dc66a968e9969
However, gstreamer points at https://gitlab.gnome.org/GNOME/libsoup/-/commit/e190e70298be1186ad1a8a5dd0ac430463f76fee, [which references an old commit of sysprof](https://gitlab.gnome.org/GNOME/libsoup/-/blob/e190e70298be1186ad1a8a5dd0ac430463f76fee/subprojects/sysprof.wrap) that lacks the fix: https://gitlab.gnome.org/GNOME/sysprof/-/commit/1bb0eb7798f6a88667681229dde415ed663b1053
Please update to a current version of `libsoup`, or use a cherry-pick branch that includes this patch:
```
~/gstreamer/subprojects/sysprof$ git diff
diff --git a/meson.build b/meson.build
index 26f289f..98ea5a2 100644
--- a/meson.build
+++ b/meson.build
@@ -84,7 +84,7 @@ has_clockid = cc.has_member('struct perf_event_attr', 'clockid', prefix: '#inclu
config_h.set('HAVE_PERF_CLOCKID', has_use_clockid and has_clockid)
add_project_arguments([
- '-I' + meson.build_root(), # config.h
+ '-I' + meson.current_build_dir(), # config.h
], language: 'c')
global_c_args = [
```
Thanks!https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/93Failing to build Tutorial on iOS2021-10-06T09:17:38ZLoris PlassonFailing to build Tutorial on iOSHello, following the iOS tutorials, I'm trying to build and run the given code examples and having this error:
`clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of iOS 7 [-Wdeprecated]
ld: library...Hello, following the iOS tutorials, I'm trying to build and run the given code examples and having this error:
`clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of iOS 7 [-Wdeprecated]
ld: library not found for -lstdc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)`
I'm running Xcode 13.0, any idea?
Thanks a lot!https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/758appsink: caps event error, caps still have parent2021-10-03T21:10:43ZMauriceappsink: caps event error, caps still have parentI have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [h...I have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/app/gstappsink.c#L981), it first parses the caps and then tries to update some private data.
As we try to replace `last_caps` of the private data with the new caps [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-base/gst-libs/gst/app/gstappsink.c#L987). I get an error in the free_priv_data function of the gst_mini_object class [code](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/gst/gstminiobject.c#L602). I presume this is because the caps stored in `priv->last_caps` still have `priv->sample` as parent.
I'm not sure but to resolve this issue it might be sufficient to move the call `gst_caps_replace (&priv->last_caps, caps);` below the other two lines, so that first the caps in the sample get replaced (which would remove the parent from `priv->last_caps` as can be seen [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/gst/gstsample.c#L352)). Afterwards, `priv->last_caps` should be safe to unref.
I can create a PR for this if someone agrees that this is indeed a valid solution.
Best
Mauricehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/943[AppSink] caps event error, caps still have parent2021-10-03T19:16:26ZMaurice[AppSink] caps event error, caps still have parentI have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [h...I have a pipeline where my capture source captures resizable windows. As a result, I will send arbitrary caps events down the pipe whenever a window is resized. My pipeline contains an appsink. Once the appsink receives the caps event [here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/app/gstappsink.c#L981), it first parses the caps and then tries to update some private data.
As we try to replace `last_caps` of the private data with the new caps [here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/blob/master/gst-libs/gst/app/gstappsink.c#L987). I get an error in the free_priv_data function of the gst_mini_object class [code](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/1.18/gst/gstminiobject.c#L602). I presume this is because the caps stored in `priv->last_caps` still have `priv->sample` as parent.
I'm not sure but to resolve this issue it might be sufficient to move the call `gst_caps_replace (&priv->last_caps, caps);` below the other two lines, so that first the caps in the sample get replaced (which would remove the parent from `priv->last_caps` as can be seen [here](https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/1.18.4/gst/gstsample.c#L352)). Afterwards, `priv->las_caps` should be safe to unref.
I can create a PR for this if someone agrees that this is indeed a valid solution.
Best
Mauricehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/932gstreamer1.0-qt5 package not available on Raspberry2021-10-06T07:05:26ZStefano Cottafavigstreamer1.0-qt5 package not available on RaspberryHi
I've tested the qmlsink example on my Linux desktop successfully, then I've crosscompiled and deployed it to my dev Raspberry Pi but can't get it to work.
Some investigation later turns out that gstreamer1.0-qt5 is not available for i...Hi
I've tested the qmlsink example on my Linux desktop successfully, then I've crosscompiled and deployed it to my dev Raspberry Pi but can't get it to work.
Some investigation later turns out that gstreamer1.0-qt5 is not available for installation on my Pi.
I'm using gstreamer1.0 (1.14.4) from Debian Buster apt.
Not sure if this is a bug or is expected?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1670teletext stream using application/x-teletext with mpegtsmux ? Showing wrong ...2023-07-11T10:52:18ZRobert Henselteletext stream using application/x-teletext with mpegtsmux ? Showing wrong type in DVBInspector and VLC Platback.Hi,
I'm using this pipeline below experimenting in attempt in producing a DVB compliant TS with a Teletext stream.
I'm using a windows batch file so I've taken out the '^' after each line for clarity. Once my pipeline is tested I'll fine...Hi,
I'm using this pipeline below experimenting in attempt in producing a DVB compliant TS with a Teletext stream.
I'm using a windows batch file so I've taken out the '^' after each line for clarity. Once my pipeline is tested I'll fine tune a little more then adapt the pipeline into a python app on linux for my DATV DVB-S transmitter project.
Issue I have is I'm sucking out the Teletext data from a TS file Program 4 on PID 1978 using the tsdemux plugin.
I'm pulling out the teletext data by selecting the correct pid attaching to pad private_0_07b ( 0=teletext PID =0x07b = Decimal 1978) from the **TSdemux**. These are so many Gstreamer pages on the web with conflicting information on correctly setting the stream and PID and the demux. Anyway, PES data flows through to be remuxed into **mpegtsmux** on the application/x-teletext pad PID of 1980.
Is seems to work however, I'd unable to show the correct teletext type=6?? Somehow it showing to be DVB subtitling in DVBInspector which isn't correct.
I'm using Gstreamer's recent windows build where all elements and plugins are version 1.19.1
I know there has been ongoing work in making **mpegtsmux** DVB and ATSC compliant which is a move forward and appreciative for all the work which goes into Gstreamer framework. I've tried **ffmpeg** however, I not sure how to go about muxing teletext data with ffmpeg as there naff all information I could find. Plenty on subtitling and actual plugin for such. sparse with actual teletext? I know there is the teletexdec plugin
Only 'if' there was a plugin for encoding teletextenc ??
Back on my issue:-
Is there a issue with mpegtsmux? or is it something I've done in my pipeline OR, plainly what I'm doing is not how you do it?
Attached is my Pipeline which encodes BigBuckBunny as RAW Video and audio to TS stream with Teletext encoding. I'd be working with live AV using fiffo's into gestreamer pipeline on the project. Teletext I hope to work on injecting these using **appsrc** however, more investigation and reseach on how to do buffer and PCR time stamping.. Has anyone out there has successfully done what I'm trying to do?
Pictures below show PID 1980 showing DVBSubtitling service (WRONG) in addition, VLC confirms such by advertising Subtitles however not the display Teletext.
gst-launch-1.0
mpegtsmux name=mux prog-map=program_map,sink_1000=10,sink_1001=10,sink_1980=10
! filesink location=C:/temp/meta1.ts ^
filesrc location=C:/Temp/big_buck_bunny_720p24.y4m
! decodebin name=vdec
! video/x-raw,format=I420,width=1280,height=720
! x264enc tune=zerolatency bitrate=5000 byte-stream=true threads=2 key-int-max=15 intra-refresh=true
! video/x-h264, profile=main
! queue
! mux.sink_1000
filesrc location=C:/Temp/BigBuckBunny-stereo.flac
! decodebin name=adec
! audioconvert
! voaacenc bitrate=128000
! aacparse
! queue
! mux.sink_1001
filesrc location=C:/temp/OC3.demo.ts
! tsdemux name=demux program-number=4 parse-private-sections=false
demux.private_0_07ba
! queue
! application/x-teletext
! mux.sink_1980
VLC codec information
![image](/uploads/5dfb335d4f4930fc9a5a6e30ec27857f/image.png)
DVB Inspector tables
![image](/uploads/3f7d6bfc487d279d2f97592f5fa04f6f/image.png)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/757rtsp-server: corrupt memory due to raciness in the session timeout handling2021-10-31T12:25:49ZOgnyan Tonchevrtsp-server: corrupt memory due to raciness in the session timeout handlingI have been noticing quite strange crashes in an application using gst-rtsp-server, mostly in glibc's malloc()/ the Glib slice allocator(when g_slice=always-malloc is not set) and other parts of the code which at a first glance seemed qu...I have been noticing quite strange crashes in an application using gst-rtsp-server, mostly in glibc's malloc()/ the Glib slice allocator(when g_slice=always-malloc is not set) and other parts of the code which at a first glance seemed quite unrelated to get-rtsp-server. But eventually managed to narrow the problem down to a corrupt memory caused by the session timeout mechanism.
Problem 1)
What happens is that under some circumstances clients will trigger session timeout and send RTSP TEARDOWN at the same time. Then gst_rtsp_session_filter() which is called by the session timeout mechanism will drop the reference owned by 'priv->medias' to the GstRTSPSessionMedia. handle_teardown() will try to do the very same thing. This would have not caused any issue if gst_rtsp_session_filter() was not temporarily releasing the lock while calling GstRTSPSessionFilterFunc.
This is the problematic piece of code:
```
gst_rtsp_session_filter():
g_mutex_unlock (&priv->lock);
res = func (sess, media, user_data);
g_mutex_lock (&priv->lock);
```
when this happens handle_teardown() will take the lock and drop the reference hold from the private structure, gst_rtsp_session_filter() will then try to do the same after that. The ref count here will still be greater than zero since the intern hash table, visited, also holds a ref, but when the hash table gets freed at the end of the function the unref will be on an already freed object.
Problem 2)
handle_* () functions in the client can be called while the session is being finalized due to session timeout. They do call:
`sessmedia = gst_rtsp_session_get_media (session, path, &matched);`
which is a transfer-none call, in the meantime sessmedia may be freed by gst_rtsp_session_filter (). One solution could possibly be to implement a version which does transfer-full?
Do you have any suggestion how to solve that correctly?https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/755playbin3: tracer leaks2022-11-10T09:21:07ZGuillaume Desmottesplaybin3: tracer leaksThe leaks tracer is detecting a bunch of leaks when running `gst-play-1.0` on a video file with `--use-playbin3`.
```
$ GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7,leaks:6" gst-play-1.0 --use-playbin3 tests/medias/video-2s.mkv
(...)
0...The leaks tracer is detecting a bunch of leaks when running `gst-play-1.0` on a video file with `--use-playbin3`.
```
$ GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7,leaks:6" gst-play-1.0 --use-playbin3 tests/medias/video-2s.mkv
(...)
0:00:02.180382846 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstTagList, address=(gpointer)0x7f6e74140630, description=(string)taglist, video-codec=(string)"H.264\ \(High\ Profile\)", encoder=(string)x264, bitrate=(uint)1442151, minimum-bitrate=(uint)1221360, maximum-bitrate=(uint)1541760;, ref-count=(uint)1, trace=(string);
0:00:02.180399648 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstStreamCollection, address=(gpointer)0x7f6e7800c660, description=(string)collection 0x7f6e7800c660 (1 streams) < stream video 0x7f6e7800c030, ID f2d60c1e06ba3aa6cf5f38c574482211fbe2efc8a2a5ddaa0dc9ead670e23370/001:3992135233783999116, flags 0x2, caps [video/x-h264, level=(string)2, profile=(string)high, codec_data=(buffer)01640014ffe1001d67640014acd94141fb016a0c020b4a000003000200000300791e28532c01000568ebecb22c, stream-format=(string)avc, alignment=(string)au, width=(int)320, height=(int)240, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:4, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true], tags [taglist, video-codec=(string)"H.264\ \(High\ Profile\)", encoder=(string)x264, bitrate=(uint)1442151, minimum-bitrate=(uint)1221360, maximum-bitrate=(uint)1541760;], >, ref-count=(uint)1, trace=(string);
0:00:02.180409558 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstStream, address=(gpointer)0x7f6e7800c030, description=(string)stream video 0x7f6e7800c030, ID f2d60c1e06ba3aa6cf5f38c574482211fbe2efc8a2a5ddaa0dc9ead670e23370/001:3992135233783999116, flags 0x2, caps [video/x-h264, level=(string)2, profile=(string)high, codec_data=(buffer)01640014ffe1001d67640014acd94141fb016a0c020b4a000003000200000300791e28532c01000568ebecb22c, stream-format=(string)avc, alignment=(string)au, width=(int)320, height=(int)240, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:4, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true], tags [taglist, video-codec=(string)"H.264\ \(High\ Profile\)", encoder=(string)x264, bitrate=(uint)1442151, minimum-bitrate=(uint)1221360, maximum-bitrate=(uint)1541760;], ref-count=(uint)1, trace=(string);
0:00:02.180422602 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstMemory, address=(gpointer)0x83c600, description=(string)0x83c600, ref-count=(uint)1, trace=(string);
0:00:02.180428627 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7f6e7410a040, description=(string)<'':sink_0>, ref-count=(uint)55, trace=(string);
0:00:02.180434930 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstCaps, address=(gpointer)0x7f6e70014c50, description=(string)video/x-h264, level=(string)2, profile=(string)high, codec_data=(buffer)01640014ffe1001d67640014acd94141fb016a0c020b4a000003000200000300791e28532c01000568ebecb22c, stream-format=(string)avc, alignment=(string)au, width=(int)320, height=(int)240, framerate=(fraction)30/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:4, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, ref-count=(uint)1, trace=(string);
0:00:02.180441880 654132 0x9ee990 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstBuffer, address=(gpointer)0x7f6e78007a20, description=(string)buffer: 0x7f6e78007a20, pts 99:99:99.999999999, dts 99:99:99.999999999, dur 99:99:99.999999999, size 45, offset none, offset_end none, flags 0x0, ref-count=(uint)1, trace=(string);
** (gst-play-1.0:654132): WARNING **: 16:19:13.367: Leaks detected and logged under GST_DEBUG=GST_TRACER:7
```
We do not have those when running without `--use-playbin3`.
Most of those are fixed with gst-plugins-base!1174 except this one for which I did not find any obvious culprit.
```
0:00:02.256666402 654310 0x18b0090 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7f1bdc0fc080, description=(string)<'':sink_0>, ref-count=(uint)55, trace=(string);
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/748ges-launch: duration in nanoseconds becomes seconds2021-09-29T09:31:19ZStéphane Cerveauscerveau@igalia.comges-launch: duration in nanoseconds becomes secondsThis bug does not reproduce always but I experienced this issue where passing this commandline
```
$ ges-launch-1.0 +clip /tmp/clip.mp4 duration=5
```
The duration becomes second where it should be nanoseconds.
I had the issue with ubun...This bug does not reproduce always but I experienced this issue where passing this commandline
```
$ ges-launch-1.0 +clip /tmp/clip.mp4 duration=5
```
The duration becomes second where it should be nanoseconds.
I had the issue with ubuntu 20.04 in gst-build dev env.
In order to get the clip for 5 seconds, it should be
```
$ ges-launch-1.0 +clip /tmp/clip.mp4 duration=5.0
```https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/747libffi mismatch version with wrap_mode=forcefallback2021-10-08T18:52:49ZStéphane Cerveauscerveau@igalia.comlibffi mismatch version with wrap_mode=forcefallback### Describe your issue
The build fails with
```
$ meson build -Dwrap_mode=forcefallback -Dbackend=ninja -Dbad=disabled -Dgood=disabled -Dintrospection=disabled -Dbase=disabled -Dlibav=disabled -Dlibnice=disabled -Dtls=disabled
```
```
...### Describe your issue
The build fails with
```
$ meson build -Dwrap_mode=forcefallback -Dbackend=ninja -Dbad=disabled -Dgood=disabled -Dintrospection=disabled -Dbase=disabled -Dlibav=disabled -Dlibnice=disabled -Dtls=disabled
```
```
[1868/3009] Linking target subprojects/gstreamer/tests/examples/controller/controller-graph
FAILED: subprojects/gstreamer/tests/examples/controller/controller-graph
cc -o subprojects/gstreamer/tests/examples/controller/controller-graph subprojects/gstreamer/tests/examples/controller/controller-graph.p/controller-graph.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-Bsymbolic-functions '-Wl,-rpath,$ORIGIN/../../../../glib/glib:$ORIGIN/../../../../glib/gobject:$ORIGIN/../../../../libffi/src:$ORIGIN/../../../../glib/gmodule:$ORIGIN/../../../gst:$ORIGIN/../../../libs/gst/controller' -Wl,-rpath-link,/workdir/gst-build/build-test/subprojects/glib/glib -Wl,-rpath-link,/workdir/gst-build/build-test/subprojects/glib/gobject -Wl,-rpath-link,/workdir/gst-build/build-test/subprojects/libffi/src -Wl,-rpath-link,/workdir/gst-build/build-test/subprojects/glib/gmodule -Wl,-rpath-link,/workdir/gst-build/build-test/subprojects/gstreamer/gst -Wl,-rpath-link,/workdir/gst-build/build-test/subprojects/gstreamer/libs/gst/controller -Wl,--start-group subprojects/glib/glib/libglib-2.0.so.0.6800.3 subprojects/glib/gobject/libgobject-2.0.so.0.6800.3 subprojects/glib/gmodule/libgmodule-2.0.so.0.6800.3 subprojects/gstreamer/gst/libgstreamer-1.0.so.0.1901.0 subprojects/gstreamer/libs/gst/controller/libgstcontroller-1.0.so.0.1901.0 -lm /usr/lib/x86_64-linux-gnu/libgtk-3.so /usr/lib/x86_64-linux-gnu/libgdk-3.so /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so /usr/lib/x86_64-linux-gnu/libpango-1.0.so /usr/lib/x86_64-linux-gnu/libharfbuzz.so /usr/lib/x86_64-linux-gnu/libatk-1.0.so /usr/lib/x86_64-linux-gnu/libcairo-gobject.so /usr/lib/x86_64-linux-gnu/libcairo.so /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so /usr/lib/x86_64-linux-gnu/libgio-2.0.so /usr/lib/x86_64-linux-gnu/libgobject-2.0.so /usr/lib/x86_64-linux-gnu/libglib-2.0.so -Wl,--end-group
/usr/bin/ld: /lib/x86_64-linux-gnu/libwayland-client.so.0: undefined reference to `ffi_type_void@LIBFFI_BASE_7.0'
/usr/bin/ld: /lib/x86_64-linux-gnu/libwayland-client.so.0: undefined reference to `ffi_call@LIBFFI_BASE_7.0'
/usr/bin/ld: /lib/x86_64-linux-gnu/libwayland-client.so.0: undefined reference to `ffi_type_uint32@LIBFFI_BASE_7.0'
/usr/bin/ld: /lib/x86_64-linux-gnu/libwayland-client.so.0: undefined reference to `ffi_type_sint32@LIBFFI_BASE_7.0'
/usr/bin/ld: /lib/x86_64-linux-gnu/libwayland-client.so.0: undefined reference to `ffi_prep_cif@LIBFFI_BASE_7.0'
/usr/bin/ld: /lib/x86_64-linux-gnu/libwayland-client.so.0: undefined reference to `ffi_type_pointer@LIBFFI_BASE_7.0'
collect2: error: ld returned 1 exit status
[1877/3009] Compiling C object subprojects/freetype2/libfreetype.so.6.16.0.p/src_autofit_autofit.c.o
ninja: build stopped: subcommand failed.
root@2c2ef8f4cf9d:/workdir/gst-build#
```
#### Setup
- **Operating System:** Ubuntu 20.04
- **Device:** Computer
- **GStreamer Version:** 1.19.1
#### Expected Behavior
Build successful
#### Observed Behavior
It fails with a wrong version of libffi for wayland-client library with all project requesting **gtk-3** as a dependency.
### How reproducible is the bug?
With ubuntu 20.4.
Working with ubuntu 18.04
### Steps to reproduce the bug
<!-- please fill in exact steps which reproduce the bug on your system or a fresh image, for example: -->
1. open terminal
2. type `command`
### Screenshots if relevant
### Solutions you have tried
adding -lffi works but using the one from the system
### Related non-duplicate issues
### Additional Information
<!-- Any other information such as logs. Make use of <details> for long output -->
<!-- Bug Report labels. Please remove if not relevant -->
<!--Feature Request label. Please Remove the label above and uncomment this if relevant -->
<!-- /label ~"Feature Request" -->https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/746gst-uninstalled crashes when pressing ^C when using the fish shell2021-09-29T09:12:24ZVivia Nikolaidougst-uninstalled crashes when pressing ^C when using the fish shell```
vivia@erato /u/l/s/g/h/gst-build (master)> python3 ./gst-uninstalled.py
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
vivia@erato /u/l/s/g/h/gst-build (master)> ^C <-- this is the ^C th...```
vivia@erato /u/l/s/g/h/gst-build (master)> python3 ./gst-uninstalled.py
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
vivia@erato /u/l/s/g/h/gst-build (master)> ^C <-- this is the ^C that I pressed
Traceback (most recent call last):
File "./gst-uninstalled.py", line 228, in <module>
env=get_subprocess_env(options, gst_version)))
File "/usr/lib/python3.7/subprocess.py", line 325, in call
return p.wait(timeout=timeout)
File "/usr/lib/python3.7/subprocess.py", line 990, in wait
return self._wait(timeout=timeout)
File "/usr/lib/python3.7/subprocess.py", line 1624, in _wait
(pid, sts) = self._try_wait(0)
File "/usr/lib/python3.7/subprocess.py", line 1582, in _try_wait
(pid, sts) = os.waitpid(self.pid, wait_flags)
KeyboardInterrupt
vivia@erato /u/l/s/g/h/gst-build (master) [1]> <-- now I am outside the uninstalled shell
```https://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-good/-/issues/930qmlgl plugin not found in ubuntu 20.042021-10-01T03:52:36ZFaliero Rogoqmlgl plugin not found in ubuntu 20.04hi, everyone i just finished to set up a machine to launch an application using Qt and Gstreamer but the qmlgl plugin can't be found by the gst-inspect command and consequently can't be launched by the application
`sudo gst-inspect-1.0 ...hi, everyone i just finished to set up a machine to launch an application using Qt and Gstreamer but the qmlgl plugin can't be found by the gst-inspect command and consequently can't be launched by the application
`sudo gst-inspect-1.0 qmlglsink`
No such element or plugin 'qmlglsink'
but the library is correctly present
`sudo gst-inspect-1.0 usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstqmlgl.so`
Plugin Details:
Name qmlgl
Description Qt gl plugin
Filename /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstqmlgl.so
Version 1.16.2
License LGPL
Source module gst-plugins-good
Source release date 2019-12-03
Binary package GStreamer Good Plugins (Ubuntu)
Origin URL https://launchpad.net/distros/ubuntu/+source/gst-plugins-good1.0
all other good plugins are found correcly so is not a path problem.
any idea?https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/169threadshare: busy wait in elements that schedule timers closer in the future ...2022-03-28T09:51:02ZMathieu Duponchellethreadshare: busy wait in elements that schedule timers closer in the future than `context_wait` / 2@fengalin I wonder what your take on this is:
In the threadshare jitterbuffer for instance, the element determines when it needs to wake up to push the next item, goes to sleep then checks if the next element is indeed ready.
The probl...@fengalin I wonder what your take on this is:
In the threadshare jitterbuffer for instance, the element determines when it needs to wake up to push the next item, goes to sleep then checks if the next element is indeed ready.
The problem is that when it wakes up too early, it determines that "now" is still too early for the next item, and goes back to sleep for a duration < `context_wait / 2` (using `delay_for`), wakes up immediately, rinse repeat until time for the next item has *actually* been reached.
I'm not sure what the best fix for this is: should our tokio fork always delegate timers to the "next" time frame, accepting that timers could be up to `context_wait` "late", or should jitterbuffer always pop the next item when it woke up without getting unscheduled (which can happen when a new item was queued while sleeping)?https://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/55https://webrtc.nirbheek.in/ seems to be down again.2021-09-28T10:16:27ZMadhav Narayan Bhathttps://webrtc.nirbheek.in/ seems to be down again.When attempting I get "Status: Too many connection attempts, aborting. Refresh page to try again" on all systems I tested with.When attempting I get "Status: Too many connection attempts, aborting. Refresh page to try again" on all systems I tested with.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/744Re-add tags for all the modules with a prefix to the monorepo2022-11-10T09:21:07ZSebastian DrögeRe-add tags for all the modules with a prefix to the monorepoCC @tpm @thiblahuteCC @tpm @thiblahuteTim-Philipp Müllertim@centricular.comTim-Philipp Müllertim@centricular.comhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/741Update translation for brazilian portuguese2021-09-26T16:47:34ZFabricio GodoyUpdate translation for brazilian portuguesePlease, update new translations for brazilian portuguese. I don't know if you are receiving translations from translationproject.org.
- [gstreamer-1.19.2.pt_BR.po](/uploads/f5cfc1f41a35b6083654406968e0bf45/gstreamer-1.19.2.pt_BR.po)
- [...Please, update new translations for brazilian portuguese. I don't know if you are receiving translations from translationproject.org.
- [gstreamer-1.19.2.pt_BR.po](/uploads/f5cfc1f41a35b6083654406968e0bf45/gstreamer-1.19.2.pt_BR.po)
- [gst-plugins-base-1.19.2.pt_BR.po](/uploads/120e24b9151a490fdfaefc2ec474c12c/gst-plugins-base-1.19.2.pt_BR.po)
- [gst-plugins-good-1.19.2.pt_BR.po](/uploads/5643572e59434d978e904bda4f524d99/gst-plugins-good-1.19.2.pt_BR.po)
- [gst-plugins-bad-1.19.2.pt_BR.po](/uploads/f0203f179a28326e48511f96c738bd8f/gst-plugins-bad-1.19.2.pt_BR.po)
- [gst-plugins-ugly-1.19.2.pt_BR.po](/uploads/b48f46ed064d18099ca1a064976f18df/gst-plugins-ugly-1.19.2.pt_BR.po)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/942Should I choose alsasrc or pulseaudio when I develop a plugin to parse iec958...2021-09-29T08:08:25Zelliot chenShould I choose alsasrc or pulseaudio when I develop a plugin to parse iec958 packet?I'm developing a spdifdemux plugin which receive iec958 packet and parse it. As a result, it can support PCM and compressed data at the same time. But alsasrc and pulseaudio can not get iec958 packet I have modified alsasrc code to get ...I'm developing a spdifdemux plugin which receive iec958 packet and parse it. As a result, it can support PCM and compressed data at the same time. But alsasrc and pulseaudio can not get iec958 packet I have modified alsasrc code to get iec958 packet. But I have a question. Should I choose alsasrc to develop the spdifdemux plugin or pulseaudio in future?
[gstalsa.c](/uploads/67c7ac490c5bb380a55c1edbd41f3be2/gstalsa.c)
[gstalsa.h](/uploads/10ee639b7fdfca7f1ae79192ebf4bef6/gstalsa.h)
[gstalsasrc.c](/uploads/31953ede8abdd7fa3790fd02910a9c9e/gstalsasrc.c)
[gstalsasrc.h](/uploads/dad8cb070cf76e3fa717b90c01b407f8/gstalsasrc.h)https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/168Relicense LGPL plugins to MPL2022-03-30T13:22:35ZSebastian DrögeRelicense LGPL plugins to MPL### Rationale
The LGPL makes it difficult to statically link code, or even to dynamically link code if there's inlining across license boundaries. It is effectively a license that has the C compilation/linking model built-in and already...### Rationale
The LGPL makes it difficult to statically link code, or even to dynamically link code if there's inlining across license boundaries. It is effectively a license that has the C compilation/linking model built-in and already falls apart easily with C++ templates.
Static linking and aggressive inlining are normal parts of Rust's compilation/linking model.
The MPL-2.0 license is GPL/LGPL/AGPL compatible and more or less provides the same guarantees as the LGPL (weak copyleft, i.e. modifications of the code are to be released under the same terms) but on a per-source-file basis instead of per-library and without technicalities like "dynamic linking".
### Plugins
Below are all the plugins and the main contributors. I didn't include "mechanic" contributions (update for API changes, moving files around, etc) but if I forgot anyone please shout.
* audiofx
* loudnorm is a translation of LGPL code, which probably means that this effectively has to stay LGPL?
* Kyle Swanson told me he's OK with re-licensing it under MPL-2. Apart from his code there's not really anything in the ffmpeg code that ended up in the Rust port.
* Contributors
* [x] @slomo
* [x] @philn
* [x] @fengalin
* [x] @chrko
* csound
* Library is LGPL but dynamically linked so it still brings advantage to have the plugin itself MPL
* Contributors
* [x] @slomo
* [x] @fengalin
* [x] @neithanmo
* [x] @gdesmott
* threadshare
* Contributors
* [x] @slomo
* [x] @fengalin
* [x] @redongjun
* [x] @meh
* [x] @abdulrehman
* [x] @wonchul
* json
* Contributors
* [x] @meh
* regex
* Contributors
* [x] @meh
* textwrap
* Contributors
* [x] @meh
* fallbackswitch
* Contributors
* [x] @slomo
* [x] @thaytan
* [x] @seungha.yang
* [x] @meh
* [x] @vivia
* togglerecord
* Contributors
* [x] @slomo
* [x] @seungha.yang
* [x] @vivia
* closedcaption
* Contributors
* [x] @slomo
* [x] @meh
* [x] @alatiera
* [x] @seungha.yang
* [x] @ystreet
* webp
* Contributors
* [x] @meh