offer

offer

关注
发信
关注(28)粉丝(399)

RTCPeerConnection媒体流在Firefox中工作，但不是Chrome

本文介绍了RTCPeerConnection媒体流在Firefox中工作，但不是Chrome的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

  
 
 var pc = new RTCPeerConnection（null）; 
 chrome.desktopCapture.chooseDesktopMedia（['screen'，'window']，null，function（streamId）{
 var constraints = {
 audio：false，
 video：{ 
必须：{
 chromeMediaSource：'desktop'，
 chromeMediaSourceId：streamId 
} 
} 
}，
 success = function（stream） {
 pc.addStream（stream）; 
 pc.createOffer（function（offer）{
 pc.setLocalDescription（offer，function（）{
 send（'make_offer'，name ，offer）; 
}，printError）; 
}，printError）; 
}; 
 getUserMedia（constraints，success，printError）; 
}）;

目前，我的报价是由一位访问者在浏览器中访问一个页面接收的。这看起来或多或少像这样（m是提供的消息对象）： 

  var pc = new RTCPeerConnection（null） ; 
 pc.onaddstream = function（e）{
 var video = document.getElementById（'video'）; 
 video.src = URL.createObjectURL（e.stream）; 
}; 
 pc.setRemoteDescription（new RTCSessionDescription（m.value），function（）{
 pc.createAnswer（function（answer）{
 pc.setLocalDescription（answer，function（）{
发送（'make_answer'，m.from，answer）; 
}，printError）; 
}，printError）; 
}，printError）;

我已经完成了这项工作，无论有无冰服务器，当我使用它们时都是这样的： 

  var iceServers = {
 iceservers：[
 {url：'stun：stun.l.google .com：19302'} 
] 
};

现在，对等方在Firefox中完美地接收和显示流。没有问题。但它不适用于Chrome。这是从chrome中选择的一些数据：// webrtc-internals：
连接到firefox： 

 ssrc_3309930214_send-transportId ：{
startTime：2014-09-30T01：41：11.525Z，
endTime：2014-09-30T01：41：21.606Z，
值：[\Channel-video-1 \，\Channel-video-1 \，\Channel-video-1 \]
}，
ssrc_3309930214_send-packetsLost：{
startTime：2014-09-30T01：41：11.525Z，
endTime：2014-09-30T01：41：21.606Z ，
values：[0,0,0,0,0,0,0]
}，

连接到chrome：

 ssrc_1684026093_send-transportId：{
 startTime：2014-09-30T01：41：57.310Z，
endTime：2014-09-30T01：42：00.313Z，
values：[\ Channel-audio-1 \，\Channel-audio-1 \，\Channel-audio-1 \，\Channel-audio-1 \]
}，
ssrc_1684026093_send-packetsLost：{
startTime：2014-09-30T01：41：57.310Z，
end时间：2014-09-30T01：42：00.313Z，
values：[-1，-1，-1，-1]//这是什么原因造成的？ 
}，

这些看起来很重要，但我不确定这些影响。我有更多的数据，但我不确定究竟什么是重要的。主要的想法是，数据发送到Firefox，但不是铬，虽然没有例外发生，我可以看到。如果我在Chrome Canary（最新版本）中加载对等页面，则会发生另一个可疑数据： 

 加载资源失败： net :: ERR_CACHE_MISS

这是一个控制台错误，我不知道它来自哪里。它发生在对方发回给主机（chrome扩展）之后。



通过wss：//完成的信令，测试对等体托管在https：/ /
我不知道该从哪里下载。



更新：基于回答和评论，我为onicecandidate添加了一个处理程序：

  pc.onicecandidate = function（e）{
 console.log（'This is the the ice candidate。'）; 
 console.log（e）; 
 if（！e.candidate）return console.warn（'no candidate！'）; 
 send（'got_ice_candidate'，name，e.candidate）; 
};

我还使用视频设置了从浏览器到浏览器的等效对等连接：

  var constraints = {
 audio：false，
 video：true 
}; 
 getUserMedia（constraints，success，printError）;

从Firefox到Chrome以及反之亦然，这可以正常工作，特定扩展...
在成功案例和扩展案例之间收集冰的方式有所不同：


  • 在浏览器之间，根本没有冰。有一个事件，并且e.candidate是 null 。

  • 从扩展到浏览器，有很多 onicecandidate 事件。他们并不完全一致。所以也许铬扩展是令人困惑的STUN服务器？我不知道。


感谢您的回答，请多多关注您的洞察。

解决方案

能否请你在双方都加上处理冰的候选人？ pc.onicecandidate = function（e）{send（'ice_candidate'，e.target）}



另一方面， 'message'do



pc.addIceCandidate（new RTCIceCandidate（message））;



即使在交换了优惠/回答后，Chrome浏览器仍然会发送候选作品，而Firefox似乎没有这样做。


Trying to keep the problem as simple as possible, I am creating a media stream in a chrome extension like so:

var pc = new RTCPeerConnection(null);
chrome.desktopCapture.chooseDesktopMedia(['screen', 'window'], null, function(streamId) {
    var constraints = {
        audio: false,
        video: {
            mandatory: {
                chromeMediaSource: 'desktop',
                chromeMediaSourceId: streamId
            }
        }
    },
    success = function(stream) {
        pc.addStream(stream);
        pc.createOffer(function(offer) {
            pc.setLocalDescription(offer, function() {
                send('make_offer', name, offer);
            }, printError);
        }, printError);
    };
    getUserMedia(constraints, success, printError);
});

For now, my offer is received by a peer visiting a page in a browser. That looks more or less like this (m is a message object with the offer):

var pc = new RTCPeerConnection(null);
pc.onaddstream = function(e) {
    var video = document.getElementById('video');
    video.src = URL.createObjectURL(e.stream);
};
pc.setRemoteDescription(new RTCSessionDescription(m.value), function() {
    pc.createAnswer(function(answer) {
        pc.setLocalDescription(answer, function() {
            send('make_answer', m.from, answer);
        }, printError);
    }, printError);
}, printError);

I have done this, both with and without ice servers, which look like this when I use them:

var iceServers = {
    iceServers: [
        {url: 'stun:stun.l.google.com:19302'}
    ]
};

Right now, the peer receives and displays the stream perfectly in Firefox. No problem at all. But it's not working in Chrome. Here is some selected data from chrome://webrtc-internals:connection to firefox:

"ssrc_3309930214_send-transportId": {
 "startTime": "2014-09-30T01:41:11.525Z",
 "endTime": "2014-09-30T01:41:21.606Z",
 "values": "[\"Channel-video-1\",\"Channel-video-1\",\"Channel-video-1\"]"
},
"ssrc_3309930214_send-packetsLost": {
 "startTime": "2014-09-30T01:41:11.525Z",
 "endTime": "2014-09-30T01:41:21.606Z",
 "values": "[0,0,0,0,0,0,0]"
},

connection to chrome:

"ssrc_1684026093_send-transportId": {
 "startTime": "2014-09-30T01:41:57.310Z",
 "endTime": "2014-09-30T01:42:00.313Z",
 "values": "[\"Channel-audio-1\",\"Channel-audio-1\",\"Channel-audio-1\",\"Channel-audio-1\"]"
},
"ssrc_1684026093_send-packetsLost": {
 "startTime": "2014-09-30T01:41:57.310Z",
 "endTime": "2014-09-30T01:42:00.313Z",
 "values": "[-1,-1,-1,-1]"  // what is causing this??
},

Those seem important, but I'm not sure exactly of the implications. I have more data, but I'm not sure exactly what is important. The main idea, is that data goes out to firefox, but not to chrome, though no exceptions occur that I can see. The one further suspicious piece of data happens if I load the peer page in Chrome Canary (latest): 

Failed to load resource: net::ERR_CACHE_MISS

This is a console error, and I don't know where it comes from. It occurs after the answer is sent from the peer back to the host (chrome extension).

Signaling done over wss://, test peer is hosted at https://I'm not sure where to go from here.

Update: Based on answer and comment, I added a handler for onicecandidate:

pc.onicecandidate = function(e) {
    console.log('This is the ice candidate.');
    console.log(e);
    if(!e.candidate) return console.warn('no candidate!');
    send('got_ice_candidate', name, e.candidate);
};

I also set up an equivalent peer connection from browser to browser using video:

var constraints = {
    audio: false,
    video: true
};
getUserMedia(constraints, success, printError);

This works fine, both from Firefox to Chrome and vise-versa, so the issue may be chrome-extension-specific...There is a difference in how ice gathering occurs between the successful case and the extension case:

  • Between browsers, there is no ice at all. There is one event, and e.candidate is null.
  • From extension to browser, there are lots of onicecandidate events. They are not all in agreement. So perhaps the chrome extension is confusing the STUN server? I don't know.

Thanks for your answers, would love any more insight that you have.

解决方案

can you please add handling ice candidates on both sides ?

pc.onicecandidate = function(e){ send('ice_candidate', e.target) }

And on the other side on receiving this 'message' do

pc.addIceCandidate(new RTCIceCandidate(message));

Chrome sends ice candidates even after offer/answer have been exchanged which firefox does not seem to do.

这篇关于RTCPeerConnection媒体流在Firefox中工作，但不是Chrome的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！

08-31 03:44
Powered by LMLPHP ©2024 offer 0.039888