gst-plugins-bad issueshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues2023-09-07T07:16:23Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1756nvcodec cannot start2023-09-07T07:16:23ZLei Zhangnvcodec cannot startI have nvcodec installed (checked through gst-inspect-1.0) but the pipeline cannot start with the following error:
`0:00:07.883819785 16738 0x2cad550 ERROR nvenc gstnvenc.c:674:gst_nv_enc_register: NvEncOpenEncodeS...I have nvcodec installed (checked through gst-inspect-1.0) but the pipeline cannot start with the following error:
`0:00:07.883819785 16738 0x2cad550 ERROR nvenc gstnvenc.c:674:gst_nv_enc_register: NvEncOpenEncodeSessionEx failed: codec h264, device 0, error code 10`
This occurs for all my four GPUs. I'm using gst-python. My pipeline is setup as:
```
webrtcbin name=sendonly stun-server=stun://stun.l.google.com:19302
appsrc name=source emit-signals=True do-timestamp=True !
videoconvert !
queue ! nvh264enc name=videnc ! rtph264pay name=videopay ! sendonly.
```
and
```
webrtcbin name=recvonly bundle-policy=max-bundle stun-server=stun://stun.l.google.com:19302
! rtph264depay name=videodepay ! h264parse ! nvh264dec! videoconvert ! video/x-raw, format=BGRA, width=%s, height=%s ! queue !
appsink name=sink emit-signals=true
```
I tested nvcodec with gst-launch-1.0 and it works. Any hint on what error code 10 indicates, or where should I investigate, e.g. nvidia setting, cuda, or gst-python? Thanks!https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1755elements_dash_mpd test case is failed, can any one please check2023-02-07T00:41:57Zvenkatesh uelements_dash_mpd test case is failed, can any one please checkNumber of TestSuite Executed :15
Test Suite Name :elements_dash_mpd
Finding the execution status from log with the keyword : Checks:
Running suite(s): dash
noname.xml:1: parser error : Start tag expected, '<' not found
<?xml version="1.0...Number of TestSuite Executed :15
Test Suite Name :elements_dash_mpd
Finding the execution status from log with the keyword : Checks:
Running suite(s): dash
noname.xml:1: parser error : Start tag expected, '<' not found
<?xml version="1.0"?>
^
noname.xml:1: parser error : Opening and ending tag mismatch: MPD line 1 and NPD
sh:schema:mpd:2011" profiles="urn:mpeg:dash:profile:isoff-main:2011"> </NPD>
^
99%: Checks: 119, Failures: 1, Errors: 0
../gst-plugins-bad-1.18.5/tests/check/elements/dash_mpd.c:5874:F:simpleMPD:dash_mpdparser_xlink_period:0: 'g_list_length (period_list)' (1) is not equal to '4' (4)
Check suite dash ran in 3.403s (tests failed: 1)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1754[Ubuntu:18.04 Docker]: webrtc-unidirectional-h264.c:207:8: error: unknown typ...2023-05-30T16:03:20ZVijay Kamble[Ubuntu:18.04 Docker]: webrtc-unidirectional-h264.c:207:8: error: unknown type name 'GstWebRTCPriorityType'HellHello,
I am using `main` branch of the [GStreamer monorepo](https://gitlab.freedesktop.org/gstreamer/gstreamer/) and the webrtc/sendonly example in `subprojects/gst-examples` within Ubuntu 18.04 Docker.
Before compiling the webrtc/sen...Hello,
I am using `main` branch of the [GStreamer monorepo](https://gitlab.freedesktop.org/gstreamer/gstreamer/) and the webrtc/sendonly example in `subprojects/gst-examples` within Ubuntu 18.04 Docker.
Before compiling the webrtc/sendonly example, I installed below GStreamer Plugins -
`sudo apt-get install -y gstreamer1.0-tools gstreamer1.0-nice gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-plugins-good libgstreamer1.0-dev git libglib2.0-dev libgstreamer-plugins-bad1.0-dev libsoup2.4-dev libjson-glib-dev`
But I am getting below error while compiling with Ubuntu 18.04 Docker -
"gcc" -O0 -ggdb -Wall -fno-omit-frame-pointer webrtc-unidirectional-h264.c -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/json-glib-1.0 -I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include -lgstwebrtc-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgstsdp-1.0 -lsoup-2.4 -ljson-glib-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -o webrtc-unidirectional-h264
**webrtc-unidirectional-h264.c:207:8: error: unknown type name 'GstWebRTCPriorityType'**
static GstWebRTCPriorityType
^~~~~~~~~~~~~~~~~~~~~
webrtc-unidirectional-h264.c: In function '_priority_from_string':
**webrtc-unidirectional-h264.c:211:40: error: 'GST_TYPE_WEBRTC_PRIORITY_TYPE' undeclared (first use in this function); did you mean 'GST_TYPE_WEBRTC_STATS_TYPE'?**
(GEnumClass *) g_type_class_ref (GST_TYPE_WEBRTC_PRIORITY_TYPE);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GST_TYPE_WEBRTC_STATS_TYPE
webrtc-unidirectional-h264.c:211:40: note: each undeclared identifier is reported only once for each function it appears in
webrtc-unidirectional-h264.c: In function 'create_receiver_entry':
**webrtc-unidirectional-h264.c:272:5: error: unknown type name 'GstWebRTCPriorityType'; did you mean 'GstWebRTCStatsType'?
GstWebRTCPriorityType priority;**
^~~~~~~~~~~~~~~~~~~~~
GstWebRTCStatsType
webrtc-unidirectional-h264.c:279:7: warning: implicit declaration of function 'gst_webrtc_rtp_sender_set_priority'; did you mean 'gst_webrtc_rtp_sender_set_transport'? [-Wimplicit-function-declaration]
gst_webrtc_rtp_sender_set_priority (sender, priority);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
gst_webrtc_rtp_sender_set_transport
webrtc-unidirectional-h264.c:287:5: error: unknown type name 'GstWebRTCPriorityType'; did you mean 'GstWebRTCStatsType'?
GstWebRTCPriorityType priority;
^~~~~~~~~~~~~~~~~~~~~
GstWebRTCStatsType
Makefile:8: recipe for target 'webrtc-unidirectional-h264' failed
make: *** [webrtc-unidirectional-h264] Error 1
I am trying the use case on Qualcomm SoC with arm64 architecture. The SW running on Qualcomm SoC is latest Ubuntu Version, which which we get the libsoup error mentioned in #1750 . Due to which, I have created Ubuntu 18.04 based Docker on device and building the example.
Could you please guide me, how I can fix the error..? Is it due to Docker environment.
Thanks and Regards!https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1753nvvp9dec: internal data flow problems causing issues with hlssink2 (warnings ...2023-02-03T08:34:40ZChristian Koopnvvp9dec: internal data flow problems causing issues with hlssink2 (warnings and criticals)* **GStreamer**: `1.20.5`
* **GPU**: NVIDIA GeForce 1070
* **OS**: Manjaro Linux (arch based)
---
I have a pipeline that basically turns any input video file into a desired HLS output (via `uridecodebin` and `hlssink2`).
I encountered...* **GStreamer**: `1.20.5`
* **GPU**: NVIDIA GeForce 1070
* **OS**: Manjaro Linux (arch based)
---
I have a pipeline that basically turns any input video file into a desired HLS output (via `uridecodebin` and `hlssink2`).
I encountered some issues with a specific video file that produces
a broken HLS manifest (and maybe segments too) in regard to the *targetDuration*.
The troubling bit is that when End-Of-Stream is reached, hlssink2 seems to rewrite the playlist file and fixed the broken durations (matching the generated segments?).
That is why we might need to kill/interrupt the process before it reaches the EOS – The duration is still not the expected `4` for the segments after the rewrite.
---
Video file (removed all streams except the video stream and only kept the first 20 seconds): [test.mkv](/uploads/399b18451722a32515d5abaa362c2d77/test.mkv)
My simple command: `gst-launch-1.0 filesrc location=./test.mkv ! matroskademux ! vp9parse ! nvvp9dec ! videoconvert ! autovideosink`
My command using `hlssink2` (kill/interrupt the process at ca. 70% progress): `gst-launch-1.0 filesrc location=./test.mkv ! matroskademux ! vp9parse ! nvvp9dec ! videoconvert ! videorate ! video/x-raw,framerate=24/1 ! x264enc key-int-max=24 ! hlssink2 target-duration=4`
**Using `vp9dec` instead of `nvvp9dec` gets rid of the warnings and issues (the output playlist.m3u8 properly generates with durations of 4 too).
---
The command using `hlssink2` prints the following:
```
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'nvvp9dec0': gst.cuda.context=context, gst.cuda.context=(GstCudaContext)"\(GstCudaContext\)\ cudacontext0", cuda-device-id=(int)0;
Got context from element 'nvvp9dec0': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0";
Redistribute latency...
Redistribute latency...
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.316: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4677:gst_pad_push_data:<nvvp9dec0:src> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.316: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4416:gst_pad_chain_data_unchecked:<videoconvert0:sink> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.316: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4677:gst_pad_push_data:<videoconvert0:src> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.316: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4416:gst_pad_chain_data_unchecked:<videorate0:sink> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.319: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4677:gst_pad_push_data:<videorate0:src> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.319: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4416:gst_pad_chain_data_unchecked:<capsfilter0:sink> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.319: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4677:gst_pad_push_data:<capsfilter0:src> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.319: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4416:gst_pad_chain_data_unchecked:<x264enc0:sink> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.639: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4677:gst_pad_push_data:<x264enc0:src> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.640: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4416:gst_pad_chain_data_unchecked:<hlssink2-0:video> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.640: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4677:gst_pad_push_data:<video:proxypad1> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.640: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4416:gst_pad_chain_data_unchecked:<splitmuxsink0:video> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.640: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4677:gst_pad_push_data:<video:proxypad0> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.640: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4416:gst_pad_chain_data_unchecked:<queue_video:sink> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-CRITICAL **: 13:37:52.640: gst_segment_to_running_time_full: assertion 'segment->format == format' failed
(gst-launch-1.0:353098): GStreamer-CRITICAL **: 13:37:52.640: gst_segment_to_running_time_full: assertion 'segment->format == format' failed
(gst-launch-1.0:353098): GStreamer-CRITICAL **: 13:37:52.640: gst_segment_to_running_time_full: assertion 'segment->format == format' failed
(gst-launch-1.0:353098): GStreamer-CRITICAL **: 13:37:52.640: gst_segment_to_running_time_full: assertion 'segment->format == format' failed
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.640: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4677:gst_pad_push_data:<queue_video:src> Got data flow before segment event
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
(gst-launch-1.0:353098): GStreamer-WARNING **: 13:37:52.897: ../gstreamer/subprojects/gstreamer/gst/gstpad.c:4416:gst_pad_chain_data_unchecked:<mpegtsmux0:sink_65> Got data flow before segment event
(gst-launch-1.0:353098): GStreamer-CRITICAL **: 13:37:52.901: gst_segment_to_running_time: assertion 'segment->format == format' failed
```
---
The generated `playlist.m3u8`:
`#EXT-X-TARGETDURATION` should be 4 here and `#EXTINF` should be 4 too as I force the framerate and keyframes to align.
```m3u
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:633437445
#EXTINF:9223371776,
segment00000.ts
#EXTINF:3.5416665077209473,
segment00001.ts
#EXTINF:4,
segment00002.ts
#EXT-X-ENDLIST
```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1752Va: Vaav1dec not loaded2023-01-19T15:25:06ZGustavVa: Vaav1dec not loadedWe trying to use the va plugins for video decoding. VaH264, vaH265, vaVP8, vaVP9 works as they should. But vaAv1 is missing. I have tried to use gst-inspect-1.0 to check what is loaded and what is part of the plugin so file.
```
gst-ins...We trying to use the va plugins for video decoding. VaH264, vaH265, vaVP8, vaVP9 works as they should. But vaAv1 is missing. I have tried to use gst-inspect-1.0 to check what is loaded and what is part of the plugin so file.
```
gst-inspect-1.0 --version
gst-inspect-1.0 version 1.20.5
GStreamer 1.20.5
```
```
gst-inspect-1.0 /usr/lib/gstreamer-1.0/libgstva.so /usr/lib/gstreamer-1.0/libgstva.so
Plugin Details:
Name va
Description VA-API codecs plugin
Filename /usr/lib/gstreamer-1.0/libgstva.so
Version 1.20.5
License LGPL
Source module gst-plugins-bad
Source release date 2022-12-19
Binary package GStreamer Bad Plug-ins source release
Origin URL Unknown package origin
vadeinterlace: VA-API Deinterlacer
vah264dec: VA-API H.264 Decoder
vah265dec: VA-API H.265 Decoder
vampeg2dec: VA-API Mpeg2 Decoder
vapostproc: VA-API Video Postprocessor
vavp8dec: VA-API VP8 Decoder
vavp9dec: VA-API VP9 Decoder
7 features:
+-- 7 elements
```
```
gst-inspect-1.0 | grep av1
videoparsersbad: av1parse: AV1 parser
```
```
gst-inspect-1.0 | grep va:
typefindfunctions: video/x-pva: pva
va: vadeinterlace: VA-API Deinterlacer
va: vah264dec: VA-API H.264 Decoder
va: vah265dec: VA-API H.265 Decoder
va: vampeg2dec: VA-API Mpeg2 Decoder
va: vapostproc: VA-API Video Postprocessor
va: vavp8dec: VA-API VP8 Decoder
va: vavp9dec: VA-API VP9 Decoder
```
I checked the source code for the plugin and there are several #if VA_CHECK_VERSION(1, 8, 0) around the av1 code. We have version 2.14. I have checked with grep for strings inside this block of code and they are present in libgstva.so.
```
grep AV1 /usr/lib/gstreamer-1.0/libgstva.so /usr/lib/gstreamer-1.0/libgstva.so
/usr/lib/gstreamer-1.0/libgstva.so:Failed to register AV1 decoder: %s
/usr/lib/gstreamer-1.0/libgstva.so:VAProfileAV1Profile0
/usr/lib/gstreamer-1.0/libgstva.so:VAProfileAV1Profile1
/usr/lib/gstreamer-1.0/libgstva.so:VA-API AV1 Decoder in %s
/usr/lib/gstreamer-1.0/libgstva.so:VA-API AV1 Decoder
/usr/lib/gstreamer-1.0/libgstva.so:VA AV1 decoder
/usr/lib/gstreamer-1.0/libgstva.so:GstVa%sAV1Dec
/usr/lib/gstreamer-1.0/libgstva.so:GstVaAV1Dec
/usr/lib/gstreamer-1.0/libgstva.so:VA-API based AV1 video decoder
/usr/lib/gstreamer-1.0/libgstva.so:Failed to register AV1 decoder: %s
/usr/lib/gstreamer-1.0/libgstva.so:VAProfileAV1Profile0
/usr/lib/gstreamer-1.0/libgstva.so:VAProfileAV1Profile1
/usr/lib/gstreamer-1.0/libgstva.so:VA-API AV1 Decoder in %s
/usr/lib/gstreamer-1.0/libgstva.so:VA-API AV1 Decoder
/usr/lib/gstreamer-1.0/libgstva.so:VA AV1 decoder
/usr/lib/gstreamer-1.0/libgstva.so:GstVa%sAV1Dec
/usr/lib/gstreamer-1.0/libgstva.so:GstVaAV1Dec
/usr/lib/gstreamer-1.0/libgstva.so:VA-API based AV1 video decoder
```
I have also tried to use GST_DEBUG to turn on debug log and checked for any output connected to vaav1 but without any luck.
How do we best debug what is causing vaav1dec to be missing?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1751src-gst_bad/ext/zxing/gstzxing.cpp:370:33: error: no matching function for ca...2023-05-17T09:29:42ZMichael Evanssrc-gst_bad/ext/zxing/gstzxing.cpp:370:33: error: no matching function for call to 'ToUtf8(std::string)'I'm trying to build gstreamer gst-plugins-bad and it's not compiling due to TextUtfEncoding::ToUtf8() expecting different variable types / counts as arguments
```
[835/882] x86_64-pc-linux-gnu-g++ -Iext/zxing/libgstzxing.so.p -Iext/zxin...I'm trying to build gstreamer gst-plugins-bad and it's not compiling due to TextUtfEncoding::ToUtf8() expecting different variable types / counts as arguments
```
[835/882] x86_64-pc-linux-gnu-g++ -Iext/zxing/libgstzxing.so.p -Iext/zxing -I../src-gst_bad/ext/zxing -I. -I../src-gst_bad -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_base64/include/gstreamer-1.0 -I /home/USER/.cache/yay/proton-ge-custom/src/build/dst-gstreamer64/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_orc64/include/orc-0.4 -I/usr/include/ZXing -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_orc64/include -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gstreamer64/include -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_base64/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++11 -Wno-non-virtual-dtor -fvisibility=hidden -fno-strict-aliasing -Wformat-nonliteral -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Wvla -Wpointer-arith -gdwarf-2 -gstrict-dwarf -O2 -march=nocona -mtune=core-avx2 -pipe -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/USER/.cache/yay/proton-ge-custom/src/build/src-gst_bad=. -std=c++17 -gdwarf-2 -gstrict-dwarf -O2 -march=nocona -mtune=core-avx2 -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/USER/.cache/yay/proton-ge-custom/src/build/src-gst_bad=. -fPIC -pthread -MD -MQ ext/zxing/libgstzxing.so.p/gstzxing.cpp.o -MF ext/zxing/libgstzxing.so.p/gstzxing.cpp.o.d -o ext/zxing/libgstzxing.so.p/gstzxing.cpp.o -c ../src-gst_bad/ext/zxing/gstzxing.cpp
FAILED: ext/zxing/libgstzxing.so.p/gstzxing.cpp.o
x86_64-pc-linux-gnu-g++ -Iext/zxing/libgstzxing.so.p -Iext/zxing -I../src-gst_bad/ext/zxing -I. -I../src-gst_bad -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_base64/include/gstreamer-1.0 -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gstreamer64/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_orc64/include/orc-0.4 -I/usr/include/ZXing -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_orc64/include -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gstreamer64/include -I/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_base64/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++11 -Wno-non-virtual-dtor -fvisibility=hidden -fno-strict-aliasing -Wformat-nonliteral -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -Wvla -Wpointer-arith -gdwarf-2 -gstrict-dwarf -O2 -march=nocona -mtune=core-avx2 -pipe -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/USER/.cache/yay/proton-ge-custom/src/build/src-gst_bad=. -std=c++17 -gdwarf-2 -gstrict-dwarf -O2 -march=nocona -mtune=core-avx2 -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -ffile-prefix-map=/home/USER/.cache/yay/proton-ge-custom/src/build/src-gst_bad=. -fPIC -pthread -MD -MQ ext/zxing/libgstzxing.so.p/gstzxing.cpp.o -MF ext/zxing/libgstzxing.so.p/gstzxing.cpp.o.d -o ext/zxing/libgstzxing.so.p/gstzxing.cpp.o -c ../src-gst_bad/ext/zxing/gstzxing.cpp
In file included from /home/USER/.cache/yay/proton-ge-custom/src/build/dst-gstreamer64/include/gstreamer-1.0/gst/gst.h:55,
from /home/USER/.cache/yay/proton-ge-custom/src/build/dst-gst_base64/include/gstreamer-1.0/gst/video/video.h:23,
from ../src-gst_bad/ext/zxing/gstzxing.h:23,
from ../src-gst_bad/ext/zxing/gstzxing.cpp:56:
../src-gst_bad/ext/zxing/gstzxing.cpp: In function 'GstFlowReturn gst_zxing_transform_frame_ip(GstVideoFilter*, GstVideoFrame*)':
../src-gst_bad/ext/zxing/gstzxing.cpp:370:33: error: no matching function for call to 'ToUtf8(std::string)'
370 | TextUtfEncoding::ToUtf8 (result.text ()).c_str (),
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
/home/USER/.cache/yay/proton-ge-custom/src/build/dst-gstreamer64/include/gstreamer-1.0/gst/gstinfo.h:682:31: note: in definition of macro 'GST_CAT_LEVEL_LOG'
682 | (GObject *) (object), __VA_ARGS__); \
| ^~~~~~~~~~~
../src-gst_bad/ext/zxing/gstzxing.cpp:369:5: note: in expansion of macro 'GST_DEBUG_OBJECT'
369 | GST_DEBUG_OBJECT (zxing, "Symbol found. Text: %s Format: %s",
| ^~~~~~~~~~~~~~~~
In file included from ../src-gst_bad/ext/zxing/gstzxing.cpp:64:
/usr/include/ZXing/TextUtfEncoding.h:15:28: note: candidate: 'std::string ZXing::TextUtfEncoding::ToUtf8(std::wstring_view)'
15 | [[deprecated]] std::string ToUtf8(std::wstring_view str);
| ^~~~~~
/usr/include/ZXing/TextUtfEncoding.h:15:53: note: no known conversion for argument 1 from 'std::string' {aka 'std::__cxx11::basic_string<char>'} to 'std::wstring_view' {aka 'std::basic_string_view<wchar_t>'}
15 | [[deprecated]] std::string ToUtf8(std::wstring_view str);
| ~~~~~~~~~~~~~~~~~~^~~
/usr/include/ZXing/TextUtfEncoding.h:16:28: note: candidate: 'std::string ZXing::TextUtfEncoding::ToUtf8(std::wstring_view, bool)'
16 | [[deprecated]] std::string ToUtf8(std::wstring_view str, const bool angleEscape);
| ^~~~~~
/usr/include/ZXing/TextUtfEncoding.h:16:28: note: candidate expects 2 arguments, 1 provided
../src-gst_bad/ext/zxing/gstzxing.cpp:398:33: error: no matching function for call to 'ToUtf8(std::string)'
398 | TextUtfEncoding::ToUtf8 (result.text ()).c_str (), NULL);
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
/usr/include/ZXing/TextUtfEncoding.h:15:28: note: candidate: 'std::string ZXing::TextUtfEncoding::ToUtf8(std::wstring_view)'
15 | [[deprecated]] std::string ToUtf8(std::wstring_view str);
| ^~~~~~
/usr/include/ZXing/TextUtfEncoding.h:15:53: note: no known conversion for argument 1 from 'std::string' {aka 'std::__cxx11::basic_string<char>'} to 'std::wstring_view' {aka 'std::basic_string_view<wchar_t>'}
15 | [[deprecated]] std::string ToUtf8(std::wstring_view str);
| ~~~~~~~~~~~~~~~~~~^~~
/usr/include/ZXing/TextUtfEncoding.h:16:28: note: candidate: 'std::string ZXing::TextUtfEncoding::ToUtf8(std::wstring_view, bool)'
16 | [[deprecated]] std::string ToUtf8(std::wstring_view str, const bool angleEscape);
| ^~~~~~
/usr/include/ZXing/TextUtfEncoding.h:16:28: note: candidate expects 2 arguments, 1 provided
../src-gst_bad/ext/zxing/gstzxing.cpp:398:33: error: no matching function for call to 'ToUtf8(std::string)'
398 | TextUtfEncoding::ToUtf8 (result.text ()).c_str (), NULL);
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
/usr/include/ZXing/TextUtfEncoding.h:15:28: note: candidate: 'std::string ZXing::TextUtfEncoding::ToUtf8(std::wstring_view)'
15 | [[deprecated]] std::string ToUtf8(std::wstring_view str);
| ^~~~~~
/usr/include/ZXing/TextUtfEncoding.h:15:53: note: no known conversion for argument 1 from 'std::string' {aka 'std::__cxx11::basic_string<char>'} to 'std::wstring_view' {aka 'std::basic_string_view<wchar_t>'}
15 | [[deprecated]] std::string ToUtf8(std::wstring_view str);
| ~~~~~~~~~~~~~~~~~~^~~
/usr/include/ZXing/TextUtfEncoding.h:16:28: note: candidate: 'std::string ZXing::TextUtfEncoding::ToUtf8(std::wstring_view, bool)'
16 | [[deprecated]] std::string ToUtf8(std::wstring_view str, const bool angleEscape);
| ^~~~~~
/usr/include/ZXing/TextUtfEncoding.h:16:28: note: candidate expects 2 arguments, 1 provided
...
ninja: build stopped: subcommand failed.
make[2]: *** [../proton-ge-custom/Makefile.in:745: /home/USER/.cache/yay/proton-ge-custom/src/build/.gst_bad-build64] Error 1
make[2]: Leaving directory '/home/USER/.cache/yay/proton-ge-custom/src/build'
make[1]: *** [../proton-ge-custom/Makefile.in:121: container-build] Error 2
make[1]: Leaving directory '/home/USER/.cache/yay/proton-ge-custom/src/build'
make: *** [../proton-ge-custom/Makefile.in:32: nested_make] Error 2
==> ERROR: A failure occurred in build().
Aborting...
-> error making: proton-ge-custom
```
Edit: Maybe code style instead of block quote...https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1750[WebRTC] (webrtc-unidirectional-h264:8209): libsoup-ERROR2023-07-13T17:05:59ZVijay Kamble[WebRTC] (webrtc-unidirectional-h264:8209): libsoup-ERRORHello,
I have cloned the WebRTC example from https://gitlab.freedesktop.org/gstreamer/gst-examples/-/tree/master/webrtc and compiled on Debian Release. But after running the webrtc-unidirectional-h264 use case, I am getting libsoup erro...Hello,
I have cloned the WebRTC example from https://gitlab.freedesktop.org/gstreamer/gst-examples/-/tree/master/webrtc and compiled on Debian Release. But after running the webrtc-unidirectional-h264 use case, I am getting libsoup error related to libsoup2/libsoup3 symbols as mentioned below -
./webrtc-unidirectional-h264
WebRTC page link: http://<rb5_ip>:57778/
Processing new websocket connection 0xaaaadab245c0
(webrtc-unidirectional-h264:8209): libsoup-ERROR **: 06:27:26.349: libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.
Trace/breakpoint trap
Could you please let me know how I can fix the above error..?
Thanks in Advance!https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1749WebRTC ICE handling differences between 1.18 and 1.202023-01-15T12:13:36ZFlorian EchtlerWebRTC ICE handling differences between 1.18 and 1.20I have a bit of a weird issue with my WebRTC setup. I have a server running on GStreamer 1.20, and various clients running on 1.18, 1.20, and browser platforms.
When I run the server and any combination of clients within the local netwo...I have a bit of a weird issue with my WebRTC setup. I have a server running on GStreamer 1.20, and various clients running on 1.18, 1.20, and browser platforms.
When I run the server and any combination of clients within the local network, everything works smoothly. Same when the both server and client(s) have a public IP.
However, when the clients are behind a NAT and the server is running on a public IP, then I can only make things work with the 1.20 client and/or browsers. The 1.18 client gets stuck when starting the streams (specifically, the first video stream starts, but doesn't play, and the other video stream and the audio stream never start).
This obviously seems like a networking-related issue and I've had a closer look at the client-generated ICE candidates in the NAT scenario, but couldn't spot anything out of the ordinary. I also tried to disable IPv6 and to test with alternative STUN servers, but none of that seems to help.
I'm attaching the ICE candidates generated by the 1.18 and 1.20 clients here, both for the public IP and the local network scenario; the only obvious difference I can spot is that 1.18 generates way more candidates than 1.20.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1748waylandsink: Frames continually dropped when timing aligns with redraw callback2023-01-13T15:20:10ZDamian Hobson-Garciadamian@hobsong.comwaylandsink: Frames continually dropped when timing aligns with redraw callbackThis seems to be similar to the problem reported in #675.
Basically, when playing a video with the same frame rate as the
screen refresh, it looks like waylandsink can get locked into
a cycle where every frame is scheduled to be displaye...This seems to be similar to the problem reported in #675.
Basically, when playing a video with the same frame rate as the
screen refresh, it looks like waylandsink can get locked into
a cycle where every frame is scheduled to be displayed very
close to a VSYNC. This results in a race between
`frame_redraw_callback()` and `gst_wayland_sink_show_frame()` where
if `gst_wayland_sink_show_frame()` wins, the redraw_pending flag will
still be set and the frame will be dropped. The next frame won't race,
since there will be no redraw callback from the previous dropped frame,
but the frame after will again be subject to dropping.
Depending on the timing, this can result in the overall frame rate dropping by
half.
Here's a log snippet showing this happening
```
0:00:01.550413402 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:749:gst_wayland_sink_show_frame:<waylandsink0> render buffer 0xffff9800d360
0:00:01.550462122 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:769:gst_wayland_sink_show_frame:<waylandsink0> buffer 0xffff9800d360 dropped (redraw pending)
0:00:01.553080293 12917 0xaaaafd773700 LOG waylandsink gstwaylandsink.c:683:frame_redraw_callback: frame_redraw_cb
0:00:01.567330710 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:749:gst_wayland_sink_show_frame:<waylandsink0> render buffer 0xffff9800d120
0:00:01.567381830 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:780:gst_wayland_sink_show_frame:<waylandsink0> buffer 0xffff9800d120 has a wl_buffer from our display, writing directly
0:00:01.567936112 12917 0xaaaafd773700 LOG waylandsink wlbuffer.c:138:buffer_release:<GstWlBuffer@0xffff98009700> wl_buffer::release (GstBuffer: 0xffff9800d240)
0:00:01.583788055 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:749:gst_wayland_sink_show_frame:<waylandsink0> render buffer 0xffff9800d000
0:00:01.583830536 12917 0xaaaafd773700 LOG waylandsink gstwaylandsink.c:683:frame_redraw_callback: frame_redraw_cb
0:00:01.583844456 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:769:gst_wayland_sink_show_frame:<waylandsink0> buffer 0xffff9800d000 dropped (redraw pending)
0:00:01.600692403 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:749:gst_wayland_sink_show_frame:<waylandsink0> render buffer 0xffffa0002ea0
0:00:01.600750243 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:780:gst_wayland_sink_show_frame:<waylandsink0> buffer 0xffffa0002ea0 has a wl_buffer from our display, writing directly
0:00:01.601464966 12917 0xaaaafd773700 LOG waylandsink wlbuffer.c:138:buffer_release:<GstWlBuffer@0xffff98009780> wl_buffer::release (GstBuffer: 0xffff9800d120)
0:00:01.617146269 12917 0xaaaafd773700 LOG waylandsink gstwaylandsink.c:683:frame_redraw_callback: frame_redraw_cb
0:00:01.617227389 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:749:gst_wayland_sink_show_frame:<waylandsink0> render buffer 0xffff9800d360
0:00:01.617256309 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:769:gst_wayland_sink_show_frame:<waylandsink0> buffer 0xffff9800d360 dropped (redraw pending)
0:00:01.634158737 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:749:gst_wayland_sink_show_frame:<waylandsink0> render buffer 0xffff9800d240
0:00:01.634231337 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:780:gst_wayland_sink_show_frame:<waylandsink0> buffer 0xffff9800d240 has a wl_buffer from our display, writing directly
0:00:01.634914740 12917 0xaaaafd773700 LOG waylandsink wlbuffer.c:138:buffer_release:<GstWlBuffer@0xffff98009640> wl_buffer::release (GstBuffer: 0xffffa0002ea0)
0:00:01.650452282 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:749:gst_wayland_sink_show_frame:<waylandsink0> render buffer 0xffff9800d000
0:00:01.650518522 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:769:gst_wayland_sink_show_frame:<waylandsink0> buffer 0xffff9800d000 dropped (redraw pending)
0:00:01.650681363 12917 0xaaaafd773700 LOG waylandsink gstwaylandsink.c:683:frame_redraw_callback: frame_redraw_cb
0:00:01.667289669 12917 0xaaaafd791c60 LOG waylandsink gstwaylandsink.c:749:gst_wayland_sink_show_frame:<waylandsink0> render buffer 0xffff9800d120
```
This doesn't happen every on every playback, but when it does (roughly 1 in 10 plays), it can persist until the end of playback.
It looks like #402 might address this, but the code in the related MR is now fairly out of date.
It seems though that just moving the wl_buffer commit and associated checks to the display thread might be a solution.
Any buffers that were ready before a frame callback was received by waylandsink would just be held until the next
callback, or a newer buffer comes in to replace it. Any thoughts?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1747AESdec wav file2023-07-13T16:57:15ZDan SirbuAESdec wav fileI'm trying to use AES enc/dec with wav. I have run the following pipeline to encrypt a wav file:
gst-launch-1.0 filesrc location=./convo2_long.raw ! rawaudioparse format=mulaw sample-rate=8000 num-channels=1 use-sink-caps =false ! mulaw...I'm trying to use AES enc/dec with wav. I have run the following pipeline to encrypt a wav file:
gst-launch-1.0 filesrc location=./convo2_long.raw ! rawaudioparse format=mulaw sample-rate=8000 num-channels=1 use-sink-caps =false ! mulawdec ! audioconvert ! capsfilter caps=audio/x-raw,format=S16LE ! wavenc ! aesenc key=1f9423681beb9a79215820f6bda73d0f iv=e9aa8e834d8d70 b7e0d254ff670dd718 per-buffer-padding=false ! filesink location=./convo2_long_enc.wav
And based on the 'log_aesenc' logs I think it is doing what is supposed to.
Then, I tried to decode the wav file using:
gst-launch-1.0 filesrc location=./convo2_long_enc.wav ! aesdec key=1f9423681beb9a79215820f6bda73d0f iv=e9aa8e834d8d70b7e0d25 4ff670dd718 per-buffer-padding=false ! filesink location=./convo2_long_dec.wav
but it fails with:
ERROR: from element /GstPipeline:pipeline0/GstAesDec:aesdec0: Cipher finalization failed. Additional debug info: ../ext/aes/gstaesdec.c(416): gst_aes_dec_sink_event (): /GstPipeline:pipeline0/GstAesDec:aesdec0: Error while finalizing the stream
I do not get any extra details in the log file.
GST_DEBUG="2,wavenc:7,aesenc:7,aesdec:7" GST_DEBUG_FILE="./log.txt"[log_aesdec.txt](/gstreamer/gst-build/uploads/972a382ed909fc7e5f1c96a40d66a23f/log_aesdec.txt)
Do I do something wrong or it is a bug ?[log_aesenc.txt](/uploads/ed5d67c653ad42cfa195b7137c1cc2ce/log_aesenc.txt)[log_aesdec.txt](/uploads/410c7ed6c1cd6d54b4c95102e5417c06/log_aesdec.txt)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1746Adding subtitle to mpegtsmux as "subpicture/x-dvb" returns error2022-12-09T12:48:07ZBabak AbolghasemiAdding subtitle to mpegtsmux as "subpicture/x-dvb" returns errorBy running the following pipe, the following error is shown and nothing is saved,
gst-launch-1.0 udpsrc uri=udp://224.4.4.4:1234 ! tsdemux program-number=10601 name=d ! video/x-h264 ! decodebin ! deinterlace ! videoconvert ! x264enc !...By running the following pipe, the following error is shown and nothing is saved,
gst-launch-1.0 udpsrc uri=udp://224.4.4.4:1234 ! tsdemux program-number=10601 name=d ! video/x-h264 ! decodebin ! deinterlace ! videoconvert ! x264enc ! h264parse ! queue ! mux. mpegtsmux name=mux ! filesink location=file.ts d. ! subpicture/x-dvb ! queue ! mux. -e
**ERROR:**
(gst-launch-1.0:2375051): GStreamer-CRITICAL **: 15:34:19.769: gst_segment_to_running_time: assertion 'segment->format == format' failedhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1745GStreamer bitrate does not work the same when implemented in C++ compared to ...2023-05-30T16:06:24ZLima LuizGStreamer bitrate does not work the same when implemented in C++ compared to command line get-launch-1.0 (x264enc and omxh264enc)I encountered different behavior with a gstreamer pipelines when implemented in C++ compared to gst-launch-1.0 execution in command line - the problem is with the bitrate property.
The pipeline which used in command line was:
`gst-launc...I encountered different behavior with a gstreamer pipelines when implemented in C++ compared to gst-launch-1.0 execution in command line - the problem is with the bitrate property.
The pipeline which used in command line was:
`gst-launch-1.0 ximagesrc ! autovideoconvert ! x264enc bitrate=800 pass=0 ! video/x-h264, stream-format=byte-stream ! h264parse ! mpegtsmux ! udpsink host=127.0.0.1 port=1234 sync=false`
The C++ implementation is:
```
GstElement* pipeline;
GstElement* appsrc;
GstElement* videoConvert;
GstElement* encoder;
GstElement* encoderCapsFilter;
GstElement* parser;
GstElement* tsmux;
GstElement* udpsink;
pipeline = gst_pipeline_new ("pipeline");
appsrc = gst_element_factory_make ("appsrc", "source");
videoConvert = gst_element_factory_make ("autovideoconvert", "my_video_convertor");
encoder = gst_element_factory_make ("x264enc", "my_encoder");
encoderCapsFilter = gst_element_factory_make("capsfilter", "my_caps");
parser = gst_element_factory_make ("h264parse", "my_parser");
tsmux = gst_element_factory_make ("mpegtsmux", "my_muxer");
udpsink = gst_element_factory_make ("udpsink", "my_udpsink");
/*Configure appsrc*/
g_object_set (G_OBJECT (appsrc), "caps", gst_caps_new_simple ("video/x-raw",
"format", G_TYPE_STRING, "I420",
"width", G_TYPE_INT, width,
"height", G_TYPE_INT, height,
"framerate", GST_TYPE_FRACTION, 25, 1, NULL), NULL);
g_object_set(G_OBJECT(appsrc), "is-live" , true, NULL);
/*Configure videoConvert*/
/*Configure encoder*/
g_object_set(G_OBJECT(encoder), "bitrate" , 800, NULL);
g_object_set(G_OBJECT(encoder), "pass" , 0, NULL);
/*Configure encoder caps*/
g_object_set(G_OBJECT (encoderCapsFilter), "caps", gst_caps_from_string("video/x-h264, stream-format=byte-stream"), NULL);
/*Configure h264parse*/
/*Configure mpegtsmux*/
/*Configure udpsink*/
g_object_set(G_OBJECT(udpsink), "host" , "127.0.0.1", NULL);
g_object_set(G_OBJECT(udpsink), "port" , 1234, NULL);
g_object_set(G_OBJECT(udpsink), "sync" , false, NULL);
// add
gst_bin_add_many(GST_BIN(pipeline),
appsrc,
videoConvert,
encoder,
encoderCapsFilter,
parser,
tsmux,
udpsink,
NULL);
// link
if (!gst_element_link_many(appsrc,
videoConvert,
encoder,
encoderCapsFilter,
parser,
tsmux,
udpsink,
NULL))
{
g_printerr("Elements could not be linked");
}
```
bitrate is set to 800kbps and when testing this pipeline from command line with Wireshark the baudrate results around 800-850kbps which is good, when tested the same pipeline in C++ (to use appsrc instead of ximagesrc) the baudrate results in different and higher bitrate (around 1200-1300kbps),
same results occured with omxh264enc encoder as well with control-rate=2 (CBR mode)
What is missing to reach the same bitrate result when executed through command line? Is there more configuration to be done into the gst elements when implemented in C++?https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1744nvav1enc:Add support for av1 hardware encoding2022-11-28T12:44:40Z谢美龙nvav1enc:Add support for av1 hardware encodingThe 8th generation nvenc has added support for av1 encoding. [Support Matrix](https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new).
And rtpav1pay just released in gstreamer 1.21.1. The nvav1enc + rtpav1pay + webr...The 8th generation nvenc has added support for av1 encoding. [Support Matrix](https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new).
And rtpav1pay just released in gstreamer 1.21.1. The nvav1enc + rtpav1pay + webrtc will be a nice combination.
[orign issue](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1489)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1743tsdemux:The huge PTS causes abnormal playback2022-11-28T12:45:43ZHmily_gg fftsdemux:The huge PTS causes abnormal playback**[Phenomenon]**
- When we plaback the test file,the total duration is 0:00:02.1,but current time is always updated and more than total duration.
Meanwhile,the Video frame is freeze.
**[Analysis]**
- The given test file 0000003281-00000...**[Phenomenon]**
- When we plaback the test file,the total duration is 0:00:02.1,but current time is always updated and more than total duration.
Meanwhile,the Video frame is freeze.
**[Analysis]**
- The given test file 0000003281-0000003301.mpg has huge PTS that leading EOS event is blocked.[0000003281-0000003301.mpg](/uploads/a9a5b50fa2830f9adb5cc6c2e1649f28/0000003281-0000003301.mpg).But the total duration is Not so long(0:00:02.1?).
Fragment log:
- tsdemux.c:2646:gst_ts_demux_parse_pes_header:<tsdemux0>�[00m stream **PTS 17:03:07.911980999** DTS 17:03:07.861925444
- tsdemux.c:2646:gst_ts_demux_parse_pes_header:<tsdemux0>�[00m stream **PTS 99:99:99.999999999** DTS 99:99:99.999999999
**[Expected Behavior]**
- Detect huge PTS, throw ERROR messge from GBUS.
**[Setup]**
- Operating System: Ubuntu 22.04
- Device: Computer
- GStreamer Version: 1.20.3.1
- Command line: gst-play-1.0 ./0000003281-0000003301.mpg
**[Steps to reproduce the bug]**
- Download 0000003281-0000003301.mpg
- Run gst-play-1.0 ./0000003281-0000003301.mpg
**[How reproducible is the bug]**
- Alwayshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1741kmssink: Messes up scaling when output has non-square pixels2022-11-09T16:45:45ZMatthijs Kooijmankmssink: Messes up scaling when output has non-square pixelsTL;DR: When the output has non-square pixels, kmssink will compensate for that by either cropping (instead of scaling) the video, or picking a drm render mode src size that is larger than the video frames, causing drm to refuse (and gst ...TL;DR: When the output has non-square pixels, kmssink will compensate for that by either cropping (instead of scaling) the video, or picking a drm render mode src size that is larger than the video frames, causing drm to refuse (and gst then falls back to just rendering pixels 1:1).
This is an issue I noticed while running on an Orange Pi SBC with a HDMI screen that reported incorrect dimensions, but I can reproduce it on a regular machine by forcing a 16:9 resolution on a 4:3 screen as well. I've had a look at the code and I suspect that the way this is handled might be all wrong, but I do not have enough familiarity with the code to really tell where the problem is and what the fix would be, so I'll just share my observations here and hope someone else will pick it up.
The original problem was:
- Rendering a 1920x1080 video to an 1920x1080 (16:9) HDMI screen with playbin3.
- The screen reports a size of 300x260mm (10.4:9), which would mean pixels are not square, but have a 1.54:1 pixel ratio (which [`gst_video_calculate_device_ratio`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmsutils.c#L230) rounds to 5:3).
- [`gst_kms_sink_calculate_display_ratio`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmssink.c#L1073), which seems to be intended to compensate for the non-square pixels, then decides the sink size should become 3200x1080. I'm not entirely sure what this number means, I think that *if* the video would be stretched up to this value, and then proportionally scaled back down to the 1920x1080 output, *then* I b believe it would be displayed correctly (with black bars above and below) - in the case the physical size of the display was really correct.
- However, the sink size is not used like this, but instead is used to set the "SRC" size of the DRM plane mode (iow, which pixels to take from the video to optionally scale and render into the given DST size). Since the video only has 1920x1080 pixels, the kernel refuses to set this up and [`drmModeSetPlane`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmssink.c#L1672) fails. If you enable drm kernel debug output (`echo 0x04 | sudo tee /sys/module/drm/parameters/debug`), the kernel complains about this:
[drm:drm_framebuffer_check_src_coords] Invalid source coordinates 3200.000000x1080.000000+0.000000+0.000000 (fb 1920x1088)
(note that the fb 1920x1088 is not the *output* fb size, but the input memory buffer that contains video)
- Because the modeset fails, gstreamer unsets can_scale and retries, which causes the video to be rendered pixel-for-pixel to the output making it fullscreen (since video and output resolution are the same). Even though this is what I wanted, gstreamer is not behaving correctly in the face of the specified physical size.
- When rendering a second video with the same kmssink, the negotiation is now down with can_scale=false, which means that kmssink advertises its non-square pixels, causing playbin to add a software scaling step to (correctly) add black horizontal bars and the output is correct (but needlessly slow, since drm could have handled scaling).
To reproduce this issue on a regular PC, I:
- Passed the `video=DP-1:1280x720` option on the kernel commandline. This forced my 4:3 monitor into a 16:9 resolution, i.e. non-square pixels
- Played a test video: `sudo GST_DEBUG=kmssink:5 gst-launch-1.0 -v videotestsrc ! video/x-raw,width=1920,height=1080 ! kmssink connector-id=317` (added `sudo` to allow DRM access, passed a connector-id to use the right monitor, value taken from `drm_info`, I used 1920x1080 video instead of 1280x720 to [trigger this if](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmssink.c#L1108).
- As before, this sets the sink size too large (2560x1080) and makes the drm plane fail (`kernel: [drm:drm_framebuffer_check_src_coords [drm]] Invalid source coordinates 2560.000000x1080.000000+0.000000+0.000000 (fb 1920x1080)`), falling back to 1:1 pixel rendering, which shows only the top left 1280x720 pixels (since the display resolution is smaller than the video resolution).
- Gstreamer output: [gst-output.txt](/uploads/b231cea8dc8f356deb2a9548a2d26bbf/gst-output.txt)
The issue can also manifest itself differently depending on the video resolution:
- `sudo GST_DEBUG=kmssink:5 gst-launch-1.0 -v videotestsrc ! video/x-raw,width=1280,height=720 ! kmssink connector-id=317`
- This [ends up in this if](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmssink.c#L1113), setting the sink resolution to 1280x540. Again, if the video would be stretched to this value and then proportionally scaled to the fill the output (which would not need scaling in this case), the output would be ok. But instead of that, the output shows black bars top and bottom, but the actual video is cropped (only showing 540 of the 720 lines), which is also incorrect. I didn't get output of this run.
And also here, with can_scale=false and a videoscale element, the non-square pixels are compensated for properly, showing the image with horizontal bars as expected: `sudo GST_DEBUG=kmssink:5 gst-launch-1.0 -v videotestsrc ! video/x-raw,width=1920,height=1080 ! videoscale ! kmssink connector-id=317 can_scale=false`
As I said, I am not entirely sure how this is supposed to work, but I have the feeling that `gst_kms_sink_calculate_display_ratio()` is not doing the right thing. Instead of modifying the SRC rectangle for rendering, I think the non-square-pixel compensation should be modifying the DST rectangle instead. i.e. always render the full src, but possible compress it to add bars to the output). This is also what is done currently when the video and output ratio do not match (through [gst_video_sink_center_rect in `gst_kms_sink_show_frame`](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/sys/kms/gstkmssink.c#L1637))
Looking at the commit history, it seems that this code was already (broken?) like this when it was first introduced in [commit 1aee6cd](https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/1aee6cdc25572d856ca414940689194f54fd9054) by @vjaquez.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1740Signal status checker (Stop code according to signal condition)2023-07-13T11:21:14Zonur aktaşSignal status checker (Stop code according to signal condition)Hi;
I’m reading a signal from v4l2src.
Tried using pad probe etc methods, but I couldn’t read the camera signal at all, when I unplug the camera cable, the code continues to run.
Need to use such a query that when the camera connection o...Hi;
I’m reading a signal from v4l2src.
Tried using pad probe etc methods, but I couldn’t read the camera signal at all, when I unplug the camera cable, the code continues to run.
Need to use such a query that when the camera connection or cable is disconnected, the system understands this and stops the code and waits according to the next signal status.
Developing on Nvidia Jetson, my problem is to stop and continue the code, depending on the signal from the camera. If the camera is not connected, I want to stop the code, and when the camera is connected, I want the code to continue again.
I am developing on C .
What headings would you recommend .
I don’t know if it will help, but I use multicast methods such as filesink, udp multicast sink, unicast sink over v4l2src in the code, if there are methods to stop the code by checking them, I can use them.
Best Regards …https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1739Audio problems using appsr and srtsink2022-10-27T20:41:15ZCarles Albert Bolaños GarciaAudio problems using appsr and srtsinkI'm trying to send AV data using srt with no success. If I use this pipe, the resulting stream is Ok. Players like VLC are able to connect them using srt://127.0.0.1:5011?mode=caller
gst-launch-1.0 uridecodebin uri="file:///C:/temp/AT_0...I'm trying to send AV data using srt with no success. If I use this pipe, the resulting stream is Ok. Players like VLC are able to connect them using srt://127.0.0.1:5011?mode=caller
gst-launch-1.0 uridecodebin uri="file:///C:/temp/AT_0007 Corzo emboscado.mxf" name=decode ! videoconvert ! x264enc ! queue ! mpegtsmux name=mux ! queue ! srtsink uri=srt://127.0.0.1:5011?mode=listener decode. ! audioconvert ! avenc_aac ! queue ! mux.
But if I use appsrc and the incoming audio and video data comes from another process, the audio using some players, not all of them, is not ok, and there are silences every few seconds. The VLC debug window does not show errors, but the audio rendering is not ok.
appsrc is-live=true do-timestamp=true ! videoconvert ! x264enc ! queue ! mpegtsmux name=mux ! queue ! srtsink uri=srt://127.0.0.1:5011?mode=listener appsrc is-live=true do-timestamp=true ! audioconvert ! avenc_aac ! queue ! mux.
I have done multiple tests with no success, always the audio has silences. If I change the pipe and instead to send using srt, I render it to a video and audio sink, the resulting output is ok.
I have done another test, saving the Transport stream in the first pipe, that works fine, and the second one, and the second one does not have DTS video packets, only PTS and PCR. This is the big difference between both transport stream files. In my "need-data" video callback I try to calculate the PTS and DTS (with the same vaule right now), but the resulting stream does not have DTS information included.
Can anybody help me? I'm working on Windows with the last GStreamer version.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1738Make compatible with Ant Media Server SRT mechanism2023-07-13T10:51:36ZSelim Emre ToyMake compatible with Ant Media Server SRT mechanismHi guys,
I'm trying to push stream to SRT source. I can able to do it with FFmpeg like as below:
```
ffmpeg -re -i {INPUT} -vcodec libx264 -profile:v baseline -g 60 -acodec aac -f mpegts srt://test.antmedia.io:4200?streamid=WebRTCAppEE/...Hi guys,
I'm trying to push stream to SRT source. I can able to do it with FFmpeg like as below:
```
ffmpeg -re -i {INPUT} -vcodec libx264 -profile:v baseline -g 60 -acodec aac -f mpegts srt://test.antmedia.io:4200?streamid=WebRTCAppEE/stream1
```
But I'm having some trouble with Gstreamer SRT plugin. Please let me know which part I'm missing. I have tried:
```
gst-launch-1.0 -v videotestsrc ! video/x-raw, height=1080, width=1920 ! videoconvert ! x264enc tune=zerolatency ! video/x-h264, profile=baseline ! mpegtsmux ! srtsink uri="srt://test.antmedia.io:4200?streamid=WebRTCAppEE/stream1"
```
Best Regards,
Selimhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1737h264parse: can not get the correct resolution in src caps for multi-resolutio...2022-10-11T09:04:29ZShiming Dongh264parse: can not get the correct resolution in src caps for multi-resolution streamsI am tring to decode a multi-resolution stream by gstreamer pipeline. But when the resolution changed during decoding, the decoder can NOT get the new width and height in src caps. I checked the function of **gst_h264_parse_update_src_ca...I am tring to decode a multi-resolution stream by gstreamer pipeline. But when the resolution changed during decoding, the decoder can NOT get the new width and height in src caps. I checked the function of **gst_h264_parse_update_src_caps** in gsth264parse.c, I found below code:
```/* sps should give this but upstream overrides */
2165 if (s && gst_structure_has_field (s, "width"))
2166 gst_structure_get_int (s, "width", &width);
2167 else
2168 width = h264parse->width;
2169
2170 if (s && gst_structure_has_field (s, "height"))
2171 gst_structure_get_int (s, "height", &height);
2172 else
2173 height = h264parse->height;```
The width and height in src caps are overrided by upstream caps instread of using the values in SPS, that's the reason why
decoder can not get the updated width and height. I have no idea why don't you directly use the crop_width and crop_height in SPS?
BTW, I am using the version of GStreamer 1.20.1
the OS is aarch64 GNU/Linuxhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1736Creating source plugin with gst-element-maker2023-07-13T10:39:49ZAlex CCreating source plugin with gst-element-makerHi,
I'm trying to create a source plugin using **gst-element-maker** (as recommended in the Plugin Writer's Guide).
I used **basesrc** as a base class and was able to compile the generated code (it shows up in gst-inspect).
When running...Hi,
I'm trying to create a source plugin using **gst-element-maker** (as recommended in the Plugin Writer's Guide).
I used **basesrc** as a base class and was able to compile the generated code (it shows up in gst-inspect).
When running the simplest pipeline possible, I see errors that I have no idea what to do with them. I understand that I have to implement some stuff in the generated skeleton code... but have no clue what exactly should I do. Is there any sample code for a simple source plugin?
This is the pipeline:
```
gst-launch-1.0 klvsrc ! fakesink
```
Here are the logs:
```
0:00:00.009232429 6529 0x55f0e2f674a0 LOG klvsrc gstklvsrc.c:133:gst_klvsrc_init: Init GstKlvsrc
0:00:00.009563499 6529 0x55f0e2f674a0 DEBUG klvsrc gstklvsrc.c:353:gst_klvsrc_query:<klvsrc0> query
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.098: gst_mini_object_ref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_caps_can_intersect: assertion 'GST_IS_CAPS (caps2)' failed
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_mini_object_unref: assertion 'mini_object != NULL' failed
0:00:00.009617073 6529 0x55f0e2f674a0 DEBUG klvsrc gstklvsrc.c:353:gst_klvsrc_query:<klvsrc0> query
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_mini_object_ref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_pad_template_new: assertion 'caps != NULL' failed
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_mini_object_unref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_element_request_compatible_pad: assertion 'GST_IS_PAD_TEMPLATE (templ)' failed
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_object_unref: assertion 'object != NULL' failed
0:00:00.009649407 6529 0x55f0e2f674a0 DEBUG klvsrc gstklvsrc.c:353:gst_klvsrc_query:<klvsrc0> query
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_mini_object_ref: assertion 'mini_object != NULL' failed
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_caps_can_intersect: assertion 'GST_IS_CAPS (caps1)' failed
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_mini_object_unref: assertion 'mini_object != NULL' failed
0:00:00.009681460 6529 0x55f0e2f674a0 DEBUG klvsrc gstklvsrc.c:353:gst_klvsrc_query:<klvsrc0> query
(gst-launch-1.0:6529): GStreamer-CRITICAL **: 10:44:41.099: gst_mini_object_ref: assertion 'mini_object != NULL' failed
0:00:00.009698831 6529 0x55f0e2f674a0 ERROR GST_PIPELINE gst/parse/grammar.y:773:gst_parse_perform_link: could not link klvsrc0 to fakesink0
WARNING: erroneous pipeline: could not link klvsrc0 to fakesink0
```
Please, can someone help me with this?
Thanks,
Alex