首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >关于音视频测试的一点建议

关于音视频测试的一点建议

作者头像
villainhr
发布2018-07-03 15:11:03
2.4K1
发布2018-07-03 15:11:03
举报
文章被收录于专栏:前端小吉米前端小吉米

作者:罗必达,腾讯音视频实验室质量平台组组长,高级工程师。早年在微软从事移动测试开发,先后参与了 Windows Live Messenger 和 Bing Mobile 两个项目的测试工作。2011 年加入腾讯,转型音视频技术研究,从事建立音视频技术测试体系的工作,并负责 QQ 音视频通话以及腾讯云互动直播 SDK 的底层音视频引擎的测试,在工作和研究中对音视频质量评估积累了丰富的经验。喜欢音乐和玩乐器,喜欢摄影,喜欢绘画,是个不折不扣的“文艺青年”。TLC 直播大会讲师之一。

从事音视频相关的测试工作也有将近5年的时间了,一路看着QQ音视频的发展,从当时只有几个人的小团队,到现在连续两年公司技术突破奖金奖,回想起来确实挺激动。好吧,自恋的东西少提为妙,进入正题。

为什么要写这篇文章

几年前我就想写这么一篇文章了,但是当时音视频在SNG乃至公司都是一块比较小众、相对独立的一个业务分支。随着SNG对音视频越来越重视,最近也有越来越多的团队线下找我咨询关于音视频测试的一些方法,我突然觉得,是时候把自己这几年对音视频测试相关的思考分享给大家了。当然也有自私的一面,因为音视频只是一种技术,应用非常广泛,而我们多年投身在实时音视频通信这其中一块分支上,难免会对整个音视频行业产生片面的认识,所以也想借此跟大家交流,让我们团队自身可以拓展一下知识面。

音视频测试测的究竟是什么

我觉得这个问题很重要。很多向我咨询音视频测试方法的同学,也许连这个问题都还没有想清楚(说得太直接,抱歉)。其实这不奇怪,说实话我也是最近才开始思考这个问题。音视频测试测的究竟是什么?

我思考这个问题的原因是,很多同学向我咨询音视频测试方法,但我却没办法给出一个明确的答案。脑海里把这5年的经验都翻了一遍,发现都无法找到可以满足他们的答案。最后终于茅塞顿开,原因是我们都没想清楚要测的是什么。

上文已经提到,音视频只是一种技术,应用面太广,并非但凡跟“音视频”这几个字眼沾上边的都可以用一套方法去解决,也就是说,没有“银弹”。

首先我们要问自己,我所负责的音视频业务究竟要测的是什么。是“音视频本身”的质量,还是“音视频周边”相关的东西。

这么说有点抽象,我还是举些例子吧。

例如我们这5年来一直负责的QQ音视频通话,学术一点来说就是实时音视频通话,因为音视频的内容是我们实时生成的,在传输过程中,为了保证通话的实时性,我们还需要对音视频的一些参数进行实时调控(例如分辨率、码率和帧率等等),以适应复杂的网络状况(注意网络状况是不断在实时变化的,之前看了很多公司内部关于网络相关的分享,大多数建立在静态分析上,这其实是不正确的,当然业务不同,关注点不一样)。所以我们要测试的就是“音视频的质量”。

好了,大家可能要问,还有不是测“音视频质量”的音视频测试吗?有的,我再举个例子。例如QQ空间里可能要播一个腾讯视频,这个视频已经在后台存好了,你没办法控制它的生成,也无法动态对它进行调控(即使可以调控,也是非实时调控)。在这种情况下,你测试的并不是“音视频质量”,而是“播放质量”,也就是我刚刚所说的“音视频周边”相关的东西。这类测试,跟大家平时测的其他非音视频需求没有太大的不同,唯一区别就是,可能对音视频相关知识的一些了解会对你设计测试用例带来一些帮助。

分析所测的音视频需求

刚刚说了一大堆,无非是想告诉大家,在接到音视频测试需求的时候,需要对其进行业务分析。我再重申一下刚刚的论点:

首先问自己,我所测试的是不是音视频质量

在解答了这个问题后,你可以进行业务分析了。

不同的业务,对音视频的要求是不一样的,相应的测试方法也不一样。我这里简单做一些归类:

  • 实时通话类业务

例如我们所负责的QQ音视频,就是这类业务。这类业务对实时性的要求很高。想象一下,你在跟家人聊天,在讲完一句话后,要在几秒后才能听到对方的反应,这是不可接受的。这就要求我们实时地根据网络情况,提供不同质量的音视频。例如,在链路带宽突降的时候,我们需要立刻感知到,并且尽快降低码率,以使得通话能够顺利进行(可参考网络带宽的水池效应,这时候如果我们还追求所谓的清晰度、流畅度,那其实是本末倒置的);当带宽恢复后,我们还要尽快地把码率提上来,以便用户得到清晰流畅的画面和声音。这些调整同样需要在其他网络损伤中进行,例如丢包(还分随机丢包和连续丢包)、抖动等等。

所以实时通话类业务的测试,我们更多地把关注点放在”流控策略“上面。

  • 异步通话类业务

异步通话类业务典型的代表是PTT。由于不需要根据网络进行实时调控(有点类似于传文件),所以这类音视频业务的音视频测试相对简单,只需要关注生成的语音音质和大小的权衡关系就行了(注意我只是说音视频测试,其他例如到达率等等的测试,那已经不是音视频测试的范畴了,下面几个分类也如此)。也就是因为这样,这种业务的音视频开发工作更多地是在选择合适的CODEC以及选择哪个码率(非实时选择)更优上。这种情况下,对用户在音质和流量的接受程度就至关重要了,当然,这种事情我个人认为应该产品经理来把握比较好(别跟我扯产品经理不需要技术知识)。

  • 一对多的秀场类业务

这类业务最近很火,最典型的就是全民直播(例如映客、花椒等等,一抓一大把)。这类业务的特点是对延时要求不高,但对清晰度和流畅度要求很高。也正是因为延时要求不高的特点,才可以把码率维持在高段,来做到高分辨率和高帧率(这是实时类无法做到的)。一般来讲,技术上都以RTMP来实现。

基于以上特点,这类音视频业务,重点就不是放在”音视频本身”的质量上了,而是其他体验了,比如说美颜、美白等等跟趣味相关的前处理上,还有频道进入的速度、切换速度等用户体验上。

另外必须要提一下,这类业务并非完全对实时性没有要求。例如教育,在一般场景下,确实是这种一对多的业务形态,但是,一旦有老师跟学生之间的交互,那么,保证一定的实时性也是必须的。所以,还是得看具体的业务形态具体分析。

  • 流媒体类业务

流媒体类业务是音视频技术的一个很重要的分支。作为常年从事通话类业务的我,或许没有太多资格来对这一块提建议。但因为这个部分是介绍不同业务的音视频测试特点,我还是有必要来讲一下流媒体这一个分类。

流媒体类业务相对通话类业务,有一个很大的不同,那就是用户之间基本上没有音视频层面的互动。广义上来讲秀场类业务也可以归为这一类。

同样,这类业务对实时性没有要求,音视频也是存储在后台的数据。音视频测试在这类业务上更多是关注编码或者转码的质量。这类测试由于可以使用很多全参考的工具(如PEAQ、PEVQ等),相对来讲会比较简单,甚至开发人员自己就可以对这一块进行测试了。

在传输层面,我不太清楚现在的流媒体业务会不会根据网络情况来动态转码(比如动态转分辨率和码率)。如果有,那这一块文章就大了。如果没有,只是静态地切换几个已生成的分辨率,那基本上也跟音视频测试没太大的关系了。

这类业务离不开下面要讲的另一类业务。

  • 播放类业务

我把QQ音乐和腾讯视频这种业务的客户端归类到播放类上(也就是说,不考虑服务器的内容生成或转码部分)。这类业务刚刚提过,测试的其实不是“音视频本身”的质量,而是播放器的质量。这类业务在传输方面,更多的是考虑缓存大小与实际体验(例如流畅性)的关系。

但是这里有一点要注意的,这类业务也并不是完全和音视频测试毫无关系,例如QQ音乐客户端有个音效相关的功能,这是后处理技术,也是需要一定的音视频测试。

。。。。。。

还有很多业务类型,就不在这里一一列举了。

也许上面的分类不一定准确,但这不重要,重要的是想希望大家在面对音视频相关的测试需求时,认真分析一下其特点,然后有所针对地进行测试。

需要什么知识

无论你是不是“真的在测音视频”,跟音视频沾点边的需求,都需要你具备一定的音视频基础知识。

当然这些知识没有办法在一篇文章里面讲清楚,所以仅在这里列举一下,大家可以根据自己的需求去学习。

音频知识

(基础篇)

了解术语:采样率、声道、码率、噪声抑制(NS)、回声抵消(EC)、增益控制(GC)、信噪比

了解CODEC:语音类CODEC、音乐类CODEC,以及他们之间的应用范围及区别

(进阶篇)

了解采样定理、心理声学模型、傅里叶变换、频谱

视频知识

(基础篇)

了解术语:分辨率、颜色空间(RGB、YUV等)、帧率、码率

(进阶篇)

了解人眼视觉系统特性,了解视频编码原理,了解帧类型(I帧、P帧、B帧)及参考关系

网络知识

(基础篇)

了解损伤类型:丢包(连续丢包、随机丢包;固有丢包、拥塞丢包)、延时、抖动

(进阶篇)

了解丢包恢复策略(FEC、重传)及其优缺点,了解Jitter Buffer及其影响,了解实时带宽预测算法

评测知识

无参考评估、全参考评估(PESQ、POLQA、PEAQ、PSNR、SSIM、PEVQ等)、MOS

其他

了解一些摄影相关的知识(例如快门、光圈、感光度),了解一些平台音视频相关的API(采集和渲染)

Q&A

这里把一些大家以前问到,或者可能问题的一些典型问题,抛出来给大家分享一下。

Q:清晰度高指的是分辨率高吗?

A:这个估计是很多非音视频专业的同学常常会搞混的两个概念。我这里先给出答案:分辨率确实会影响清晰度,但是两者没有绝对的关系。为什么这么说呢?抛开采集因素(例如摄像头没对焦)之外,这里还涉及一个因素:码率。我先假设这里大家讲的不是无损视频,那么必然涉及到编码。如果编码码率低,就算分辨率再高,单帧质量也会由于各种块效应显得很“脏”,就更不用提清晰度了。

Q:采样率对音质有什么影响?

A:首先要了解采样定理,即采样率必须高于输入信号最高频率的2倍,这样才能无失真地恢复原始信号或完整地保留信息。也就是说,8kHz的采样率只能表示0~4kHz频率的声音信号,而48kHz能够表示0~24kHz频率的声音信号。所以,如果要表示所有人耳能听到的所有声音(频率范围20~20kHz),就必须使用40kHz以上的采样率(常见的是44.1kHz和48kHz)。当然,采样率高了,意味着数据量就大了,编码后的码率也就高了。所以选择什么采样率,跟你的应用对高频的需求有多大。例如电话这种应用,目的是用于人与人的沟通,而人类的发声范围是100~3400Hz,所以8kHz基本上就能满足。QQ音视频用的是16kHz采样率,因为用户在满足沟通之余,还需要一定的所谓的真实感。

这个采样定理也可以用在视频上,比如上面所说的分辨率,实际上就是空间采样率,分辨率越高,能够表示的空间频率越大,也就是说可以表示更加复杂的纹理,所以一般情况下清晰度也就上去了。

Q:码率能再低些吗?

A:这是我最经常被问到的问题,特别是之前在跟手Q基础侧PK音视频流量的时候。这个问题其实不好回答,因为这里涉及到质量与码率的权衡关系。在相同的CODEC情况下,码率对质量的影响最大,降低码率,意味着就损失质量,而音视频质量却又是一个非常主观的东西。你很难证明目前的质量是否可以再降。因此QQ音视频只能在移动网络这种流量敏感的网络类型中,提供比wifi及有线网络质量稍差的体验,以减少流量的消耗。但是依然会被问,还能再低些吗?这个问题没有答案。

Q:我看你们的文档里经常有提到主观测试,有更高效的方法吗?

A:首先,我要强调一点,如果你是做音视频测试,一定不能排斥主观测试,哪怕效率低下。这是因为音视频质量本来就是一个很主观的东西。我举个例子,在可用带宽极低的情况下,QQ音视频能用的码率有限,在视频中,必然涉及清晰度和流畅度的权衡。如果这时你问不同的人,是希望保证清晰度还是流畅度,你肯定会得到不同的答案。ITU对主观测试有一些规范,也就是我们经常听到的MOS评分,这是最准确的测试方法。

但是主观测试确实很影响效率,这个毋庸置疑,所以业内也有很多人在研究客观评测的方法,例如PESQ等等,目的是使得这些工具评测的结果更加符合主观。

再来举个我们经常提到的一个悖论的例子。我们来说一下回声抵消的测试。目前我们回声抵消只有主观测试的方法,为什么呢?回声抵消算法的关键是区分一段语音近端信号和远端回声,然后进行消除。我们要测试回声抵消的效果,那么就需要一个判断回声是否被消除干净的算法或工具,咦,这不就是在做回声抵消吗?如果我的算法没有开发的算法好,那我肯定检查不出来是否有回声,如果算法比开发的好,那为啥开发不直接把我的算法用在回声抵消中呢?

Q:能否告诉我你的测试结果究竟是pass还是fail?

A:能,也不能。音视频质量的测试从来就不只有0和1的结果。音视频质量往往是在给定资源情况下的一种权衡结果(参考上面讲到的清晰度与流畅度)。所以这里要明确你的目标是什么,但这个目标不一定是“正确”的。如果拿捏不准自己的产品音视频质量是否已经达到最优,通过竞品对比分析也是一种很有效的解决方法,这也是很多产品在做性能优化时采用的手段

结语

好了,先写到这了。欢迎大家找我交流,也希望通过这篇文章,可以让大家了解到我们这个组平时都在做些什么东西 欢迎各位打扰。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-09-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 前端小吉米 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 为什么要写这篇文章
  • 音视频测试测的究竟是什么
  • 分析所测的音视频需求
相关产品与服务
实时音视频
实时音视频(Tencent RTC)基于腾讯21年来在网络与音视频技术上的深度积累,以多人音视频通话和低延时互动直播两大场景化方案,通过腾讯云服务向开发者开放,致力于帮助开发者快速搭建低成本、低延时、高品质的音视频互动解决方案。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档