Web端H.265播放器研发解密

音视频编解码对于前端工程师是一个比较少涉足的领域，涉及到流媒体技术中的文本、图形、图像、音频和视频多种理论知识的学习，才能够应用到具体实践中，本团队在多媒体领域深耕两年多，才算是有一定产出，我们自研web播放器并支持h.265解码，在码率优化的大背景下（保持画质不变情况下，应用图像增强、roi区域检测、智能场景分类和h265编解码等多种技术能力，将码流降低50%。达到减少带宽成本，提升视频服务QoE的目的），真正做到了h265解码播放的全域覆盖。

播放器整体架构

我们播放器整体架构设计如下：

本文主要分享了我们基于WebAssembly实现H.265格式的解封装、解码和播放。

背景

H.265又称HEVC(全称High Efficiency Video Coding，高效率视频编码)，是ITU-T H.264/MPEG-4 AVC标准的继任者。相比H.264，H.265拥有更高的压缩率，也就意味着同样码率（又称比特率是指每秒传送的比特(bit)数。单位为bps(Bit Per Second)，比特率越高，每秒传送数据就越多，画质就越清晰），H.265的画质会更清晰，更高的压缩率就能使用更低的存储和传输成本。

• 带宽成本：在有限带宽下H.265能传输更高质量的网络视频，理论上，H.265最高只需H.264编码的一半带宽即可传输相同质量视频。更低的带宽可以更好的降低存储及传输成本，并为未来基于短视频及直播领域更多更复杂好玩的互动玩法做铺垫。
• 转码成本：但是当前主流浏览器均不支持H.265原生视频播放，因此通常视频生产端需要针对浏览器做一次H.264视频的转码来适配浏览器端如PC场景的播放，而增加了转码成本。如在淘宝直播中，假设以每天5万场直播计算，每场直播转码成本20元，一天就是100万的转码成本。
  为此，我们团队对浏览器端H.265视频播放的可行性及兼容性进行了一次探索，为移动端及PC端全量H.265做准备，也对浏览器端视音频处理、WebAssembly实践进行一次深入的尝试。

H.264 vs H.265

H.264是当下用的最为广泛的视频编码格式，H.265标准围绕着现有的视频编码标准H.264，保留原来的某些技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。H.265和H.264都是基于块的视频编码技术，主要的差别在于编码单元的大小以及一些编码算法细节，H.265将图像划分为“编码树单元(coding tree Unit, CTU)”，而不是像H.264那样的16×16的宏块。根据不同的编码设置，编码树单元的尺寸可以被设置为64×64或有限的32×32或16×16。一般来说区块尺寸越大，压缩效率就越好。具体的算法及相关细节这里不具体展开了，还有一些其他的压缩算法如因为H.265专利限制而生的开放编码格式如AV1等，读者可以参考其他相关文章。

如下图，可以看到同样主观画面质量，H.265(500K)仅需H.264(800K)一半左右的带宽码率。

浏览器现状

如下图，因为H.265专利及硬解支持情况不完善的原因，主流现代浏览器均不兼容H.265编码的视频播放（Edge新版本以插件方式支持），但是因为Apple对H.265的支持（这里作者认为这可能是一个很重要的标志，因为技术的发展很多时候不光是这个技术本身所决定的，而是很多因素共同作用的结果，商业也是其中很重要的一个因素），移动端ios safari在11.0版本以上支持原生播放。

想要在浏览器端播放H.265视频原生的<video />标签没有办法支持，但是因为视频格式本身是连续图像画面和音频的集合，参考了chromium的源码及video标签内部的实现原理，可以通过<canvas /> + Web Audio API 的结合来模拟实现一个虚拟的video标签来实现播放器功能。

demo

因为直播流时效性的缘故，发布了一个播放H.265 mp4视频（该视频地址直接在浏览器中播放只有声音而没有画面）的在线demo，读者可以有一个直观感受。
地址：