本次演讲由腾讯高级工程师陈映平为大家介绍基于WebAssembly的H.265播放器，以及在NOW直播中的应用。本次主要介绍采用WebAssembly制作音视频H.265播放器的整体思路、播放器架构设计以及线上实践。
演讲嘉宾简介：陈映平（程序猿小卡）， 腾讯高级工程师，IVWEB团队负责人之一。
本次分享主要围绕以下五个方面：
一、方案背景介绍
二、方案选型
三、播放器架构设计
四、线上实践
五、未来展望
一、方案背景介绍
1.直播行业概况
下图为互动直播行业从2003年至2016年的发展变化历程。2003年至2008年，语音直播行业比较受欢迎，平台有YY语音直播、QT等。2008年至2011年PC聊天室场景逐渐火爆，广受欢迎的有9158、六间房。2011年至2014年，秀场直播异军突起。2014至2015年，垂类直播开始火爆。垂类直播主要指集中在某些特定领域和特定需求，以直播形式提供相关信息与服务的直播，例如游戏直播等。主要平台包括虎牙、龙珠等。2015年移动直播出现，2016年被称为直播元年。2015年开始我国提倡大众创业、万众创新，市场上涌现众多资本。由于直播行业盈利强劲，资本纷纷涌入，出现千团混战局面。代表厂家包括虎牙直播、企鹅电竞、花椒直播、NOW直播等。
2.直播行业成本支持
内容：直播内容成本包括聘请优质主播等花费。
薪酬：企业员工薪酬成本。
带宽：根据部分上市公司（例如虎牙）的统计材料，带宽成本比重大约为10%~30%。对于部分小企业而言，内容成本比大企业低，带宽成本可能占总成本40%甚至50%以上。目前国内带宽计费方式通常有两种。一是根据使用量计费。例如观看一天视频，则根据当天消耗流量的总量计费。二是峰值带宽收费，即根据流量速度峰值计费，直播行业一般采用峰值带宽收费。下图所示为国内某知名云服务厂商的带宽流量计费方式，峰值带宽计费。例如某天游戏总决赛直播峰值带宽为3.5T，按照下表收费即为3.5*1024*1024*0.58=212W元。即一场比赛当天带宽成本就达到212万元，带宽成本高昂。
一些大公司会与云服务厂商签订战略合作协议，带宽收费可能会比对外公开价格低。下图为虎牙直播2018年Q3至2019年Q3的带宽支出情况统计。2018年Q3虎牙直播带宽支出为1.74亿，2019年Q3支出为2.1亿。同比增长率由66.8%降低至21%，这是虎牙直播带宽成本优化的结果。
3.直播方案需求
直播行业在技术选型时需要考虑如下因素。
延迟：互动延迟会影响用户体验，解决直播互动延迟问题十分重要。
成本：内容、薪酬、带宽等成本。
性能：关键指标包括音视频播放时的CPU占用、内存占用、卡顿、帧率等。
扩展性：音视频直播行业出现至今，音视频编解码领域飞速发展，经常发布更新编解码协议。如果播放器架构扩展性设计不好，一旦编解码协议更新或替换，就可能需要重构播放器架构，于业务方而言是难以承受的。
二、方案选型
1.常见直播协议
RTMP、HLS、HTTP-FLV都有各自的应用场景。
HLS：HLS在移动端使用非常多，是苹果主导的一个规范。HLS的特点是可以自适应码率以及带宽状况。例如可以根据手机的网络情况自动切换到不同的码率，可以使用户在4G、3G等不同网络条件下正常观看直播。
RTMP：Adobe公司的私有协议，特点是延迟比较低。RTMP的缺点，首先作为私有协议，协议细节部分为黑盒，出现问题时难以排查。第二是RTMP使用的不是标准80端口，会导致一些问题。例如一位直播观众需要在校园网环境观看直播。众所周知校园网络有各种保护措施，如防火墙等会屏蔽一些非标准端口。此时不适合使用RTMP观看。RTMP协议较适合做推流。例如主播需要在直播间里进行直播，那么可以采用RTMP进行推流。即将直播流采集后上传到服务器，然后给用户观看。
HTTP-FLV：协议栈与RTMP相似。HTTP-FLV与RTMP内部数据封装都基于FLV Tag。HTTP-FLV的延迟介于RTMP与HLS之间。同时HTTP-FLV使用的是标准的HTTP协议，端口是80标准端口，网络穿透性较好，因此一般在观看端会采用HTTP-FLV。过去几年，由于浏览器不支持FLV的原生播放，许多时候需要借助Flash播放器进行播放。bilibili出品的flv.js，采用MSE解码播放的方式达到对HTTP-FLV的支持。
2.视频编码简述
由于流量的重要性，需要降低视频对带宽的占用。如下图，视频是由一个一个的视频帧构成的。例如每秒播放20视频帧，连续播放就形成视频。视频帧在编码层面又是由一个一个的切片组成的。视频编码首先将视频帧分块为多个视频切片，然后采取帧内预测等手段对视频切片进行压缩。实际压缩效果较下图图示更加优秀。
视频编码技术的重要性：举例说明直播视频的数据流量消耗。下图所示直播页面宽高比为540 * 960，每秒15帧。每一个像素由三个通道组成，每一个通道占8bit。则一分钟数据量为540 * 960 * 8 * 3 * 15 * 60bit。转化为Mb为1334Mb，即一分钟直播流量约1.33G。如果视频的带宽消耗的确为上述程度，多数人应该不会在数据流量环境下观看视频。因此通过视频编码来压缩视频尺寸十分重要。对视频采用H264进行编码，上述一分钟时长1334Mb尺寸的视频压缩后尺寸仅为11Mb。视频编码压缩的效果比前文图示效果更为显著，带宽费用降低至不到原来的1%。
视频编码技术的发展：下图为音视频编码技术发展历程。1992年ISO/IEC（专家工作组）发布MPEG-1标准。MPEG-1主要为VCD服务。1994年MPEG-2发布，主要服务于DVD。MPEG-3发布目的是为HDTV服务，后发现MPEG-2已经满足该需求，因此废弃MPEG-3，并将其优化部分并入了MPEG-2。1998年发布MPEG-4标准。2003年ISO与ITU联合发布了一个非常重要的标准H.264。H.264与AVC是同一个东西，是在MPEG-4 Part 10中定义的。2012年由谷歌主导的VP9发布，其被定位为下一代的视频编码解决方案。VP9在H.264基础上进一步压缩视频带宽的占用，目标是提升50%左右的带宽。目前国内VP9的应用相对较少。2013年ISO与ITU联合发布H.265，相较于H.264进一步提升了带宽。
3.选择H.265
特点：首先在相同码率条件下H.265视频画质更高。第二，压缩效率更高：例如同时观看同一份分别采用H.264和H.265标准编码的视频，H.265节省更多带宽，平均能达到30%~ 50%。第三，由于H.265压缩效率高，因此码率要求更低。下图为同一个视频的流量对比，由于根据不同视频优化带宽能力不同，因此下图没有具体比重或数值。整体上H.265较H.264节省30%以上的带宽。
原因：H.265压缩比较H.264高很多是因为H.265优化了非常多的技术细节。如下图，以对视频分块压缩过程为例。H.264会将下图分为若干16*16的宏块，然后对其进行编码。采用例如计算残差等一系列压缩手段。H.265整体播放设计架构与H.264没有太大差异，同样采用混合编码架构，同时采用的编码压缩的优化手段也差不多，可能会支持更多帧间预测的方式等。H.265支持了更大的宏块，以及可变的宏块。例如下图左上角黑色区域，视觉效果乌黑一片。如果采用H.264编码方式，虽然其像素RGB值完全相同，但是编码为许多像素款。而使用H.265编码方式，当该区域RGB值接近，可以直接采用64*64的宏块提高压缩效率。
浏览器支持情况差问题：如下图，诸多浏览器不支持H.265。H.265是由多个厂商联合发布的标准，同时发布厂商对于H.265涉及的专利如何进行收费没有统一的标准。例如起初用户使用H.265标准进行视频编码并不收费，产品上线一年规模扩大之后，可能突然收到律师函通知用户专利费欠款上千万。据不完全统计，H.265一年的专利授权费在1亿美元以上，价格非常高昂。因此H.265没有推广开来并不主要是技术方面的原因，而是专利授权方面的原因。相比之下H.264收费公开透明，也较H.265低。
4.方案选型
如果需要在浏览器中支持H.265编码标准，应该做哪些准备。
业界方案参考：下表所示为业界支持H.264等标准的方案参考。flv.js基于HTTP-FLV协议，解码方式为MSE软解。支持音频播放，支持H.264标准。不支持并且不打算支持H.265。libe265.js基于WASM H.265解码方案，H.265 C库基于libe265。现已支持视频播放，但不打算支持音频播放、流媒体等。
解码方案对比：MSE复用现有能力方面，如果要支持H.264，需要自行实现解码算法，获取H.264的视频数据，再重新编码为浏览器可支持的格式。如果要支持H.265也一样。WASM复用现有能力比MSE好很多。WASM可以将采用C/C++编写的一些库转化为浏览器可支持的WASM模块。因此只需要做非常少量改动甚至无需改动就能在浏览器中复用现有能力，例如FFMpeg。性能方面，MSE采用js对视频进行软解，因此性能一般。WASM性能中等，仍在优化。MSE可维护性非常差，每当新加一种编码就需要重新实现解码方式。WASM可维护性好。
最终方案：在业务场景中采用HTTP-FLV+WASM+FFMpeg+H.265解码方案。WASM是可在浏览器运行的高性能模块，可以采用传统强类型语言如C、C++等进行编写，再编译为浏览器可识别的高性能模块。FFMpeg为跨平台的音视频录制、转码解决方案。FFMpeg功能复杂，方案中主要利用其编解码功能。WASM浏览器支持情况如下图。用户可根据产品支持平台的需要等判断WASM是否适用。
三、播放器架构设计
1.直播通用架构
传统直播由主播到用户的链路架构如下图。主播开播、打开设备进行音视频采集、音视频编码、采用流媒体协议进行封装以在网络上传输、推向音视频服务。
2.FFMpeg核心编解码流程
3. H.265播放器解析、播放流程
解码器初始化后，会在解码线程中进行一定的流缓存，存储到一定量的数据后再将数据发送给解码器。否则解析过程可能出现问题。例如数据发送给解码器后，解码器首先需要确认数据的编码，第二确认音视频帧率，第三确认视频的宽、高，若缺少以上初始化信息，可能导致解码出错。接下来进行解复用。然后进行视频解码以及音频解码获取视频帧与音频帧数据。将音视频数据发送至浏览器播放之前，需要进行时间戳对齐，否则会导致音画不同步等问题。最后进行播放。
4.播放器整体架构
最底层：主线程，包括播放器实例、线程调度、数据中转以及统一的控制逻辑。
上一层：两个核心线程，包括IO线程以及解码线程。
中间层：播放器的核心环节，借助WASM以及FFMpeg对音视频数据进行解封装以及解码。
中上层：基于播放器的工具。例如在播放器中可能包括播放工具栏、用于展示流媒体信息的媒体面板。比如展示视频地区、宽高、帧率、码率等。
顶层：播放及渲染。
四、线上实践
1.数据验证
如下图，实验1为本地测试播放15分钟视频的平均CPU及内存占用分别为181.96MB以及34.98%。实验二为H.265与H.264观看同一直播间15分钟的对比情况。H.265占用流量减少30%左右。
2.典型问题
FLV规范如何支持H.265：
在FLV Tag中存在一个关键的CodeID字段，标识了FLV Tag中视频数据的编码。然而FLV规范中还未明确指出H.265应该采用哪个CodeID。目前腾讯云等用于标识H.265的CodeID为0x12。
音画不同步：每一个音频帧与视频帧都包含PTS信息，用于标识音频帧与视频帧应在哪一个时间进行播放。由于视频与音频分开播放，如果二者PTS不同、出现明显偏移，就会导致音画不同步。根据ITU的规范，设定Diff值为音频与视频PTS值差异。如下图，当Diff值在不同范围内，的音画差异可分为无法感知、可以感知、无法忍受等程度。当Diff值在-125ms至45ms范围内，可视为音画同步。故解决音画不同步问题由此着手。
第一种方案：音频帧与视频帧进行对齐，音频帧根据视频帧播放进度对齐播放。
第二种方案：视频帧与音频帧进行对齐，视频帧根据音频帧播放进度对齐播放。
人耳对流式音频更敏感，容易察觉到不连贯。人眼对视频帧刷新相对不敏感，不易察觉。故采用方案二。设置diff值为PTS（视频）-PTS（音频），当diff值在正负min值内，允许播放。当diff值大于max值或小于min值，丢弃音视频。当diff值处于min值与max值之间，说明视频帧解码速度较快，音频帧还未跟上，暂时缓存在本地，当解码完成后再进行播放。
五、未来展望
1.完善的WEB音视频播放能力
支持直播、录播；支持多种流媒体协议，如FLV、HLS、WEBRTC等；支持多种编码格式，如H.264、H.265、VP9、AV1等（AV1是VP9的升级版本，由包括谷歌、微软、腾讯等大厂商主导的规范）；支持扩展选项，如截图、滤镜等。
2.定制化能力
可根据使用场景选择、组合播放能力。抹平不同流媒体协议API之间的差异，开发者实现无缝切换播放方案。
