来源：Global Video Tech Meetup：Milan 主持人：Andrea Fassina 演讲者：Behnam Kakavand, Alexey Malikov 整理：李昊勇 这次会议主要包含四个主题：WebAssembly 作为网络播放的可能性；一个视频 DRM 系统的工作原理；基于实时边缘记录和 CMCD KPI 的视频监控面板；OTT/IPTV 视频内容传输质量的提升。本文将介绍其中的第一段和最后一段演讲。
目录
- 开场
- 展望未来：WebAssembly 或成为网页播放的一种方式
- OTT/IPTV 视频内容传输质量的提升
开场
会议由来自 videodeveloper.io 的 Andrea Fassina 主持。他首先回顾了上一期（6th Milan Meetup）中的内容：直播、数据质量、可交互体积视频以及智能编码，并简介了本场会议的其他三位嘉宾：来自 Evolution 的 Behnam Kakavand、来自 Akamai 的 Luca Moglia、来自 Elecard 的 Alexey Malikov。
展望未来：WebAssembly 或成为网页播放的一种方式
这段演讲（1:37-17:21）的主讲人 Behnam Kakavand 是 Evolution 公司的首席视频工程师，从 2010 年他就开始从事视频点播和直播行业。
实时视频现在处于行业的核心位置，为了产生并交付实时视频内容，演讲者搭建了他们自己的视频平台，来为浏览器、安卓提供视频内容。他使用 Websocket 来连接安卓和浏览器，端到端延迟在 1.5-3s 内，并使用 MSE(Media Source Extensions) 来进行播放。而在 Iphone 平台上则使用的是 HLS，延迟在 3.5-7s 的范围内。由于这项技术的场景是用户与推流端的频繁交互，延迟是十分关键的。
什么是 WebAssembly
WebAssembly，也就是 WASM，是一个跨平台二进制标准的用于在任何浏览器、设备、平台上运行预编译的代码的平台。预编译代码也就意味着是优化过的，低延迟的代码。相比于 JavaScript，有着 3-4 倍更好的运行速度方面的表现。同时你也可以自由地选择它的后端语言，如 C，Rust，Go 等。这就意味着你在范围非常庞大丰富的开源库里进行选择，并将他们作为新的功能加入你的浏览器应用里。
为什么使用 WASM 播放器
演讲者选择 WASM 来开发他们的播放器主要有以下原因：
- 希望在全平台上都保持流和延迟等服务内容的一致性。
- 为了有更直接地访问到解码函数，获得一个全局的控制，包括缓存控制、丢包和丢帧控制等功能。
- 更直接地管理对于各种编解码器的支持，以及对传输协议的选择。
- 苹果的 LL-HLS 可以把延迟控制在 2s 的范围下，但仅此而已。而演讲者的延迟目标在 1s。
- WebRTC 在编码器方面受限，必须要使用基础配置文件，导致了更大的质量和带宽需求。
使用浏览器自带功能
演讲者继续介绍了浏览器自带的一些功能。HTML5<video> tag 会获取源 URL 地址并控制整个 pipe 视频流，然而对播放不同部分它的控制范围却是有限的，并且在不同的浏览器上，HTML5 的部署都存在着一些不同，更为麻烦。MSE(Media Source Extension) 会整合输入源并控制播放的几乎所有部分。
使用自定义部分
演讲者介绍了播放器中自定义的部分：WASM 和 WebGL。WASM 可以配置任意的视频编解码器、可以有自定义的缓存控制来达到低延迟播放，也可以自由选择传输协议。由于 WASM 使用的是软件编解码，没有硬解码加速支持，导致其耗电会更高一些。且由于要传输的是整个更大的包含编解码的二进制代码，因此传输的内容大小也会更大。WASM 还可以使用各类开源的编解码器，如 VP9 和 AV1，这类编码器并不是在所有浏览器上都被支持的。而 WebGL 则可以用于个性化渲染以及色域空间管理等。
接下来演讲者介绍了播放器的工作流程。首先他们使用 Emscripten 编译的基于 C 的解码器库，并基于这些库去编译他们的播放器。JS 导入 WASM 文件并用于同步，输入字节缓存并读取像素缓存，最终通过 WebGL 渲染像素。他还展示了编译 libav 所使用的 emscripten 的配置。
WASM 播放器组成
关于 WASM 播放器的组成部分，如上图所示。其中主线程在运行在播放器上的 JS 的前端线程，用于给用户进行交互操作。另一个线程里的 WebSocket 用于操作传输协议，以及另一个线程 WASM Decoder 用于解码视频流。
当前的结果
演讲者最后展示了他们的播放器延迟效果，可以看到只有 0.9s 的端到端稳定延迟，而他们当前的产品播放器延迟有 1.8s。此外还有无缝的自适应码率切换功能，可以在 iOS，Android 和桌面环境上运行。
演讲者将来的计划包括了使用共享向量内存，使用 WASM SIMD，离屏桌面和音频类别组来进一步提升性能，也就能进一步能够优化电池消耗。此外进一步减小播放器包大小也是一个优化方向。
OTT/IPTV 视频内容传输质量的提升
本段演讲（38:26起）的演讲者 Alexy Malikov 是 Elecard 公司的工程师。
要提升服务质量，首先就需要监测当前的传输质量，因此就需要一个分布式监测方案。通常来说分布式监测包含几个部分：一个中心服务器和分布式的客户端应用或者硬件。在网络中需要这样的监测方案是因为在 OTT/IPTV，通常（包括供应商）有多个用户端，由于他们供应的内容常常会因为被卫星上传或下载过程中被改变质量，便需要一种方法来得知最终接收到的质量状态。
接下来演讲者介绍了几种真实遇到的场景和对应的解决方案。
Case1: 用户的信号被遮挡，TV 画面在广告插播时卡死
Case1
演讲者安装了两个探测器，一个在转码拼接器之前，另一个在 DVB 调制器之前。其中在转码部分监测到的码流没有问题，而在后面的调制器监测到视频流的参数与主视频流参数不同。这是一种很经典的错误，称为“视频信息变化事件”。
从他具体展示的监测画面可以看到，是由于广告画面比例为 16:9，而先前播出的视频内容为 4:3，部分用户设备无法直接适应这个变化，也就导致了视频流的卡死，影响了观看体验。
Case2: 视频流完全无法被用户进行接收
Case2
在这个案例下，内容分布式网络包括了卫星链路，并且已经有探测器安装在多处，包括解调器后和转码器后。通过检测发现，卫星解调器会时不时地不正常工作。
在检测画面可以直观地看到在解调模块不工作时，会直接没有波形的显示。而解决方案也很简单：直接将整个解调模块更换即可。
Case3: 客户端播放器停止工作
Case3
这里是一个很大的供应商在为城市的各个区域提供业务。演讲者安装了非常多的探测器，包括在转码分发，以及在 CDN 前后，甚至是各个区域级的 CDN 前后都有安装探测器。在一些区域的 CDN 边缘，演讲者探测到有些 HLS 广播片段丢失，且下载速度过低无法满足实时需求。
在监测画面可以直接看到规律的波形在一些片段的空白，就是 HLS 片段丢失的结果。
Case4: 电视信道不可获取或严重受损
Case4
在这个场景下，演讲者在转码前，卫星调制器前和卫星解调后，端到端都安装了探测器，并观察到在传输层上有大量的数据错误丢失。
在监测画面可以看到传输的包到达间隔，丢包率的变化，在一天的相同时间会发生信号的丢失。在经过调查后他发现这是由于两个卫星之间的信号干扰导致的，最后通过更改卫星的调制频段解决了问题。
Case5: 用户订阅端没有声音
Case5
演讲者在供应商侧转码器的前后以及用户端 DVB 解调器的后面设置了探测器，而在转码器前的信号输入的探测器上，发现了音频信道的 PID 丢失。
而在监控图上可以清晰地看到音频信号丢失，没有它的负载包。因此这个问题回报给了供应商后便迅速得以解决了。
Case6: 一个供应商的画面卡顿
Case6
在此演讲者在转码器前后以及 CDN 后设置了探测器，而在转码器前的数据就有很大问题。
在监控图上可以更明显地看到转码器的信号没有办法成为输入，导致了画面的冻结，即使在之后信号恢复了，转码器还是没有办法回到正轨。最后直接通过更换了转码器模块来解决了这个问题。
附上会议视频：
http://mpvideo.qpic.cn/0bc3veaasaaalqamebxtvbqvbkodbguqacia.f10002.mp4?dis_k=4d0100fe20fc264759d75f81606847f6&dis_t=1645152790&vid=wxv_2244374462395793417&format_id=10002&support_redirect=0&mmversion=false
