根据 RTCPeerConnection.ontrack 文档,“ontrack”事件假设为每个传入流触发。我有一个带有两个视频流的 PeerConnection,连接后,“ontrack”触发两次(到目前为止一切正常)。但两次它都发送相同的流,所以我最终得到两个相同的视频,我确信发送者正在发送两个不同的流,它们的尺寸和帧速率不同,我可以在 chrome://webrtc-internals/ 中清楚地看到2 个视频流具有不同的帧大小/速率。
这是 PeerConnection ontrack 代码:
this.peerConnection.ontrack = function(evt) {
console.log("PeerConnection OnTrack event: ", evt.streams);
that.emit('onRemoteStreamAdded', evt.streams);
};
我不认为
evt.streams
有 1 个对象,所以我没有写 evt.streams[0]
。
从日志中可以明显看出,
getRemoteStreams()
仅返回一个对象。当它只有一个流时,怎么可能 ontrack
触发两次,为什么第二个 RTCRtpTransceiver 不创建新流?
经过几个小时的努力,使用不同的浏览器并阅读文档多次后,我解决了这个问题!
问题始于 MediaStream.id,它应该是唯一的,但 HTML5 中的
<video>
元素仅侦听每个流中的第一个轨道。 PeerConnection 将新的收发器(如 MediaStreamTrack)添加到同一个 MediaStream,因此无论 ontrack
处理程序触发多少次,您都会获得完全相同的 MediaStream
对象,但每次在 MediaStreamTrack
中都有新的唯一 RTCTrackEvent
。
解决方案是在
MediaStream
处理程序中为每个新 MediaStreamTrack
创建新的 ontrack
对象。
this.peerConnection.ontrack = function(event) {
that.emit('onRemoteStreamAdded', new MediaStream([event.track]));
};
或者,更像标准示例:
pc.ontrack = function(event) {
document.getElementById("received_video").srcObject = new MediaStream([event.track]);
};
您将获得两个轨道,它们是单个流的一部分。您可以看到,在 event.track 属性中,其中一个应该是音频,另一个应该是视频。
请参阅 https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/ 了解有关流和轨道如何工作的背景信息。
这个帖子太旧了,但我会为未来的访客添加这个答案。在WebRTC应用程序中,两端都必须进行更改。在发送方,必须将多个视频单独添加到轨道(不使用通常的过程)。通过正常程序,两个流将在接收端合并。在接收端,您需要检查 event.stream 和 Even.track 并将它们分别添加到相应的标签中。