webrtc - video get blob, but it remain black

Question

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

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

Does anyone have any similar problem?

Answer 1

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

Answer 2

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.