GStreamer issues
https://gitlab.freedesktop.org/groups/gstreamer/-/issues
2020-10-14T13:36:26Z
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/831
webrtcbin Issue in turn-server property
2020-10-14T13:36:26Z
aswathisivan
webrtcbin Issue in turn-server property
The turn-server credentials is not being parsed properly in **webrtcbin**. The issue is happening in the following cases mainly:
1. Username: By default username will be in the form "timestamp:id". The colon in the username is not suppo...
The turn-server credentials is not being parsed properly in **webrtcbin**. The issue is happening in the following cases mainly:
1. Username: By default username will be in the form "timestamp:id". The colon in the username is not supported by TURN property. The library is parsing 'timestamp' as username and 'id' as password. The issue is because of the function `_parse_userinfo` in [gstwebrtcice.c](https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcice.c), where it is expecting ':' as separator between username and password.
**Eg:** If we register a new user with COTURN, say foo, it returns the username as **1543467204:foo**
2. Password: If the TURN password has slash ('/') character in it, then *"**Could not parse turn server**"* error is being thrown by the library. The problem is because of `gst_uri_from_string()` usage in `_validate_turn_server()` [gstwebrtcice.c](https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcice.c) which is considering slash to find the end of authority.
`eoa = uri + strcspn (uri, "/?#");`.
Also I tried using base64_encode format, somehow library is not accepting this as well.
**Eg:** The password autogenerated by COTURN could be something like **adrJU6svd/M4aAt2hAzCy8qJPXg=** , and in
base64 encode format it is **69dac953ab2f77f338680b76840cc2cbca893d78**
I checked the same credentials with [trickle-ice](https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) and it is able to resolve the credentials correctly, and gather the TURN server in ICE candidates list, but webrtcbin seems to have problem.
This issue is blocking the usage of turn-server property in webrtcbin. Could anyone recommend a better way to clearly pass credentials to turn-server property? Something like how we pass in webrtc javascript:
```
var rtc_configuration = {iceServers: [{urls: "turn:<url>:<port>?transport=udp",
credential: "adrJU6svd/M4aAt2hAzCy8qJPXg=",
username: "1543467204:foo"}]
```
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/603
aggregator API is inherently racy
2020-10-14T13:06:56Z
Vivia Nikolaidou
aggregator API is inherently racy
The following discussion from https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/711 should be addressed:
- [ ] @meh started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_reques...
The following discussion from https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/711 should be addressed:
- [ ] @meh started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/711#note_612623): (+1 comment)
> Hm, what if the pad gets flush stopped and receives a new buffer in the interval? In that case, we may end up not muxing the "best" pad. The alternative solution is to keep a reference to the "best" buffer alongside the best pad, and call drop_buffer() on it once actually processed.
Basically:
- @slomo [said](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/711#note_612657):
> The only thing you can do is to pop() and then use up the buffer or queue it up locally. Everything else is racy :) So peek() and drop() are useless API and we just noticed that the aggregator API is bad 🤪
https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/issues/119
1.18.0: meson fails: Unknown variable "scenario"
2020-10-14T10:53:49Z
Tomasz KÅ‚oczko
1.18.0: meson fails: Unknown variable "scenario"
```
+ /usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man --infodir=/usr/share/info --l...
```
+ /usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/libexec --bindir=/usr/bin --sbindir=/usr/sbin --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload --auto-features=enabled . x86_64-redhat-linux-gnu -D doc=disabled -D validate=disabled -D tests=enabled
The Meson build system
Version: 0.55.1
Source dir: /home/tkloczko/rpmbuild/BUILD/gst-editing-services-1.18.0
Build dir: /home/tkloczko/rpmbuild/BUILD/gst-editing-services-1.18.0/x86_64-redhat-linux-gnu
Build type: native build
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Project name: gst-editing-services
Project version: 1.18.0
Using 'CC' from environment with value: 'gcc'
Using 'CFLAGS' from environment with value: '-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none'
Using 'LDFLAGS' from environment with value: '-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin'
Using 'AR' from environment with value: '/usr/bin/gcc-ar'
Using 'CC' from environment with value: 'gcc'
Using 'CFLAGS' from environment with value: '-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -flto=auto -flto-partition=none'
Using 'LDFLAGS' from environment with value: '-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin'
C compiler for the host machine: gcc (gcc 10.2.1 "gcc (GCC) 10.2.1 20200826 (Red Hat 10.2.1-3)")
C linker for the host machine: gcc ld.bfd 2.35-12
Using 'AR' from environment with value: '/usr/bin/gcc-ar'
Host machine cpu family: x86_64
Host machine cpu: x86_64
Library m found: YES
Compiler for C supports link arguments -Wl,-Bsymbolic-functions: YES
Compiler for C supports arguments -fvisibility=hidden: YES
Compiler for C supports arguments -fno-strict-aliasing: YES
Found pkg-config: /usr/bin/pkg-config (1.7.3)
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-1.0 found: YES 1.18.0
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-pbutils-1.0 found: YES 1.18.0
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-video-1.0 found: YES 1.18.0
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-audio-1.0 found: YES 1.18.0
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-base-1.0 found: YES 1.18.0
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-check-1.0 found: YES 1.18.0
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-controller-1.0 found: YES 1.18.0
Dependency gst-validate-1.0 skipped: feature validate disabled
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gio-2.0 found: YES 2.65.3
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency libxml-2.0 found: YES 2.9.10
Program g-ir-scanner found: YES
Program python3 found: YES (/usr/bin/python3)
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency python-3.8-embed found: YES 3.8
Message: pylib_loc = /usr/lib64
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gmodule-2.0 found: YES 2.65.3
Message: python_abi_flags =
Message: pylib_loc = /usr/lib64
Header <gst/gstconfig.h> has symbol "GST_DISABLE_GST_DEBUG" with dependency gstreamer-1.0: YES
Compiler for C supports arguments -Wno-unused -Wunused: YES
Compiler for C supports arguments -Wmissing-declarations: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Wredundant-decls: YES
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wwrite-strings: YES
Compiler for C supports arguments -Wformat: YES
Compiler for C supports arguments -Wformat-security: YES
Compiler for C supports arguments -Winit-self: YES
Compiler for C supports arguments -Wmissing-include-dirs: YES
Compiler for C supports arguments -Waddress: YES
Compiler for C supports arguments -Wno-multichar -Wmultichar: YES
Compiler for C supports arguments -Wdeclaration-after-statement: YES
Compiler for C supports arguments -Wvla: YES
Compiler for C supports arguments -Wpointer-arith: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ges-version.h using configuration
Program flex found: YES
Found pkg-config: /usr/bin/pkg-config (1.7.3)
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Build-time dependency gobject-introspection-1.0 found: YES 1.64.1
Program g_ir_scanner found: YES (/usr/bin/g-ir-scanner)
Program g_ir_compiler found: YES (/usr/bin/g-ir-compiler)
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency bash-completion found: YES 2.11
Configuring gst-editing-services-1.0.pc using configuration
Configuring gst-editing-services-1.0-uninstalled.pc using configuration
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-plugins-base-1.0 found: YES 1.18.0
Using 'PKG_CONFIG_PATH' from environment with value: ':/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Run-time dependency gstreamer-plugins-bad-1.0 found: YES 1.17.90
Program gst-validate-launcher found: YES
tests/check/meson.build:126:8: ERROR: Unknown variable "scenario".
A full log can be found at /home/tkloczko/rpmbuild/BUILD/gst-editing-services-1.18.0/x86_64-redhat-linux-gnu/meson-logs/meson-log.txt
error: Bad exit status from /var/tmp/rpm-tmp.1fyvyG (%build)
```
https://gitlab.freedesktop.org/gstreamer/meson-ports/x264/-/issues/5
version.py fails when using git worktrees
2020-10-14T09:35:27Z
1000 realities dev team
version.py fails when using git worktrees
When a specific release of gstreamer is checked out via git worktrees, there is no .git subdirectory in the /subprojects/x264 directory. Instead, there is a .git **file** which contains the path to the actual gitdir.
This causes the is_g...
When a specific release of gstreamer is checked out via git worktrees, there is no .git subdirectory in the /subprojects/x264 directory. Instead, there is a .git **file** which contains the path to the actual gitdir.
This causes the is_git variable in version.py line 52 to be False. As a consequence version.py returns exit status 255, which breaks the process of configuring the x264 gstremaer subproject with meson.
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/446
gst_value_deserialize writes to a const char* when deserializing a list
2020-10-13T23:59:06Z
James Cowgill
gst_value_deserialize writes to a const char* when deserializing a list
The declaration for the `gst_value_deserialize` function seems to imply you can pass a constant string to it:
```
gboolean gst_value_deserialize (GValue *dest, const gchar *src);
```
However, if you try deserialize a list from a constan...
The declaration for the `gst_value_deserialize` function seems to imply you can pass a constant string to it:
```
gboolean gst_value_deserialize (GValue *dest, const gchar *src);
```
However, if you try deserialize a list from a constant string, it fails because `_priv_gst_value_parse_value` tries to write to it.
Example:
```c
#include <gst/gst.h>
int main(int argc, char* argv[])
{
gst_init (&argc, &argv);
GValue value = G_VALUE_INIT;
g_value_init (&value, GST_TYPE_LIST);
gst_value_deserialize (&value, "{ hello, world }");
return 0;
}
```
Stack trace:
```
Program received signal SIGSEGV, Segmentation fault.
_priv_gst_value_parse_value (str=0x67c006 "hello, world }", after=0x7fffffffddb8, value=0x7fffffffddc0, default_type=0) at ../gst/gstvalue.c:2581
2581 *value_end = '\0';
(gdb) bt
#0 _priv_gst_value_parse_value (str=0x67c006 "hello, world }", after=0x7fffffffddb8, value=0x7fffffffddc0, default_type=0) at ../gst/gstvalue.c:2581
#1 0x00000000004aab0b in _priv_gst_value_parse_any_list (s=0x67c006 "hello, world }", after=0x7fffffffde48, value=0x7fffffffdec0, type=0, begin=123 '{', end=125 '}') at ../gst/gstvalue.c:2449
#2 0x00000000004aacc1 in _priv_gst_value_parse_list (s=0x67c004 "{ hello, world }", after=0x7fffffffde48, value=0x7fffffffdec0, type=0) at ../gst/gstvalue.c:2486
#3 0x00000000004a7df4 in gst_value_deserialize_value_list (dest=0x7fffffffdec0, s=0x67c004 "{ hello, world }") at ../gst/gstvalue.c:1095
#4 0x00000000004b3dec in gst_value_deserialize (dest=0x7fffffffdec0, src=0x67c004 "{ hello, world }") at ../gst/gstvalue.c:6158
#5 0x0000000000402350 in main (argc=1, argv=0x7fffffffe008) at /tmp/test-value.c:9
(gdb) info locals
try_types = {24, 60, 220, 228, 20, 64}
i = 32767
type_name = 0x0
type_end = 0x7fffffffde20 "P\336\377\377\377\177"
value_s = 0x67c006 "hello, world }"
value_end = 0x67c00b ", world }"
s = 0x67c00b ", world }"
c = 44 ','
ret = 0
type = 0
__func__ = "_priv_gst_value_parse_value"
```
I think either the string shouldn't be written to, or the function signature needs to be changed (although the latter probably has too many other downsides).
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1349
vulkan: Support using glslangValidator instead of glslc
2020-10-13T20:38:29Z
Sebastian Dröge
vulkan: Support using glslangValidator instead of glslc
The former is packaged with Debian, the latter not. Prevents the vulkan to build on Debian right now :)
CC @ystreet
The former is packaged with Debian, the latter not. Prevents the vulkan to build on Debian right now :)
CC @ystreet
https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/107
Update Windows toolchain to a more recent version (GCC 8.2.0 + MinGW v6.0.0)
2020-10-13T11:48:21Z
Andoni Morales Alastruey
Update Windows toolchain to a more recent version (GCC 8.2.0 + MinGW v6.0.0)
The current toolchain used in cerbero for Windows is quite old, both the GCC compiler version and the MinGW one. It's time for an update to catch up with new windows headers and projects that requires more recent GCC versions.
The propos...
The current toolchain used in cerbero for Windows is quite old, both the GCC compiler version and the MinGW one. It's time for an update to catch up with new windows headers and projects that requires more recent GCC versions.
The proposed versions are GCC-8.2.0 and MinGW 6.0.0 with the same configuration as before: posix threads and SJLJ exceptions.
At some point we should move away from SJLJ exceptions and use DWARF2 for x86 and SEH for x86_64 so that we are compatible with MSYS2 builds, which is what most people are using nowadays. Maybe this is a good moment for the switch too, for example QT did this move already: https://wiki.qt.io/MinGW-64-bit.
EDIT:
The new toolchains are finally configured to used SEH for x86_64 and SJLJ for x86.
* [x] Create Window multilib toolchain for Linux x86_64
* [x] Create Window multilib toolchain for Windows x86_64
* [x] Upload Window multilib toolchain for Linux x86_64 freedesktop
* [x] Upload Window multilib toolchain for Windows x86_64 freedesktop
* [x] Test a full cross-compilation build from Linux for Windows x86_64
* [x] Test a full cross-compilation build from Linux for Windows x86
* [x] Test a full cross-compilation build from Windows for Windows x86_64
* [ ] Test a full cross-compilation build from Windows for Windows x86
* [ ] Write documentation
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1285
rtmp2sink: handle EOS and close connection gracefully
2020-10-12T12:02:56Z
Nazar Mokrynskyi
rtmp2sink: handle EOS and close connection gracefully
It would be nice for rtmp2sink to handle EOS event and close connection gracefully, ideally with configurable commands that are sent (FCUnpublish, closeStream, deleteStream).
I've tried to hack something together, and it seems to do som...
It would be nice for rtmp2sink to handle EOS event and close connection gracefully, ideally with configurable commands that are sent (FCUnpublish, closeStream, deleteStream).
I've tried to hack something together, and it seems to do something useful (commands are being sent), but having no experience with GStreamer plugins development I could use some help with directions, something as simple as link to specific part of the documentation would be useful already.
The most worrying is this in logs so far:
```
0:00:06.329080082 92351 0x7f3e9c00ef00 ERROR rtmpconnection rtmpconnection.c:1023:gst_rtmp_connection_send_command:<GstRtmpConnection@0x7f3e84015cd0> Called from wrong thread
0:00:06.329096544 92351 0x7f3e9c00ef00 ERROR rtmpconnection rtmpconnection.c:1023:gst_rtmp_connection_send_command:<GstRtmpConnection@0x7f3e84015cd0> Called from wrong thread
0:00:06.329107698 92351 0x7f3e9c00ef00 ERROR rtmpconnection rtmpconnection.c:1023:gst_rtmp_connection_send_command:<GstRtmpConnection@0x7f3e84015cd0> Called from wrong thread
```
Here is what I have so far: https://gitlab.freedesktop.org/nazar-pc/gst-plugins-bad/-/commit/1f373afd7be16983fa78eaadffea00bc730e6bbd
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/825
videodecoder: invalid buffer size on alternate interlace mode
2020-10-12T11:17:14Z
azerowall
videodecoder: invalid buffer size on alternate interlace mode
Version: 1.18.0
Pipeline:
`filesrc location=test.ts ! tsdemux ! video/x-h265 ! h265parse ! avdec_h265 ! fakesink`
Video:
[test.ts](https://yadi.sk/i/naIzWheM57Ewww)
Error:
```
0:00:00.189203923 16470 0x55cf953e8b20 ERROR ...
Version: 1.18.0
Pipeline:
`filesrc location=test.ts ! tsdemux ! video/x-h265 ! h265parse ! avdec_h265 ! fakesink`
Video:
[test.ts](https://yadi.sk/i/naIzWheM57Ewww)
Error:
```
0:00:00.189203923 16470 0x55cf953e8b20 ERROR default video-frame.c:182:gst_video_frame_map_id: invalid buffer size 779520 < 1555200
ERROR: from element /GstPipeline:pipeline0/avdec_h265:avdec_h265-0: Cannot access memory for read and write operation.
Additional debug info:
../subprojects/gst-libav/ext/libav/gstavviddec.c(1538): get_output_buffer (): /GstPipeline:pipeline0/avdec_h265:avdec_h265-0:
The video memory allocated from downstream pool could not mapped forread and write.
ERROR: pipeline doesn't want to preroll.
```
Interlace mode detected by the parser: alternate
In videodecoder, I discovered a hardcoded progressive interlace mode. At the same time, the real interlace mode is specified in reference->info.interlace_mode.
```
GstVideoCodecState *
gst_video_decoder_set_output_state (GstVideoDecoder * decoder,
GstVideoFormat fmt, guint width, guint height,
GstVideoCodecState * reference)
{
return gst_video_decoder_set_interlaced_output_state (decoder, fmt,
GST_VIDEO_INTERLACE_MODE_PROGRESSIVE /* reference->info.interlace_mode */,
width, height, reference);
}
```
After replacing this value with a real one, the size of the allocated buffer became correct, but many errors appeared in other places (e.g. avdec_h265, nvh265sldec). Please correct me if this replacement is wrong and there are no errors on this line.
I also checked version 1.14.5 and found that this pipeline works fine with no errors. In this version, the interlaced mode detected by the parser is mixed.
Does this mean that the parser did not correctly recognize interlace mode as alternate in the new version? Or is it because alternate mode has poor support at the moment? Are there any ways to work around this issue on the new version?
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/794
fMP4 (fragmented mp4) H265 codec
2020-10-12T07:27:02Z
Alexandr Topilski
fMP4 (fragmented mp4) H265 codec
Hello, how we can generate fmp4 chunks for Apple native players?
Here dev issue: http://gstreamer-devel.966125.n4.nabble.com/hlssink2-amp-fMP4-fragmented-mp4-td4692048.html
Thanks
Hello, how we can generate fmp4 chunks for Apple native players?
Here dev issue: http://gstreamer-devel.966125.n4.nabble.com/hlssink2-amp-fMP4-fragmented-mp4-td4692048.html
Thanks
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1422
GNU GPL v2 in COPYING
2020-10-11T12:40:56Z
Jacek Tomaszewski
GNU GPL v2 in COPYING
I noticed that [COPYING](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/COPYING) file contains GNU GPL v2 text while [COPYING.LIB](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/COPYING.LIB...
I noticed that [COPYING](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/COPYING) file contains GNU GPL v2 text while [COPYING.LIB](https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/COPYING.LIB) contains GNU LGPL v2. Is that intended?
https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/113
threadshare: some src ts-elements reset `configured_caps` when they shouldn't
2020-10-11T09:47:14Z
François Laignel
threadshare: some src ts-elements reset `configured_caps` when they shouldn't
The following discussion from !328 should be addressed:
- [x] @fengalin started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/328#note_482644): (+1 comment)
> Not a consequence of this MR,...
The following discussion from !328 should be addressed:
- [x] @fengalin started a [discussion](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/328#note_482644): (+1 comment)
> Not a consequence of this MR, but I think there's an issue with `caps` management. As an example, in `AppSrc::stop` we call `AppSrcPadHandler::reset` which sets the `configured_caps` to `None`. If we switch back to `Playing` after `Stopped`, there will no longer be a `configured_caps`. I think we should set `configured_caps` to `None` in `AppSrc::unprepare`. Will address this in a separate MR if you confirm.
https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/282
Bus.Remove_Watch Fails Silently
2020-10-09T07:13:09Z
Patton Doyle
Bus.Remove_Watch Fails Silently
Removing a watch from the bus of a playbin will occasionally fail silently.
This can be reproduced by creating a cycle of calls to remove_watch and add_watch on the bus. After several cycles (~10-15), remove watch will fail silently and...
Removing a watch from the bus of a playbin will occasionally fail silently.
This can be reproduced by creating a cycle of calls to remove_watch and add_watch on the bus. After several cycles (~10-15), remove watch will fail silently and add_watch will return an error, presumably because there is already an existing watch on the bus.
I haven't yet created an simple reproducible example, but I will do so if this isn't a known issue.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/987
DeckLink: GStreamer v1.16 changes the card's duplex mode on startup, making t...
2020-10-08T20:43:09Z
Tim Autin
DeckLink: GStreamer v1.16 changes the card's duplex mode on startup, making the video not working
Hello,
I'm using this pipeline to view the video from a DeckLink 8K Pro:
```
gst-launch-1.0 -vvv \
decklinkvideosrc device-number=0 mode=26 ! \
videoconvert ! \
autovideosink
```
It is perfectly working with GStreamer 1.8....
Hello,
I'm using this pipeline to view the video from a DeckLink 8K Pro:
```
gst-launch-1.0 -vvv \
decklinkvideosrc device-number=0 mode=26 ! \
videoconvert ! \
autovideosink
```
It is perfectly working with GStreamer 1.8.3.
With the latest version (1.16), on startup GStreamer changes the duplex mode of the card (manually set to "SDI 1 In or Out" in the Blackmagic Desktop Video Setup software) to "SDI 1 to 4 In or Out". This leads to a black frame.
Commenting the content of the gst_decklink_configure_duplex_mode method (in gstdecklink.cpp) solves this problem (but then I have #986).
Thanks
https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/94
Warnings when bootstapping on Ubuntu bionic beaver for mingw32 cross compile
2020-10-08T20:34:54Z
Aaron Boxer
Warnings when bootstapping on Ubuntu bionic beaver for mingw32 cross compile
Command is `./cerbero-uninstalled -c config/cross-win32.cbc bootstrap`
Output:
```
WARNING: No bootstrapper for the distro version windows_07
WARNING: No bootstrapper for the distro version ubuntu_18_04_bionic
```
cc @ndufresne
Command is `./cerbero-uninstalled -c config/cross-win32.cbc bootstrap`
Output:
```
WARNING: No bootstrapper for the distro version windows_07
WARNING: No bootstrapper for the distro version ubuntu_18_04_bionic
```
cc @ndufresne
https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/73
There is a little mistake in "Basic tutorial 3: Dynamic pipelines" tutorial text
2020-10-07T14:44:28Z
Luis Paulo Fernandes
There is a little mistake in "Basic tutorial 3: Dynamic pipelines" tutorial text
First of all, thank you by the excellent tutorial. It's helping me a lot!
I found a little mistake:
In the tutorial text we have:
> if (!gst_element_link (data.convert, data.sink)) {
But in the code this other function is used instead...
First of all, thank you by the excellent tutorial. It's helping me a lot!
I found a little mistake:
In the tutorial text we have:
> if (!gst_element_link (data.convert, data.sink)) {
But in the code this other function is used instead:
> if (!gst_element_link_many (data.convert, data.resample, data.sink, NULL)) {
https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/122
Undefined symbol when loading plugin
2020-10-07T09:59:04Z
Elie Génard
Undefined symbol when loading plugin
Hello,
First of all thank you for your work on this project, being able to use GStreamer through Rust is just amazing!
I'm currently writing some custom plugins and I'm having an issue that I can't seem to debug myself.
I built my plugi...
Hello,
First of all thank you for your work on this project, being able to use GStreamer through Rust is just amazing!
I'm currently writing some custom plugins and I'm having an issue that I can't seem to debug myself.
I built my plugin without any issue but it doesn't want to be loaded because of a missing symbol when I inspect it:
```
$ gst-inspect-1.0 ../target/debug/libgstgbt.so
(gst-inspect-1.0:134149): GStreamer-WARNING **: 19:48:02.112: Failed to load plugin '../target/debug/libgstgbt.so': ../target/debug/libgstgbt.so: undefined symbol: _ZN58_$LT$glib..value..GetError$u20$as$u20$core..fmt..Debug$GT$3fmt17h65361abc613071b3E
Could not load plugin file: Opening module failed: ../target/debug/libgstgbt.so: undefined symbol: _ZN58_$LT$glib..value..GetError$u20$as$u20$core..fmt..Debug$GT$3fmt17h65361abc613071b3E
```
Running `ldd` on the plugin gives me this, which seems normal:
```
$ ldd ../target/debug/libgstgbt.so
linux-vdso.so.1 (0x00007fff21b31000)
libgstmeta.so => $HOME/gbt/target/debug/libgstmeta.so (0x00007f2ffb08b000)
libstd-672309112770bee9.so => $HOME/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libstd-672309112770bee9.so (0x00007f2ffad99000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2ffab87000)
libgstvideo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstvideo-1.0.so.0 (0x00007f2feb92d000)
libgstbase-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 (0x00007f2feb8af000)
libgstreamer-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 (0x00007f2feb768000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f2feb708000)
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f2feb5df000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2feb5ba000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2feb59f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2feb3ad000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2ffc1e1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2feb25e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2feb258000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2feb24b000)/lib/libgomp-75eea7e8.so.1 (0x00007f2feb026000)
liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007f2feafa3000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f2feaf9d000)
libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007f2feaf91000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f2feaf1e000)
```
I don't know if that's relevant but I created a dynamic library with Meta APIs (`libgstmeta.so`) so I can share it between different plugins.
My guess is that it has to do with something I don't know about the way dynamic linking works.
Any tip about how to debug this would be highly appreciated :)
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/621
Support SMPTE 2022-1 FEC
2020-10-07T06:34:28Z
Bugzilla Migration User
Support SMPTE 2022-1 FEC
## Submitted by Aaron Boxer
**[Link to original bug (#789074)](https://bugzilla.gnome.org/show_bug.cgi?id=789074)**
## Description
Python implementation:
https://github.com/davidfischer-ch/pytoolbox/tree/master/pytoolbox/networ...
## Submitted by Aaron Boxer
**[Link to original bug (#789074)](https://bugzilla.gnome.org/show_bug.cgi?id=789074)**
## Description
Python implementation:
https://github.com/davidfischer-ch/pytoolbox/tree/master/pytoolbox/network/smpte2022
https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/305
Undefined symbol: _gst_plugin_dashdemux_register building for iOS 11
2020-10-06T05:10:14Z
Jerry
Undefined symbol: _gst_plugin_dashdemux_register building for iOS 11
Getting this error: Undefined symbol: _gst_plugin_dashdemux_register
Previously used Gstreamer for iOS 1.16 compiled fine
Just swapped in 1.18
Using Xcode 11.7
Set project target iOS 11
Getting this error: Undefined symbol: _gst_plugin_dashdemux_register
Previously used Gstreamer for iOS 1.16 compiled fine
Just swapped in 1.18
Using Xcode 11.7
Set project target iOS 11
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/613
openh264dec not working properly in latest gstreamer android release 1.18.0
2020-10-06T04:56:44Z
Abeesh M P
openh264dec not working properly in latest gstreamer android release 1.18.0
We are using gstreamer library for our custom network stream player. In some of the android device , video was not playing most of the time, when we dig into the issue, we could see that the devices in which openh264dec is being selected...
We are using gstreamer library for our custom network stream player. In some of the android device , video was not playing most of the time, when we dig into the issue, we could see that the devices in which openh264dec is being selected as decoder by decodebin component, then video will not be playing. this issue we are seeing in some of the devices in which has Android 10 OS.
Is there any known issues with openh264dec in latest android OS? because it was working well with last gstreamer release 1.16.0 ( in android 9).