「视频直播技术详解」系列之七:直播云 SDK 性能测试模型

?关于直播的技术文章不少,成体系的不多。我们将用七篇文章,更系统化地介绍当下大热的视频直播各环节的关键技术,帮助视频直播创业者们更全面、深入地了解视频直播技术,更好地技术选型。

本系列文章大纲如下:

(一)采集

(二)处理

(三)编码和封装

(四)推流和传输

(五)延迟优化

(六)现代播放器原理

(七)SDK 性能测试模型

本篇是《视频直播技术详解》系列的最后一篇直播云 SDK 性能测试模型,SDK 的性能对最终 App 的影响非常大。SDK 版本迭代快速,每次发布前都要进行系统的测试,测试要有比较一致的行为,要有性能模型作为理论基础,对 SDK 的性能做量化评估。本文就是来探讨影响 SDK 性能的指标并建立相应的性能模型的。


影响视频质量和大小的重要参数

在进行测试之前我们需要明确几个对视频的质量和大小影响最大的参数:帧率、码率和分辨率。

1)如何制定帧率

一帧就是一副静止的画面,连续的帧就形成动画,如电视图象等。我们通常说帧数,简单地说,就是在 1 秒钟时间里传输的图片的数,也可以理解为图形处理器每秒钟能够刷新几次,通常用 fps(Frames Per Second)表示。每一帧都是静止的图象,快速连续地显示帧便形成了运动的假象。高的帧率可以得到更流畅、更逼真的动画。每秒钟帧数 (fps) 愈多,所显示的动作就会愈流畅。

2)如何制定码率

我们首先看视频编码的目的,它是为了在有限的带宽中传输尽可能清晰的视频,我们以每秒 25 帧的图像举例,25 帧图像中定义了 GOP 组,目前主要是有 I,B,P 帧三种帧格式,I 帧是关键帧,你可以想象它就是一幅 JPEG 压缩图像,而 B,P 帧是依靠 I 帧存在的,如果丢失了 I 帧,B,P 帧是看不到图像的,B,P 帧描述的不是实际的图像像素内容,而是每个相关像素的变化量,他们相对于 I 帧信息量会很小。GOP 组是指一个关键帧I帧所在的组的长度,每个 GOP 组只有 1 个 I 帧。

我们再来看,一组画面的码流大小跟什么有关?当视频编码的压缩方式都一样,清晰度要求都一样的时候,GOP 组的长度格式决定了码流的大小,例如:每秒 25 帧画面,GOP 组长度为 5,那么帧格式为 IBPBP,那么 1 秒钟有 5 个 I 帧,10 个 B 帧,10 个 P 帧,如果 GOP 组长度为 15,帧格式就是 IBBPBBPBBPBBPBB,那么 1 秒钟内会有 2 个 I 帧和 16 个 B 帧和 7 个 P 帧,那么 5 个 I 帧比 2 个 I 帧占用的数据信息量大,所以 GOP 组的长度格式也决定了码流的大小。

3)如何指定分辨率

分辨率概念视频分辨率是指视频成像产品所成图像的大小或尺寸。常见的视像分辨率有 640×480,1088×720,1920×1088。在成像的两组数字中,前者为图片长度,后者为图片的宽度,两者相乘得出的是图片的像素。

影响 SDK 性能的指标

有了上述的前置知识,我们可以开始准备测试 SDK 的性能了,我们首先分析一下都有哪些指标可以反映 SDK 的性能,分成 Android 和 iOS 两个平台:

Android

  • GC :可以通过 GC 日志记录,Mirror GC 和 Full GC 的频次和时间,Full GC 会造成比较明显的卡顿,需要评估
  • UI Loop 就是 VSync Loop :反映 SDK 对 App 流畅度的影响,理论上 60 fps 是最流畅的值。
  • Memory :反映 SDK 占用内存的大小
  • CPU Usage :反映 SDK 占用计算资源的大小

iOS

  • UI Loop :反映 SDK 对 App 流畅度的影响,理论上 60 fps 是最流畅的值。
  • Memory :反映 SDK 占用内存的大小
  • CPU Usage :反映 SDK 占用计算资源的大小

除了上面的一些系统级别的指标外,下面是直播 SDK 中特有的一些指标,这些指标可以反映出 SDK 的核心竞争力和一些主要的差异,涉及到视频的清晰度和流畅度,也是可以量化的。

1)影响视频清晰度的指标

  • 帧率
  • 码率
  • 分辨率
  • 量化参数(压缩比)

2)影响视频流畅度的指标

  • 码率
  • 帧率

3)其他重要指标

直播是流量和性能的消耗大户,有一些指标,直接影响了用户的感受,也是我们需要重点关注的:

  • 耗电量
  • 发热(不好量化,大部分情况发热和耗电量正比,可以使用耗电量暂时替代)

测试计划

测试过程需要先固化一些测试条件,然后根据不同的测试条件得出测试结果,这里选择了两个现在最常见的条件,是我们通过回访大量的客户得出的一些统计数字,可以反映大部分直播应用所处的场景。主要从分辨率、视频处理、码率和网络环境几个维度进行限制。
最后分为几个两种测试指标:客观和主观指标,前者反映了 SDK 对系统的消耗程度,但虽说是客观指标并不是说对用户没有影响、只是说得出的结果用户感受不明显。主观指标则会直接影响最终用户体验,但在传统的测试中反而容易被忽略,因为不好量化,这里拍砖引玉的提出一些量化的方式,希望引起读者的思考。

测试条件 A

  • 分辨率 480p
  • 无水印,无美颜
  • 码率 1 M
  • 网络保证在 0.5 M ~ 2 M

这个条件,反映了大部分低速网络情况下的使用场景,也反映了 SDK 基本的性能情况,可以作为 SDK 基本推流和拉流情况下的基准测试,不引入太多的测试依赖。

测试条件 B

  • 分辨率 720p
  • 无水印,有美颜
  • 码率 1 M
  • 网络保证在 0.5 M ~ 2 M

这个条件,反映了大部分客户的使用场景,具有较高的分辨率和美颜视频处理,可以作为 SDK 竞品分析的重要依据,测试结果非常接近真实场景。

1)客观指标测试计划
客观影响 App 稳定性和性能的指标:

  • Memory
  • 测试 10 分钟,内存曲线
  • 测试 1 小时,TP99,TP95,TP90,需要归档
  • 测试 1 小时,内存增量,考察是否有内存泄露,需要归档
  • 参考值:上次结果
  • CPU
  • 测试 10 分钟,CPU Usage 曲线
  • 测试 10 分钟,TP99,TP95,TP90,需要归档
  • 参考值:上次结果
  • 码率
  • 测试 10 分钟,TP99,TP95,TP90,重点说明,这里的码率控制需要分开来看,如果网络抖动造成码率降低,这样的点不计入进来,只测试 SDK 码率控制,需要归档
  • 参考值:1 M(大小都是偏差)
  • 耗电量
  • 测试一小时,记录进程总耗电量、屏幕显示耗电量、CPU 耗电量,需要归档
  • 参考值:上次结果

2)主观指标测试计划
主观影响 App 使用者的指标:

  • UI Loop App 本身可以达到的最大帧率,不同于视频帧率,统计他的原因是我们的 SDK 可能会影响整个 App 的流畅度,需要跟踪
  • 测试 10 分钟,UI Loop 曲线
  • 测试 10 分钟,UI Loop TP99,TP95,TP90,需要归档反复比较
  • 参考值:60 fps
  • Android GC
  • 测试 1 小时,记录 Mirror GC 和 Full GC 的频次,记录 GC 时长的 TP99,TP95,TP90,需要归档反复比较
  • 参考值:上次结果
  • 帧率(fps)
  • 测试 10 分钟,TP99,TP95,TP90,需要归档反复比较
  • 参考值:30 fps
  • PSNR 比较视频清晰度的指标
  • 测试 10 分钟,需要归档反复比较,这个指标可以使用固定视频作为输入。
  • 参考值:上次结果

3)结果显示

  • 表格显示具体指标
  • 曲线显示原始数据和时间轴的数据
  • 热图显示和参考值的偏差
  • 热图显示距离上次归档值是改善了还是恶化了

通过这种反复迭代的自动化的、系统化的测试,我们以职人之心近乎偏执地反复打磨着 SDK 的性能,只为给最终用户带来最好的直播体验,帮助我们的客户通过次时代的媒体最大化自己的商业价值,我们希望在您披荆斩棘的路上我们始终相伴。

本文作者:七牛云布道师@卜赫,原文可去七牛云官方博客查看。

时间: 2024-08-05 04:55:35

「视频直播技术详解」系列之七:直播云 SDK 性能测试模型的相关文章

「视频直播技术详解」系列之四:推流和传输

关于直播的技术文章不少,成体系的不多.我们将用七篇文章,更系统化地介绍当下大热的视频直播各环节的关键技术,帮助视频直播创业者们更全面.深入地了解视频直播技术,更好地技术选型. 在上一期中,我们介绍了讲解编码和封装. 本篇是<解密视频直播技术>系列之四:推流和传输.推流是直播的第一公里,直播的推流对这个直播链路影响非常大,如果推流的网络不稳定,无论我们如何做优化,观众的体验都会很糟糕.所以也是我们排查问题的第一步,如何系统地解决这类问题需要我们对相关理论有基础的认识. 本系列文章大纲如下: (一

PHP写在线视频直播技术详解

2016年7月22日 22:26:45 交流QQ:903464207 目前楼主专注php开发,最直接的方法就是使用lnmp去直接做,搜索以下资料,发现还是行得通的,先把基础架构列出来 前端页面 php 弹幕flash+js 数据来源是redis集群 及时聊天 redis集群 +js长连接 礼物系统 服务器流媒体 nginx-rtmp-module 在线调用ffmpeg对流媒体进行转码 基于HTTP的FLV/MP4 VOD点播HLS (HTTP Live Streaming) M3U8的支持基于h

技术详解:实现互动直播全过程

本文主要整理互动直播中各端的逻辑,重点是与前端相关的教师端IM的部分和Web/Wap学生端.希望通过这份整理,对于前端在维护时可以尽快的理解互动直播的流程,提高项目的可维护性:对于客户端和教师端来说,可以了解到前端提供的接口和消息的实现.也能提高对整个请麦过程的理解,便于联调和后期的定位问题. 相关阅读推荐 <连麦互动直播方案全实践1:什么是连麦互动直播?> <连麦互动直播方案全实践2:网易云信连麦互动直播方案的演变过程> <连麦互动直播方案全实践3:网易云信连麦互动的实现方

【H.264/AVC视频编解码技术详解】十一、H.264的Slice Header解析

<H.264/AVC视频编解码技术详解>视频教程已经在"CSDN学院"上线,视频中详述了H.264的背景.标准协议和实现,并通过一个实战工程的形式对H.264的标准进行解析和实现,欢迎观看! "纸上得来终觉浅,绝知此事要躬行",只有自己按照标准文档以代码的形式操作一遍,才能对视频压缩编码标准的思想和方法有足够深刻的理解和体会! 链接地址:H.264/AVC视频编解码技术详解 GitHub代码地址:点击这里 H.264中的条带(Slice) 1. Slic

【H.264/AVC视频编解码技术详解】十三、熵编码算法(3):CAVLC原理

<H.264/AVC视频编解码技术详解>视频教程已经在"CSDN学院"上线,视频中详述了H.264的背景.标准协议和实现,并通过一个实战工程的形式对H.264的标准进行解析和实现,欢迎观看! "纸上得来终觉浅,绝知此事要躬行",只有自己按照标准文档以代码的形式操作一遍,才能对视频压缩编码标准的思想和方法有足够深刻的理解和体会! 链接地址:H.264/AVC视频编解码技术详解 GitHub代码地址:点击这里 上下文自适应的变长编码(Context-base

【H.264/AVC视频编解码技术详解】十三、熵编码算法(4):H.264使用CAVLC解析宏块的残差数据

<H.264/AVC视频编解码技术详解>视频教程已经在"CSDN学院"上线,视频中详述了H.264的背景.标准协议和实现,并通过一个实战工程的形式对H.264的标准进行解析和实现,欢迎观看! "纸上得来终觉浅,绝知此事要躬行",只有自己按照标准文档以代码的形式操作一遍,才能对视频压缩编码标准的思想和方法有足够深刻的理解和体会! 链接地址:H.264/AVC视频编解码技术详解 GitHub代码地址:点击这里 1. H.264的CAVLC解析宏块残差数据的流

CDN技术详解及实现原理

CDN技术详解 一本好的入门书是带你进入陌生领域的明灯,<CDN技术详解>绝对是带你进入CDN行业的那盏最亮的明灯.因此,虽然只是纯粹的重点抄录,我也要把<CDN技术详解>的精华放上网.公诸同好. 第一章    引言    “第一公里”是指万维网流量向用户传送的第一个出口,是网站服务器接入互联网的链路所能提供的带宽.这个带宽决定了一个 网站能为用户提供的访问速度和并发访问量.如果业务繁忙,用户的访问数越多,拥塞越严重,网站会在最需要向用户提供服务时失去用户.(还有“中间一公里” 和

unity3d开发实战《啪啪三国》技术详解!

去年11月,上海火溶网络CEO王伟峰以其第一款3d手游产品<啪啪三国>为例,着重讲解了unity3D手机网游开发的经验,其中涉及了团队组成.人员要求.常见的unity3d开发遇到的坑及解决办法.在演讲中,王伟峰也贡献了<啪啪三国>开发过程中总结的各种经验,从优化.插件库.服务器架构.SDK等很多细节进行了讲解.值得一说的是,王伟峰现场演讲十分幽默,冷笑话段子不断爆出,让在场观众在连续的笑声中听完这个特别的技术演讲. <ignore_js_op> 以下是王伟峰现场演讲实录

[转帖]技术盛宴 | 关于PoE以太网供电技术详解

技术盛宴 | 关于PoE以太网供电技术详解 https://smb.pconline.com.cn/1208/12085824.html [PConline 干货铺]随着物联网技术飞速发展,需要提供网络服务的终端越来越丰富,使用传统强电的方式为多种多样的智能终端供电变得越来越困难,以太网供电(Power over Ethernet,简称PoE)技术的普及,正逐一解决各类智能终端的供电问题.目前PoE技术已经从传统的WLAN.网络监控.IP电话等应用场景延伸到新零售.IoT(Internet of