【问题标题】:WebRTC logic for stream renegotiation (enable/disable video)用于流重新协商的 WebRTC 逻辑(启用/禁用视频)
【发布时间】:2026-01-16 16:15:01
【问题描述】:

我在我的应用程序中使用 SimpleWebRTC 已经有一段时间了。它非常容易设置并且适用于简单的应用程序。但是,我需要能够在不影响我的应用程序中的音频的情况下禁用/启用视频,这就是 SimpleWebRTC 的不足之处。搜索其他一些 * 问题后发现,这似乎被称为“重新协商”。

显然直到最近(去年或两年?)浏览器还没有公开MediaStreamTracks (https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack),这使得重新谈判变得不可能。现在这显然是可能的,但我没有看到任何包装库这样做。实际上,大多数流行的 WebRTC 库似乎都不再维护了。

有没有人使用流重新协商,并且可以为我指明正确的方向,无论是实现它的库、polyfill,还是一些关于如何通过当前 WebRTC 标准实现它的指导?我不介意摆脱一个支持准系统 WebRTC 的库,我只是不确定结束/开始连接的正确方法是什么,因为浏览器之间的实现似乎仍然很挑剔。

【问题讨论】:

  • 另外,您是否尝试过禁用视频?这会导致视频数据包停止发送,至少在 Firefox 中:jsfiddle.net/ec9ossmu(小提琴需要 Firefox,因为 Chrome 尚不支持规范的统计信息)。
  • @jib 谢谢,就小提琴而言,它与 Philipp 在 Chrome 中的解决方案具有相同的效果,视频有效暂停但相机保持打开状态,使用户产生怀疑。至于您的第一个链接,您是对的,这在技术上是重复的,抱歉我错过了。自回答以来,Chrome 的状态发生了变化,它现在部分支持轨道,特别是 addTrackremoveTrack,但不支持 replaceTrack,正如 Phillip 指出的那样,这正是我所需要的。我可以将其标记为重复,但由于对 WebRTC 的支持不断发展,我需要看看答案是否仍然有效,以及现在是否有更清洁的方法。

标签: javascript webrtc simplewebrtc


【解决方案1】:

特别是对于 simplewebrtc,有 https://simplewebrtc.com/notsosimple.html#mute 它不会重新协商,而是将启用 MediaStreamTrack 的属性设置为 false,这会发送黑帧(低带宽)。缺点是如果你用这种方式静音相机,相机灯会一直亮着。

【讨论】:

  • 是的,我已经知道这个解决方案,我很抱歉我忘了提及它。它的问题正如您所描述的那样,当他们打算只传输音频时看到相机灯的用户可能会认为我的应用程序正在做一些粗略的事情。
  • 那么问题是某些浏览器 (Chrome) 仍然没有实现 RTPSender.replaceTrack,这将允许在不重新协商的情况下进行此操作。如果你想重新协商:祝你好运。
  • 我明白了,就 WebRTC 标准而言,Firefox 似乎比 Chrome 做得更好。不幸的是,我们的大多数用户可能会使用 Chrome。