gstreamer1.0-rs
gstreamer1.0-rs copied to clipboard
arturoc
Automatically generate bindings from GObject-Introspection information
Hi,
thanks for your effort to create these bindings. For the long run it will be much less maintenance work for you to have them autogenerated from the GObject-Introspection information provided by GStreamer. This approach is successfully done for many other languages already.
For Rust there's this project here to build a generic GObject-Introspection bindings generator: https://github.com/gi-rust
thanks for pointing that out i thought about how this can be made more automatic but could only come up with somehow parsing the headers which seemed a ton of work, didn't knew that other bindings used introspection but of course it seems the way to go. will give it a look when i have a moment
Let me know if you need some help or have questions around anything there, also generic GStreamer things :)
that's great, i never got around to look into this, by now i'll port this crate to use your ffi instead of the bindgen bindings when i have a moment
btw, i've been following a bit all the progress in the latest gnome hackfest and the new crates for plugins are really nice, do you think it would be useful to have rsplugin as a dependency for this and make use of classes there like GstRc?
I think as a first step it would make sense to move the existing bindings over to gstreamer-sys and also the existing glib/gobject infrastructure (see also https://github.com/arturoc/gstreamer1.0-rs/issues/25).
And for example use gtk-rs' "gir" tool to automatically generate nice bindings for types where that works (see e.g. https://github.com/gtk-rs/gtk/blob/master/src/auto/button.rs for such a case), and generally make use of the macros from gtk-rs (glib_wrapper!() specifically) and generally follow their style (with naming, usage of traits, ...). Best to keep all this consistent :)
For GstRc, for the time being it probably makes most sense to copy that over here as "rsplugin" is not stable in any way yet, and it's also small enough.
Hi @arturoc :)
Let me know if I can help you with porting this to use @sdroege -sys.
Happy to help
i don't have time right now to do it so if you want to look into it you are completely welcome to send a PR. i guess it's probably just a matter of removing my ffi file and adding the corresponding dependency in the cargo file since the naming should be the same
Yes that part is mostly search&replace. Once that is done we can think about the next steps one-by-one for how to bring everything closer to how the other GObject bindings are done.
For GstRc and bindings for all the basic GStreamer types (GstStructure and all the GstMiniObject based ones that can't be properly covered by GIR), it probably makes sense for me to put them into another crate that can be used by gstreamer1.0-rs, my stuff and anything else that needs it.
Going to put that on my list, but I'll have to add some more types before that then (GstMemory, GstMessage/Event/Query, GstStructure at least).
Work in progress. Just wanted to check if I'm going in the right direction compared to your ideas.
https://github.com/luisbg/gstreamer1.0-rs/commit/754502ba7a83347ad1850ea2d1dd0a4111a69377
My WIP patch has been updated with some small fixes. Like using c_char and c_uint, instead of gchar and guint.
All the issues remaining are related to mismatched types. Which I will solve right after the easter weekend, since I am going out on a trip.
Enjoy! :smiley:
I worked on autogenerating bindings from the GObject-Introspection data now (except for GstMiniObject which does not map well automatically). Current status can be found here: https://github.com/sdroege/gstreamer-rs It's a bit raw still, but works and properly integrates (and is consistent with) all the gtk-rs crates. And almost no hand-written code at this point (which I had to pay for with working quite a bit on the code generator).
This also covers https://github.com/arturoc/gstreamer1.0-rs/issues/25 and https://github.com/arturoc/gstreamer1.0-rs/issues/24 (once I moved more things over from gst-plugin-rs).
@arturoc are you interested in collaborating on that one and making it the next version of the gstreamer crate?
That sounds great, i'll take a look as soon as i have a moment and will try to port the code that i have using this repo to yours to see how it goes. Will let you know
I'll keep this around for a while until yours stabilizes and then mark it as deprecated
Right now only (big parts) of the core API are available. Please send me a pull request with any of the examples from https://github.com/arturoc/gstreamer1.0-rs/tree/master/examples ported over (or anything else of course!), and also let me know what is missing. appsrc/appsink/playbin bindings at least, the first two should be easy to add and the last is something we (speaking with my GStreamer hat on here) generally, as a policy, don't like to have in bindings (bindings for elements from plugins).
However I'll have to come up with a solution for being able to use arbitrary signals/properties for playbin to be usable, which is next on my list once the other parts are complete.
When you say deprecated, you'd be fine with replacing the gstreamer crate on crates.io with this one once it's stabilized and ~feature equivalent? That would be great to reduce confusion :)
When you say deprecated, you'd be fine with replacing the gstreamer crate on crates.io with this one once it's stabilized and ~feature equivalent? That would be great to reduce confusion :)
sure, if we manage to make the generated bindings at least as feature complete as this one and if something is missing from the generated bindings it would perhaps be better to turn this into a complement/utilities crate for the missing bits on the autogenerated bindings rather than maintain 2 different full ports
Yeah, making some kind of utils (or probably "plugins") crate would make sense. When I wrote the C# bindings, I also made some kind of generator for plugin-element bindings, should be easy to do the same here again once all the foundation is ready.
Something like your decodebin and gst-launch examples are available in my repository now btw, the others except for appsink/appsrc should be easily possible too. More things missing of course, but getting there.
All of the GStreamer core API is available now, much more than here. I don't think anything is really missing at this point now, except for bindings for the other GStreamer bindings (libgstapp, libgstvideo, etc... which would go into separate threads).
@arturoc Did you have a chance to take a look already?
Hey sorry no i haven't had time to test it yet. Most of my code though rely on appsink/src and video to work so i'm not sure how useful this new wrapper is to me right away but i'll try to see how i can port the utilities that i have to use your port when i have a moment. I'm going to add a note in my README pointing to your repo though so people just using plain gstreamer know that there's a more complete port of the whole api
@arturoc appsrc/appsink bindings are there already, worked on that earlier today: https://github.com/sdroege/gstreamer-rs/tree/master/gstreamer-app . Currently I'm writing some examples for that.
Plan is to also add (at least) gstbase, gstvideo, gstaudio, gstpbutils and gstplayer.
What would be missing from your point of view until the new stuff can go on crates.io (with the same name) and replace the existing bindings?
just had a quick look (haven't had time to test it yet) and it looks really good. i'll try to port my code during this week to use the new bindings and will let you know if there's something that i could do before that i can't do now.
You can find examples for appsrc and appsink here now: https://github.com/sdroege/gstreamer-rs/blob/master/examples/src/bin/appsrc.rs https://github.com/sdroege/gstreamer-rs/blob/master/examples/src/bin/appsink.rs (signals can also be used instead of the callbacks, but callbacks are faster)
@arturoc VideoInfo, AudioInfo, VideoFrame and related things are there too now. I think now it's feature-equivalent.