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