丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
本次演讲由腾讯高级工程师陈映平为大家介绍基于WebAssembly的H.265播放器，以及在NOW直播中的应用。本次主要介绍采用WebAssembly制作音视频H.265播放器的整体思路、播放器架构设计以及线上实践。
演讲嘉宾简介：陈映平（程序猿小卡），腾讯高级工程师，IVWEB团队负责人之一。
内容：直播内容成本包括聘请优质主播等花费。薪酬：企业员工薪酬成本。带宽：根据部分上市公司（例如虎牙）的统计材料，带宽成本比重大约为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%，这是虎牙直播带宽成本优化的结果。
直播行业在技术选型时需要考虑如下因素。延迟：互动延迟会影响用户体验，解决直播互动延迟问题十分重要。成本：内容、薪酬、带宽等成本。性能：关键指标包括音视频播放时的CPU占用、内存占用、卡顿、帧率等。扩展性：音视频直播行业出现至今，音视频编解码领域飞速发展，经常发布更新编解码协议。如果播放器架构扩展性设计不好，一旦编解码协议更新或替换，就可能需要重构播放器架构，于业务方而言是难以承受的。
RTMP、HLS、HTTP-FLV都有各自的应用场景。HLS：HLS在移动端使用非常多，是苹果主导的一个规范。HLS的特点是可以自适应码率以及带宽状况。例如可以根据手机的网络情况自动切换到不同的码率，可以使用户在4G、3G等不同网络条件下正常观看直播。RTMP：Adobe公司的私有协议，特点是延迟比较低。RTMP的缺点，首先作为私有协议，协议细节部分为黑盒，出现问题时难以排查。第二是RTMP使用的不是标准80端口，会导致一些问题。例如一位直播观众需要在校园网环境观看直播。众所周知校园网络有各种保护措施，如防火墙等会屏蔽一些非标准端口。此时不适合使用RTMP观看。RTMP协议较适合做推流。例如主播需要在直播间里进行直播，那么可以采用RTMP进行推流。即将直播流采集后上传到服务器，然后给用户观看。HTTP-FLV：协议栈与RTMP相似。HTTP-FLV与RTMP内部数据封装都基于FLVTag。HTTP-FLV的延迟介于RTMP与HLS之间。同时HTTP-FLV使用的是标准的HTTP协议，端口是80标准端口，网络穿透性较好，因此一般在观看端会采用HTTP-FLV。过去几年，由于浏览器不支持FLV的原生播放，许多时候需要借助Flash播放器进行播放。bilibili出品的flv.js，采用MSE解码播放的方式达到对HTTP-FLV的支持。
由于流量的重要性，需要降低视频对带宽的占用。如下图，视频是由一个一个的视频帧构成的。例如每秒播放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-4Part10中定义的。2012年由谷歌主导的VP9发布，其被定位为下一代的视频编码解决方案。VP9在H.264基础上进一步压缩视频带宽的占用，目标是提升50%左右的带宽。目前国内VP9的应用相对较少。2013年ISO与ITU联合发布H.265，相较于H.264进一步提升了带宽。
特点：首先在相同码率条件下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.264等标准的方案参考。flv.js基于HTTP-FLV协议，解码方式为MSE软解。支持音频播放，支持H.264标准。不支持并且不打算支持H.265。libe265.js基于WASMH.265解码方案，H.265C库基于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是否适用。
传统直播由主播到用户的链路架构如下图。主播开播、打开设备进行音视频采集、音视频编码、采用流媒体协议进行封装以在网络上传输、推向音视频服务。
最底层：主线程，包括播放器实例、线程调度、数据中转以及统一的控制逻辑。上一层：两个核心线程，包括IO线程以及解码线程。中间层：播放器的核心环节，借助WASM以及FFMpeg对音视频数据进行解封装以及解码。中上层：基于播放器的工具。例如在播放器中可能包括播放工具栏、用于展示流媒体信息的媒体面板。比如展示视频地区、宽高、帧率、码率等。顶层：播放及渲染。
如下图，实验1为本地测试播放15分钟视频的平均CPU及内存占用分别为181.96MB以及34.98%。实验二为H.265与H.264观看同一直播间15分钟的对比情况。H.265占用流量减少30%左右。
FLV规范如何支持H.265：在FLVTag中存在一个关键的CodeID字段，标识了FLVTag中视频数据的编码。然而FLV规范中还未明确指出H.265应该采用哪个CodeID。目前腾讯云等用于标识H.265的CodeID为0x12。
第一种方案：音频帧与视频帧进行对齐，音频帧根据视频帧播放进度对齐播放。第二种方案：视频帧与音频帧进行对齐，视频帧根据音频帧播放进度对齐播放。人耳对流式音频更敏感，容易察觉到不连贯。人眼对视频帧刷新相对不敏感，不易察觉。故采用方案二。设置diff值为PTS（视频）-PTS（音频），当diff值在正负min值内，允许播放。当diff值大于max值或小于min值，丢弃音视频。当diff值处于min值与max值之间，说明视频帧解码速度较快，音频帧还未跟上，暂时缓存在本地，当解码完成后再进行播放。
支持直播、录播；支持多种流媒体协议，如FLV、HLS、WEBRTC等；支持多种编码格式，如H.264、H.265、VP9、AV1等（AV1是VP9的升级版本，由包括谷歌、微软、腾讯等大厂商主导的规范）；支持扩展选项，如截图、滤镜等。
可根据使用场景选择、组合播放能力。抹平不同流媒体协议API之间的差异，开发者实现无缝切换播放方案。