技术和要求
唯一真正面向低延迟的基于 Web 的技术集是 WebRTC。它专为视频会议而设计。编解码器针对质量低延迟进行了调整。比特率通常是可变的，选择稳定的连接而不是质量。
但是，您不一定需要对所有用户进行这种低延迟优化。事实上，从我收集到的你的要求来看，每个人的低延迟都会损害用户体验。虽然您控制机器人的用户肯定需要低延迟视频，以便他们可以合理地控制它，但不受控制的用户没有这个要求，而是可以选择可靠的更高质量的视频。
如何设置
控制用户到机器人连接
控制机器人的用户将加载一个页面，该页面利用一些 WebRTC 组件连接到摄像头和控制服务器。为了促进 WebRTC 连接，您需要某种 STUN 服务器。要绕过 NAT 和其他防火墙限制，您可能需要一个 TURN 服务器。这两者通常都内置在基于 Node.js 的 WebRTC 框架中。
凸轮/控制服务器也需要通过 WebRTC 进行连接。老实说，最简单的方法是让您的控制应用程序有点基于 Web。由于您已经在使用 Node.js，请查看 NW.js 或 Electron。两者都可以利用 WebKit 中已经内置的 WebRTC 功能，同时仍然让您可以灵活地使用 Node.js 做任何您想做的事情。
受控用户和凸轮/控制服务器将通过 WebRTC（或 TURN 服务器，如果需要）建立对等连接。从那里，您需要打开一个媒体通道和一个数据通道。数据端可用于发送您的机器人命令。媒体通道当然会用于将低延迟视频流发送回受控用户。
同样，请务必注意，将发送回的视频将针对延迟而非质量进行优化。这种连接还可以确保快速响应您的命令。
用户观看视频
只是观看流而不控制机器人的用户可以使用正常的视频分发方法。实际上，使用现有的 CDN 和转码服务对您来说非常重要，因为您将有 10k-15k 人观看流媒体。有了这么多用户，您可能会希望您的视频采用几个不同的编解码器，当然还有一系列比特率。目前使用DASH 或HLS 分发是最容易使用的，并且可以让您摆脱对Flash 的要求。
您可能还希望将流发送到社交媒体服务。这是从高质量高清流开始很重要的另一个原因。这些服务将再次对您的视频进行转码，从而降低质量。如果您首先以良好的质量开始，最终您将获得更好的质量。
元数据（聊天、控制信号等）
根据您的要求并不清楚您需要哪种元数据，但对于基于消息的小型数据，您可以使用 Web 套接字库，例如 Socket.IO。当您将其扩展到几个实例时，您可以使用 pub/sub（例如 Redis）在整个服务器中分发消息。
将元数据与视频同步在一定程度上取决于元数据中的内容以及具体的同步要求。一般来说，您可以假设源视频和客户端之间存在合理但不可预测的延迟。毕竟，您无法控制它们缓冲多长时间。每个设备都不同，每个连接变量。您可以假设播放将从客户端下载的第一段开始。换句话说，如果客户端开始缓冲视频并在 2 秒后开始播放，则视频会比第一次请求时晚 2 秒。
检测客户端何时真正开始播放是可能的。由于服务器知道将视频发送到客户端的时间戳，它可以通知客户端其相对于视频播放开始的偏移量。由于您可能会使用 DASH 或 HLS，并且无论如何您都需要使用 MCE 和 AJAX 来获取数据，因此您可以use the response headers in the segment response 指示段开始的时间戳。然后客户端可以自行同步。让我逐步分解：
- 客户端开始从应用服务器接收元数据消息。
- 客户端从 CDN 请求第一个视频片段。
- CDN 服务器回复视频片段。在响应标头中，
Date: 标头可以指示段开始的确切日期/时间。
- 客户端读取响应
Date: 标头（假设2016-06-01 20:31:00）。客户端继续缓冲这些段。
- 客户端正常开始缓冲/播放。
- 播放开始。客户端可以检测到播放器上的这种状态变化，并知道视频播放器上的
00:00:00实际上是2016-06-01 20:31:00。
- 客户端显示与视频同步的元数据，丢弃之前的所有消息并为未来缓冲任何消息。
这应该可以满足您的需求，并让您可以灵活地为您的视频做任何您需要做的事情。
为什么不 [magic-technology-here]？
- 当您选择低延迟时，您会失去质量。质量来自可用带宽。带宽效率来自于在编码时能够缓冲和优化整个图像序列。如果您想要完美的质量（每张图像无损），您将需要大量（每个观众千兆位）的带宽。这就是为什么我们一开始就有这些有损编解码器。
- 由于您实际上需要为大多数观众提供低延迟，因此最好为他们优化质量。
- 对于 15,000 个确实需要低延迟的用户中的 2 个，我们可以为他们优化低延迟。他们将获得不合格的视频质量，但能够主动控制机器人，这太棒了！
- 永远记住，互联网是一个充满敌意的地方，没有任何东西可以正常工作。系统资源和带宽是不断变化的。这实际上就是 WebRTC 自动调整（尽可能合理）以适应不断变化的条件的原因。
- 并非所有连接都能满足低延迟要求。这就是为什么每一个低延迟连接都会出现掉线的原因。互联网是分组交换的，而不是电路交换的。没有真正的专用带宽可用。
- 拥有大缓冲区（几秒钟）可以让客户端在连接的瞬间丢失中幸存下来。这就是为什么带有防跳缓冲区的 CD 播放器被创造出来并且卖得很好的原因。如果视频正常工作，这对这 15,000 名用户来说是一个更好的用户体验。他们不必知道自己落后于主流 5-10 秒，但他们肯定会知道视频是否每隔一秒就掉线。
每种方法都需要权衡取舍。我认为我在这里概述的内容将关注点分开，并为您提供每个领域的最佳权衡。请随时在 cmets 中要求澄清或提出后续问题。