GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-02-09T07:50:40Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1005Update gtk gstreamer plugin2022-02-09T07:50:40ZKavitha ktUpdate gtk gstreamer pluginHi
I found that new patch added in gstremer (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/712 ) but it is not available in gtk. Any option to do the same in gtk3?Gtk contain gstremer version 1.18.5Hi
I found that new patch added in gstremer (https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/712 ) but it is not available in gtk. Any option to do the same in gtk3?Gtk contain gstremer version 1.18.5https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1004Allow for multiple qmlglsink instances on windows2024-02-28T15:39:28ZAkash PatelAllow for multiple qmlglsink instances on windowsI am creating this issue on behalf of [mavlink/qgroundcontrol](https://github.com/mavlink/qgroundcontrol).
Is there a way to allow multiple qmlglsink instances on windows? If so what is the proper way to go about this?
Currently in our ...I am creating this issue on behalf of [mavlink/qgroundcontrol](https://github.com/mavlink/qgroundcontrol).
Is there a way to allow multiple qmlglsink instances on windows? If so what is the proper way to go about this?
Currently in our project, we have forked `gst-plugins-good` and have implemented the [following patch](https://github.com/mavlink/gst-plugins-good/commit/9d782fad9dc0384ba86ecae64511c193f6149f93). I don't understand the workings of gst-plugins-good but it seems like our patch is handling the Windows case separately via `defines`.
If it is not possible to currently allow multiple qmlglsink instances on windows than would you be interested in incorporating the patch qgroundcontrol is using? Or maybe providing a better/proper solution to the issue than what we are using.
Thanks,
Additional info:
See https://github.com/mavlink/qgroundcontrol/issues/10140 for qgroundcontrol's side of the discussion.
See https://github.com/mavlink/gst-plugins-good/commit/9d782fad9dc0384ba86ecae64511c193f6149f93 for our current solution.
Relevant People:
Author of commit: @andrew.voznytsa (not sure if they are active anymore)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1003Update hw accelerated video decoding docs2022-02-08T19:31:50ZNirbheek Chauhannirbheek.chauhan@gmail.comUpdate hw accelerated video decoding docs`subprojects/gst-docs/markdown/tutorials/playback/hardware-accelerated-video-decoding.md` needs updating, carrying over from discussion at https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1671`subprojects/gst-docs/markdown/tutorials/playback/hardware-accelerated-video-decoding.md` needs updating, carrying over from discussion at https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1671https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1700ICE Connection state changed to '4' without any indication2023-05-30T16:08:14ZSabri MTIBAAICE Connection state changed to '4' without any indicationI'm facing an issue with streaming app between cam with webrtbin and HTML5 client.
in some cases, the negotiation doesn't end correctly and ICE Connection state changed to '4' .. then the player become dark.
I don't know how to debug th...I'm facing an issue with streaming app between cam with webrtbin and HTML5 client.
in some cases, the negotiation doesn't end correctly and ICE Connection state changed to '4' .. then the player become dark.
I don't know how to debug the issue. Have you any idea about the issue?
![image](/uploads/8cdce1c56942bebfbb827ac24f3106f1/image.png)
the issue is more frequent when I'm using the HTLM5 player from my VPN.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/954rtpopuspay/ timstamp issue2023-07-01T21:03:30Zsuresh manirtpopuspay/ timstamp issuewhenever, Set the play state once again in the pipeline which is had rtpopuspay element. it's gave the timestamp difference between two consecutive RTP packets are varied. timestamp duration couldn't as expected value.it got varied while...whenever, Set the play state once again in the pipeline which is had rtpopuspay element. it's gave the timestamp difference between two consecutive RTP packets are varied. timestamp duration couldn't as expected value.it got varied while re-play pipeline.
pipeline flow:
filesrc location="file-name" ! pcapparse caps="PCMA capabilities" ! alawdec ! audioconvert ! audioresample ! opusenc ! rtpopuspay ![trancode_send](/uploads/f7606a3dbe0a33b3b0bdadc929242bb6/trancode_send.PNG)https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1002RTSP stream does not work2022-02-08T11:23:01ZantonioasRTSP stream does not workHi, I'm using the plugin with OBS and it works great with Dahua cameras, but I have a problem with Panasonic's RTSP stream (example link: rtsp://root:root@123.456.789.000:554/MediaInput/h264) and I can't understand why.
Thank you for yo...Hi, I'm using the plugin with OBS and it works great with Dahua cameras, but I have a problem with Panasonic's RTSP stream (example link: rtsp://root:root@123.456.789.000:554/MediaInput/h264) and I can't understand why.
Thank you for your help.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1001gst-plugins-bad depends on two different versions webrtc-audio-processing2023-09-04T15:44:40ZJan Tojnargst-plugins-bad depends on two different versions webrtc-audio-processingWhen updating gst-plugins-bad to 1.20.0 on NixOS, we noticed that it depends on two different versions of webrtc-audio-processing:
* `isac` plug-in requires ≥ 1.0: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/6434d69f8c1ed9...When updating gst-plugins-bad to 1.20.0 on NixOS, we noticed that it depends on two different versions of webrtc-audio-processing:
* `isac` plug-in requires ≥ 1.0: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/6434d69f8c1ed94271c4fa9c8ce6275106e42dd0/subprojects/gst-plugins-bad/ext/isac/meson.build#L1
* `webrtcdsp` plug-in requires < 0.4: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/6434d69f8c1ed94271c4fa9c8ce6275106e42dd0/subprojects/gst-plugins-bad/ext/webrtcdsp/meson.build#L7
Can’t this cause symbol conflicts at runtime?
Downstream discussion: https://github.com/NixOS/nixpkgs/pull/158280https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/182Implement a Transcriber element using Google Cloud Speech-to-Text API2022-09-16T09:07:28ZRafael CarícioImplement a Transcriber element using Google Cloud Speech-to-Text APII would like to implement a new plugin around Google Cloud multimedia/machine learning APIs. The first one that seems to make sense to me is an element similar to the existing [`awstranscriber`](https://gitlab.freedesktop.org/gstreamer/g...I would like to implement a new plugin around Google Cloud multimedia/machine learning APIs. The first one that seems to make sense to me is an element similar to the existing [`awstranscriber`](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/tree/main/net/rusoto/src/aws_transcriber) but using the Google [Speech-to-Text API](https://cloud.google.com/speech-to-text).
Is this something you would consider accepting here? If yes, I will start working on it. :smiley:https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1000audioinvert: silent with F32LE2022-02-08T10:01:27ZDavid Grinbergaudioinvert: silent with F32LE### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstream...### Describe your issue
<!-- a clear and concise summary of the bug. -->
<!-- For any GStreamer usage question, please contact the community using the #gstreamer channel on IRC https://www.oftc.net/ or the mailing list on https://gstreamer.freedesktop.org/lists/ -->
This simple pipeline outputs silent invert.wav file
```
gst-launch-1.0 filesrc location=input.wav ! wavparse ! audioconvert ! audioresample ! 'audio/x-raw,format=F32LE' ! audioinvert degree=1.0 ! wavenc ! filesink location=invert.wav
```
But if I change F32LE to S16LE everything is ok.
#### Expected Behavior
invert.wav contains inverted input.wav
#### Observed Behavior
invert.wav contains silence
#### Setup
- **Operating System:** macOS 11.5.2
- **Device:** MacBook Pro 2019 Intel Core i9
- **GStreamer Version:** 1.18.4
### How reproducible is the bug?
<!-- The reproducibility of the bug is Always/Intermittent/Only once after doing a very specific set of steps-->
100%
### Solutions you have tried
Tried running with different GST_DEBUG values but found none errorshttps://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/953audioinvert silent with F32LE2022-02-08T10:01:28ZDavid Grinbergaudioinvert silent with F32LEThis simple pipeline outputs silent invert.wav file
```
gst-launch-1.0 filesrc location=input.wav ! wavparse ! audioconvert ! audioresample ! 'audio/x-raw,format=F32LE' ! audioinvert degree=1.0 ! wavenc ! filesink location=invert.wav
```...This simple pipeline outputs silent invert.wav file
```
gst-launch-1.0 filesrc location=input.wav ! wavparse ! audioconvert ! audioresample ! 'audio/x-raw,format=F32LE' ! audioinvert degree=1.0 ! wavenc ! filesink location=invert.wav
```
But if I change F32LE to S16LE everything is ok. GStreamer version:
```
gst-launch-1.0 --version
gst-launch-1.0 version 1.18.4
GStreamer 1.18.4
Unknown package origin
```https://gitlab.freedesktop.org/gstreamer/meson-ports/libffi/-/issues/9Build failure with `-Dc_std=c11`2022-02-07T04:10:11ZLászló VáradyBuild failure with `-Dc_std=c11`When configuring the project with `-Dc_std=cXX` (89, 99, 11), the compilation fails due to an incorrectly detected PCREL check:
```sh
$ meson setup -Dc_std=c11 build
...
$ meson compile -C build
[1/10] Compiling C object src/libffi.so.7...When configuring the project with `-Dc_std=cXX` (89, 99, 11), the compilation fails due to an incorrectly detected PCREL check:
```sh
$ meson setup -Dc_std=c11 build
...
$ meson compile -C build
[1/10] Compiling C object src/libffi.so.7.1.0.p/x86_unix64.S.o
FAILED: src/libffi.so.7.1.0.p/x86_unix64.S.o
cc -Isrc/libffi.so.7.1.0.p -Isrc -I../src -I. -I.. -Iinclude -I../include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -O2 -g -DFFI_BUILDING -fPIC -DTARGET=X86_64 -MD -MQ src/libffi.so.7.1.0.p/x86_unix64.S.o -MF src/libffi.so.7.1.0.p/x86_unix64.S.o.d -o src/libffi.so.7.1.0.p/x86_unix64.S.o -c ../src/x86/unix64.S
../src/x86/unix64.S: Assembler messages:
../src/x86/unix64.S:451: Error: junk at end of line, first unrecognized character is `@'
```
The problematic check:
```
Command line: cc /tmpg5c31nq9/testfile.c -o /tmpg5c31nq9/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -std=c11
Code:
asm (".text; foo: nop; .data; .long foo-.; .text");
Compiler stdout:
Compiler stderr:
/tmpg5c31nq9/testfile.c:1:6: error: expected declaration specifiers or '...' before string constant
1 | asm (".text; foo: nop; .data; .long foo-.; .text");
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Checking if "ASM x86 PCREL" : compiles: NO
```
Workaround:
Using `-Dc_std=gnuXX`.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/999av1parse: Parse colorimetry, mastering display metadata, content light level ...2022-02-07T14:02:59ZSebastian Drögeav1parse: Parse colorimetry, mastering display metadata, content light level metadata from bitstream if not provided by upstreamhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/998nvcodec messes up the aspect resolution for different SAR and DAR values2022-02-05T23:57:27ZGuru Govindannvcodec messes up the aspect resolution for different SAR and DAR values### Describe your issue
When the SAR/DAR values are very high, the nvcodecs seems to change the aspect ratio of the video.
I have a video segment which has a high SAR/DAR values. The sw and intel transcodes seems to handle it properly. ...### Describe your issue
When the SAR/DAR values are very high, the nvcodecs seems to change the aspect ratio of the video.
I have a video segment which has a high SAR/DAR values. The sw and intel transcodes seems to handle it properly. However nvcodecs seems to change aspect ration from 16/9 to 4/3. Also the SAR values seems to be flipped or sometimes completely messes up the video.
The following is the SAR/DAR values of the ts segment I am trying to transcode.
```
Stream #0:0[0x41]: Video: h264 (High) (HDMV / 0x564D4448), yuvj420p(pc, bt709, progressive), 480x270 [SAR 46892:45837 DAR 750272:412533], 15 fps, 25 tbr, 90k tbn, 30 tbc
```
After the nvcodec transcode the SAR/DAR values are as follows
```
Stream #0:0[0x41]: Video: h264 (HDMV / 0x564D4448), yuvj420p(pc, bt709, progressive), 1920x1086 [SAR 62959:17280 DAR 62959:9774], 15 fps, 15 tbr, 90k tbn, 30 tbc
```
I am using the following pipeline to transcode it
```
gst-launch-1.0 filesrc location="high_sar_values.ts" ! tsdemux ! queue ! h264parse ! nvh264dec ! videorate ! videoscale ! video/x-raw,width=1920,height=1086,framerate=15/1 ! nvh264enc ! mpegtsmux ! filesink location="output_gst.ts"
```
#### Expected Behavior
It should retain the aspect ratio similar to software transcodes.
#### Observed Behavior
It changes the Aspect ratio to 4:3 or other unviewable strip. The resulting SAR and DAR values dont match the original ratios.
#### Setup
- **Operating System:** Ubuntu 20.04
- **GStreamer Version:** 18.04
- **Command line:**
```
gst-launch-1.0 filesrc location="high_sar_orig.ts" ! tsdemux ! queue ! h264parse ! nvh264dec ! videorate ! videoscale ! video/x-raw,width=1920,height=1086,framerate=15/1 ! nvh264enc ! mpegtsmux ! filesink location="output_gst.ts"
```
### Steps to reproduce the bug
1. open terminal
2. type ```
gst-launch-1.0 filesrc location="high_sar_orig.ts" ! tsdemux ! queue ! h264parse ! nvh264dec ! videorate ! videoscale ! video/x-raw,width=1920,height=1086,framerate=15/1 ! nvh264enc ! mpegtsmux ! filesink location="output_gst.ts"
```
3. Play the output_gst.ts
### How reproducible is the bug?
Happens everytime.
[high_sar_orig.ts](/uploads/e7ca4858f886795b0b99c085de147c09/high_sar_orig.ts)https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1699set local-description in webrtcbin takes long time2023-05-16T03:53:01ZSabri MTIBAAset local-description in webrtcbin takes long timeHello
I'm using webrtcbin in webrtc app between GW deployed on my camera and a HTML5 client. Tests performed are OK but the performance is not acceptable.
After a deep analysis on the log, I found that the streaming takes too long time ...Hello
I'm using webrtcbin in webrtc app between GW deployed on my camera and a HTML5 client. Tests performed are OK but the performance is not acceptable.
After a deep analysis on the log, I found that the streaming takes too long time because the set local description associated to the offer takes variable time to return the result. The fact that it's asynchronous by design doesn't mean that g_signal_emit_by_name remain blocked 10s, 18s even 20s.
I don't know if there is any solution to investigate the issue, I suspect that the signal is not emitted and maybe there is a hidden dependency.
here the screenshot
![image](/uploads/ee834bad22289ca23ea40eec151b72d2/image.png)
Thanks in advance for your help.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/952pngdec: green/pink color issue with 16-bit depth files2023-05-30T10:20:56ZMohan Rpngdec: green/pink color issue with 16-bit depth filesHi,
I have this commandlines
```
$ convert -size 1080x1920 xc:green -gravity center \( -size 540x960 -background green pango:'<span bgcolor="green" fgcolor="white"
size="40000">வணக்கம்</span>' \) -composite test.png
$ gst-launch-1.0 mu...Hi,
I have this commandlines
```
$ convert -size 1080x1920 xc:green -gravity center \( -size 540x960 -background green pango:'<span bgcolor="green" fgcolor="white"
size="40000">வணக்கம்</span>' \) -composite test.png
$ gst-launch-1.0 multifilesrc location=test.png num-buffers=1 ! pngdec ! videorate ! videoconvert ! videoscale ! video/x-raw,framerate=1/4 ! x264enc ! mp4mux ! filesink location=test.mp4
```
The first commandline produces one png image which contains a green
background with white text, there is no issue here, but when I tried
to convert that image into a video, I got a pink background instead of
green.
This issue only happens when using "green", not happening with "red" or "blue".
If I switch the image format to jpg, I'm not facing any issue, these
commandlines works
```sh
$ convert -size 1080x1920 xc:green -gravity center \( -size 540x960 -background green pango:'<span bgcolor="green" fgcolor="white" size="40000">வணக்கம்</span>' \) -composite test.jpg
$ gst-launch-1.0 multifilesrc location=test.jpg num-buffers=1 ! jpegdec ! videorate ! videoconvert ! videoscale ! video/x-raw,framerate=1/4 ! x264enc ! mp4mux ! filesink location=test.mp4
```
So, this seems to be a bug in pngdec, or maybe I'm doing something
wrong in the pngdec commandline.https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/370ci: Scheduled cargo outdated / cargo deny jobs not running anymore2022-09-16T14:00:15ZSebastian Drögeci: Scheduled cargo outdated / cargo deny jobs not running anymoreSame for gst-plugins-rs. Something must've changed in gitlab at some point.
CC @alatiera @gdesmottSame for gst-plugins-rs. Something must've changed in gitlab at some point.
CC @alatiera @gdesmotthttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/997Python bindings don't compile with Python 3.11.0a4 (low-pri)2022-02-04T17:57:10ZSimon FarnsworthPython bindings don't compile with Python 3.11.0a4 (low-pri)Downstream Fedora bug at https://bugzilla.redhat.com/show_bug.cgi?id=2050102.
The Python frame analysis code at https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-python/gi/overrides/gstmodule.c#L669 in funct...Downstream Fedora bug at https://bugzilla.redhat.com/show_bug.cgi?id=2050102.
The Python frame analysis code at https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-python/gi/overrides/gstmodule.c#L669 in function `pygst_debug_log` reads private members of the PyFrameObject structure directly.
In https://docs.python.org/3.11/whatsnew/3.11.html under bullet "Changes of the private PyFrameObject structure members", there's an explanation of the changes involved to make this work with Python 3.11
My colleagues on the Fedora Python team are doing test builds against Python 3.11 now, as they hope to start migrating to it for Fedora 37, and want upstream projects to be ready for the changes in plenty of time. I'm not in a position to work on this myself, but I'm raising an issue so that if someone has time and motivation, they can start the migration to Python 3.11 compatible frame analysis now; note that some care will be needed to maintain back-compat to Python before Python 3.8.https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/323Consider blocklisting the Intel i965 VAAPI driver2022-02-04T02:59:03ZRobert MaderConsider blocklisting the Intel i965 VAAPI driverThe Gnome project currently [considers enabling hardware encoding for screencasting by default](https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2080) in the upcoming 42 release. Right now it looks like only [three driver impl...The Gnome project currently [considers enabling hardware encoding for screencasting by default](https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2080) in the upcoming 42 release. Right now it looks like only [three driver implementations are allowed by defaul](https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/blob/master/gst/vaapi/gstvaapipluginutil.c#L953-955)t:
- `Intel i965 driver`
- `Intel iHD driver`
- `Mesa Gallium driver`
During testing it was found that the i965 driver was by far the one most likely to cause issues. Further more, unlike the later ones which appear to have active upstream activity and generally responsive developers, development on the i965 driver [appears to have mostly stalled](https://github.com/intel/intel-vaapi-driver/commits/master).
In order to provide a more reliable out-of-the-box experience, would it make sense to consider disabling that driver by default? It looks like at least Gnome-Shell otherwise would need to carry its own blocklist.
While this decreases VAAPI support on the first look, the hope by the responsive Shell devs is that using hardware encoding by default in more common places increases driver quality eventually, leading to more widespread use.
---
cc: @ndufresne @vjaquez @He_Junyanhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/993Some id3 tags repeated2022-11-10T09:21:10ZAustin ButlerSome id3 tags repeated### Describe your issue
Running `gst-discoverer-1.0 -v my_file.mp3` results in the `artist`, `album`, and `genre` tags showing repetition.
Other applications, such as `ffprobe`, do not have the same issue.
```
artist: William Elliott ...### Describe your issue
Running `gst-discoverer-1.0 -v my_file.mp3` results in the `artist`, `album`, and `genre` tags showing repetition.
Other applications, such as `ffprobe`, do not have the same issue.
```
artist: William Elliott Whitmore & Jenny Hoyston, Jenny Hoyston and William Whitmore, Jenny Hoyston and William Whitmore, Jenny Hoyston and William Whitmore, Jenny Hoyston and William Whitmore
album: Hallways Of Always, Hallways Of Allways, Hallways Of Allways, Hallways Of Allways, Hallways Of Allways
genre: Country, Folk, Folk, Folk, Folk
```
#### Expected Behavior
Tags are "normal" like in other ID3 readers.
#### Observed Behavior
Certain tag values are repeated multiple times.
#### Setup
- **Operating System:** NixOS
- **Device:** Computer
- **GStreamer Version:** 1.18.5
- **Command line:** gst-discoverer-1.0 -v my_file.mp3
### Steps to reproduce the bug
1. open terminal
2. type `gst-discoverer-1.0 -v my_file.mp3`
### How reproducible is the bug?
100%
### Solutions you have tried
I'm able to fix the file by running `mp3val -f my_file.mp3` on it.
### Additional Information
I can't provide the files directly due to copyright, but if you're interested I can probably extract the tags if you're able to guide me a bit. It's easy enough for _me_ to fix the files now that I know a workaround, but for users of applications like Lollypop that use GStreamer and don't offer tag editing, it's hard to fix. I tried a number of other tag editors and none of them repro'd this issue.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/992Subproject libdrm fails the build when --wrap-mode=forcefallback is used2022-11-10T09:21:10ZErik De RijckeSubproject libdrm fails the build when --wrap-mode=forcefallback is usedWhen building with `--wrap-mode=forcefallback`, meson fails to properly build libdrm even though all required dependencies seem to be satisfied.
```
meson build \
--buildtype=release \
--default-library=static \
...When building with `--wrap-mode=forcefallback`, meson fails to properly build libdrm even though all required dependencies seem to be satisfied.
```
meson build \
--buildtype=release \
--default-library=static \
--wrap-mode=forcefallback \
-Dgpl=enabled \
-Dorc=enabled \
-Dbase=enabled \
-Dgood=enabled \
-Dbad=enabled \
-Dugly=enabled \
-Dauto_features=disabled \
-Dgst-plugins-base:gl=enabled \
-Dgst-plugins-base:videoconvert=enabled \
-Dgst-plugins-base:app=enabled \
-Dgst-plugins-base:gl_winsys=egl,gbm \
-Dgst-plugins-base:gl_api=opengl \
-Dgst-plugins-good:videobox=enabled \
-Dgst-plugins-good:png=enabled \
-Dgst-plugins-bad:gl=enabled \
-Dgst-plugins-bad:nvcodec=enabled \
-Dgst-plugins-ugly:x264=enabled
```
[meson-output.txt](/uploads/5ec3f4be26994db49c34e270caf27fdf/meson-output.txt)