媒体源扩展 Javascript API 相对于 WebRTC。一些问题
Media Source Extension Javascript API vis-a-vis WebRTC. Some questions
我最接近的是 但这只是为了基本理解。
我的问题是：当使用媒体源扩展 (MSE) 从远程端点获取媒体源时，例如，通过 AJAX 或 fetch API 甚至 websocket，媒体通过 TCP 发送。
- 这将处理数据包丢失和排序，因此不使用 RTP 和 RTCP 等协议。那是对的吗？
- 但是这样会造成延迟，不能真正用于实时通信。是吗？
- 与 WebRTC (DTLS/SRTP) 一样，MSE 没有 security/encryption 要求。是吗？
- 例如，不能将来自 MSE 的远程音频源与来自 RTCPeerConnection 的音频 mediaStreamTrack 混合，因为它们没有像 CNAME (RTCP) 这样的任何公共参数，或者是同一媒体流的一部分。换句话说，除非同步不重要，否则 MSE 和 WebRTC 的世界不能混合。正确的？
- That will handle packet loss and sequencing so protocol like RTP with RTCP is not used. Is that correct?
AJAX 和 Fetch 只是 JavaScript API 用于发出 HTTP 请求。 Web Socket 只是一个 API 和从初始 HTTP 请求扩展而来的协议。 HTTP 使用 TCP。 TCP 负责确保数据包到达并按顺序到达。所以，是的，你不需要担心数据包丢失等问题，但不是因为 MSE。
- But this will result in delay so it cannot be truly used for real-time communication. Yes?
这完全取决于您的目标。 TCP 速度不快，或者 TCP 会增加每个数据包的一般延迟是一个神话。 是真实的是，最初的 3 次握手需要几次往返。这也是事实，如果数据包确实被丢弃，应用程序会看到延迟突然急剧增加，直到再次请求并再次发送数据包。
如果您的目标类似于电话应用程序，其中丢失一两个数据包总体上毫无意义，那么 UDP 更合适。 （在语音通信中，我们说话的速度足够慢，如果几毫秒的声音丢失，我们仍然可以破译所说的内容。我们的口语足够强大，即使整个单词出现乱码或沉默，我们也可以弄清楚要点根据上下文所说的内容。）保持语音通信的即时连续性也很重要。权衡是实时性优于任何特定 instant/packet.
的准确性
但是，如果您正在做某事，比如单向流，您可能会选择基于 TCP 的协议。在这种情况下，尽可能实时可能很重要，但更重要的是 audio/video 不要出现故障。想想超级碗或其他一些大型体育赛事。这是一个现场活动，重要的是它保持实时。但是，如果观众的时间参考仅比直播延迟 3-5 秒，对于观众来说仍然 "live" 足够了。如果视频出现故障并且他们错过了比赛中发生的事情，而不是仅仅落后几秒钟，观众会更加生气。由于它是单向流式传输并且没有通信反馈回路，因此在可靠性和质量与极低延迟之间进行权衡是有意义的。
- There is no security/encryption requirement for MSE like in WebRTC (DTLS/SRTP). Yes?
MSE 不知道也不关心您如何获取数据。
- One cannot, for example, mix a remote audio source from MSE with an audio mediaStreamTrack from a RTCPeerConnection as they do not have any common param like CNAME (RTCP) or are part of the same mediastream). In other words, the world of MSE and WebRTC cannot mix unless synchronization is not important. Correct?
混，在哪？同步，在哪里？无论您做什么，如果您有来自不同地方的流……甚至没有 sync/gen 锁定的不同设备，它们就会不同步。但是，如果您可以在考虑事物的地方定义一个参考点 "synchronized"，那么一切都很好。例如，您可以让独立的流进入服务器，服务器使用其当前时间戳来设置所有内容并通过 WebRTC 一起分发。
如何执行此操作或做什么取决于应用程序的具体情况。
我最接近的是
- 这将处理数据包丢失和排序，因此不使用 RTP 和 RTCP 等协议。那是对的吗？
- 但是这样会造成延迟，不能真正用于实时通信。是吗？
- 与 WebRTC (DTLS/SRTP) 一样，MSE 没有 security/encryption 要求。是吗？
- 例如，不能将来自 MSE 的远程音频源与来自 RTCPeerConnection 的音频 mediaStreamTrack 混合，因为它们没有像 CNAME (RTCP) 这样的任何公共参数，或者是同一媒体流的一部分。换句话说，除非同步不重要，否则 MSE 和 WebRTC 的世界不能混合。正确的？
- That will handle packet loss and sequencing so protocol like RTP with RTCP is not used. Is that correct?
AJAX 和 Fetch 只是 JavaScript API 用于发出 HTTP 请求。 Web Socket 只是一个 API 和从初始 HTTP 请求扩展而来的协议。 HTTP 使用 TCP。 TCP 负责确保数据包到达并按顺序到达。所以，是的，你不需要担心数据包丢失等问题，但不是因为 MSE。
- But this will result in delay so it cannot be truly used for real-time communication. Yes?
这完全取决于您的目标。 TCP 速度不快，或者 TCP 会增加每个数据包的一般延迟是一个神话。 是真实的是，最初的 3 次握手需要几次往返。这也是事实，如果数据包确实被丢弃，应用程序会看到延迟突然急剧增加，直到再次请求并再次发送数据包。
如果您的目标类似于电话应用程序，其中丢失一两个数据包总体上毫无意义，那么 UDP 更合适。 （在语音通信中，我们说话的速度足够慢，如果几毫秒的声音丢失，我们仍然可以破译所说的内容。我们的口语足够强大，即使整个单词出现乱码或沉默，我们也可以弄清楚要点根据上下文所说的内容。）保持语音通信的即时连续性也很重要。权衡是实时性优于任何特定 instant/packet.
的准确性但是，如果您正在做某事，比如单向流，您可能会选择基于 TCP 的协议。在这种情况下，尽可能实时可能很重要，但更重要的是 audio/video 不要出现故障。想想超级碗或其他一些大型体育赛事。这是一个现场活动，重要的是它保持实时。但是，如果观众的时间参考仅比直播延迟 3-5 秒，对于观众来说仍然 "live" 足够了。如果视频出现故障并且他们错过了比赛中发生的事情，而不是仅仅落后几秒钟，观众会更加生气。由于它是单向流式传输并且没有通信反馈回路，因此在可靠性和质量与极低延迟之间进行权衡是有意义的。
- There is no security/encryption requirement for MSE like in WebRTC (DTLS/SRTP). Yes?
MSE 不知道也不关心您如何获取数据。
- One cannot, for example, mix a remote audio source from MSE with an audio mediaStreamTrack from a RTCPeerConnection as they do not have any common param like CNAME (RTCP) or are part of the same mediastream). In other words, the world of MSE and WebRTC cannot mix unless synchronization is not important. Correct?
混，在哪？同步，在哪里？无论您做什么，如果您有来自不同地方的流……甚至没有 sync/gen 锁定的不同设备，它们就会不同步。但是，如果您可以在考虑事物的地方定义一个参考点 "synchronized"，那么一切都很好。例如，您可以让独立的流进入服务器，服务器使用其当前时间戳来设置所有内容并通过 WebRTC 一起分发。
如何执行此操作或做什么取决于应用程序的具体情况。