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

Question

我正在构建一个 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 允许将 a 添加.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实际上并不存在。有一个MediaStreamTrack.label属性，但它是只读的，并且不会在传输中保留。通过实验，发送端的 .label 属性提供了丰富的信息（例如label: "FaceTime HD Camera (Built-in) (05ac:8514)"）。但在接收端，.label同一轨道的 信息不会被保留。（它似乎被替换为.id曲目的 － 至少在 Chrome 中是这样。）

Kevin Moreland 的这篇文章 描述了同样的问题，并推荐了一个有点可怕的解决方案：在发送端 munge SDP，然后在接收端 grep SDP。但这个解决方案感觉非常脆弱且低级。

我知道有一个MediaStreamTrack.id属性。还有一处MediaStream.id房产。这两者似乎都在传播中得以保留。这意味着我可以在侧通道中发送元数据，例如信令通道或DataChannel. 从发送端，我会发送{ "myStreams": { "screen": "<some stream id>", "camera": "<another stream id>" } }. 接收端将等到拥有元数据和流后才显示任何内容。然而，这种方法引入了侧通道（以及与之相关的不可避免的并发挑战），而侧通道感觉没有必要。

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

Answer 1

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

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

{
  "kind": "sessionDescription",

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

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

{
  "kind": "sessionDescription",

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

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

Answer 2

使用元数据发送自定义流标签的更规范方法是在发送之前（但在 setLocalDescription 之后）修改 SDP 并修改属性msid（代表媒体流 id，请参阅规范）。这里的优点是，在远程端，媒体流id属性被解析并在 ontrack 事件的流中可见。看看这个小提琴

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