如何监控流服务

来源：Global Video Tech Meetup：Berlin 主讲人：Werner Robitza, Alexander Dethof 内容整理：彭峰 本文为 AVEQ 公司 CEO 和 CTO 的演讲纪要，演讲介绍了 AVEQ 公司的成就，并揭示了在视频服务质量衡量的过程中存在的问题及原因，最后对当前的视频服务质量衡量做出了总结。

目录

• AVEQ 的目标——You stream it, we measure it!
• 视频服务质量衡量
• 指标信息难以获取
• 进展与总结

AVEQ 的目标——You stream it, we measure it!

本文来自 Berlin Video Tech 的演讲“How to monitor a streaming service”，演讲者是 AVEQ 公司的 CEO Werner Robitza 和 CTO Alexander Dethof。CEO 首先介绍了 AVEQ 公司的情况，该公司的目标之一就是衡量流媒体的质量，让用户安心推送流媒体服务，具体体现在三个方面，即：

• 衡量 OTT 服务的质量，重点是视频流；
• 比较不同的供应商和平台；
• 开发一套用于质量分析的产品。

接着 CEO 介绍了一些现实中的案例，并说明为什么需要外部监控 OTT 服务的质量，如下图所示，当公司可以实现完整的服务环节时显然想要衡量服务质量非常容易，如果作为基准测试提供商（Benchmarking provider)或监控服务提供商（monitoring provider)，则需要其他信息，例如不同网络下的拥塞信息，ISP 网络上的服务质量等，从而对不同网络供应商进行对比。

从外部空间监控示意图

通常而言，许多机构都需要这些信息，例如政府或监管机构需要对视频和网络提供商进行监管；网络服务提供商需要与其他同行进行对比；大学需要相关数据进行研究。CEO 提到通常而言视频服务的质量衡量通常包含几个问题，下载这个视频需要多长时间?多长时间播放一次(即缓冲)?比特率/分辨率是多少?总的体验是什么?

CTO Alexander Dethof 介绍了 AVEQ 公司在进行视频服务质量监控方面了案例，在 2018 年到 2019 年，公司因为需要对德国的大型 OTT 视频流进行的拥塞研究，因此其开发了一套软件系统能够监控德国不同地区的流媒体服务情况并衡量其服务质量，并且研究三家主要 OTT 提供商和对五家主要 ISP 的性能和服务质量比较，此外也对来自 2000 用户的 40 万视频回放记录进行分析，最终构建在终端用户设备上运行的软件，并以相同的方式衡量服务。但是问题在于，如果从外部对服务质量进行评价，通常只能使用一些在 HTML 中的 API 返回信息进行衡量，这显然是不够的。

视频服务质量衡量

视频服务质量衡量需要多种信息，并不是单单在视频服务过程中使用一些监听组件收集到的信息就可以衡量的，而是需要非常多关于会话的信息，下图是一个衡量视频服务质量模型的示意图：

视频服务质量衡量模型

在过去 HTML5 视频很简单——只是一个指向 MP4 文件的 src，衡量起来比较容易，但是 MPEG-DASH 和 HLS 使其变得复杂，DRM / 加密媒体的使用更是使得服务质量衡量过程变得困难。自定义播放器实例化一个视频元素，播放器对象在 Javascript 中隐藏，尽管其不像 mp4 src 直接指示视频，但其依然可以抽象为视频元素，在播放相同的内容期间，视频元素会被替换多次；一些公司如 Netflix 会根据付费/基本账户为不同用户提供不同的视频元素，那么用户观看的视频是哪一个呢？为了对用户体验分析，就必须要弄清楚上述的问题。通常而言，可以通过事件监听器 (EventListener) 去收集用于分析的信息，但是在一些情况下，事件监听并不能正常工作，例如一些视频服务有些从不发送事件；有的则在开始时发送事件，但在几秒钟后停止，这使得并不能分析每一个视频服务。

指标信息难以获取

即使完整地收集到了一些可用的信息，那些信息也并不能真实代表用户体验。例如测量视频的加载时间时，不能简单地通过等待用户视频请求到来，然后测量播放事件发生的时间，通过时间差来衡量加载时间，对于用户来说，“主观的”加载时间可能要大得多!如果想要去衡量用户的体验，就应该使用用户真正看到的现象去衡量。

加载时间测量示意图

在获取真实获得的比特率（衡量服务质量的重要指标）时也存在许多的困难，对于 Webkit 浏览器引擎来说，可以使用其内置的 Video/Audio DecodedByteCount 工具来获取这一指标，但是现在主流的浏览器并不基于该引擎。一些替代的方法是检查请求清单、检查网络请求，但是几种方法都存在问题，第一种方法不能区分视频和音频，第二种方法的问题在于不能从 JS 内容中分离出想要的信息。并且比特率会由于视频内容的复杂度不同而出现较大的波动，与带宽并不相同，下图是 Dash.js 中的比特率和带宽不同的一个实例。

Dash.js中的比特率和带宽不等

除了加载时间、比特率外，还有一些关键信息的获取也是困难的，例如服务过程中使用的编解码器，视频编解码器不能作为 HTML API 的一部分导出，有时候可以通过在 JS 中调试播放器对象来获得它，或者可以解析清单；如果没有获取这个信息，则需要根据服务和浏览器做出假设。

针对指标获取困难的问题，人们开始思考能否有更通用的方式为他人提供衡量服务质量所需要的元数据，在 2011 年成立的 WHATWG HTML "Video Metric" 工作组在这方面进行了尝试，但其依然存在衡量标准不同的问题。

进展与总结

CTO 介绍了 AVEQ 在过去做出的一些成果：

• 监控不同的OTT视频服务（如下图所示）
• 测量与实际客户体验相关的参数，而不仅仅是CDN性能
• 构建了一个解决方案，可以衡量(几乎)任何使用 HTML 视频的视频服务
• 自动处理视频流媒体提供商使用的许多奇怪的东西，但个人调整和定期验证总是必要的

监控系统

通过上述的演讲，可以得到如下结论：

• 获取流数据是困难的，而且没有通用的解决方案；
• 真正需要的是一个适当的 API (MIME 类型，实际的比特率，…)；
• CDN 性能不是一切——用户视角很重要；
• 从用户视角出发去衡量服务质量；
• 服务质量衡量还有很长的路要走。

附上演讲视频：

http://mpvideo.qpic.cn/0bc3o4aagaaaeuabdtu6pnqva56dan3qaaya.f10002.mp4?dis_k=4e837565fe1b32343d3c94f658b1ba1d&dis_t=1638411326&vid=wxv_2150118675012517889&format_id=10002&support_redirect=0&mmversion=false