Unless I am just missing it, there appears to be no PlayBin wrapper in GtkD for the PlayBin of GStreamer.
On 02/26/2016 03:37 AM, Russel Winder wrote:
Unless I am just missing it, there appears to be no PlayBin wrapper in GtkD for the PlayBin of GStreamer.
No, it's currently not wrapped. PlayBin is part of "gst-plugins-base"
which currently doesn't supply a gir file for the generator to use.
On Fri, 26 Feb 2016 20:00:27 +0100, Mike Wey wrote:
[…]
No, it's currently not wrapped. PlayBin is part of "gst-plugins-base"
which currently doesn't supply a gir file for the generator to use.
Sad, my application is necessarily GStreamer based. I guess I have to build an API module manually. :-(
On Fri, 26 Feb 2016 20:00:27 +0100, Mike Wey wrote:
[…]
No, it's currently not wrapped. PlayBin is part of "gst-plugins-base"
which currently doesn't supply a gir file for the generator to use.
I have emailed the GStreamer Developers list to see if there is some way forward on this.
Doing Gtk/GStreamer applications is D would make it so much more fun that using C++ – I refuse to use C for this stuff! Rust bindings are so far behind D bindings, D beats Rust on this. :-)
(I haven't checked Go, but I doubt there are good GStreamer bindings, Gtk ones are OK (-ish)).
Exchanges via private email with GStreamer folk and on the GStreamer developer list are rapidly leading me to the conclusion that GStreamerMM has the wrong approach and that reflecting the C API of handling of plugins with no subtypes of Bin and Element is a better way forward. This means more checking at runtime, but that is the price to pay for a dynamic plugin based system.
The question is how best to present this in D. There need be no automatic generation, it can be hand coded, since it is very small and doesn't change that much.
On 03/08/2016 01:20 PM, Russel Winder wrote:
Exchanges via private email with GStreamer folk and on the GStreamer developer list are rapidly leading me to the conclusion that GStreamerMM has the wrong approach and that reflecting the C API of handling of plugins with no subtypes of Bin and Element is a better way forward. This means more checking at runtime, but that is the price to pay for a dynamic plugin based system.
The question is how best to present this in D. There need be no automatic generation, it can be hand coded, since it is very small and doesn't change that much.
Do you know a good example of how it's usually done in c?
On Tue, 8 Mar 2016 22:08:51 +0100, Mike Wey wrote:
Do you know a good example of how it's usually done in c?
The GStreamer Git repositories are the place to go. Examples on the Web generally, especially StackOverflow that many rely on, are not actually reliable. There are a couple of GStreamer examples in the GtkD repository already, and they have been helpful. I guess there just need to be a few more.
I can say that using GStreamer as the GStreamer folk think it should be used, works much better in D than in C, I think C is just thw wrong language for any form of application programming. D code just reads better and the GC is a huge win. Assuming it never stops the world for more than a few picoseconds. Looking at GStreamerMM code now, it just feels wrong: attempting to reify as types, plugins that are dynamically loaded looks and feels wrong now!