{"id":430,"date":"2017-07-31T17:21:51","date_gmt":"2017-07-31T15:21:51","guid":{"rendered":"https:\/\/coaxion.net\/blog\/?p=430"},"modified":"2017-07-31T17:34:29","modified_gmt":"2017-07-31T15:34:29","slug":"writing-gstreamer-applications-in-rust","status":"publish","type":"post","link":"https:\/\/coaxion.net\/blog\/2017\/07\/writing-gstreamer-applications-in-rust\/","title":{"rendered":"Writing GStreamer Applications in Rust"},"content":{"rendered":"

tl;dr:<\/strong> GStreamer bindings for Rust can be found here: https:\/\/github.com\/sdroege\/gstreamer-rs<\/a><\/p>\n

In the last few months since RustFest in Kiev<\/a>, I was working (as promised during Luis and my talk at the conference) on creating (mostly autogenerated) Rust<\/a> bindings for GStreamer<\/a>, with a nice API and properly integrating with gtk-rs<\/a> and other software. But the main goal was to autogenerate as much as possible with the help of GObject-Introspection<\/a> to keep the maintenance effort low, and re-use \/ have all kinds of infrastructure for GLib\/GObject that already exists in the gtk-rs ecosystem.<\/p>\n

There are already GStreamer bindings available<\/a>, which hopefully can be replaced by this very soon<\/a>.<\/p>\n

Most of the time working on this in the last months was spent on making the code generator<\/a> work well with GStreamer and add lots of missing features, and also add missing bits and pieces to the GLib\/GObject<\/a> bindings. That should all be in place now, and now at GUADEC<\/a>, I had some time to finish the last pieces of the GStreamer core API. Every needed piece of the GStreamer core API should be covered now, and lots of pieces that are not needed very often. The code can currently be found here<\/a>.<\/p>\n

Example code<\/h3>\n

There currently is no real documentation available. The goal is the autogenerate this too, from the existing C documentation. But until then, the main GStreamer documentation like the Application Development Manual<\/a> and Core API Reference<\/a> should be helpful. Almost everything is mapping 1:1.<\/p>\n

I’ve written some example applications though, which can be found in the same GIT repository<\/a>.<\/p>\n

GTK<\/h4>\n

The first example is a GTK<\/a> application, using the gtkglsink (or gtksink if no GL support is available) GStreamer elements to show a test video in a GTK window and the current playback position in a GTK label below the video. It’s using the GLib event loop for handling GTK events (closing the window), timeouts (query position every few hundred ms) and handling the GStreamer messages (errors, etc.).<\/p>\n

The code can be found here<\/a>.<\/p>\n

Tokio<\/h4>\n

The next example is using Tokio<\/a> instead of the GLib event loop for handling the GStreamer messages. The same should also work with anything else working with future-rs<\/a>. Tokio is a Rust library for asynchronous IO, based on Futures.<\/p>\n

For this to work, a BusStream struct is defined that implements the Stream trait (from future-rs), and produces all messages that are available on the bus. Then this stream is passed to the Tokio Core (basically the event loop) and each message is handled from there.<\/p>\n

The code can be found here<\/a>.<\/p>\n

Pipeline building, Pad Probes, Buffers, Events, Queries, …<\/h4>\n

Various other examples also exist.<\/p>\n

There is one example<\/a> that is dynamically building a pipeline with decodebin for decoding a file with audio and\/or video.<\/p>\n

Another example<\/a> is building a minimal version (without any features other than creating a pipeline from a string and running it) of the gst-launch-1.0 tool. This is not using the GLib main loop for handling the GStreamer messages, but there is a slightly modified variant<\/a> of the same example that uses the GLib main loop instead.<\/p>\n

Yet another example<\/a> is building a small pipeline with an audio test source, producing a 440Hz sine wave, and calculates the RMS<\/a> of the audio. For this a pad probe<\/a> is installed<\/a> on the source pad of the audio source, and the samples of each buffer are analyzed.<\/p>\n

And three last examples are showing how to work with queries<\/a> and events<\/a>, and a rather boring example that just uses playbin<\/a>.<\/p>\n

What next?<\/h3>\n

Overall I have to say that using the bindings is already much more convenient and fun than to write any GStreamer code in C. So if you’re thinking of writing a new GStreamer application and would consider Rust for that: I can highly recommend that \ud83d\ude42<\/p>\n

So what comes next. First of all, the next steps would be to make sure that the bindings work for everybody. So if you are using the old bindings<\/a>, or if you want to use GStreamer from Rust, now is a good time to start testing and let me know of any problems, any inconveniences, anything that seems ugly, or anything that is still missing but you need it.<\/p>\n

In the meantime I’m going to make the bindings a full replacement of the old ones<\/a>. For this various non-core GStreamer libraries have to be added too: gstreamer-app, gstreamer-video, gstreamer-audio and gstreamer-pbutils. Hopefully this can all be done over the next few weeks, but at this point all API that is needed to use GStreamer is already available. Only some convenience\/helper API is missing.<\/p>\n

And of course my efforts to make it easy to write GStreamer plugins in Rust<\/a> didn’t end yet. I’ll continue working on that, and will also move all that over to these bindings too to remove a lot of code duplication.<\/p>\n","protected":false},"excerpt":{"rendered":"

tl;dr: GStreamer bindings for Rust can be found here: https:\/\/github.com\/sdroege\/gstreamer-rs In the last few months since RustFest in Kiev, I was working (as promised during Luis and my talk at the conference) on creating (mostly autogenerated) Rust bindings for GStreamer, with a nice API and properly integrating with gtk-rs and other software. But the main … Continue reading Writing GStreamer Applications in Rust<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[3,6,5,53],"tags":[],"class_list":["post-430","post","type-post","status-publish","format-standard","hentry","category-free-software","category-gnome","category-gstreamer","category-rust"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/posts\/430","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/comments?post=430"}],"version-history":[{"count":7,"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/posts\/430\/revisions"}],"predecessor-version":[{"id":437,"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/posts\/430\/revisions\/437"}],"wp:attachment":[{"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/media?parent=430"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/categories?post=430"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/coaxion.net\/blog\/wp-json\/wp\/v2\/tags?post=430"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}