网络视频一直都很火。虽然在页面上嵌入 Instagram 和 Youtube 视频非常简单，但是有越来越多的需求 —— 比如许多电子商务的场景 —— 要求定制的视频传输方法。在设置视频处理和传输管道时，首先要考虑的是要服务的视频格式。 用户体验、支持（浏览器和系统）、压缩效率或编码速度等方面可能与此项选择相关。

容器和编解码器

与通常的图像格式相比，意识到容器和编码标准之间的区别是非常重要的。文件扩展名只能告诉我们它属于哪个容器，而不是使用哪个编解码器。所遵循的编码标准决定了浏览器或系统是否支持它。

例如，虽然 Web 视频格式一般都用了 mp4 容器和 H264 标准进行编码，但并非每个 mp4 文件都能受到普遍支持，因为它可能采用了不同的标准编码，如 H265。

它甚至在自适应比特率（ABR）方面变得更加复杂，这为响应用户的网络和设备功能带来了最佳方式。

让我们看一下容器，编码和交付标准的主要组合，以及它们在支持、压缩效率、编码速度和用户体验方面的差异。

渐进式视频

H264/AVC

视频格式之王采用带有 H264/AVC 编码的mp4容器。有时你也会在 m4v 容器（Handbrake 中的默认格式）中看到它，这是 Apple 为具有 DRM 保护的 H264 视频开发的 mp4 衍生产品。

每个浏览器和系统 —— 以及iOS和Android中的本机应用程序 —— 都支持这种格式。这是避免兼容性问题的安全选择。

此外，几乎所有台式机和移动设备都支持 H264 的硬件加速。编解码速度很快。、

总而言之，对这种格式编码和使用都非常简单。与图像一样，你只需用 html5 插入视频链接，就可以在任何浏览器下使用。

大约 2000 kbps 和超过几秒的延迟时间可能会影响视觉质量。当通过移动网络或网络高峰时段观看时，可能会出现停顿和重新缓冲。如果使用降低图像质量的方案将会产生模糊、飞蚊或块状之类的伪影。

H265/HEVC

这是一种使用相同的容器并用 H265 HEVC 编码的强大的视频格式，可以产生更高的压缩效率（体积减少约50％），除了模糊之外的其他问题要小得多。这种格式的主要问题在于支持仅限于 Apple 设备，其中包括其价格中的高额版税。几乎只有 Safari 和 iOS 应用才能使用它。如果你有许多 iPhone 或 Mac 用户，可以把它作为 H264 的后备版。他们的体验会更好。

即使用了硬件加速（几乎只在Apple设备中可用）这种格式更高的复杂性意味着会使编码速度明显变慢 ，因此生成交付文件需要更多的运算和时间。

VP9

这是 Google 提供的免费开源的视频格式。它使用 webm 容器代替 mp4，基本上是 mkv 容器，但将编码标准设置为 VP8 或 VP9。用 H265 也能带来类似的好处，也许是效率低一点但与 H264 相比仍然要多得多。同样，它允许减少大小，除了模糊之外的伪影要小得多。编码速度类似于 H265，这很慢。

注意，虽然以前的版本（VP8）也有相同的支持，但我们根本不推荐，因为它不会给已经普遍支持的 H264 带来任何好处。只有通过 VP9 编码才能使用 webm。

当然，对 webm 的支持仅限于 Google 的世界。这意味着只有 Chrome 和 Android 才会支持。

AV1

该标准的第一个稳定版本于 2018 年 3 月发布，其中包含 MP4 和 MKV 容器的映射。与 H265 相比，它可以提供相似或稍高的压缩效率增益，同时许可免费。与 H265 相比，最后的实现也提高了解码速度，AV1 是 web 视频传输的一个引人注目的替代品

参与创建该格式的开放媒体联盟承诺不久的将来为其提供广泛的支持。

但是，目前可用的实现应该仍然是实验性的，其瓶颈仍然是编码速度。缺乏硬件加速显然是一个问题，预计今年年底将有第一个解决方案。

VVC

负责 H264 AVC 和 H265 HEVC 的委员会正在快速追踪新标准，预计将于 2020 年发布。目前所考虑的方法的初步测试与 H265 和 AV1 相比性能已显着增加。我把它作为一个未来主义的可能性包含在这里，只是为了表明视频编码的竞争似乎远未结束。

自适应比特率（ABR）

这是渐进格式的一个非常有趣的替代方案。它建立在基于 HTTP 的媒体流通信协议之上。这种方法把视频作为主播放列表提供。播放列表可提供具有不同的分辨率和比特率的选项，可满足不同的视口大小、网络带宽和设备。

此外，视频被分成片段或块，以便客户端可以从一个质量级别跳转到另一个质量级别。它能够适应用户当前的条件，即网络速度，也适应视口大小 —— 如切换到全屏。

ABR 为优化移动设备的用户体验带来了巨大的优势，避免了在移动网络下的停顿或重新缓冲。如果你正在寻找真正的响应式的行为，这显然是应该采取的方法。它有两个主要标准：HLS 和 MPEG-DASH。

尽管人们普遍认为 ABR 只对很长的视频有意义，但根据我的经验，很多情况下相当短的剪辑也可以从这种方法中受益。

HLS

由 Apple 开发，这种 ABR 协议依赖于以 mp4 格式分割的不同再现。最初使用 H264，现在也支持 H265。但是作为折衷方案，我建议坚持对 HLS 使用 H264 编码，因为它可以在各种客户端案例中实现更好的兼容性。

这个标准的一个重点是最近的 Apple 设备的支持。对于 Safari 或本机 iOS 应用以外的客户端，你需要一个 viewer。但这不是个大问题，因为有很好的开源选择，比如 videojs。或者你需要付出一些努力，来定制它并将其用于自己的前端程序。另外还提供很棒的转码和传送服务，为你完成所有这些工作提供方便。

由于每个播放应该以恒定的比特率编码，所以我建议将 HLS与 per-title encoding 结合使用。 也就是说，基于视频的内容选择播放的比特率。

MPEG-DASH

这是针对 ABR 的编解码器无关的协议，因此除了 H264 和 H265 之外，它还可以用 VP9 编码，甚至可以使用 AV1 等新的替代方案。缺点是它的相对年轻，这意味着与 HLS 相比支持较少。这就是为什么我们不建议大多数 Web 企业使用它的原因。

总结

多年来 H264 AVC 压缩的优势很明显，新的方法正在 web 视频增添动力。在显示尺寸和分辨率方面的竞争促进了新格式的发展，能够在相同带宽下提供更多的内容。

webm 中的 VP9 对压缩效率有着显着的提升（约30％），没有版权问题，而且受到 Google 解决方案（Chrome，Android）的支持。更进一步来说，与 H264 相比，H265/HEVC 只用了一半的比特率就达到了相当的主观质量。由于它们都没有被普遍支持，因此仍然需要 H264，至少作为后备方案。

自适应比特率是一种引人注目的替代方案，可提供无与伦比的用户体验。在这方面，HLS 在开源 viewers 的帮助下得到了广泛的支持。它可能是中型网络的最佳选择。由于 videojs 等开源计划，以及能够提供极具竞争力价格的第三方服务，显着减轻了 viewer 的需求所带来的复杂性。如果你采用最后一条技术路线，请务必要求 per-title encoding。

链接: https://fly63.com/article/detial/4147