GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2022-04-19T06:37:11Zhttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/165[2.0] GstUriHandler interface issue in vala2022-04-19T06:37:11ZBugzilla Migration User[2.0] GstUriHandler interface issue in vala## Submitted by Yannick Inizan
**[Link to original bug (#764345)](https://bugzilla.gnome.org/show_bug.cgi?id=764345)**
## Description
some interfaces in GStreamer and other projects are ugly, ex. with URIHandler :
struct _GstU...## Submitted by Yannick Inizan
**[Link to original bug (#764345)](https://bugzilla.gnome.org/show_bug.cgi?id=764345)**
## Description
some interfaces in GStreamer and other projects are ugly, ex. with URIHandler :
struct _GstURIHandlerInterface {
GTypeInterface parent;
/* vtable */
/*`< public >`*/
/* querying capabilities */
GstURIType (* get_type) (GType type);
const gchar * const * (* get_protocols) (GType type);
/* using the interface */
gchar * (* get_uri) (GstURIHandler * handler);
gboolean (* set_uri) (GstURIHandler * handler,
const gchar * uri,
GError ** error);
};
where some members don't have 'GstURIHandler * handler' parameter. with these interfaces, languages like Vala can't implement it because the language implement interface with this parameter by defaulthttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1714How to install bad plugins in Windows2022-04-18T20:41:12ZAngela YanHow to install bad plugins in Windows**Version: 1.20.1**
**OS: Win 10**
I have installed the MSVC 64-bit and MinGW 64-bit package with complete installation. I even successfully built AWS Kinesis Video Stream Producer plugin on the same Windows system by referencing files ...**Version: 1.20.1**
**OS: Win 10**
I have installed the MSVC 64-bit and MinGW 64-bit package with complete installation. I even successfully built AWS Kinesis Video Stream Producer plugin on the same Windows system by referencing files from MSVC installation directory.
But I couldn't find bad plugins in either MSVC or MinGW directory. I would like to use **uvch264src** plugin in the Windows system.
May I know how to install good/ugly/bad plugins in Windows?
I have download the tar file from https://gstreamer.freedesktop.org/src/gst-plugins-bad/ but not sure if I can manually copy the extracted files into MSVC directory or copy to any specific path.
Not sure if it matters, first time install of MSVC and MinGW were using 'typical' installation and later launch the installer again, and modify the installation by manually select every single components. Also tried the 'complete installation' as an over-installation on existing installation. But still can't find bad plugin files in the installation.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1162rtspsrc/rtpbin: Doesn't sync A/V if the server does not provide RTCP2022-04-18T13:11:07ZSebastian Drögertspsrc/rtpbin: Doesn't sync A/V if the server does not provide RTCPThe A/V synchronization only happens in `rtpbin` when it receives an RTCP SR from `rtpjitterbuffer`. In case of RTSP this could already happen once the caps are received with `clock-base` / `npt-start`, and the first packet is received t...The A/V synchronization only happens in `rtpbin` when it receives an RTCP SR from `rtpjitterbuffer`. In case of RTSP this could already happen once the caps are received with `clock-base` / `npt-start`, and the first packet is received to know the local arrival times. The `clock-base` is the RTP timestamp of each stream that corresponds to `npt-start`.
If the server never sends an RTCP SR then A/V sync is never fixed up, and even if the server sends an RTCP SR it would be much later than necessary.
This can probably be solved by adding a new variant of the `sync` signal to `rtpjitterbuffer` that provides `clock-base` and `npt-start` among other things and has `rtpbin` handle this as a special-case in `gst_rtp_bin_associate()`.https://gitlab.freedesktop.org/gstreamer/gst-libav/-/issues/110avenc_g726le: Format not mapped to caps2022-04-18T02:25:02ZDũng Hoàngavenc_g726le: Format not mapped to capsHi team, I have problem when using g 726 codec with little endian format. My pipeline can't work.
htdung@CaCs:~$ **gst-launch-1.0 audiotestsrc ! audio/x-raw,rate=8000 ! audioconvert ! avenc_g726le ! avdec_g726le ! wavenc ! > filesink lo...Hi team, I have problem when using g 726 codec with little endian format. My pipeline can't work.
htdung@CaCs:~$ **gst-launch-1.0 audiotestsrc ! audio/x-raw,rate=8000 ! audioconvert ! avenc_g726le ! avdec_g726le ! wavenc ! > filesink location=xxx.wav**
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> ERROR: from element /GstPipeline:pipeline0/avenc_g726le:avenc_g726le0: GStreamer error: negotiation problem.
> Additional debug info:
> gstaudioencoder.c(1369): gst_audio_encoder_chain (): /GstPipeline:pipeline0/avenc_g726le:avenc_g726le0:
> encoder not initialized
> ERROR: pipeline doesn't want to preroll.
> Setting pipeline to NULL ...
> Freeing pipeline ...
I tried with big endian with same pipeline, and it is ok.
htdung@CaCs:~$ **gst-launch-1.0 audiotestsrc ! audio/x-raw,rate=8000,channels=1 ! audioconvert ! avenc_g726 ! avdec_g726 ! wavenc ! filesink location=xxx.wav**
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> ^Chandling interrupt.
> Interrupt: Stopping pipeline ...
> Execution ended after 0:00:00.410484569
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
Thanks, version of my gstreamer is 1.16https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/106d3dvideosink: bufferpool implementation does not work well with device-lost/r...2022-04-17T22:53:53ZBugzilla Migration Userd3dvideosink: bufferpool implementation does not work well with device-lost/resets## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#706566)](https://bugzilla.gnome.org/show_bug.cgi?id=706566)**
## Description
+++ This bug was initially created as a clone of [Bug 697868](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#706566)](https://bugzilla.gnome.org/show_bug.cgi?id=706566)**
## Description
+++ This bug was initially created as a clone of [Bug 697868](https://bugzilla.gnome.org/show_bug.cgi?id=697868) +++
Resizing requires resetting the device and all the resources allocated to this
d3d pool if we use the default pool. I believe that using a managed pool
instead allows resources to persists in a device reset:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb147168(v=vs.85).aspx
"Use the D3DPOOL_MANAGED flag at creation time to specify a managed resource.
Managed resources persist through transitions between the lost and operational
states of the device. These resources exist both in video and system memory. A
managed resource will be copied into video memory when it is needed during
rendering. The device can be restored with a call to IDirect3DDevice9::Reset,
and such resources continue to function normally without being reloaded with
data. However, if the device must be destroyed and re-created, all resources
must be re-created."
We should also be using the managed for devices lost, and not recreate the
device as it's done now but only reset it to reuse the existent resources.
We should probably disable allowing usage of the pool outside d3dvideosink for 1.2, and then find a real solution that allows us to still continue to work zerocopy.
Version: 1.xhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/734d3dvideosink: videocrop results in black screen2022-04-17T22:53:27ZBugzilla Migration Userd3dvideosink: videocrop results in black screen## Submitted by Colin
**[Link to original bug (#796569)](https://bugzilla.gnome.org/show_bug.cgi?id=796569)**
## Description
gst-launch-1.0.exe videotestsrc ! videoscale ! video/x-raw,width=1280,height=720 ! videocrop top=2 left=0 r...## Submitted by Colin
**[Link to original bug (#796569)](https://bugzilla.gnome.org/show_bug.cgi?id=796569)**
## Description
gst-launch-1.0.exe videotestsrc ! videoscale ! video/x-raw,width=1280,height=720 ! videocrop top=2 left=0 right=0 bottom=0 ! videoconvert ! d3dvideosink
This pipeline produce black screen on GStreamer 1.14.0 and 1.14.1 but works on v1.12.4 on two different computers.
Removing the videocrop by setting top=0 or changing d3dvideosink to glimagesink works, the problem seems to be the interaction between videocrop and d3dvideosink on GStreamer 1.14.x
Version: 1.14.1https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/752d3dvideosink: SetRenderRectangle bug2022-04-17T22:49:45ZBugzilla Migration Userd3dvideosink: SetRenderRectangle bug## Submitted by tom..@..il.com
**[Link to original bug (#796812)](https://bugzilla.gnome.org/show_bug.cgi?id=796812)**
## Description
Created attachment 373057
Gtk on Windows 10
It seems that there's a bug in d3dvideosink whe...## Submitted by tom..@..il.com
**[Link to original bug (#796812)](https://bugzilla.gnome.org/show_bug.cgi?id=796812)**
## Description
Created attachment 373057
Gtk on Windows 10
It seems that there's a bug in d3dvideosink when setting render rectangle.
I have modified
https://github.com/GStreamer/gstreamer-sharp/blob/master/samples/BasicTutorial5.cs
to set the render rectangle, like this:
VideoOverlayAdapter adapter = new
VideoOverlayAdapter(overlay.Handle);
adapter.WindowHandle = windowHandle;
adapter.SetRenderRectangle(50, 50, 427, 240);
adapter.HandleEvents(true);
I expected that the video will be rendered in the 427x240 rectangle, at the
position 50,50, but there is a correct rectangle at the position, and video
is moved to the 50,50 inside this rectangle. The same happens in the
WinForms version of the sample.
It looks OK when running on Linux Mint 19.
**Attachment 373057**, "Gtk on Windows 10":
![gtk](/uploads/b0826639105875ad7cc47ed0419c1cf6/gtk.jpg)
Version: 1.14.1https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1014msdkh264dec: Deadlock with reverse playback2022-04-17T19:59:12ZSeungha Yangseungha@centricular.commsdkh264dec: Deadlock with reverse playbackI don't know whether msdk decoder ever supported reverse playback or not. But it shouldn't fail in this way
Tested with gst-play-1.0 and https://media.w3.org/2010/05/sintel/trailer.mp4, also with other h264 streams on Windows and LinuxI don't know whether msdk decoder ever supported reverse playback or not. But it shouldn't fail in this way
Tested with gst-play-1.0 and https://media.w3.org/2010/05/sintel/trailer.mp4, also with other h264 streams on Windows and Linuxhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1196msdk: Heavy perf. degradation when filter elements are placed between msdkdec...2022-04-17T19:57:46ZSeungha Yangseungha@centricular.commsdk: Heavy perf. degradation when filter elements are placed between msdkdec and msdkencThis pipeline `A` is super slower than `B`. I feel like we need to revisit caps features for msdk as I tried at https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/655#note_219257 to use system memory even on Linux.
...This pipeline `A` is super slower than `B`. I feel like we need to revisit caps features for msdk as I tried at https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/merge_requests/655#note_219257 to use system memory even on Linux.
### Pipeline A
```gst-launch-1.0 souphttpsrc location=http://media.w3.org/2010/05/sintel/trailer.mp4 ! qtdemux ! h264parse ! msdkh264dec ! videoscale ! video/x-raw,width=1280,height=720 ! msdkh264enc ! fakesink```
### Pipeline B
```gst-launch-1.0 souphttpsrc location=http://media.w3.org/2010/05/sintel/trailer.mp4 ! qtdemux ! h264parse ! msdkh264dec ! msdkh264enc ! fakesink```https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/651wasapi: Implement automatic stream management2022-04-17T19:55:18ZBugzilla Migration Userwasapi: Implement automatic stream management## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#793059)](https://bugzilla.gnome.org/show_bug.cgi?id=793059)**
## Description
Currently, when using wasapisrc/wasapisink, if the default source devices changes WA...## Submitted by Nirbheek Chauhan `@nirbheek`
**[Link to original bug (#793059)](https://bugzilla.gnome.org/show_bug.cgi?id=793059)**
## Description
Currently, when using wasapisrc/wasapisink, if the default source devices changes WASAPI captures and sends us silence, and if the default sink device changes WASAPI throws away all rendered audio. Starting with Windows 10, WASAPI now has automatic stream management:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt784437(v=vs.85).aspx
We should implement this in such a way that this mechanism is used at runtime if running on Windows 10, and a fallback mechanism (manually switching devices) is used when running on Windows 7 or 8.https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/555ksvideosrc: Failed to start capture2022-04-17T19:50:13ZBugzilla Migration Userksvideosrc: Failed to start capture## Submitted by Michael MacIntosh
**[Link to original bug (#782466)](https://bugzilla.gnome.org/show_bug.cgi?id=782466)**
## Description
Created attachment 351570
GST_DEBUG=ks*:4 output
I am on windows 10 using gstreamer 1.12...## Submitted by Michael MacIntosh
**[Link to original bug (#782466)](https://bugzilla.gnome.org/show_bug.cgi?id=782466)**
## Description
Created attachment 351570
GST_DEBUG=ks*:4 output
I am on windows 10 using gstreamer 1.12 and I am trying to capture video from an Osprey 460e analog capture card, and I was running into any difficulties using the ksvideosrc element.
It appears to be finding the device but is running into some errors.
My test pipeline:
gst-launch-1.0.exe ksvideosrc device-index=0 ! autovideosink
After executing that, I get a warning that it cant create or open ksclock.
It gives a warning about how it doesn't recognize the GUID for rgb8.
And then it says it can't start capture because of reason 0x048f (ERROR_DEVICE_NOT_CONNECTED), even though the device is connected and I can capture it through VLC, directshow, and the Osprey capture card driver software. My best guess (looking over the source code near https://github.com/GStreamer/gst-plugins-bad/blob/master/sys/winks/gstksvideosrc.c#L961 ), it appears to be getting the error from a call to GetOverlappedResult.
I have tested with a USB webcam to verify that the ksvideosrc does at least work for something and it does work with a USB web camera.
Also all devices on this card appear to have the same issue. I also get this same behavior from autovideosrc as well.
Let me know if I can provide anymore information, or if anyone has any suggestions on things to try.
Attached is my GST_DEBUG=ks*:4 output.
**Attachment 351570**, "GST_DEBUG=ks*:4 output":
[ksvideosrc_debug_4_output.txt](/uploads/92a18cb13c38ede6d857dee4167c7bfe/ksvideosrc_debug_4_output.txt)
Version: 1.12.0https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/12dshowsrcwrapper and wasapi uninitializes the COM library2022-04-17T19:42:40ZBugzilla Migration Userdshowsrcwrapper and wasapi uninitializes the COM library## Submitted by Youness Alaoui
**[Link to original bug (#592415)](https://bugzilla.gnome.org/show_bug.cgi?id=592415)**
## Description
Hi,
So here's the situation, aMSN is a tcl/tk application which uses multiple different exten...## Submitted by Youness Alaoui
**[Link to original bug (#592415)](https://bugzilla.gnome.org/show_bug.cgi?id=592415)**
## Description
Hi,
So here's the situation, aMSN is a tcl/tk application which uses multiple different extensions for specific tasks, one of these extensions is called 'tkvideo' and uses dshow to capture video from webcam devices/other..
The problem now is that when gstreamer (specifically dshowaudiosrc/dshowvideosrc/wasapisrc elements) are used, then completely break tkvideo, and here's why :
tkvideo does a CoInitialize(NULL) when initialized then creates/uses COM objects...
dshowaudiosrc/dshowvideosrc call CoInitializeEx(NULL, COINIT_MULTITHREADED) in the _init and call CoUninitialize() in the dispose. The CoInitializeEx tries to initialize the COM library in a multithreaded model, which fails with RPC_E_CHANGED_MODE.. but it doesn't check the return value... The problem being that CoInitialize(NULL) initializes the COM library in a singlethreaded mode, and when calling CoInitialize or CoInitializeEx, if the threading model changes, the call fails...
later on when dispose is called, dshowaudiosrc/dshowvideosrc call CoUninitialize() which will uninitialize the COM library and free its resources.. but tkvideo is *still* using the COM library and may have COM objects allocated.. this causes it to fail, or crash...
wasapisrc does the same thing, but it uses CoInitialize(NULL), which means that the same problem would occur if any application creates a pipeline using both wasapisrc and dshowvideosrc for example.. you end up initializing COM once (the other initialization failing) but uninitializing it TWICE...
Also note that the fact that the CoUninitialize() is called in the dispose is bad, since dispose *could* be called more than once, it should instead be put in the finalize function of the gobject...
I have to solutions, first, use this :
HRESULT hr = CoInitializeEx (NULL, COINIT_MULTITHREADED);
if (hr == RPC_E_CHANGED_MODE)
hr = CoInitializeEx (NULL, COINIT_APARTMENTTHREADED);
and then check if it failed or not for the second CoInitializeEx, if it failed, either fail to create the element, or just ignore it (a bit risky) but store a variable saying whether or not we should call CoUninitialize later on in the finalize...
second solution would be to do the same code as above, but do it in the class_init and completely remove any call to CoUninitialize()...
not checking for RPC_E_CHANGED_MODE after calling the second CoInitializeEx would mean that we know the COM library is initialized and we can use it, BUT if the main application that initialized it calls CoUninitialize at some point, we're risking a crash... so we could just cross our fingers and hope it never calls CoUninitialize (the other concurrency models possible are : COINIT_DISABLE_OLE1DDE and COINIT_SPEED_OVER_MEMORY, but will most probably never be seen in real life situations).
Note that wasapisrc should also be modified to use CoInitializeEx instead of CoInitialize... with the above solution(s) of course...
KaKaRoTohttps://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/273d3dvideosink: instances out of sync viewing same stream2022-04-17T19:35:47ZBugzilla Migration Userd3dvideosink: instances out of sync viewing same stream## Submitted by Fabio Cetrini
**[Link to original bug (#752323)](https://bugzilla.gnome.org/show_bug.cgi?id=752323)**
## Description
Need help debugging this situation:
I'm viewing 16 times the same live stream (704x576@25fps) ins...## Submitted by Fabio Cetrini
**[Link to original bug (#752323)](https://bugzilla.gnome.org/show_bug.cgi?id=752323)**
## Description
Need help debugging this situation:
I'm viewing 16 times the same live stream (704x576@25fps) inside the same application instance, each viewer is indipendent from others.
After 15/20 seconds, the viewers goes unsynchronized by a bunch of seconds...
Here is a d3dvideosink log of what is happening:
Line 4167: 0:00:16.027982237 10056 12AAA500 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4200: 0:00:16.143013838 10056 1FAFC0B0 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4246: 0:00:16.326275554 10056 1FB10770 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4300: 0:00:16.540716452 10056 1FB10A68 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4353: 0:00:16.777062571 10056 12C28B20 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4387: 0:00:16.907878760 10056 1FB10108 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4610: 0:00:17.823888110 10056 1FB1A718 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4614: 0:00:17.840651538 10056 1FB10748 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4666: 0:00:18.043435521 10056 1FB1AA38 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4670: 0:00:18.058406121 10056 1FB10130 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4741: 0:00:18.344632643 10056 1FB1A0D8 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4765: 0:00:18.442028456 10056 12E6E9B8 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 4824: 0:00:18.656777565 10056 1AECCE00 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 5189: 0:00:20.073670180 10056 1FB1A3F8 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 5550: 0:00:21.490712250 10056 12AAA820 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
Line 5569: 0:00:21.576102846 10056 1FB1AD58 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:`<video_sink>` Render 4:23:36.465000000
As you can see the same frame is processed by the 16 instances in 5 seconds.
Following the code, I've found a LOCK_CLASS statement in d3d_present_swap_chain, other logs here reveal that all the presenting threads are queued waiting to acquire this lock, processed one by one.
At the same time, the application gui becomes unmanageable, e.g. it's almost impossible to resize the main application window.
There is no problem if there are 4 instances of main application streaming 4 players each one, while no problem is registered with lower framerate cameras, even 16 player instances.
This problem is not spotted in 0.10, no shared lock in the old code.https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/599mp4mux/qtdemux: Add support for HDR metadata2022-04-17T17:19:14ZSebastian Drögemp4mux/qtdemux: Add support for HDR metadataSee https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/130#note_154177
There are 2x2 atoms for storing the HDR metadata, the VP9 specific one, and the colr box that we already support but would have to extend with ...See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/merge_requests/130#note_154177
There are 2x2 atoms for storing the HDR metadata, the VP9 specific one, and the colr box that we already support but would have to extend with new transfer functions at least.
CC @seungha.yangSebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/380Failed to use plugins of latest GStreamer version 1.20.x installed by brew on...2022-04-17T07:50:47ZAlbert CheungFailed to use plugins of latest GStreamer version 1.20.x installed by brew on macOSI have a test project to try gstreamer-rs examples with dependencies from crates.io.
It worked nicely at first, but after recent upgrade of gstreamer, the code no longer runs. It complains for missing element from various plugins, e.g. ...I have a test project to try gstreamer-rs examples with dependencies from crates.io.
It worked nicely at first, but after recent upgrade of gstreamer, the code no longer runs. It complains for missing element from various plugins, e.g. "no element playbin", "no element decodebin", etc:
I have pushed the test project to Github so you may try it with the project: [text](https://github.com/albertcsm/rust-gst-examples)
Here is what I see when I run the example
```
$ cargo run --bin basic-tutorial-1
Finished dev [unoptimized + debuginfo] target(s) in 0.10s
Running `target/debug/basic-tutorial-1`
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error { domain: gst_parse_error, code: 1, message: "no element \"playbin\"" }', src/bin/basic-tutorial-1.rs:14:71
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Versions of gstreamer and plugins are all 1.20.1. I forgot the previous version, probably it was 1.18.x.
I have no way to revert, as brew only supports installing the latest version. In fact, I didn't intend to upgrade gstreamer, but brew did it by itself when I install other unrelated brew formula.
```
I tried re-installing gstreamer, rust & toolchain, and upgraded macOS from 12.2 to 12.3.1, but none of them worked.
Then I check GStreamer's release notes, and note that it moved all modules (I suppose it include plugins) to single git repository in 1.20.0.
> Development in GitLab was switched to a single git repository containing all the modules
I guess this could be the reason I got the "no element playbin" error.https://gitlab.freedesktop.org/gstreamer/gst-examples/-/issues/61gstwebrtcbin : BUNDLE not coming in offer SDP with error 'GstWebRTCBin' has...2022-04-17T07:29:49ZGhost Usergstwebrtcbin : BUNDLE not coming in offer SDP with error 'GstWebRTCBin' has no property named 'bundle-policy'Implementing gstreamer based webrtc client app for receiving nest camera stream using google api's.
However in the offer SDP bundle are not getting created(no lines for BUNDLE i.e BUNDLE audio0 video1 application2 in offer sdp).
Followin...Implementing gstreamer based webrtc client app for receiving nest camera stream using google api's.
However in the offer SDP bundle are not getting created(no lines for BUNDLE i.e BUNDLE audio0 video1 application2 in offer sdp).
Following error is getting trigerred on running the webrtc client app
GLib-GObject-WARNING **: g_object_set_valist: object class 'GstWebRTCBin' has no property named 'bundle-policy'https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1712gstwebrtcbin : BUNDLE not coming in offer SDP with error 'GstWebRTCBin' has...2022-04-17T07:28:03ZGhost Usergstwebrtcbin : BUNDLE not coming in offer SDP with error 'GstWebRTCBin' has no property named 'bundle-policy'Implementing gstreamer based webrtc client app for receiving nest camera stream using google api's.
However in the offer SDP bundle are not getting created(no lines for BUNDLE i.e BUNDLE audio0 video1 application2 in offer sdp).
Followin...Implementing gstreamer based webrtc client app for receiving nest camera stream using google api's.
However in the offer SDP bundle are not getting created(no lines for BUNDLE i.e BUNDLE audio0 video1 application2 in offer sdp).
Following error is getting trigerred on running the webrtc client app
GLib-GObject-WARNING **: g_object_set_valist: object class 'GstWebRTCBin' has no property named 'bundle-policy'https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1154Regression: Misuse of AC4 detection in tsdemux2022-04-16T08:58:59ZEdward HerveyRegression: Misuse of AC4 detection in tsdemuxThis regression was introduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1102 and has been present since 1.18
* Stream Type 0x06 is defined in the base mpeg-ts specification as Private PES Packets. Det...This regression was introduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1102 and has been present since 1.18
* Stream Type 0x06 is defined in the base mpeg-ts specification as Private PES Packets. Determining the content should be solely based on descriptors found within the PMT.
* This was abused in that commit by defining a "bluray-only" stream type for AC4 : `ST_BD_AUDIO_AC4`
* This should be entirely handled in the regular private pes handling further down in the codehttps://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1158master / main branches2022-04-16T08:50:35ZTechnetiummaster / main branchesThere is both a `master` and `main` branch at the same time. This should not be the case.There is both a `master` and `main` branch at the same time. This should not be the case.https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1148gtksink hardware decoding2022-04-15T07:27:19ZDániel Kolozsigtksink hardware decodingI'm using gtksink in one of my GTK applications, and I get terrible performance. I figured it can't display hardware accelerated video (as mentioned [here](https://forums.developer.nvidia.com/t/is-there-a-way-to-use-accelerated-decode-wi...I'm using gtksink in one of my GTK applications, and I get terrible performance. I figured it can't display hardware accelerated video (as mentioned [here](https://forums.developer.nvidia.com/t/is-there-a-way-to-use-accelerated-decode-with-gtksink/120012) as well).
Is this right? And if so, do I have any alternatives to work with GTK3? (as for GTK4, it looks like [gtk4sink](https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/767) isn't implemented yet at all)