我遇到的最接近的是this question on SO，但这只是为了基本理解。 我的问题是：当使用媒体源扩展 (MSE) 从远程端点获取媒体源时，例如，通过 AJAX 或 fetch API 甚至 websocket，媒体通过 TCP 发送.
【问题讨论】：
标签： webrtc media-source
- 这将处理数据包丢失和排序，因此不使用带有 RTCP 的 RTP 协议。对吗？
AJAX 和 Fetch 只是用于发出 HTTP 请求的 JavaScript API。 Web Socket 只是从初始 HTTP 请求扩展而来的 API 和协议。 HTTP 使用 TCP。 TCP 负责确保数据包按顺序到达和到达。所以，是的，您不必担心丢包等问题，但不是因为 MSE。
- 但这会导致延迟，因此不能真正用于实时通信。是吗？
这完全取决于您的目标。 TCP 不快，或者 TCP 会增加每个数据包的一般延迟是一个神话。 是正确的是，最初的 3 次握手需要几次往返。如果数据包确实被丢弃，应用程序会发现延迟突然急剧增加，直到再次请求并再次发送数据包，这也是事实。
如果您的目标类似于电话应用程序，其中丢失一两个数据包总体而言毫无意义，那么 UDP 更合适。 （在语音通信中，我们说话的速度足够慢，以至于如果丢失了几毫秒的声音，我们仍然可以破译所说的内容。我们的口语足够强大，如果整个单词出现乱码或无声，我们就能弄清楚要点上下文中所说的内容。）保持语音通信的即时连续性也很重要。权衡是实时性优于任何特定瞬间/数据包的准确性。
但是，如果您正在做某事，例如单向流，您可能会选择 TCP 协议。在这种情况下，尽可能实时可能很重要，但更重要的是音频/视频不会出现故障。考虑超级碗，或其他一些大型体育赛事。这是一个现场活动，重要的是它保持实时。但是，如果观看者的时间参考仅比直播延迟 3-5 秒，那么对于观看者来说，它仍然足够“直播”。如果视频出现故障并且他们错过了游戏中发生的某些事情，而不是仅仅落后几秒钟，观众会更加生气。由于它是单向流式传输并且没有通信反馈循环，因此在可靠性和质量与极低延迟之间进行权衡是有意义的。
- 没有像 WebRTC (DTLS/SRTP) 中那样的 MSE 安全/加密要求。是吗？
MSE 不知道也不关心您如何获取数据。
- 例如，不能将来自 MSE 的远程音频源与来自 RTCPeerConnection 的音频 mediaStreamTrack 混合，因为它们没有像 CNAME (RTCP) 这样的任何公共参数，或者是同一媒体流的一部分）。换句话说，除非同步不重要，否则 MSE 和 WebRTC 的世界不能混为一谈。正确吗？
混合，在哪里？同步，在哪里？无论您做什么，如果您有来自不同地方的流......甚至是没有同步/同步锁定的不同设备，它们就会不同步。但是，如果您可以定义一个您认为事物“同步”的参考点，那么一切都很好。例如，您可以让独立的流进入服务器，服务器使用其当前时间戳来设置所有内容并通过 WebRTC 一起分发。
如何执行此操作或执行什么操作取决于您的应用程序的具体情况。
【讨论】：