Webrtc sendonly example does not work

Hi there,

I’m trying to build something similar to this example:
https://gitlab.freedesktop.org/gstreamer/gst-examples/-/blob/master/webrtc/sendonly/webrtc-unidirectional-h264.c

But I do not get it to work.

I’d build a small gstreamer webrtc client and a javascript webrtc client.
Signalling is done with a really simple websocket C++ server.

Questions:

  1. It seems the example is not really up to date, is that correct ? in the example, this is beeing done:
g_signal_emit_by_name (receiver_entry->webrtcbin, "get-transceivers",
      &transceivers);

even before the pipeline is set to playing. For me, that never worked, transceivers is always NULL.
Somewhere on stackoverflow I found the comment that this has to be done in the “on-ice-candidate” callback function. Even so I could not find any documentation on that, this seemed to have worked. Is this now correct, or am I missing something ?

  1. After lots of debugging, I finnally got the erros to a minimum. but there is still no RTP stream send.
    my pipeline looks like this:
    pipeline = gst_parse_launch("webrtcbin name=webrtcbin stun-server=stun://stun.l.google.com:19302  "
                                "audiotestsrc is-live=true wave=red-noise ! audioconvert ! audioresample ! opusenc ! rtpopuspay ! queue ! "
                                "application/x-rtp,media=audio,encoding-name=OPUS ! webrtcbin.",
                                NULL);

I created a pipeline image in this callback:

            g_signal_connect(webrtcbin, "notify::ice-gathering-state",
                             G_CALLBACK(on_ice_gathering_state_notify), NULL);

The image is created when the state is complete:

For me it looks like that en audiotestsrc streams to the trancseiver and not any further… ?? why is that ?

  1. What is the state of the webrtc implementation. This is still in the “bad” plugins directory… does this mean this should not be used in production ?.

  2. I get one conserning WARN message that is:

webrtcbin gstwebrtcbin.c:4636:_create_answer_task:<webrtcbin> did not find compatible transceiver for offer caps application/x-rtp, media=(string)audio, payload=(int)109, clock-rate=(int)48000, encoding-name=(string)OPUS, encoding-params=(string)2, maxplaybackrate=(string)48000, stereo=(string)1, useinbandfec=(string)1; application/x-rtp, media=(string)audio, payload=(int)9, clock-rate=(int)8000, encoding-name=(string)G722, encoding-params=(string)1; application/x-rtp, media=(string)audio, payload=(int)0, clock-rate=(int)8000, encoding-name=(string)PCMU; application/x-rtp, media=(string)audio, payload=(int)8, clock-rate=(int)8000, encoding-name=(string)PCMA; application/x-rtp, media=(string)audio, payload=(int)101, clock-rate=(int)8000, encoding-name=(string)TELEPHONE-EVENT, encoding-params=(string)1, 0-15=(string)1, will only receive

which is a little change, because I only want to send audio from the gstreamer client to the javascript client… can I ignore this or is it essential ?

Every help is very much appreciated!!

If a code example is necessary, I will try to create a simplified version.

Your payload (96) does not match the remote offer payload (109). They must match for a transceiver to be used. As a result, webrtcbin will not be able to match and send the audio.

Hi, thanks for the answer, you are correct !
Fortunately, I figured it out just before your answer after I struggled for days :slight_smile:

To my point, 1 )
The reason why it failed seemed to be that I made an error retrieving my webrtcbin, therefore… so my mistake :-/
Unfortunately, I found this stackoverflow answer suggesting the on-ice-candidate callback. So I will go back and answer to the stack entry, maybe that will help others in the future.

To 2 and 4)
As you said, the payload was wrong.
I figured that out after I got the sendonly examples to work.
I had to migrate the source from libsoup 2.x to libsoup 3.0, otherwise I had unresolvable conflicts in the current version of Manjaro Linux.

To 3 )
I would still be interested in the state of the webrtc feature in gstreamer. Is the fact that this is in plugins-bad problematic ? Are there plans to change that ?

Additionally:
One problem I had for the ice resolution of my local network. As I digged into it, the reason was mDNS. It seems like gstreamer (or libnice ? ) does not support it ? I got it to work as soon as I disabled mDNS in firefox.
Is there another solution of this that I did miss ?

Many people are using webrtcbin in production. The reason for keeping webrtcbin in -bad is outlined in webrtcbin: Moving from "bad" to "good" (#1758) · Issues · GStreamer / gstreamer · GitLab. The state of this has not changed and there are more changes since that issue in the web specification that webrtcbin does not quite handle yet.

For mDNS, resolving should work if you have the relevant system configuration enabled. This is generally avahi on linux and other platforms may have equivalents. Otherwise, using STUN and TURN are the backups that are provided if mDNS resolution fails.