WebRTC example doesn't send any video streams in initial stream

[jdm]

The example program quits immediately for me because the WS connection is closed. This happens because the webpage receives a remote stream from the program, but this stream only includes an audio stream, not a video stream.

[jdm]

This is using the website and the example, rather than two instances of the example.

[jdm]

This works fine using two instances of the example program.

[jdm]

This occurs because the JS from https://github.com/centricular/gstwebrtc-demos/tree/master/sendrecv expects that the remote stream will contain both audio and video streams. The fact that our example program seems to add first audio, then video subsequently is a behaviour difference that we should be aware of.

[Manishearth]

Can you list what you're running?

Is your program having trouble getting video cap? This is somewhat inconsistent across platforms

[Manishearth]

Hmm, are you consistently getting this behavior? There's a bit of a race that's possible here; it may be worth waiting till steady state to trigger delayed negotiation.

The actual fix for the race would be to support renegotiation, which we don't at the moment.

[jdm]

Yes, it was consistent every time I tried it.

[Manishearth]

I don't know what caused this bug -- when I worked on the sink pad ordering stuff it seemed to work fine, but something may have broken it in the meantime. I can try and pinpoint when this happened.

[Manishearth]

I have noticed that add_stream in servo is linking streams instead of creating pending streams. It should not be doing this.

[Manishearth]

Oh, never mind, the way webrtc.js works it's possible to have remote mline info before we get our streams, so they get linked directly. That seems to be working correctly.

[Manishearth]

On talking with @ystreet00 there's a good chance this is a gstreamer bug.

When we prerequest pads in link_stream, I'm getting some assertions:

Details

** (servo:2260): WARNING **: 23:27:11.200: (gstwebrtcbin.c:1294):_create_transport_channel: code should not be reached

** (servo:2260): WARNING **: 23:27:11.200: (gstwebrtcbin.c:1300):_create_transport_channel: code should not be reached
[New Thread 0x7ffef64b4700 (LWP 2430)]
[New Thread 0x7ffed984d700 (LWP 2431)]
[New Thread 0x7ffed904c700 (LWP 2432)]
[New Thread 0x7ffed884b700 (LWP 2433)]

(servo:2260): GStreamer-WARNING **: 23:27:11.202: Element 'nicesink5' already has parent

** (servo:2260): WARNING **: 23:27:11.202: (transportsendbin.c:372):transport_send_bin_constructed: code should not be reached

(servo:2260): GStreamer-WARNING **: 23:27:11.202: Element 'nicesink6' already has parent

** (servo:2260): WARNING **: 23:27:11.202: (transportsendbin.c:402):transport_send_bin_constructed: code should not be reached

(servo:2260): GStreamer-WARNING **: 23:27:11.202: Element 'nicesrc5' already has parent

** (servo:2260): WARNING **: 23:27:11.202: (transportreceivebin.c:277):transport_receive_bin_constructed: code should not be reached

(servo:2260): GStreamer-WARNING **: 23:27:11.202: Element 'nicesrc6' already has parent

** (servo:2260): WARNING **: 23:27:11.202: (transportreceivebin.c:297):transport_receive_bin_constructed: code should not be reached

what seems to be happening is that get_request_pad is somehow stumbling on the same transceiver and attempting to reconnect it, which errors since it's already hooked up.

[Manishearth]

Turns out it's a bit of a race in our code. However, we did discover some other bugs in gstreamer which once fixed can lead to nicer code on our side.

https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/commit/5c450c5992ca6dc7100207560224167797fe4c13#a34551971d28ab169dd8c6e6dc00da53df75677d_3022_3827 is a commit that exists in 1.15 which may fix problems like these.