媒体源扩展Javascript API vis-a-vis WebRTC。一些问题

我遇到的最接近于这一点的是，但这只是为了基本的理解。 我的问题是：当使用媒体源扩展（MSE）从远程端点获取媒体源时，例如，通过AJAX或fetch API甚至websocket，媒体通过TCP发送

这将处理数据包丢失和排序，因此不使用RTP和RTCP之类的协议。对吗

但这将导致延迟，因此无法真正用于实时通信。是吗

与WebRTC（DTLS/SRTP）一样，MSE没有安全/加密要求。是吗

例如，不能将来自MSE的远程音频源与来自RTPeerConnection的音频mediaStreamTrack混合，因为它们没有任何公共参数（如CNAME（RTCP）或是同一媒体流的一部分）。换句话说，除非同步不重要，否则MSE和WebRTC的世界无法混合。对吗

这将处理数据包丢失和排序，因此不使用RTP和RTCP之类的协议。对吗

AJAX和Fetch只是用于发出HTTP请求的JavaScript API。WebSocket只是从初始HTTP请求扩展而来的API和协议。HTTP使用TCP。TCP负责确保数据包按顺序到达。所以，是的，您不需要担心数据包丢失之类的问题，但不是因为MSE

但这将导致延迟，因此无法真正用于实时通信。是吗

这完全取决于你的目标。TCP不快，或者TCP增加了每个数据包的一般延迟，这是一个神话。事实上，最初的三方握手需要几次往返。同样，如果数据包确实被丢弃，应用程序会认为延迟会突然急剧增加，直到再次请求并发送数据包

如果您的目标类似于电话应用程序，其中一两个数据包的丢失总体上没有意义，那么UDP更合适。（在语音通信中，我们说话的速度足够慢，以至于如果几毫秒的声音消失，我们仍然可以破译所说的话。我们的口语足够强健，如果整个单词都被弄乱或沉默，我们可以从上下文中找出所说话的要点。）语音通信保持即时连续性也很重要。折衷是，在任何特定的瞬间/数据包中，实时性都优于准确性

然而，如果您正在做一些事情，比如说单向流，您可能会选择TCP协议。在这种情况下，尽可能做到实时可能重要，但更重要的是音频/视频不会出现故障。想想超级碗，或者其他大型体育赛事。这是一个现场活动，保持实时性很重要。但是，如果查看器的时间参考仅从live延迟了3-5秒，那么对于查看器来说，它仍然“live”足够。如果视频出现故障，观众错过了游戏中发生的事情，而不是仅仅落后几秒钟，观众会更加愤怒。由于它是单向流，并且没有通信反馈循环，因此在极低延迟的情况下，在可靠性和质量上进行权衡是有意义的

与WebRTC（DTLS/SRTP）一样，MSE没有安全/加密要求。是吗

MSE不知道也不关心您如何获取数据

例如，不能将来自MSE的远程音频源与来自RTPeerConnection的音频mediaStreamTrack混合，因为它们没有任何公共参数（如CNAME（RTCP）或是同一媒体流的一部分）。换句话说，除非同步不重要，否则MSE和WebRTC的世界无法混合。对吗

混合，在哪里？同步，在哪里？无论你做什么，如果你有来自不同地方的溪流。。。甚至是没有同步/发电机锁定的不同设备，它们也不同步。但是，如果你可以定义一个参考点，你认为事物是“同步的”，那么一切都是好的。例如，您可以让独立的流进入服务器，服务器使用其当前时间戳设置所有内容，并通过WebRTC一起分发

---

您是如何做到这一点的，或者您是如何做到的，这取决于您的应用程序的具体情况。

我想确认我所理解的内容。你的解释很简洁。