GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2019-05-16T22:15:31Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/523qt: Fails to compile because to constant redefinition GL_GLEXT_VERSION2019-05-16T22:15:31ZSebastian Drögeqt: Fails to compile because to constant redefinition GL_GLEXT_VERSION```
make all-am
make[1]: Entering directory '/home/slomo/Projects/gstreamer/head/gst-plugins-good/ext/qt'
CXX libgstqmlgl_la-gstqsgtexture.lo
In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/qopengl.h:146,
...```
make all-am
make[1]: Entering directory '/home/slomo/Projects/gstreamer/head/gst-plugins-good/ext/qt'
CXX libgstqmlgl_la-gstqsgtexture.lo
In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/qopengl.h:146,
from /usr/include/x86_64-linux-gnu/qt5/QtGui/qopenglfunctions.h:54,
from /usr/include/x86_64-linux-gnu/qt5/QtGui/QOpenGLFunctions:1,
from gstqsgtexture.h:30,
from gstqsgtexture.cc:31:
/usr/include/x86_64-linux-gnu/qt5/QtGui/qopenglext.h:60: error: "GL_GLEXT_VERSION" redefined [-Werror]
#define GL_GLEXT_VERSION 20170325
In file included from /usr/include/GL/gl.h:2055,
from /home/slomo/Projects/gstreamer/head/gst-plugins-base/gst-libs/gst/gl/gstglfuncs.h:68,
from gstqsgtexture.cc:30:
/usr/include/GL/glext.h:54: note: this is the location of the previous definition
#define GL_GLEXT_VERSION 20180725
cc1plus: all warnings being treated as errors
```
This is on Debian/unstable with 5.11.2https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/41retrieve-sender-address property in ts-udpsrc2019-03-13T20:41:38ZAbdul Rehmanretrieve-sender-address property in ts-udpsrcI am using udpsrc, I tried to replace it with ts-udpsrc, but "retrieve-sender-address" property is not there yet. I am using the property to retrieve address by adding a probe in udpsrc src pad.
struct _GstNetAddressMeta *meta = gst...I am using udpsrc, I tried to replace it with ts-udpsrc, but "retrieve-sender-address" property is not there yet. I am using the property to retrieve address by adding a probe in udpsrc src pad.
struct _GstNetAddressMeta *meta = gst_buffer_get_net_address_meta(buffer);
assert(meta);
GInetSocketAddress *sockAddr = (GInetSocketAddress *) meta->addr;
assert(sockAddr);
Is there any other way to achieve this in ts-udpsrc ?https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/123[regression] gstreamer-vaapi decode/encode tests fail on iHD driver since 17...2019-08-29T14:01:30Zharibommi[regression] gstreamer-vaapi decode/encode tests fail on iHD driver since 176bbce9750875f8934a361d748b9845d5f1c88egstreamer-vaapi decode/encode tests fail on iHD driver since:
(same tests pass on i965 driver)
commit 176bbce9750875f8934a361d748b9845d5f1c88e
Author: He Junyan <junyan.he@hotmail.com>
Date: Wed Nov 14 13:11:56 2018 +0800
plugin...gstreamer-vaapi decode/encode tests fail on iHD driver since:
(same tests pass on i965 driver)
commit 176bbce9750875f8934a361d748b9845d5f1c88e
Author: He Junyan <junyan.he@hotmail.com>
Date: Wed Nov 14 13:11:56 2018 +0800
plugins: modify image check of extract_allowed_surface_formats.
Test command for re-producing the failure:
GST_VAAPI_ALL_DRIVERS=1 LIBVA_DRIVER_NAME=iHD gst-launch-1.0 -vf filesrc location=input.264 ! h264parse ! vaapih264dec ! videoconvert ! video/x-raw,format=I420 ! checksumsink2 file-checksum=false frame-checksum=false plane-checksum=false dump-output=true dump-location=test.yuv
software stack:
libva (master) heads/master-0-g2852675 https://github.com/01org/libva
gmmlib (master) heads/master-0-g10ad15a https://github.com/intel/gmmlib
intel-media-driver (master) heads/master-0-g59763808 https://github.com/intel/media-driver
gstreamer (master) heads/master-0-gd3fa67c08 https://anongit.freedesktop.org/git/gstreamer/gstreamer
gst-plugins-base (master) heads/master-0-gdb1722c9c https://anongit.freedesktop.org/git/gstreamer/gst-plugins-base
gst-plugins-good (master) heads/master-0-ge9495c55f https://anongit.freedesktop.org/git/gstreamer/gst-plugins-good
gst-plugins-bad (master) heads/master-0-g1f562870e https://anongit.freedesktop.org/git/gstreamer/gst-plugins-bad
gst-checksumsink (master) heads/master-0-g36eafdc https://github.com/ceyusa/gst-checksumsinkhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/522rtpsession: pseudo memory leaking while retaining RTCP feedback2018-11-30T11:00:25ZMiguel París Díazrtpsession: pseudo memory leaking while retaining RTCP feedbackI have detected a pseudo memory leaking caused by a wrong RTCP feedback retaining implementation.
It is causing to retain every RTCP packet which are never pruned.I have detected a pseudo memory leaking caused by a wrong RTCP feedback retaining implementation.
It is causing to retain every RTCP packet which are never pruned.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/510audioconvert: Wrong endianness swap for unpacked audio format2018-11-30T09:20:06ZGhodhbane Marouenaudioconvert: Wrong endianness swap for unpacked audio formatThe audioconverter plugin is not correctly converting endianness for unpacked audio format (where sample width is different from sample depth):
`gst-launch-1.0 -v audiotestsrc ! audio/x-raw, format=S24_32BE ! audioconvert ! audio/x-raw...The audioconverter plugin is not correctly converting endianness for unpacked audio format (where sample width is different from sample depth):
`gst-launch-1.0 -v audiotestsrc ! audio/x-raw, format=S24_32BE ! audioconvert ! audio/x-raw, format=S24_32LE ! autoaudiosink`
The problem originates from the fact that the audio converter is initiating the endian conversion function based on the sample width, which i don't think it's the right behavior, where it should be based on the sample width.
I tried the attached patch for the audio-converter and it seems to fix the issue.[0001-audio-convert-Fix-endianness-conversion-function-ini.patch](/uploads/1e3ce3dc37c5985430aa37c143554155/0001-audio-convert-Fix-endianness-conversion-function-ini.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/833player: eventfd leak on GMainContext2021-09-24T14:36:48ZSeungha Yangseungha@centricular.complayer: eventfd leak on GMainContextvalgrind unit test with `--track-fds=yes` option reported that there is eventfd leak.
```
$GST_CHECKS=test_create_and_free make libs/player.valgrind
==10668== FILE DESCRIPTORS: 5 open at exit.
==10668== Open file descriptor 5:
==10668==...valgrind unit test with `--track-fds=yes` option reported that there is eventfd leak.
```
$GST_CHECKS=test_create_and_free make libs/player.valgrind
==10668== FILE DESCRIPTORS: 5 open at exit.
==10668== Open file descriptor 5:
==10668== at 0x5CA0A87: eventfd (syscall-template.S:78)
==10668== by 0x58FABA6: g_wakeup_new (gwakeup.c:146)
==10668== by 0x589F6AE: g_main_context_new (gmain.c:658)
==10668== by 0x589F755: g_main_context_default (gmain.c:694)
==10668== by 0x589F80B: g_main_context_push_thread_default (gmain.c:783)
==10668== by 0x4E4B9E2: gst_player_main (gstplayer.c:2882)
==10668== by 0x58D4197: g_thread_proxy (gthread.c:784)
==10668== by 0x6C726DA: start_thread (pthread_create.c:463)
==10668== by 0x5CA088E: clone (clone.S:95)
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/832gstreamer-plugins-bad 1.14.4 doesn't build on GCC 4.52018-11-28T13:07:59ZMaciej Wolnygstreamer-plugins-bad 1.14.4 doesn't build on GCC 4.5The build fails with "redefinition of typedef ..." errors
In the following environment:
gstreamer 1.14.4
custom Linux distro (32-bit)
GCC 4.5.3
This is because duplicated typedefs are not allowed in C99, and GCC 4.5.3 doesn't sup...The build fails with "redefinition of typedef ..." errors
In the following environment:
gstreamer 1.14.4
custom Linux distro (32-bit)
GCC 4.5.3
This is because duplicated typedefs are not allowed in C99, and GCC 4.5.3 doesn't support C11.https://gitlab.freedesktop.org/gstreamer/cerbero/-/issues/91Recipes do not get rebuilt when patches are updated2019-01-10T17:49:51ZNirbheek Chauhannirbheek.chauhan@gmail.comRecipes do not get rebuilt when patches are updatedIf you make a fix to a recipe that only changes a patch that is applied by the recipe, the recipe state is not invalidated since only the recipe mtime is used to determine that. You have to manually do `buildone`.
This has been known f...If you make a fix to a recipe that only changes a patch that is applied by the recipe, the recipe state is not invalidated since only the recipe mtime is used to determine that. You have to manually do `buildone`.
This has been known for a while, but it's important that we get this fixed because it's bad for the CI, and also for people running Cerbero.
CCing @ndufresne since it's relevant for CI.Andoni Morales AlastrueyAndoni Morales Alastrueyhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/831webrtcbin Issue in turn-server property2020-10-14T13:36:26Zaswathisivanwebrtcbin Issue in turn-server propertyThe 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-rs/-/issues/163Gstreamer Player assertion failure self->cached_duration != duration2018-11-28T07:03:13ZAron HeineckeGstreamer Player assertion failure self->cached_duration != durationHi,
not sure if this is the right place, I hit the following error using the player
```
** (yamba_backend-29cb52cb91ea1df0:21813): CRITICAL **: 02:52:19.651: emit_duration_changed: assertion 'self->cached_duration != duration' failed
```...Hi,
not sure if this is the right place, I hit the following error using the player
```
** (yamba_backend-29cb52cb91ea1df0:21813): CRITICAL **: 02:52:19.651: emit_duration_changed: assertion 'self->cached_duration != duration' failed
```
Playing works but no "connect_" function is triggered.
I've attached my code for completeness.
[playback.rs](/uploads/a6190599f1c06bbac498477117cf1f74/playback.rs)https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/521rtpssrcdemux: Does not behave correct when adding pads2018-11-30T09:13:58ZNicolas Dufresnertpssrcdemux: Does not behave correct when adding padsAll other demuxers are mandated to expose pads for which caps has been sticked to. rtpssrcdemux is doing something quite odd. If you only attach one of the input pad and push buffers to it (there is two sink pad, rtp and rtcp)) will will...All other demuxers are mandated to expose pads for which caps has been sticked to. rtpssrcdemux is doing something quite odd. If you only attach one of the input pad and push buffers to it (there is two sink pad, rtp and rtcp)) will will automatically expose two src pads (rtp and rtcp). One of the two pads won't have caps.
In this context, sending EOS to the sink pad was only sending EOS to the rtp pad. Which I wrongly fixed here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/commit/21378d83c20e47e538e50bd12df97eadc883bd22
I'm thinking it might have been the wrong fix, since conceptually, the events from RTP sink pad should be forwarded to all RTP sink pad, and the events from RTCP sink pad should be forward to all the RTCP src pads. So internal links should look like (if you have two SSRC):
```
[rtp_sink]------------------[rtp_src_0]
|
---------[rtp_src_1]
[rctp_sink]-----------------[rtcp_src_0]
|
---------[rtcp_src_1]
```
But by creating and exposing the RTCP src pads regardless if there will ever be RTCP in the stream, we now create a really hard to handle bindings between the pads. With the current fix, what I think is happening, is that if we send new caps after the first buffer has been pushed, the caps will be sent to all pads, which does not seem to stick with the design.
I'm not too sure how to fix this yet. Dissociating the pad creation to only add the pad when caps are available will clearly break rtpbin. And then, there is no logic why this would be one element instead of rtpssrcdemux and rtcpssrcdemux (which different is in how the SSRC is extracted). If I keep the current violation of the usual pad-added contract, then I need to special case at least EOS, so EOS is forward to all pads, even if there was not stream-start yet. On this regard, I don't remember if EOS before stream-start is valid or not. I'd really like to get feedback. I am writing a unit test for that now, I have the forward case I was trying to fix working, and I am about to add a unit test to demontrate the regression it caused.
cc @slomo who was my reviewerhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/830msdk: generate caps templates dynamically2021-09-24T14:36:48ZVíctor Manuel Jáquez Lealmsdk: generate caps templates dynamicallyThe available codec profiles are dependent on hardware and driver version, so not all the codec profiles are available in all the MediaSDK setups. It is required to create the definitely negotiable caps in runtime, just as gstreamer-vaap...The available codec profiles are dependent on hardware and driver version, so not all the codec profiles are available in all the MediaSDK setups. It is required to create the definitely negotiable caps in runtime, just as gstreamer-vaapi does.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/829msdk: Add HEVC 10 bit encode support2018-12-12T13:38:49ZHaihao Xiangmsdk: Add HEVC 10 bit encode supportAdd 10-bit encode support in msdkh265encAdd 10-bit encode support in msdkh265enchttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/520v4l2deviceprober: Mark if cameras are front facing or back camera2021-09-24T13:33:13ZThibault Sauniertsaunier@igalia.comv4l2deviceprober: Mark if cameras are front facing or back cameraBasically in WebKit WebRTC we need to have that information and expose it to the application, currently we do not extract the information. The way we expose it should be common to all camera device provider.Basically in WebKit WebRTC we need to have that information and expose it to the application, currently we do not extract the information. The way we expose it should be common to all camera device provider.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/509gstreamer-plugins-base 1.14.4 doesn't build on GCC 4.52018-11-28T12:08:35ZMaciej Wolnygstreamer-plugins-base 1.14.4 doesn't build on GCC 4.5The build fails with:
```
In file included from ../../../../gst-libs/gst/gl/gl.h:28:0,
from gstglcontext_glx.c:37:
../../../../gst-libs/gst/gl/gstgldebug.h:28:33: error: redefinition of typedef 'GstGLAsyncDebug'
../g...The build fails with:
```
In file included from ../../../../gst-libs/gst/gl/gl.h:28:0,
from gstglcontext_glx.c:37:
../../../../gst-libs/gst/gl/gstgldebug.h:28:33: error: redefinition of typedef 'GstGLAsyncDebug'
../gstgl_fwd.h:107:33: note: previous declaration of 'GstGLAsyncDebug' was here
```
In the following environment:
gstreamer 1.14.4
custom Linux distro (32-bit)
GCC 4.5.3
This is because duplicated typedefs are not allowed in C99, and GCC 4.5.3 doesn't support C11.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/828Remove VDPAU2022-02-08T19:54:29ZTim-Philipp Müllertim@centricular.comRemove VDPAUI think we should just remove the VDPAU plugin.
It's been replaced by NVENC/NVDEC and even NVIDIA doesn't support VDPAU any longer and hasn't for quite some time.
It's fair to say it's pretty much unmaintained and unsupported and given...I think we should just remove the VDPAU plugin.
It's been replaced by NVENC/NVDEC and even NVIDIA doesn't support VDPAU any longer and hasn't for quite some time.
It's fair to say it's pretty much unmaintained and unsupported and given the track record over the last 10 years it seems highly unlikely anyone is going to make it work well or us adding plumbing for proper zero-copy or gst-gl integration.
I think it's better to remove badly supported things and give clear signals what people should be using instead.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/122The vaapipostproc plugin can not support RGBA -> NV12 conversion2018-11-26T11:28:38ZHe JunyanThe vaapipostproc plugin can not support RGBA -> NV12 conversionAll RBGx kind of format can not be converted to other format in vaapipostproc.
gst-launch-1.0 videotestsrc ! capsfilter caps=video/x-raw,format=RGBA,framerate=30/1,width=640,height=360 ! vaapipostproc format=nv12 ! vaapisink
can not work.All RBGx kind of format can not be converted to other format in vaapipostproc.
gst-launch-1.0 videotestsrc ! capsfilter caps=video/x-raw,format=RGBA,framerate=30/1,width=640,height=360 ! vaapipostproc format=nv12 ! vaapisink
can not work.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/121vaapipostproc can not support RGBA to NV12 conversion2019-04-09T16:30:59ZHe Junyanvaapipostproc can not support RGBA to NV12 conversionAll RBGx kind of format can not be converted to other format in vaapipostproc.
gst-launch-1.0 videotestsrc ! capsfilter caps=video/x-raw,format=RGBA,framerate=30/1,width=640,height=360 ! vaapipostproc format=nv12 ! vaapisink
can not wo...All RBGx kind of format can not be converted to other format in vaapipostproc.
gst-launch-1.0 videotestsrc ! capsfilter caps=video/x-raw,format=RGBA,framerate=30/1,width=640,height=360 ! vaapipostproc format=nv12 ! vaapisink
can not work.[log.txt](/uploads/fe8007d1a90a4625bcd6e2d152ff05bd/log.txt)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/827cuda: Add public API for enhancing NVIDIA CUDA support2022-05-03T16:31:32ZSeungha Yangseungha@centricular.comcuda: Add public API for enhancing NVIDIA CUDA supportOne CUDA device context per one device (i.e., GPU card) seems to the best practice, if there is no specific demand. But we don't have any related interface. So every nvenc/nvdec creates new CUDA device context for now. Like openGL contex...One CUDA device context per one device (i.e., GPU card) seems to the best practice, if there is no specific demand. But we don't have any related interface. So every nvenc/nvdec creates new CUDA device context for now. Like openGL context sharing, CUDA context sharing by using new object such as GstCudaContext can be helpful for CUDA use case.
Additionally, CUDA specific allocator/bufferpool (and CudaUpload/CudaDownload maybe?) is required obviously.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/826opencv: make compatible with opencv 42018-11-26T13:51:00ZNicolaopencv: make compatible with opencv 4[0001-opencv-make-compatible-with-opencv-4.patch](/uploads/ddb9bdd72f8780d9c10274346750acfe/0001-opencv-make-compatible-with-opencv-4.patch)
not yet retested against opencv3[0001-opencv-make-compatible-with-opencv-4.patch](/uploads/ddb9bdd72f8780d9c10274346750acfe/0001-opencv-make-compatible-with-opencv-4.patch)
not yet retested against opencv3