低延迟（< 2 秒）实时视频流 HTML5 解决方案？
Low latency (< 2s) live video streaming HTML5 solutions?
由于 Chrome 默认禁用 Flash，我需要开始研究 flash/rtmp html5 替代解决方案。
目前使用 Flash + RTMP 我有一个实时视频流，延迟 < 1-2 秒。
我已经尝试过 MPEG-DASH，它似乎是流媒体的新行业标准，但结果很短，5 秒的延迟是我能从中获得的最佳延迟。
对于上下文，我试图让用户控制他们可以在流中看到的物理对象，因此任何超过几秒的延迟都会导致令人沮丧的体验。
是否还有其他技术，或者是否真的没有用于直播的低延迟 html5 解决方案？
技术和要求
唯一真正面向低延迟的 web-based 技术集是 WebRTC。它专为视频会议而打造。编解码器针对低延迟质量进行了调整。比特率通常是可变的，选择稳定的连接而不是质量。
但是，您不一定需要为所有用户进行这种低延迟优化。事实上，根据我收集到的您的要求，每个人的低延迟都会损害用户体验。虽然控制机器人的用户肯定需要低延迟视频以便他们可以合理地控制它，但不受控制的用户没有此要求，而是可以选择可靠的更高质量的视频。
如何设置
In-Control 机器人连接的用户
控制机器人的用户将加载一个页面，该页面利用一些 WebRTC 组件连接到摄像头和控制服务器。为了促进 WebRTC 连接，您需要某种 STUN 服务器。要绕过 NAT 和其他防火墙限制，您可能需要一个 TURN 服务器。这两个通常都内置在 Node.js-based WebRTC 框架中。
cam/control 服务器也需要通过 WebRTC 连接。老实说，最简单的方法是让您的控制应用程序有点基于 Web。由于您已经在使用 Node.js，请查看 NW.js or Electron。两者都可以利用 WebKit 中已经内置的 WebRTC 功能，同时仍然让您可以灵活地使用 Node.js.
做任何您想做的事
in-control 用户和 cam/control 服务器将通过 WebRTC（或 TURN 服务器，如果需要）建立 peer-to-peer 连接。从那里，您需要打开媒体渠道和数据渠道。数据端可用于发送您的机器人命令。媒体通道当然会用于发送回 in-control 用户的低延迟视频流。
再次强调，发回的视频将针对延迟而非质量进行优化，这一点很重要。这种连接还可以确保对您的命令做出快速响应。
观看用户的视频
单纯看直播不控制机器人的用户可以使用正常的视频分发方式。使用现有的 CDN 和转码服务对您来说实际上非常重要，因为您将有 10k-15k 人观看流。有那么多用户，您可能希望您的视频采用几种不同的编解码器，当然还有各种比特率。使用 DASH or HLS 的分发目前最容易使用，并且无需 Flash 要求。
您可能还想将您的流发送到社交媒体服务。这是从高质量高清流开始很重要的另一个原因。这些服务将再次对您的视频进行转码，从而降低质量。如果你先从好的质量开始，你最终会得到更好的质量。
元数据（聊天、控制信号等）
从您的要求中不清楚您需要哪种元数据，但是对于小 message-based 数据，您可以使用网络套接字库，例如 Socket.IO。当您将其扩展到几个实例时，您可以使用 pub/sub，例如 Redis，在整个服务器中分发消息。
将元数据同步到视频在一定程度上取决于元数据中的内容以及具体的同步要求。一般来说，您可以假设源视频和客户端之间存在合理但不可预测的延迟。毕竟，您无法控制它们缓冲多长时间。每个设备都不同，每个连接变量。您可以假设播放将从客户端下载的第一个片段开始。换句话说，如果客户端开始缓冲视频并在 2 秒后开始播放，则视频比第一次请求时滞后 2 秒。
检测播放真正开始的时间client-side是可能的。由于服务器知道将视频发送到客户端的时间戳，因此它可以通知客户端其相对于视频播放开始的偏移量。由于您可能会使用 DASH 或 HLS，并且您需要将 MCE 与 AJAX 一起使用以获取数据，因此您可以 use the response headers in the segment response 指示段开始的时间戳。然后客户端可以同步自身。让我分解一下 step-by-step:
- 客户端开始从应用程序服务器接收元数据消息。
- 客户端从 CDN 请求第一个视频片段。
- CDN 服务器回复视频片段。在响应 header 中，
Date: header 可以指示确切的 date/time 作为段的开始。
- 客户端读取响应
Date: header（比方说 2016-06-01 20:31:00）。客户端继续缓冲段。
- 客户端正常启动 buffering/playback。
- 播放开始。客户可以在播放器上检测这个状态变化，并且知道视频播放器上的
00:00:00 实际上是 2016-06-01 20:31:00.
- 客户端显示与视频同步的元数据，删除以前的任何消息并为将来缓冲任何消息。
这应该可以满足您的需求，并让您可以灵活地做任何您需要的视频。
为什么不 [magic-technology-here]？
- 当你选择低延迟时，你会失去质量。质量来自可用带宽。带宽效率来自于在编码时能够缓冲和优化整个图像序列。如果你想要完美的质量（每张图片无损），你需要大量的带宽（每个观众千兆位）。这就是为什么我们首先要有这些有损编解码器。
- 由于您实际上 需要 大多数观众的低延迟，因此最好为他们优化质量。
- 对于 15,000 名确实需要低延迟的 2 名用户，我们可以为他们优化低延迟。他们将获得不合格的视频质量，但能够主动控制机器人，这太棒了！
- 永远记住，互联网是一个充满敌意的地方，没有任何东西可以正常工作。系统资源和带宽不断变化。这就是为什么 WebRTC auto-adjusts（尽可能合理地）改变条件。
- 并非所有连接都能满足低延迟要求。这就是为什么每个低延迟连接都会经历 drop-outs。互联网是 packet-switched，而不是 circuit-switched。没有真正可用的专用带宽。
- 拥有较大的缓冲区（几秒钟）可以让客户端在暂时失去连接的情况下幸存下来。这就是为什么带有 anti-skip 缓冲器的 CD 播放器被创造出来并且卖得很好的原因。如果视频正常播放，那 15,000 名用户的用户体验会好得多。他们不必知道自己落后主流 5-10 秒，但他们肯定会知道视频是否每隔一秒掉一次。
每种方法都需要权衡取舍。我认为我在这里概述的内容将关注点分开，并为您提供了每个领域的最佳权衡。请随时要求澄清或在评论中提出 follow-up 问题。
由于 Chrome 默认禁用 Flash，我需要开始研究 flash/rtmp html5 替代解决方案。
目前使用 Flash + RTMP 我有一个实时视频流，延迟 < 1-2 秒。
我已经尝试过 MPEG-DASH，它似乎是流媒体的新行业标准，但结果很短，5 秒的延迟是我能从中获得的最佳延迟。
对于上下文，我试图让用户控制他们可以在流中看到的物理对象，因此任何超过几秒的延迟都会导致令人沮丧的体验。
是否还有其他技术，或者是否真的没有用于直播的低延迟 html5 解决方案？
技术和要求
唯一真正面向低延迟的 web-based 技术集是 WebRTC。它专为视频会议而打造。编解码器针对低延迟质量进行了调整。比特率通常是可变的，选择稳定的连接而不是质量。
但是，您不一定需要为所有用户进行这种低延迟优化。事实上，根据我收集到的您的要求，每个人的低延迟都会损害用户体验。虽然控制机器人的用户肯定需要低延迟视频以便他们可以合理地控制它，但不受控制的用户没有此要求，而是可以选择可靠的更高质量的视频。
如何设置
In-Control 机器人连接的用户
控制机器人的用户将加载一个页面，该页面利用一些 WebRTC 组件连接到摄像头和控制服务器。为了促进 WebRTC 连接，您需要某种 STUN 服务器。要绕过 NAT 和其他防火墙限制，您可能需要一个 TURN 服务器。这两个通常都内置在 Node.js-based WebRTC 框架中。
cam/control 服务器也需要通过 WebRTC 连接。老实说，最简单的方法是让您的控制应用程序有点基于 Web。由于您已经在使用 Node.js，请查看 NW.js or Electron。两者都可以利用 WebKit 中已经内置的 WebRTC 功能，同时仍然让您可以灵活地使用 Node.js.
做任何您想做的事in-control 用户和 cam/control 服务器将通过 WebRTC（或 TURN 服务器，如果需要）建立 peer-to-peer 连接。从那里，您需要打开媒体渠道和数据渠道。数据端可用于发送您的机器人命令。媒体通道当然会用于发送回 in-control 用户的低延迟视频流。
再次强调，发回的视频将针对延迟而非质量进行优化，这一点很重要。这种连接还可以确保对您的命令做出快速响应。
观看用户的视频
单纯看直播不控制机器人的用户可以使用正常的视频分发方式。使用现有的 CDN 和转码服务对您来说实际上非常重要，因为您将有 10k-15k 人观看流。有那么多用户，您可能希望您的视频采用几种不同的编解码器，当然还有各种比特率。使用 DASH or HLS 的分发目前最容易使用，并且无需 Flash 要求。
您可能还想将您的流发送到社交媒体服务。这是从高质量高清流开始很重要的另一个原因。这些服务将再次对您的视频进行转码，从而降低质量。如果你先从好的质量开始，你最终会得到更好的质量。
元数据（聊天、控制信号等）
从您的要求中不清楚您需要哪种元数据，但是对于小 message-based 数据，您可以使用网络套接字库，例如 Socket.IO。当您将其扩展到几个实例时，您可以使用 pub/sub，例如 Redis，在整个服务器中分发消息。
将元数据同步到视频在一定程度上取决于元数据中的内容以及具体的同步要求。一般来说，您可以假设源视频和客户端之间存在合理但不可预测的延迟。毕竟，您无法控制它们缓冲多长时间。每个设备都不同，每个连接变量。您可以假设播放将从客户端下载的第一个片段开始。换句话说，如果客户端开始缓冲视频并在 2 秒后开始播放，则视频比第一次请求时滞后 2 秒。
检测播放真正开始的时间client-side是可能的。由于服务器知道将视频发送到客户端的时间戳，因此它可以通知客户端其相对于视频播放开始的偏移量。由于您可能会使用 DASH 或 HLS，并且您需要将 MCE 与 AJAX 一起使用以获取数据，因此您可以 use the response headers in the segment response 指示段开始的时间戳。然后客户端可以同步自身。让我分解一下 step-by-step:
- 客户端开始从应用程序服务器接收元数据消息。
- 客户端从 CDN 请求第一个视频片段。
- CDN 服务器回复视频片段。在响应 header 中，
Date:header 可以指示确切的 date/time 作为段的开始。 - 客户端读取响应
Date:header（比方说2016-06-01 20:31:00）。客户端继续缓冲段。 - 客户端正常启动 buffering/playback。
- 播放开始。客户可以在播放器上检测这个状态变化，并且知道视频播放器上的
00:00:00实际上是2016-06-01 20:31:00. - 客户端显示与视频同步的元数据，删除以前的任何消息并为将来缓冲任何消息。
这应该可以满足您的需求，并让您可以灵活地做任何您需要的视频。
为什么不 [magic-technology-here]？
- 当你选择低延迟时，你会失去质量。质量来自可用带宽。带宽效率来自于在编码时能够缓冲和优化整个图像序列。如果你想要完美的质量（每张图片无损），你需要大量的带宽（每个观众千兆位）。这就是为什么我们首先要有这些有损编解码器。
- 由于您实际上 需要 大多数观众的低延迟，因此最好为他们优化质量。
- 对于 15,000 名确实需要低延迟的 2 名用户，我们可以为他们优化低延迟。他们将获得不合格的视频质量，但能够主动控制机器人，这太棒了！
- 永远记住，互联网是一个充满敌意的地方，没有任何东西可以正常工作。系统资源和带宽不断变化。这就是为什么 WebRTC auto-adjusts（尽可能合理地）改变条件。
- 并非所有连接都能满足低延迟要求。这就是为什么每个低延迟连接都会经历 drop-outs。互联网是 packet-switched，而不是 circuit-switched。没有真正可用的专用带宽。
- 拥有较大的缓冲区（几秒钟）可以让客户端在暂时失去连接的情况下幸存下来。这就是为什么带有 anti-skip 缓冲器的 CD 播放器被创造出来并且卖得很好的原因。如果视频正常播放，那 15,000 名用户的用户体验会好得多。他们不必知道自己落后主流 5-10 秒，但他们肯定会知道视频是否每隔一秒掉一次。
每种方法都需要权衡取舍。我认为我在这里概述的内容将关注点分开，并为您提供了每个领域的最佳权衡。请随时要求澄清或在评论中提出 follow-up 问题。