black screen

[gmbad]

Hello @muaz-khan

I'm using google chrome / chrome, and many times, when I make a video call, my camera appears fine, but the other person complains that the screen turns black with a circle (loading) in the middle and does not connect.

I have already updated the IceServersHandler.js but I did not succeed.

This is only happening on some calls.

Would this be a problem on the STUN / TURN server?

Can you help me?

Thank you,

Gabriel

[matiaslopezd]

@gmbad are you check the StreamMedia tracks? You only recieve audio or neither?

Maybe you can check seeking event of video element and play when event seeked is fired. Maybe read this doc of Media events :)

[gmbad]

@matiaslopezd neither audio nor video is working.

This problem began to occur about 2 months ago. Sometimes it works, sometimes it does not.

Thanks for the answer.

[matiaslopezd]

@gmbad Maybe TURN server is not working. Can you log connections and post here?

[samehdoush]

I'm having the same problem ,Please help, It's even the same problem on the demo ,https://rtcmulticonnection.herokuapp.com/demos/dashboard/ After the scan it works with the same ip connection but if there is a peer has a different ip do not work for him and the videos show a black screen and do not share any of the chat or files

[samehdoush]

VM1772:305 Uncaught TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node'. at RTCMultiConnection.connection.onstream (:305:21) at RTCMultiConnection.min.js:442 at getRMCMediaElement (RTCMultiConnection.min.js:209) at MultiPeers.RTCMultiConnection.mPeer.onGettingRemoteMedia (RTCMultiConnection.min.js:441) at Object.onRemoteStream (RTCMultiConnection.min.js:61) at PeerInitiator.peer.ontrack (RTCMultiConnection.min.js:272) at wrappedCallback (VM1766 adapter-latest.js:2667) at wrappedCallback (VM1766 adapter-latest.js:2667) at RTCPeerConnection.wrappedCallback (adapter.js:2513) at RTCPeerConnection.c (rocket-loader.min.js:1)

	(anonymous)	@	VM1912:3
	t.activateScript	@	rocket-loader.min.js:1
	(anonymous)	@	rocket-loader.min.js:1
	t.run	@	rocket-loader.min.js:1
	(anonymous)	@	rocket-loader.min.js:1
	(anonymous)	@	rocket-loader.min.js:1

[muaz-khan]

Please try following code both for screen-sharing and camera-streaming:

// try in your HTML demo files
// paste anywhere on top
// quickly after "connection = new RTCMultiConnection"
// make sure that other codes are not overriding it in the same HTML demo file

var bitrates = 512;
var resolutions = 'Ultra-HD';
var videoConstraints = {};

if (resolutions == 'HD') {
    videoConstraints = {
        width: {
            ideal: 1280
        },
        height: {
            ideal: 720
        },
        frameRate: 30
    };
}

if (resolutions == 'Ultra-HD') {
    videoConstraints = {
        width: {
            ideal: 1920
        },
        height: {
            ideal: 1080
        },
        frameRate: 30
    };
}

connection.mediaConstraints = {
    video: videoConstraints,
    audio: true
};

var CodecsHandler = connection.CodecsHandler;

connection.processSdp = function(sdp) {
    var codecs = 'vp8';
    
    if (codecs.length) {
        sdp = CodecsHandler.preferCodec(sdp, codecs.toLowerCase());
    }

    if (resolutions == 'HD') {
        sdp = CodecsHandler.setApplicationSpecificBandwidth(sdp, {
            audio: 128,
            video: bitrates,
            screen: bitrates
        });

        sdp = CodecsHandler.setVideoBitrates(sdp, {
            min: bitrates * 8 * 1024,
            max: bitrates * 8 * 1024,
        });
    }

    if (resolutions == 'Ultra-HD') {
        sdp = CodecsHandler.setApplicationSpecificBandwidth(sdp, {
            audio: 128,
            video: bitrates,
            screen: bitrates
        });

        sdp = CodecsHandler.setVideoBitrates(sdp, {
            min: bitrates * 8 * 1024,
            max: bitrates * 8 * 1024,
        });
    }

    return sdp;
};

REASON?

I found that chromium default implementation is kind of BUGGY. You've to force bitrates/framerates to get stable HD stream. (Even 480p stream isn't stable using default codes)

Repeat: It makes sure that stream is "STABLE". There are lesser packet-drops. And it uses more bandwidth comparing to the default implementation.

Note

You can reduce stream quality from 720p to 360p or lower. You can listen for connection.onPeerStateChanged to detection disconnections and reduce stream quality accordingly. Some users may not have bandwidth to fullfil above code's needs.

You can look on chrome://webrtc-internals/ to make sure above codes are successfully applied.

[samehdoush]

@muaz-khan Thanks for the help I've experimented but it didn't work , Then I tried to add `connection.iceServers = [];

// second step, set STUN url connection.iceServers.push({ urls: 'stun:stun4.l.google.com:19302' });

// last step, set TURN url (recommended) connection.iceServers.push( { url: 'turn:numb.viagenie.ca', credential: 'muazkh', username: '[email protected]' });`

It works but the video and audio is slow and choppy

[codysherman]

Can confirm the original poster's complaint. Started a few months ago, sometimes it works sometimes it doesn't. Having the client on the same network as the casting host dramatically increases odds it fails. I'm getting this issue on the Chrome p2p extension.

[aminbaig]

Is there a way to even bring the resolution lower then HD? For example if we were to reduce it to SD instead of HD or Full HD can we do that and if yes how would we change the values in the code above?

[BasilVictor]

Same issue with me. This happens only on particular devices. Any fix or workaround? The user joins the room but the video keeps loading and neither can hear the host nor can his voice be heard by others.

[moMamdouhSaad]

same issue with me , some times open and sometimes not

[igo21]

I had the same problem with the black screen, but solved it using a TURN server.

here's a link on how to use a TURN server: here here's a link on how to install a TURN server: here

[BasilVictor]

@muaz-khan Thanks for the help I've experimented but it didn't work , Then I tried to add `connection.iceServers = [];

// second step, set STUN url connection.iceServers.push({ urls: 'stun:stun4.l.google.com:19302' });

// last step, set TURN url (recommended) connection.iceServers.push( { url: 'turn:numb.viagenie.ca', credential: 'muazkh', username: '[email protected]' });`

It works but the video and audio is slow and choppy

This works for me

[rifrocket]

my connection works fine when I remote access it from my mobile phone but when I try to access it from my pc it just keeps loading with a black screen can anybody help me?

[happog]

@muaz-khan

HI I have successfully set up video conference call in local wifi network , so i need not to conisder bandwith since local wifi is enough to use, so i want to try test more codecs and more higher resolution and more higher fps scenarios since latest mobile phone have this capability even 8K streaming available. So my question is that How can i change code to support 4K@60fps H264, even H265 4K@60fps etc.. thanks

[anfha1]

I found 1 solution to my problem here: https://kast.zendesk.com/hc/en-us/articles/360030808871-What-to-do-if-I-m-sharing-video-and-others-see-just-a-black-screen-Chrome-

[frankdors]

Please try following code both for screen-sharing and camera-streaming:

// try in your HTML demo files
// paste anywhere on top
// quickly after "connection = new RTCMultiConnection"
// make sure that other codes are not overriding it in the same HTML demo file

var bitrates = 512;
var resolutions = 'Ultra-HD';
var videoConstraints = {};

if (resolutions == 'HD') {
    videoConstraints = {
        width: {
            ideal: 1280
        },
        height: {
            ideal: 720
        },
        frameRate: 30
    };
}

if (resolutions == 'Ultra-HD') {
    videoConstraints = {
        width: {
            ideal: 1920
        },
        height: {
            ideal: 1080
        },
        frameRate: 30
    };
}

connection.mediaConstraints = {
    video: videoConstraints,
    audio: true
};

var CodecsHandler = connection.CodecsHandler;

connection.processSdp = function(sdp) {
    var codecs = 'vp8';
    
    if (codecs.length) {
        sdp = CodecsHandler.preferCodec(sdp, codecs.toLowerCase());
    }

    if (resolutions == 'HD') {
        sdp = CodecsHandler.setApplicationSpecificBandwidth(sdp, {
            audio: 128,
            video: bitrates,
            screen: bitrates
        });

        sdp = CodecsHandler.setVideoBitrates(sdp, {
            min: bitrates * 8 * 1024,
            max: bitrates * 8 * 1024,
        });
    }

    if (resolutions == 'Ultra-HD') {
        sdp = CodecsHandler.setApplicationSpecificBandwidth(sdp, {
            audio: 128,
            video: bitrates,
            screen: bitrates
        });

        sdp = CodecsHandler.setVideoBitrates(sdp, {
            min: bitrates * 8 * 1024,
            max: bitrates * 8 * 1024,
        });
    }

    return sdp;
};

REASON?

I found that chromium default implementation is kind of BUGGY. You've to force bitrates/framerates to get stable HD stream. (Even 480p stream isn't stable using default codes)

Repeat: It makes sure that stream is "STABLE". There are lesser packet-drops. And it uses more bandwidth comparing to the default implementation.

Note

You can reduce stream quality from 720p to 360p or lower. You can listen for connection.onPeerStateChanged to detection disconnections and reduce stream quality accordingly. Some users may not have bandwidth to fullfil above code's needs.

You can look on chrome://webrtc-internals/ to make sure above codes are successfully applied.

• It still necessary?
• HD and Ultra HD is same, differ only dimensions, is correct?
• In some connections video quality is poor, but using meet is better, wich difference?