ffmpeg - 直接提供静态视频内容与通过自适应流媒体协议(protocol)(HLS、DASH)

Question

通过自适应流协议(protocol)(例如 HLS 或 DASH)提供静态视频内容(不是实时流)是否比使用 HTTP 服务器直接将它们作为文件提供在速度方面有优势？

例如，当您有一个 500MB 的 mp4 h264+AAC 视频时，您必须通过 HTML5 视频元素在网站上提供该视频。您宁愿直接提供它，因为大多数流行的浏览器都实现了诸如 seek 之类的功能，而无需先下载整个文件；或者您更愿意使用 ffmpeg 或类似的解决方案从 mp4 文件创建 HLS block ，而是为 HTML5 视频元素提供 .m3u8 播放列表源。在这样做的速度方面是否有真正的优势？

如果您将数百个视频文件全部用作静态内容，您会实现哪一个？

Answer 1

大多数大型视频点播 (VOD) OTT 服务将使用 ABR 进行流式传输。

这是因为它允许最终用户设备根据当前网络条件选择最佳分辨率和比特率。

它还可以避免浪费带宽，因为设备将意识到自己的能力，并且可以避免，例如，如果它只能显示高清或更低，则可以流式传输 4K。

当视频首次启动时，它可以通过使用较低的分辨率和比特率来帮助加快启动速度，因为这会下载错误，然后在网络条件允许的情况下加快速度。当您开始新视频时，您通常可以在 Netflix 和 YouTube 等服务上观察到这一点。

您可以在此处查看查看统计信息和切换行为的方法:https://stackoverflow.com/a/42365034/334402

如果您有一个封闭的用户组，并且您知道他们都将与您的服务器具有高速连接，例如在高容量内部网络上，那么您可能不需要复杂性，但在大多数其他情况下，通常更喜欢 ABR。