There's some examples that demo how to use it. Of course not all the library is wrapped but the most useful bits are there. Probably the most useful for rust applications, appsink, allows to get data from a pipeline into a Rust application to use it from there.
The objects in gstreamer are reference counted, while in the c api that reference count is explicitly managed, this rust bindings take care of it by unrefing the corresponding gobject when the rust reference is dropped
I believe you're allowed to impl Send for the wrapper struct that contains a pointer. That's what you send to other threads then. (Assuming it's safe to use the underlying objects from different threads.)
Another thing: if you manage reference count explicitly (g_object_unref in the destructor), when you get a 'floating' object from an FFI call, you need to g_object_sinkg_object_ref_sink it.
yes the problem is that if the object is already ref'd then it'll be a memory leak, i'm assuming that the object is ref'd for elements and other full g_objects which is usually the case in gstreamer i think, for mini objects like samples... there's an owned flag that tells the object if it needs to ref or not since it's more common to get non ref'd objects in that case.
i've removed the Uniques and the Arcs, thanks for the hint!
No need to assume, ownership transfers in GObject world are documented.
For example, gst_element_factory_make returns an object with transfer floating.
The notion of floating references is explained here: GObject – 2.0
oh yeah, i was refering to the constructors accepting a *mut but didn't realized that gst_element_factory_make and others return floating references. i think it's fixed now in every case. thanks again!
This might be subjective but to me doing use ffi::*;
hurts readability a lot because it's not so apparent when you're calling the foreign functions. It's easier to read code that says ffi::gst_foo_bar().
mmh not sure about that, everything that doesn't belong to the ffi is gst:: oposed to gst_ and internally in the library everything that starts with gst_ refers to the ffi (as oposed to no prefix). even methods to access the ffi objects are named as gst_* like in fn gst_element() -> *const GstElement.
i've been using this for a while and usually had to access functions from the ffi from outside the library mixed with the bindings so i might be used to that, now that the library is more stable it might be a good idea to differentiate better the ffi calls. perhaps even change the gst_* methods to something else