如何解决 webrtc 对等点之间发送的重复曲目的问题

Question

在我的 webrtc 客户端程序中（javascript，在 1 个本地主机上调试两个对等点）

negotiationneeded

事件被调用 2 次。
每次收到该事件时，我都会先调用

getUserMedia

，然后调用

addtrack()

将音频和视频轨道发送到遥控器，尽管我总是只使用 1 个麦克风和 1 个摄像头，并且不会更改它们的参数。
所以我的程序总共发送 4 首曲目 = (2

negotiationneeded

事件) * (每个事件 2 首曲目)。
我注意到，我发送的所有同一种曲目都具有不同的 id。
因此，当我扫描所有发送的轨道 (peerConnection.getSenders().track) 时，我发现有 4 个轨道 = 2 个视频 + 2 个音频。

问题是：

1. 为什么 getUserMedia() 返回一种具有不同 id 的曲目？这是否意味着视频或音频在物理上有 2 个不同的数据“流”（参见下面的 P.S.）？或者它是一个流，但只是具有不同的 id？

2. getSenders()

   返回 4 首曲目是否正确？这是否意味着遥控器将获得比实际需要 (1 + 1) 多 2 倍的数据 (2音频 + 2视频)？
3. 谁负责消除重复的曲目：我的程序（曲目的发送者）还是应该由浏览器或其他选项来完成？ 例如，发送者是否应该检查 - 视频轨道是否已添加到遥控器，如果是，则调用

   replacetrack()

   而不是

   addtrack()

   来消除重复？

PS：在

streams

提出的问题中，我的意思不是

MediaStream

对象，而是在 webrtc 对等点之间流动的带有视频或音频的真实数据流。

Answer 1

简短的回答 - 在收到

negotiationneeded

事件后，您不需要再次添加曲目。

negotiationneeded

仅表示对等方需要 SDP 提议-答案交换，以便他们了解如何传输新曲目。这种交换对于同行就要使用的编解码器参数达成一致是必要的。您已添加到连接的曲目将保留在原处。

因此，在

onnegotiationneeded

回调中，您通常会有一个新的

createOffer -> setLocalDescription -> send offer

序列。

1. 轨道不仅代表媒体源，还提供媒体流控制。它们可以被停止、临时禁用等。这就是为什么每次您获得具有新 ID 的新对象时，您都可以单独控制创建的轨道。但是，是的，它们可能代表相同的物理来源。但请记住，在幕后，这些轨道可能针对不同的对等点进行不同的编码。因此，即使来自相同的物理源，对等点之间流动的数据也可能不相同。

2. 这是添加相同曲目两次的结果。是的，您可能会发送相同的数据两次，您可以在 chrome://webrtc-internals 页面中检查这一点。

3. 关于媒体传输，由发送方负责。接收方对发送的媒体的控制有限；它可以忽略它，但媒体仍然会流动。