做者:Anton Garcia Diaz翻译:疯狂的技术宅前端
原文:https://www.freecodecamp.org/...程序员
未经容许严禁转载web
网络视频一直都很火。虽然在页面上嵌入 Instagram 和 Youtube 视频很是简单,可是有愈来愈多的需求 —— 好比许多电子商务的场景 —— 要求定制的视频传输方法。面试
在设置视频处理和传输管道时,首先要考虑的是要服务的视频格式。 用户体验、支持(浏览器和系统)、压缩效率或编码速度等方面可能与此项选择相关。segmentfault
根据我 web 商业媒体优化的经验,我将会试着强调须要考虑的主要方面。若是你正在寻找关于使用 ffmpeg 的简单转码和优化选项,你还能够查看这篇文章。浏览器
与一般的图像格式相比,意识到容器和编码标准之间的区别是很是重要的。文件扩展名只能告诉咱们它属于哪一个容器,而不是使用哪一个编解码器。所遵循的编码标准决定了浏览器或系统是否支持它。安全
例如,虽然 Web 视频格式通常都用了 mp4 容器和 H264 标准进行编码,但并不是每一个 mp4 文件都能受到广泛支持,由于它可能采用了不一样的标准编码,如 H265。服务器
它甚至在自适应比特率(ABR)方面变得更加复杂,这为响应用户的网络和设备功能带来了最佳方式。微信
让咱们看一下容器,编码和交付标准的主要组合,以及它们在支持、压缩效率、编码速度和用户体验方面的差别。网络
视频格式之王采用带有 H264/AVC 编码的mp4容器。有时你也会在 m4v 容器(Handbrake 中的默认格式)中看到它,这是 Apple 为具备 DRM 保护的 H264 视频开发的 mp4 衍生产品。
每一个浏览器和系统 —— 以及iOS和Android中的本机应用程序 —— 都支持这种格式。这是避免兼容性问题的安全选择。
此外,几乎全部台式机和移动设备都支持 H264 的硬件加速。编解码速度很快。、
总而言之,对这种格式编码和使用都很是简单。与图像同样,你只需用 HTML5 插入视频连接,就能够在任何浏览器下使用。
大约 2000 kbps 和超过几秒的延迟时间可能会影响视觉质量。当经过移动网络或网络高峰时段观看时,可能会出现停顿和从新缓冲。若是使用下降图像质量的方案将会产生模糊、飞蚊或块状之类的伪影。
这是一种使用相同的容器并用 H265 HEVC 编码的强大的视频格式,能够产生更高的压缩效率(体积减小约50%),除了模糊以外的其余问题要小得多。这种格式的主要问题在于支持仅限于 Apple 设备,其中包括其价格中的高额版税。几乎只有 Safari 和 iOS 应用才能使用它。若是你有许多 iPhone 或 Mac 用户,能够把它做为 H264 的后备版。他们的体验会更好。
即便用了硬件加速(几乎只在Apple设备中可用)这种格式更高的复杂性意味着会使编码速度明显变慢 ,所以生成交付文件须要更多的运算和时间。
这是 Google 提供的免费开源的视频格式。它使用 webm 容器代替 mp4,基本上是 mkv 容器,但将编码标准设置为 VP8 或 VP9。用 H265 也能带来相似的好处,也许是效率低一点但与 H264 相比仍然要多得多。一样,它容许减小大小,除了模糊以外的伪影要小得多。编码速度相似于 H265,这很慢。
注意,虽然之前的版本(VP8)也有相同的支持,但咱们根本不推荐,由于它不会给已经广泛支持的 H264 带来任何好处。只有经过 VP9 编码才能使用 webm。
固然,对 webm 的支持仅限于 Google 的世界。这意味着只有 Chrome 和 Android 才会支持。
该标准的第一个稳定版本于 2018 年 3 月发布,其中包含 MP4 和 MKV 容器的映射。与 H265 相比,它能够提供类似或稍高的压缩效率增益,同时许可免费。与 H265 相比,最后的实现也提升了解码速度,AV1 是 web 视频传输的一个引人注目的替代品
参与建立该格式的开放媒体联盟承诺不久的未来为其提供普遍的支持。
参与 AV1 的开放媒体联盟合做伙伴
可是,目前可用的实现应该仍然是实验性的,其瓶颈仍然是编码速度。缺少硬件加速显然是一个问题,预计今年年末将有第一个解决方案。
负责 H264 AVC 和 H265 HEVC 的委员会正在快速追踪新标准,预计将于 2020 年发布。目前所考虑的方法的初步测试与 H265 和 AV1 相比性能已显着增长。我把它做为一个将来主义的可能性包含在这里,只是为了代表视频编码的竞争彷佛远未结束。
这是渐进格式的一个很是有趣的替代方案。它创建在基于 HTTP 的媒体流通讯协议之上。这种方法把视频做为主播放列表提供。播放列表可提供具备不一样的分辨率和比特率的选项,可知足不一样的视口大小、网络带宽和设备。
此外,视频被分红片断或块,以便客户端能够从一个质量级别跳转到另外一个质量级别。它可以适应用户当前的条件,即网络速度,也适应视口大小 —— 如切换到全屏。
ABR 为优化移动设备的用户体验带来了巨大的优点,避免了在移动网络下的停顿或从新缓冲。若是你正在寻找真正的响应式的行为,这显然是应该采起的方法。它有两个主要标准:HLS 和 MPEG-DASH。
尽管人们广泛认为 ABR 只对很长的视频有意义,但根据个人经验,不少状况下至关短的剪辑也能够从这种方法中受益。
由 Apple 开发,这种 ABR 协议依赖于以 mp4 格式分割的不一样再现。最初使用 H264,如今也支持 H265。可是做为折衷方案,我建议坚持对 HLS 使用 H264 编码,由于它能够在各类客户端案例中实现更好的兼容性。
这个标准的一个重点是最近的 Apple 设备的支持。对于 Safari 或本机 iOS 应用之外的客户端,你须要一个 viewer。但这不是个大问题,由于有很好的开源选择,好比 videojs。或者你须要付出一些努力,来定制它并将其用于本身的前端程序。另外还提供很棒的转码和传送服务,为你完成全部这些工做提供方便。
因为每一个播放应该以恒定的比特率编码,因此我建议将 HLS与 per-title encoding 结合使用。 也就是说,基于视频的内容选择播放的比特率。
这是针对 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。