在 WebRTC 中，如何标记本地 MediaStream 以便远程对等方可以识别它？

如何解决在 WebRTC 中，如何标记本地 MediaStream 以便远程对等方可以识别它？

我正在构建一个 WebRTC 应用程序，用户可以在其中共享他们的相机和屏幕。 当客户端接收到一个流/轨迹时，它需要知道它是一个摄像头流还是一个屏幕录制流。 这种区别在发送端很明显， 但是当轨道到达接收端时，区别就消失了。

这是我的应用程序中的一些示例代码：

// Note the distinction between streams is obvious at the sending end.
const localWebcamStream = await navigator.mediaDevices.getUserMedia({ ... });
const screenCaptureStream = await navigator.mediaDevices.getDisplayMedia({ ... });

// This is called by signalling logic
function addLocalTracksToPeerConn(peerConn) {
  // Our approach here loses information because our two distinct streams 
  // are added to the PeerConnection's homogeneous bag of streams

  for (const track of screenCaptureStream.getTracks()) {
    peerConn.addTrack(track,screenCaptureStream);
  }

  for (const track of localWebcamStream.getTracks()) {
    peerConn.addTrack(track,localWebcamStream);
  }
}

// This is called by signalling logic
function handleRemoteTracksFromPeerConn(peerConn) {
    peerConn.ontrack = ev => {
      const stream = ev.streams[0];
      if (stream is a camera stream) {  // FIXME how to distinguish reliably?
        remoteWebcamVideoEl.srcObject = stream;
      }
      else if (stream is a screen capture) {  // FIXME how to distinguish reliably?
        remoteScreenCaptureVideoEl.srcObject = stream;
      }
  };
}

我理想的虚构 API 将允许向轨道或流添加 .label，如下所示：

// On sending end,add arbitrary metadata
track.label = "screenCapture";
peerConn.addTrack(track,screenCaptureStream);

// On receiving end,retrieve arbitrary metadata
peerConn.ontrack = ev => {
      const trackType = ev.track.label;  // get the label when receiving the track
}

但是这个API实际上并不存在。 有a MediaStreamTrack.label property， 但它是只读的，并且不会在传输中保存。 通过实验， 发送端的 .label 属性提供信息（例如 label: "FaceTime HD Camera (Built-in) (05ac:8514)"）。 但在接收端，同一轨道的 .label 没有保留。 （它似乎被曲目的 .id 替换 - 至少在 Chrome 中是这样。）

This article by Kevin Moreland 描述了同样的问题， 并推荐一个有点可怕的解决方案： 在发送端修改 SDP， 然后在接收端grep SDP。 但是这个解决方案感觉非常脆弱和低级。

我知道有一个 MediaStreamTrack.id 属性。 还有一个 MediaStream.id 属性。 这两者似乎都在传输中得以保存。 这意味着我可以在侧信道中发送元数据， 例如信令通道或 DataChannel。 从发送端，我会发送 { "myStreams": { "screen": "<some stream id>","camera": "<another stream id>" } }。 在显示任何内容之前，接收端会等到它同时拥有元数据和流。 但是，这种方法引入了侧信道（以及与之相关的不可避免的并发挑战）， 不需要侧信道的地方。

我正在寻找一种惯用的、可靠的解决方案。 如何在发送端标记/识别 MediaStreams， 以便接收端知道哪个流是哪个？

解决方法

我最终在信令通道中发送了这个元数据。每个包含 SessionDescription (SDP) 的信令消息现在还包含元数据对象，它注释 SDP 中描述的 MediaStream。这没有并发问题，因为在为该 MediaStream 触发 track 事件之前，客户端始终会收到该 MediaStream 的 SDP+元数据。

所以以前我有这样的信令消息：

{
  "kind": "sessionDescription",// An RTCSessionDescriptionInit
  "sessionDescription": { "type": "offer","sdp": "..." }
}

现在我有这样的信令消息：

{
  "kind": "sessionDescription","sdp": "..." },// A map from MediaStream IDs to arbitrary domain-specific metadata
  "mediaStreamMetadata": {
    "y6w4u6e57654at3s5y43at4y5s46": { "type": "camera" },"ki8a3greu6e53a4s46uu7dtdjtyt": { "type": "screen" }
  }
}

,

用元数据发送自定义流标签的更规范的方法是在发送之前（但在 setLocalDescription 之后）修改 SDP 并修改 msid 属性（代表媒体流 ID，{{3} })。 这里的优点是在远程端媒体流 id 属性被解析并在 ontrack 事件的流中可见。见see the specification

请注意，您不能对轨道 ID 做出任何假设。在 Firefox 中，SDP 中的轨道 ID 甚至与发送方的轨道 ID 不匹配。

,

第三种方法是依赖收发器的确定性顺序：

const pc1 = new RTCPeerConnection(),pc2 = new RTCPeerConnection();

go.onclick = () => ["Y","M","C","A"].forEach(l => pc1.addTrack(getTrack(l)));

pc2.ontrack = ({track,transceiver}) => {
  const video = [v1,v2,v3,v4][pc2.getTransceivers().indexOf(transceiver)];
  video.srcObject = new MediaStream([track]);
};

pc1.onicecandidate = e => e.candidate && pc2.addIceCandidate(e.candidate);
pc2.onicecandidate = e => e.candidate && pc1.addIceCandidate(e.candidate);
pc1.onnegotiationneeded = async () => {
  await pc1.setLocalDescription(await pc1.createOffer());
  await pc2.setRemoteDescription(pc1.localDescription);
  await pc2.setLocalDescription(await pc2.createAnswer());
  await pc1.setRemoteDescription(pc2.localDescription);
};

function getTrack(txt,width = 100,height = 100,font = "100px Arial") {
  const can = Object.assign(document.createElement("canvas"),{width,height});
  const ctx = Object.assign(can.getContext('2d'),{font});
  requestAnimationFrame(function draw() {
    ctx.fillStyle = '#eeeeee';
    ctx.fillRect(0,width,width);
    ctx.fillStyle = "#000000";
    ctx.fillText(txt,width/2 - 14*width/32,width/2 + 10*width/32);
    requestAnimationFrame(draw);
  });
  return can.captureStream().getTracks()[0];
};

<button id="go">Go!</button><br>
<video id="v1" autoplay></video>
<video id="v2" autoplay></video>
<video id="v3" autoplay></video>
<video id="v4" autoplay></video>
<div id="div"></div>

当你控制谈判时，这很有效，比如最初的谈判只发生在一侧。

当双方都可以发起协商时，效果不太好，因为当双方创建收发器时，它们的顺序不再是确定性的。

在这些情况下，您最好像其他答案所示那样在带外发出 transceiver.mid 或 stream.id 之类的 id。我在 my blog 中详细介绍了这一点。