My talk at the GStreamer Conference 2023 - an introduction on WHIP/WHEP protocols and the initial version of elements are implemented in GStreamer using Rust and how they are evolving using the Signaller based design in the GStreamer’s WebRTC Rust plugins.
Do any of the new plugins support WebRTC Data Channels? Or must we continue to use webrtcbin create-data-channel for that?
I see nothing about data channels in “rswebrtc” or “webrtchttp”. I understand if keeping the interface simple precludes data channels but to me this is a common enough use case to expose as development proceeds
Yes, the webrtchttp elements do not provide a way for the application to create data channels on the
The rswebrtc elements do use the data channel but it is specific to the navigation events internally and I don’t think the application will be able to access to those anyway at the moment.
I think one solution is to have a
GstChildProxy interface on these elements to access webrtcbin’s properties and signal?
Or, we need to expose specific signals and properties of webrtcbin, starting with
on-data-channel, so that these high level elements can proxy those to the webrtcbin internally?
The standard solution for dealing with data channels with
webrtcsink is to connect to
consumer-added and interface with the webrtcbin received there. We are missing such a signal on
webrtcrsrc at the moment, but iirc there is a MR which adds one (
Right, the application using
webrtcsink can connect to the
consumer-added signal on it and access the webrtcbin
webrtcbin-ready is the the new name for
consumer-added on the signaller interface for the signallers to access webrtcbin. We added it in one of the commits as a part of net/webrtc/whip_signaller: implement WHIP server (!1284) · Merge requests · GStreamer / gst-plugins-rs · GitLab
We do not have any signal on
webrtcsrc yet for webrtcbin
oh that’s right, yes we need to add a
producer-added signal eventually then