Question

我正在像这样预热收发器：

pc.addTranceiver('video')

这将在收发器的receiver中创建一个虚拟轨道。此后不久，unmute事件在该轨道上触发。然后，约3秒后，mute事件就会触发。

我的目标是尽可能快地检测到轨道是虚拟轨道。

想法

通过数据通道发送一条消息，告知对等方轨道已无效。这很痛苦，因为我以后打电话给replaceTrack
写一个轨道的框架以画布并查看它是否为图像。这似乎很野蛮，但是比3秒要快。

还有什么更好的吗？感觉应该很简单。

Answer 1

这是bug in Chrome（请使用★，以便他们进行修复）。

规范说接收方的跟踪必须从muted开始，并且应该一直保持这种状态，直到数据包到达为止。但是Chrome会立即触发unmute事件，然后由于不活动（another bug）而在几秒钟后触发mute事件：

const config = {sdpSemantics: "unified-plan"};
const pc1 = new RTCPeerConnection(), pc2 = new RTCPeerConnection();

pc1.addTransceiver("video");
pc2.ontrack = ({track}) => {
  console.log(`track starts out ${track.muted? "muted":"unmuted"}`);
  track.onmute = () => console.log("muted");
  track.onunmute = () => console.log("unmuted");
};

pc1.onicecandidate = e => pc2.addIceCandidate(e.candidate);
pc2.onicecandidate = e => pc1.addIceCandidate(e.candidate);
pc1.onnegotiationneeded = async e => {
  await pc1.setLocalDescription(await pc1.createOffer());
  await pc2.setRemoteDescription(pc1.localDescription);
  await pc2.setLocalDescription(await pc2.createAnswer());
  await pc1.setRemoteDescription(pc2.localDescription);
}

在Chrome中，您会看到错误的行为：

track starts out muted
unmuted
muted

在Firefox中，您将看到正确的行为：

track starts out muted

Chrome解决方法：

在Chrome修复此问题之前，我将使用this workaround：

const video = document.createElement("video");
video.srcObject = new MediaStream([track]);
video.onloadedmetadata = () => log("unmuted workaround!");

在此触发之前，假设轨道为muted。

WebRTC：预热后更快检测静音轨道

1 个答案:

Chrome解决方法：