基于WebAssembly的H265播放器

1. 基于WebAssembly的H.265播放器器腾讯前端⾼高级⼯工程师陈映平(程序猿⼩小卡) 1

2. 陈映平 (程序猿⼩小卡) 腾讯⾼高级⼯工程师，IVWEB团队负责⼈人之⼀一对前端性能优化、Node.js、⽹网络协议等有较为深⼊入的理理解。活跃于技术社区，多次参与⾏行行业技术⼤大会分享，著有开源电⼦子书《Nodejs学习笔记》。 2

3. 分享⼤纲 1. ⽅方案背景介绍 2. ⽅方案选型 3. 播放器器架构设计 4. 线上实践 5. 未来展望

4. ⽅案背景介绍 4

5. 直播⾏业概况语⾳音直播 2003 2008 秀场直播 2011 PC聊天室⼤大混战移动直播 2015 2014 2016 垂类直播直播元年年

6. 直播⾏业成本⽀持内容带宽薪酬

7. ⾼昂的带宽成本流量量计费⽅方式：峰值带宽计费假设业务峰值带宽20G，⼀一年年带宽费⽤用 ≈ 0.58 * 20 * 1024 * 365 = 435W

8. ⾼昂的带宽成本带宽⽀支出(百万) 220 同⽐比增⻓长率(%) 66.8% 210.5 70% 195.7 174 161.6 165 169 52.5% 42.1% 110 35% 21.5% 21% 55 17.5% 8.3% 0% 2018 Q3 2018 Q4 2019 Q1 ⻁虎⽛牙直播带宽⽀支出情况(百万) 2019 Q2 2019 Q3

9. 需要什么直播⽅案延迟成本性能扩展性

10. ⽅案选型 10

11. 常见直播协议 RTMP HLS HTTP-FLV RTMP HTTP HTTP FLV H264 AAC .m3u8 .ts H264 AAC FLV H264 AAC 延迟是否私有协议插件⽀支持 HTTP-FLV 2~5S（适中）否 flv.js √ HLS 10S+（⾼高）否 hls.js X RTMP 1~3S（低）是 flash X { 流媒体协议 { 编解码器器

12. 视频编码简述视频的构成视频视频帧视频帧视频帧视频帧切⽚片视频帧视频编码视频帧分块视频切⽚片视频切⽚片视频切⽚片视频切⽚片压缩视频帧 (压缩后) 视频帧

13. 为什么视频编码很重要例例⼦子：540*960 的视频，每秒15帧，1分钟的数据量量 540 * 960 * 8 * 3 * 15 * 60 / 8 / 1024 / 1024 = 1334Mb ⼀一帧⼀一秒⼀一分钟（bit）

14. 为什么视频编码很重要 1、视频编码主要做什什么：压缩视频尺⼨寸编码类型视频原始尺⼨寸压缩后尺⼨寸压缩率 H264 1334Mb 11Mb 120倍 2、带宽费⽤用： < 1%

15. 视频编码技术的发展 ISO/IEC 废弃，没有发布 ISO/IEC + ITU-T ISO/IEC + ITU-T MPEG-1 MPEG-3 H.264 H.265 1992 1994 ? 1998 2003 2012 MPEG-2 MPEG-4 VP9 ISO/IEC ISO/IEC Google H.264/AVC：MPEG-4 Part 10 H.265/HEVC：MPEG-H Part 2 2013 MPEG：ISO/IEC Moving Picture Experts Group VCEG：ITU-T Video Coding Experts Group JVT：Joint Video Team

16. 为什么选择H.265 H265特点视频画质更更⾼高压缩效率更更⾼高码率要求更更低同⼀一个视频流量量对⽐比 MPEG-4 H.264 H.265 10 20 30 40

17. 为什么H.265压缩⽐更⾼ H.265 H.264

18. H.265问题浏览器器⽀支持情况差

19. ⽅案参考 1、业界⽅方案参考⽅方案流媒体协议解码⽅方式⽀支持⾳音频⽀支持H.264 ⽀支持H.265 是否打算⽀支持H.265 flv.js HTTP-FLV MSE 是是否不不打算⽀支持 libe265.js ⽆无 WASM 否否是已⽀支持 2、解码⽅方案对⽐比复⽤用现有能⼒力力性能可维护性 MSE 需实现解码算法⼀一般差 X WASM 复⽤用现有能⼒力力(FFmpeg) 中好 √

20. ⽅案选型 1、最终⽅方案： FLV + WebAssembly + FFMpeg + H.265 2、FFMpeg：跨平台的⾳音视频录制、转码解决⽅方案 3、WebAssembly：可在浏览器器运⾏行行的⾼高性能模块； 4、WebAssembly浏览器器⽀支持情况

21. 播放器器架构设计 21

22. 直播通⽤架构 RTMP ⾳音视频服务流媒体封装 FLV(H264/ACC) ⾳音视频编码 H264/ACC ⾳音视频采集主播（开播） HTTP + FLV(H264/ACC) 流媒体解封装 H264/ACC ⾳音视频解码 YUV / PCM ⾳音视频播放观众（收看）

23. FFmpeg核⼼编解码流程 IO Demux Decoder Filter Encoder Mux

24. H.265播放器解析、播放流程

25. 播放器整体架构 Renderer - Main Thread 视频渲染⾳音频播放 Utilities - Main Thread 播放⼯工具栏媒体⾯面板性能统计性能/异常监控 Decoder (WebAssembly + FFmpeg +C) 解码缓存解复⽤用 FLV 视频解码⾳音频解码 H265 / … AAC / … Decoder Thread IO Thread 解码器器加载解码调度流加载流缓存控制器器⾳音画对⻬齐 IO控制器器流检测 Player - Main Thread 播放器器实例例线程调度数据中转统⼀一控制

26. 线上实践 26

27. 数据验证测试机器器：MacBook Pro (2017) 处理理器器 4.2 GHz Intel Core i7 内存 16 GB 2400 MHz DDR4 实验1：播放15分钟，CPU和内存占⽤用平均内存占⽤用平均CPU占⽤用 CPU波动内存占⽤用波动 181.96MB 34.98% 19% - 59% 122.4M - 236.23M 实验2：同⼀一个直播间，H265 vs H264，播放15分钟编码类型播放时⻓长流量量⼤大⼩小 H265 15min 138MB H264 15min 197MB ——流量量减少30%

28. 问题：FLV规范如何 ”⽀持” H.265 FLV Header FLV File Body PreviousTagSize0 Tag1 PreviousTagSize1 Tag2 CodeID：0x12 . . . 标准规范：Video File Format Specification Version 10

29. 问题：⾳画不同步偏移过⼤大会导致『⾳音画不不同步』解码播放流程视频解码视频帧(pts) 视频流播放器器时间戳同步⾳音频解码播放⾳音频帧(pts) 潜在问题：PTS(视频)、PTS(⾳音频) 偏移导致⾳音画不不同步 • 考标准：Rec. ITU-R BT.1359-1 • 参考值：Diff值 = pts(⾳音频) - pts(视频）可以感知⽆无法忍受可以感知⽆无法感知⽆无法忍受 Diff值 -185ms -125ms +45ms +90ms

30. 问题：⾳画不同步⽅方案：视频对⻬齐⾳音频 • ⼈人⽿耳对流式的⾳音频更更敏敏感，容易易察觉到不不连贯 • ⼈人眼对视频帧的刷新相对不不敏敏感，不不易易察觉 A A A A A pts(⾳音频) Master Clock (m-clock) diff = pts(视频) - m-clock Shipin min < diff < max P P p p pts(视频) 参考：播放器器技术分享（3）：⾳音画同步 min- <= diff <= min sleep(diff - min) 渲染 diff < -min || diff > max 丢弃

31. 未来展望 31

32. 未来展望⼀一、完善的WEB⾳音视频播放能⼒力力 1.⽀支持直播、录播； 2.⽀支持多种流媒体协议：flv、hls、webrtc等； 3.⽀支持多种编码格式：h264、h265、vp9、AV1等； 4.⽀支持扩展选项：截图、滤镜等；⼆二、定制化能⼒力力 1.可根据使⽤用场景选择、组合播放能⼒力力； 2.抹平不不同流媒体协议API之间的差异，开发者实现⽆无缝切换播放⽅方案

33. Thanks 33