Gstreamer bindings


Just published bindings for gstreamer 1.x:

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

Category suggestions

Why put Arc on top of pointers that already are reference counted (and are far from being Unique by the way)?


i need to pass the *mut accross threads in a couple of places and that’s the only way i managed to pass it, is there a better way?


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.)


oh, great, yeah that seems to work. was looking into this for a while but didn’t managed to make it work without the Unique,


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_sink g_object_ref_sink it.


do you mean g_object_ref?


Sorry, I mean g_object_ref_sink in general but in your case it would be gst_object_ref_sink.


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:


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


Using Weak for callbacks – cool trick. :+1:
I was wondering how to do that properly.