【问题标题】:WebRTC connections randomly without audio outputWebRTC 随机连接,无音频输出
【发布时间】:2018-11-06 14:47:30
【问题描述】:

我在 WebRTC 网络应用程序中偶然发现了一个奇怪的问题。这是设置: 客户端 A 和客户端 B 通过仅发送 WebRTC 连接将音频发送到 SFU。 客户端 C 通过与同一 SFU 的两个仅接收连接接收来自客户端 A 和 B 的音频流,并将它们添加到两个不同的“音频”元素。这些发送和接收连接之间的路由正常工作。

问题来了: 在刷新页面时,有时客户端 C 会听到来自客户端 A 和 B 的音频。但大多数时候客户端 C 只会随机听到来自 A 或 B 的音频。 Firefox 和 chrome 都会出现这种情况。

两个连接都在接收数据(参见图表“bitsReceivedPerSecond”),但只有一个连接在输出音频。这是一个 C 可以听到 A 但听不到 B 的示例:

连接客户端 A -> C:

连接客户端 B -> C:

我对这些图表的理解是原始 WebRTC 连接工作正常(发送和接收数据),但不知何故连接不会随机输出音频。

有人知道这是怎么发生的吗?

这是用于将流添加到音频元素的“ontrack”回调。每个连接的日志都正确显示。

gotRemoteStream(e) {
    Logger.log("Remote Streams: #"+e.streams.length);

    if (this.audioElement.srcObject !== e.streams[0]) {
        Logger.log("Received remote Stream with tracks to audio: " + this.audioElement.id);
        this.audioElement.srcObject = e.streams[0];
    }
}

【问题讨论】:

  • 来自客户端 B 的 totalAudioEnergy 没有显示音频,这表明 B 中存在发送方问题。可能发生,例如如果它的输入轨道(麦克风?)不小心被静音了(在这种情况下浏览器仍然发送数据包)。您是否体验过两者的音频?
  • “bitsReceivedPerSecond”与客户端 B 发送的音频相同。他开始说话,然后沉默了几秒钟,然后又开始说话。所以我认为发送方和传输也应该没问题。我猜“总AudioEnergy”只是audioOutputLevel随时间的积分

标签: javascript audio webrtc


【解决方案1】:

单个音频元素一次只能播放一个音轨。

你说有两个传入的音轨,所以如果this.audioElement 是同一个元素,那么每次调用gotRemoteStream 都会争用设置srcObject,一个覆盖另一个。

这很可能是您只能听到其中一个的原因。

最简单的解决方案可能是关闭发送的流关联,因为它们往往会有所不同:

const elements = {};

gotRemoteStream({streams: [stream]}) {
    if (!elements[stream.id]) {
      elements[stream.id] = this.audioElementA.srcObject ? this.audioElementB
                                                         : this.audioElementA; 
    }
    elements[stream.id].srcObject = stream;
}

这应该适用于两个传入连接。剩下的就是练习了。

【讨论】:

  • 正如我在原始帖子中所写的“[...] 将它们添加到两个不同的“音频”元素中。”。我不会为两个流使用一个音频元素
  • @DominikVincenz 涉及多少“ontrack”回调?我会仔细检查this 值,因为这可以解释症状。您显示的代码中没有任何内容表明涉及不同的元素。你如何确定哪一个得到 A 和 B?
  • 为每个连接创建一个新对象,其中包含 RTCPeerConnection 及其目标音频元素。代码 sn-p 是该容器类中的回调函数。所以有两个对象包含两个不同的音频元素。有时客户端 C 可以同时听到 A 和 B,如您所说,使用单个音频元素是不可能的。日志还显示了两个不同的元素 id:Logger.log("Received remote Stream with tracking to audio:" + this.audioElement.id)
  • @DominikVincenz 你是对的,这个答案不适合。
猜你喜欢
  • 2020-09-15
  • 2015-03-10
  • 1970-01-01
  • 1970-01-01
  • 2021-10-31
  • 2011-07-03
  • 1970-01-01
  • 2020-04-29
  • 1970-01-01
相关资源
最近更新 更多