问题描述
我们希望能够在另一个标签（例如YouTube，Spotify，Soundcloud等）中播放音乐，然后通过WebRTC连接将其流式传输到其他同伴。
我们正在通过屏幕共享来执行此操作，并且大多数情况下都可以正常运行，但是有时音乐会为听众切入和切出，给人震撼的声音。换句话说，它对发送它的人听起来很顺畅（即从原始URL共享它），但对WebRTC连接的接收方来说却听起来很不稳定。
对造成这种情况的任何想法？这是一个缓冲问题吗？如果是这样，是否更有可能在发送方或接收方进行缓冲？
非常感谢您的帮助！
解决方法
WebRTC倾向于低延迟而不是质量，目的是确保您可以进行正常的语音通信。为此，音频会发生很多事情：
- 播放速率不断变化。如果播放落后，则速度加快。如果距离太远，它会减慢速度。
- 有一个非常小缓冲区，为播放缓冲区变干提供了更多机会。
- 如果数据包丢失，则仅丢弃其时间的音频...跳过。播放不太可能会缓冲然后继续。
- 当音频丢失时，会合成一些拖尾。这对语音来说不错，但对音乐来说却很糟糕。
在媒体捕获端，还有一些用于处理不良网络摄像头麦克风的音频“增强”功能，如果配置不正确，有时可以将其应用于其他媒体流。这些包括：
- 回音消除
- 降噪
- 自动增益控制
最后，通常情况下，默认情况下音频比特率非常低。如果要立体声高质量的音频，通常必须对SDP进行调整。
所有这些说明，如果您关注质量，WebRTC可能不是您的正确选择。我经常求助于MediaRecorder API。