10

I run my webrtc code with chrome 21.

If I open two tabs in the same chrome, and then open page with webrtc code inside. One tab is for sending video stream; one tab is for receiving video stream It works fine.

However, If I open page with two Incognito mode or two different chrome browser, I can get the sdp and candidate information correctly. It seems that video can decode the information.

In remote video, I can see only enter image description here

Besides, it seems crash. I tried to click "close chrome" but useless.

Does anyone have any similar problem?

0xc0de
  • 8,028
  • 5
  • 49
  • 75
Shih-En Chou
  • 4,007
  • 6
  • 20
  • 27

2 Answers2

14

While testing WebRTC, I found that such condition occurs when we call peerConnection.addStream(…) in the wrong place ----

You must remember that ordering highly matters in WebRTC!

Updated at: 6:36 PM - Thursday, July 17, 2014 (UTC)

Blank video occurs in following cases:

  1. You're using STUN whilst your SSL certificate is either expired or it has invalid entries.
  2. You're using STUN however it is corporate firewall, or hospital network or private network which is blocking or hiding external ip addresses or some ports.
  3. Both peers has invalid sendrecv/sendonly/recvonly pairs
  4. Offerer didn't attach the stream or it is Firefox which fails in cases when user attached only audio stream however you're using OfferToReceiveVideo:true
  5. You're checking for HTMLMediaElement.HAVE_CURRENT_DATA or mediaElement.paused or mediaElement.currentTime whilst it is android which has known issues regarding these properties.

Solutions?

  1. Use TURN from XirSys or install your own.
  2. Make sure that you're using valid SSL certificate or use HTTP instead.
  3. Make sure that offerer attached the stream; also make sure that OfferToReceiveAudio/OfferToReceiveVideo are used according to stream(s) attached.
  4. Make sure that you didn't modify the SDP; also try to compare SDP between both peers and find-out mismatches.

Ordering of the code is, kind of rare-issues, nowadays, because we all know that addStream should be called before creating offer or answer; even for renegotiated sessions.

Try to use chrome://webrtc-internals and Firefox's about:config to see what's happening inside these browsers; and always use console-logs for onIceConnectionStateChange event which helps you check if ICE-Agent failed in the ICE-connectivity check process or...

Sometimes setting-remote-sdp for offerer too earlier, causes exceptions. Always use onSdpError both for createOffer/createAnswer and setLocalDescription/setRemoteDescription e.g.

peer.setRemoteDescription(remoteSDP, onSdpSuccess, onSdpFailure);

A few demos resources:

  1. https://github.com/muaz-khan/WebRTC-Experiment / Demos
  2. https://github.com/mozilla/webrtc-landing

and https://www.webrtc-experiment.com/docs/TURN-server-installation-guide.html

Muaz Khan
  • 7,138
  • 9
  • 41
  • 77
  • The process is while creating offer --- you've to addStream right after creating PeerConnection ---- but when creating answer --- you must addStream after calling setRemoteDescription ---- I tested it; and it worked for me! --- It is just my personal experience!!!! – Muaz Khan Sep 03 '12 at 01:48
  • pc2.onaddstream = gotRemoteStream; pc2.setRemoteDescription(pc2.SDP_OFFER, new SessionDescription(sdp)); is this wrong ? – Shih-En Chou Sep 03 '12 at 03:23
  • peerConnection.setRemoteDescription(peerConnection.SDP_OFFER, offer); --- peerConnection.addStream(yourCameraStream); ----- so the stream you'll attach for other peer will work fine! – Muaz Khan Sep 03 '12 at 08:46
  • I have this same issue, However the ordering appears to be correct and still no video stream is presented. Has anybody managed to resolve this? – kylewelsby Nov 15 '13 at 10:45
  • OfferToReceiveAudio and OfferToReceiveVideo constraints "must" be true for createOffer/createAnswer. "addStream" must be called before creating offer/answer sdp. – Muaz Khan Nov 15 '13 at 15:01
  • I have got the same problem, but can not resolve it. Could someone who got it to work make a list of the ordering on the one client sending the stream and the one receiving the stream? I do not see my mistake :( – Kevkong Jul 17 '14 at 15:02
  • @MuazKhan Thank you for the reply, but sadly I am still not able to locate my error. I tested a WebRTC Demo provided by http://www.esegece.com/ and everything works fine. I even looked through their js (sadly it is minified) to pick the same STUN server they do, but still black :/ – Kevkong Jul 18 '14 at 17:49
  • Try any demo from https://github.com/muaz-khan/WebRTC-Experiment especially [video-conferencing](https://www.webrtc-experiment.com/video-conferencing/) and [RTCMultiConnection demos](https://www.webrtc-experiment.com/RTCMultiConnection/). Last night I was testing "RTCMultiConnection-demo" with a friend, and it is appeared that both Google's and AnyFirewall's STUN failed because my friend was using corporate-network, however XirSys's STUN succeeded and STUN-connection was established. I thought that it'll use TURN, but it didn't. It was direct-p2p. – Muaz Khan Jul 19 '14 at 03:47
  • Please, how do you suggest to "compare SDP between both peers" - I should compare all fields in `sdpOffer` and `sdpAnswer` which I send to receive video? – Alexander Yakovlev May 31 '16 at 12:58
  • Same black video comes in my case if local & remote are in local. Tried from two different system, for local and remote, and it works like a charm. – Radix Nov 17 '16 at 08:46
4

I had the same issue, and I just resolved it by calling VideoElement.play() right after attaching the stream as the VideoElement.src

document.querySelector( "#video" ).src = window.URL.createObjectURL( remoteStream );
document.querySelector( "#video" ).play();

Don't wait for the loadedmetadata event because it doesn't seem to be triggered but the WebRTC stream.

Horsetopus
  • 103
  • 7
  • will play the video as soon there is e src added, e.g. your blob url. And for your selfView use to prevent hearing yourself. – Mexx Apr 28 '16 at 09:05