Building & Installing Rust plugins

Hey,
I am trying to follow a tutorial for streaming audio/video via WebRTC WHIP to AWS IVS.

It uses a pipeline with a whipsink end, but I want to be an exemplary GStreamer user and follow the depreciation notice, and switch to the whipclientsink element, of the rswebrtc plugin.

This is not a standard plugin, and so I wanted to install it from source, from the gst-plugins-rs repo.

I am not that experienced with Rust, but I cloned the repo, cd’ed into /net/webrtc and ran cargo build, as documented in the plugin, without incident.

But
gst-launch-1.0 videotestsrc ! webrtcsink run-signalling-server=true run-web-server=true
results in
WARNING: erroneous pipeline: no element "webrtcsink"

Just like

raspberry@raspberrypi:~/gst-plugins-rs/net/webrtc $ gst-inspect-1.0 whipclientsink
No such element or plugin 'whipclientsink'
raspberry@raspberrypi:~/gst-plugins-rs/net/webrtc $ gst-inspect-1.0 rswebrtc
No such element or plugin 'rswebrtc'

How do I properly install the Rust plugins? The root folder does not contain any executables or target/ which I would have to add to some path.

Folder structure
raspberry@raspberrypi:~/gst-plugins-rs/net/webrtc $ tree -L 2
.
|-- build.rs
|-- Cargo.toml
|-- examples
|   |-- android
|   |-- README.md
|   |-- webrtc-precise-sync-recv.rs
|   |-- webrtc-precise-sync-send.rs
|   |-- webrtcsink-custom-signaller
|   |-- webrtcsink-custom-signaller.py
|   |-- webrtcsink-high-quality-tune.rs
|   |-- webrtcsink-stats
|   |-- webrtcsink-stats-server.rs
|   `-- whipserver.rs
|-- gstwebrtc-api
|   |-- index.html
|   |-- LICENSE-MPL-2.0
|   |-- package.json
|   |-- patches
|   |-- README.md
|   |-- src
|   |-- test
|   `-- webpack.config.cjs
|-- LICENSE-MPL-2.0
|-- protocol
|   |-- Cargo.toml
|   `-- src
|-- README.md
|-- signalling
|   |-- Cargo.toml
|   `-- src
`-- src
    |-- aws_kvs_signaller
    |-- janusvr_signaller
    |-- lib.rs
    |-- livekit_signaller
    |-- signaller
    |-- utils.rs
    |-- webrtcsink
    |-- webrtcsrc
    `-- whip_signaller

21 directories, 20 files
1 Like

Check the Building section of the README.md.

In short, you’d do cargo cinstall -p gst-plugin-webrtc --prefix=/usr for example. If you don’t want to use cargo-c you could copy the libgstrswebrtc.so from the target directory yourself into the right place after cargo build. It needs to go into the system/user-wide plugin path, or wherever GST_PLUGIN_PATH points to.

1 Like

I’m not seeing a libgstrswebrtc.so file in the target directory after running cargo build. I do see libgstrswebrtc.d and libgstrswebrtc.rlib in target/release (or target/debug if I don’t use the --release flag on the build command).

Haven’t used rust/cargo before, not sure what I might be doing wrong. No errors while building.

That should be sufficient and give you an .so / .dll / .dylib. Can you provide the whole build output?

Here’s the output from running cargo build --release --package gst-plugin-webrtc: gst-plugin-webrtc build output · GitHub

But I just noticed this in the target/.rustc_info.json

{
  "rustc_fingerprint": 11465475230826947000,
  "outputs": {
    "4614504638168534921": {
      "success": true,
      "status": "",
      "code": 0,
      "stdout": "rustc 1.80.1 (3f5fd8dd4 2024-08-06)\nbinary: rustc\ncommit-hash: 3f5fd8dd41153bc5fdca9427e9e05be2c767ba23\ncommit-date: 2024-08-06\nhost: x86_64-unknown-linux-musl\nrelease: 1.80.1\nLLVM version: 18.1.7\n",
      "stderr": ""
    },
    "16495917692426387086": {
      "success": true,
      "status": "",
      "code": 0,
      "stdout": "___\nlib___.rlib\nlib___.a\nlib___.so\n",
      "stderr": "warning: dropping unsupported crate type `dylib` for target `x86_64-unknown-linux-musl`\n\nwarning: dropping unsupported crate type `cdylib` for target `x86_64-unknown-linux-musl`\n\nwarning: 2 warnings emitted\n\n"
    },
    "15729799797837862367": {
      "success": true,
      "status": "",
      "code": 0,
      "stdout": "___\nlib___.rlib\nlib___.a\nlib___.so\n/root/.rustup/toolchains/stable-x86_64-unknown-linux-musl\noff\npacked\nunpacked\n___\ndebug_assertions\npanic=\"unwind\"\nproc_macro\ntarget_abi=\"\"\ntarget_arch=\"x86_64\"\ntarget_endian=\"little\"\ntarget_env=\"musl\"\ntarget_family=\"unix\"\ntarget_feature=\"fxsr\"\ntarget_feature=\"sse\"\ntarget_feature=\"sse2\"\ntarget_has_atomic=\"16\"\ntarget_has_atomic=\"32\"\ntarget_has_atomic=\"64\"\ntarget_has_atomic=\"8\"\ntarget_has_atomic=\"ptr\"\ntarget_os=\"linux\"\ntarget_pointer_width=\"64\"\ntarget_vendor=\"unknown\"\nunix\n",
      "stderr": "warning: dropping unsupported crate type `dylib` for target `x86_64-unknown-linux-musl`\n\nwarning: dropping unsupported crate type `cdylib` for target `x86_64-unknown-linux-musl`\n\nwarning: 2 warnings emitted\n\n"
    }
  },
  "successes": {}
}

I’m running this as part of a docker container build with an Alpine base image, so it looks like I just need to figure out how to get it to play nice with those crates. Not sure if it’s possible to install them separately and use the separate installations as part of the crate build or if the Cargo.toml/whatev needs to be modified.

If you’re using Alpine, or musl in general, you’ll have to deal with such things, yes. There are various peculiarities with the musl toolchain, especially related to dynamic / static linking.

You’ll also likely run into problems with musl’s ridiculously small default thread stack size when running GStreamer applications. If you get any stack overflows, that’s most likely the reason.

Setting this environment variable did the trick: RUSTFLAGS="-C target-feature=-crt-static" :smiley:

hrmm, but now I’m seeing

WARNING: erroneous pipeline: no property "run-signalling-server" in element "webrtcsink"

when I went to test it with

gst-launch-1.0 videotestsrc ! webrtcsink run-signalling-server=true run-web-server=true

I was using gst to convert audio to Opus/RTP and pipe it to Janus via udpsink. So just trying to cut out the Janus middleman and use gst for the audio-over-webrtc. Wasn’t having any issues before with gst, so hopefully it’ll be fine here as well. I have considered just switching to a Debian base image tho.

That property was just added in Webrtcsink all included with web and signalling server (!1671) · Merge requests · GStreamer / gst-plugins-rs · GitLab and is not part of the 0.13 releases. It will probably be backported though, it’s very useful :slight_smile:

yeah, I figured that was probably the case and now am building from the main branch :stuck_out_tongue: thanks!