渐进式HTTP下载是否可以替代HLS / DASH / RTMP提供实时视频？

我正在一个需要向用户流式传输实时视频的网站上工作，因此，我不得不直奔当前基于浏览器的视频流技术的遗憾状态。目前，最流行的实时流媒体解决方案都存在兼容性问题。RTMP需要Flash，Safari和Chrome for Android仅本地支持HLS，DASH在任何地方均不受本地支持，使用dash.js需要Media Source Extensions，但尚未得到广泛支持。

这给我带来了一个显而易见的问题：是否可以使用简单的渐进式下载来替代需要浏览器支持或插件的HLS，RTMP和DASH之类的协议？

使用渐进式下载流式传输实时媒体的想法并不是前所未有的。人们已经将其用于音频。诸如liveCaster之类的工具可让您通过单个渐进式HTTP响应流式传输实时MP3音频，而无需预先录制的MP3文件，而AmplitudeJS之类的库已竭尽全力添加与这种实时音频流相关的功能。

不过，我还没有看到这种技术在视频中被广泛使用的任何实例，而且我也不能说出原因。似乎它将以较少的权衡消除一层混乱且困难的浏览器端兼容性问题。（即使是专业人士，兼容性仍然是实时流的一个巨大问题；如果我尝试在Firefox中BBC的iPlayer上观看实时视频，它只会给我一条错误消息，告诉我安装Flash。）这种技术，我从未见过有人提到我这个想法。

为什么？是否有基本限制（我看不到），使得它无法像正在生成的MP4一样通过渐进式下载流式传输视频文件，并在<video>下载时在元素中播放？

您的问题是有效的，从理论上讲，我认为您可以使用渐进式下载进行实时视频流传输。实际上，许多在线流视频（例如YouTube等）已经在使用HTTP。我假设您严格地讲的是LIVE流媒体，而不仅仅是流媒体。

但是，您必须自己实现Live Streaming用例！否则，流协议（RTMP等）自行执行。以下是一些偏爱这些协议和体系结构的原因：

1.可变比特率

大多数实时流视频均以VBR编码，您的视频将必须快速适应不断变化的客户端网络拥塞。因此，根据客户端连接的快慢，您的视频可以在很短的时间内切换多种分辨率。

根据维基百科

它通过实时检测用户的带宽和CPU容量并相应地调整视频流的质量来工作

2.直播内容

最重要的一点是，实时流媒体意味着实时内容。与HTTP渐进式下载不同，您无法随时进行缓冲。用户必须看到面向全世界的最新镜框，并且不能落后。

3.禁用寻找

这是一个小问题，但协议应明确不允许用户向后搜索（显然是向前搜索）。这不仅应该在视频播放器级别上进行控制，还应该在网络级别上进行控制。

4.频繁断开连接/网络不可靠

对于这一点我不太清楚，但是我确实知道，一旦断开传入的HTTP下载，可能需要一些时间来建立另一个握手（即使使用keep-alive）。由于下一点，实时协议的连接和断开连接要快得多->

5.延迟

HTTP固有地在TCP上运行，从而保证了数据包的传递。将此与许多协议（尤其是实时多人游戏）中使用的UDP进行比较，在这些协议中，速度优先于保证。

有关更多信息，请参见此处-> https://en.wikipedia.org/wiki/Streaming_media#Protocols

6.内容复制

大多数实时流服务器只会响应当前时间的内容。尽管仍然可以复制实时流的内容，但是人们必须诉诸于屏幕捕获等。通过进行HTTP渐进式下载，复制内容的任务变得微不足道了（因此，那里有许多YouTube下载器）。

现在，可以对HTTP进行建模以提供上述大部分功能。

您提到的Apple的HTTP Live Streaming（HLS）最接近您要实现的目标。

此处给出了该领域的活跃研究-> http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65749&PageNum=2

我正在寻找更多信息，并将更新此答案。