zoukankan      html  css  js  c++  java
  • 实时音视频直播带货中影响用户体验的Bug根因

    VOL 131

    05

    2020-06

    今天距2021年209天

    这是ITester软件测试小栈第131次推文

    点击上方蓝字“ITester软件测试小栈“关注我,每周一五早上 07:30准时推送。

    微信公众号后台回复“资源测试工具包”领取测试资源,回复“21天打卡”一起学习成长,打怪升级。

    本文4476字,阅读约需12分钟

    Hi,大家好,我是CoCo。

    短视频市场的引爆下,直播带货似乎一下子成了2020年实现财富自由的最佳途径之一,前有李佳琦、罗永浩、薇娅,后有董明珠 、刘涛、李小璐。

    肉多狼更多,市场上从来不缺来抢蛋糕的狼人,无论素人、网红、明星,还是各路企业家们,甚至虚拟主播……在直播带货概念爆发后,都一窝蜂扑进来。

    作为一位在音视频相关领域被千锤百虐的卑微小测试,以下从音视频专项测试角度出发聊一聊实时音视频直播中影响用户体验的致命伤。

    音视频传输技术

    直播平台采用的音视频传输技术,通常有两种:CDN(Content Delivery Network,内容分发网络)和 RTC(Real-time Communications,实时音视频)。

    1

    CDN

    CDN 采用的是 TCP 传输,一般延时在 5-15 秒,也就是说,主播说话之后 5-15 秒,观众端才能听和看见主播说的内容。CDN 适用于对互动要求没那么高的直播场景,例如单主播直播、大班课直播、赛事直播、演唱会直播等。

    在老罗带货首秀直播中“还有 15 秒红包开抢!”,结果手机屏幕上显示已经进入最后 1 秒倒计时,好消息让人猝不及防,红包一个都没有抢到......

    是什么原因导致了抢红包翻车呢?是因为直播卡住了?还是因为手速太慢?

    其实是因为直播平台在单主播直播的时候,采用的是 CDN 技术,发红包的消息经罗老师口播 10 秒左右之后,观众才听到这个至关重要的抢红包提醒,这个时长是在 CDN 技术的正常延时范围内,但是对于竞争激烈的抢红包,吃瓜的我们确实是来不及准备的。

    众所周知,抢红包这件事情,抢得越多越好。但前提是,能抢到?

    2

    RTC

    RTC 技术采用了 UDP 传输,延时在毫秒级别,适用于强互动场景,比如直播连麦、直播PK、一对一教学、视频会议、音视频电话等。

    在直播平台,通常单主播直播用 CDN,在用到连麦和PK这种场景的时候,则会选择用 RTC。因为连麦和 PK ,通常是需要主播与主播、主播与观众之间的实时互动和深度沟通,别说 10 秒延时了,就算是 1 秒的延时都无法顺畅沟通。这个时候,RTC 技术就是不二之选。

    试想,如果罗老师口播提醒的同时,就能够实时听到”红包预警“,凭你的手速,会抢不到红包?

    当然,技术无优劣,关键看场景。重在观看可选 CDN ,重在互动则用 RTC。

    视频体验指标

    1

    帧率

    帧率(FPS )表示每秒显示的图片数,可理解为1秒钟时间里刷新的图片的帧数,也可以理解为图形处理器每秒钟能够刷新几次,也就是指每秒钟能够播放或者录制多少格画面帧率影响画面流畅度,帧率越大,画面越流畅;帧率越小,画面越有跳动感,也就是卡。

    由于人类眼睛的特殊生理结构,如果所看画面之帧率高于24的时候,就会认为是连贯的。高的帧率可以得到更流畅、更逼真的画面。

    董明珠直播首秀是在主持人陪同下选择“走播”的形式,将格力科技馆走了个遍,向观众一一介绍旗下产品,结果却遭遇“卡”字刷屏。原因之一是因解码、渲染能力跟不上而导致发生卡顿。

    2

    分辨率

    分辨率是指单位英寸中所包含的像素点数,决定了位图图像细节的精细程度,在计算机显示领域,我们也表示成“每英寸像素”(ppi)

    分辨率和图像的像素有直接关系。举个例子,一张分辨率为640 x 480的图片,那它的分辨率就达到了307200像素,也就是我们常说的30万像素,而一张分辨率为1600 x 1200的图片,它的像素就是200万。

    在一个固定的平面内,分辨率越高,意味着可使用的点数越多,图像越细致。

    3

    码率

    码率就是数据传输时单位时间传送的数据位数,一般我们用的单位是kbps(即千位每秒)。通俗一点的理解就是取样率或者比特率。单位时间内取样率越大,精度就越高,处理出来的文件就越接近原始文件。但是文件体积与取样率是成正比的,所以几乎所有的编码格式重视的都是如何用最低的码率达到最少的失真。

    视频组开发小哥哥一般通过优化编解码算法来优化码率,让主播可以在低码率下也保持视频清晰度不变,从而降低主播带宽的压力,让直播不仅看起来“好看”,而且不卡。

    4

    清晰度

    4K、1080p、720p,这些概念被各大电视机厂商炒作这么多年,相信地球人都懂。4K在互联网视频直播里现在还不普及,主要是对网络数据传输要求太高。1080p在一些对清晰度要求较高的场景如游戏直播里已经慢慢普及,要求的数据传输速率大约在4Mbps左右。720p是现在直播的主流清晰度,速率大约在1Mbps左右。在一些要求不太高的领域,还会有540p或者360p出现。清晰度决定看到的画面是清晰,还是模糊。

    在给定的码率下,清晰度和分辨率有关系。如分辨率过低,则画面模糊,细节丢失;如分辨率过高,则失真明显。在分辨率够用的前提下,分辨率和清晰度成反比。在分辨率一定的情况下,码率与清晰度成正比关系,码率越高,图像越清晰;码率越低,图像越不清晰。

    5

    流畅度


    如果在直播时出现卡顿、转圈,就意味着不流畅。主播和观众的连接通道好比一根水管,流量是有限的,因此如果清晰度提升意味着观众收看直播的流畅度有可能会下降。流畅度决定你看到的连续画面是否流畅,不会卡顿。

    在视频压缩的过程中, I帧是帧内图像数据压缩,是独立帧,视频序列中的第一个帧始终都是I帧。 在视频画面播放过程中,若I帧丢失了,则后面的P帧也就随着解不出来,就会出现视频画面黑屏的现象;若P帧丢失了,则视频画面会出现花屏、马赛克等现象。

    刘涛入职阿里担任“官方优选官”,花名“刘一刀”。直播现场又蹦又跳,分享自己的生活心得不说,为兑现观看人数破2000万的诺言,二话不说在直播间表演起倒立。其实在直播间突然涌入大量观众时,容易出现大范围的服务器资源过载,带宽资源瓶颈,就会导致音视频传输在服务器与服务器之间出现了高丢包,最终出现大范围的卡顿问题。然而作为一个秀场直播的APP,开发小哥哥可能更倾向于保证画面的质量,哪怕用户看得稍微卡一点,只要卡的画面还是美美的,用户也可以接受。如果在直播、视频交流场景下,开发者选择保证流畅,牺牲质量,即使画面出现局部马赛克。

    什么样的场景会相反呢?比如直播体育赛事,哪怕牺牲一些画面质量,也需要优先保证流畅度。试想如果在看直播的时候,隔壁老王已经在欢呼,而你看到的球画面还卡在空中,是不是会有摔手机的冲动?

    6

    首屏时间

    当观众进入直播间那一刻算起,到出现第一个主播画面的时间叫做首屏时间,这相当于整个直播生命周期的开始。为了保证直播流畅,会缓存一段数据之后再开始播放,但这个也不是绝对的。

    当进入直播间后,播放器会向CDN请求数据。此时,假设主播已经发送视频流数据到了第100帧,由于数据传输的一些延时,CDN端最新收到的数据可能在第90帧。当CDN接收到拉取视频流请求时,会往前回溯一段数据,在图中显示的是回溯2秒钟,那就到了视频流的第五帧。CDN会把第五帧开始往后的数据,通过RTMP或其他直播协议源源不断的发送到播放器。那为什么要往回2秒钟呢,这可能算是目前视频直播技术中一个比较有特点的技术优化,能用于很好地平衡流畅度和首屏秒开时间。

    音频体验指标

    1

    采样率

    采样率是指每秒从连续信号中提取并组成离散信号的采样个数采样率越高,音频听起来越接近真实声音。

    对于直播带货这类泛娱乐领域来讲,提升用户活跃、刺激变现是最主要的目标。从实现效果来讲,主播间的粉丝可以同时看到两个主播在连麦聊天,或边聊边唱。假设网络状态稳定不变,如果采样率越高、码率越高,音质就越好。但是相应单个采样信息量就越大,传输时间可能会相对更长。也就是说,高音质也可能会影响延时。

    2

    音质

    论音质好坏主要是衡量声音的音量、音高和音色三方面是否达到一定的水准,即相对于某一频率或频段的音高是否具有一定的强度,并且在要求的频率范围内 、同一音量下,各频点的幅度是否均衡、饱满,频率响应曲线是否平直,声音的音准是否准确,是否忠实地呈现了音源频率或成分的原来面目,音质的数值是由实际比特率决定的。回声、噪声、音质,都会影响用户的体验,导致音质不够清晰流畅。

    除了音质上的精确评分,一般还会从主观上测试3A引擎:AEC(回声消除),AGC(增益控制),ANS(噪声抑制)。

    3

    时延

    时延是指一个报文或分组从一个网络的一端传送到另一个端所需要的时间。它包括了发送时延,传播时延,处理时延,排队时延。一般,发送时延与传播时延是我们在测试时主要考虑的。时延与数据包长相关,通常在路由器端口吞吐量范围内测试,超过吞吐量测试该指标则没有意义。

    此前有过一个“李佳琦眼眶红了”的热搜,说的是李佳琦在直播间发红包,但是员工仗着延时优势抢红包遭网友吐槽,隔天员工在直播间流泪道歉,李佳琦在旁边递纸安慰,最后喜提”红眼眶“热搜第一名。

    网络指标

    1

    网络丢包

    网络瞬息万变,网络状态一般来说都是会伴随着丢包。其实对于通信来说丢包并不意味着真正的包丢了,只要包没有按时到达都可以理解为丢包,比如第一个包没有来,第二个包已经到了,此时第二个包发出去了,那么第一个包再来对我没有任何的帮助,实时通信不可能重来。

    通常来说晚上8点网络高峰期,这个时候网络传输非常上不稳定,在服务器和服务器之间经常容易产生丢包。第二是不同的运营商之间,比如电信和联通之间,当联通向电信传输数据时,由于两个运营商出口带宽结算问题,不在高峰期都可能不太稳定。还有一个问题就是,小运营商,比如教育网,机房的状态不是一直稳定的,可能会产生丢包。

    既然丢包问题这么常见,开发小哥哥用哪些办法来解决这类问题呢?通常有这四种方案:FEC前向纠错)、PLC(基于后端的抗丢包方法)、ARC(自动码率控制)、ARQ(自动请求重传),还有一个是编码器。ARC和ARQ,都是针对网络状态进行调整的策略,但是它们俩应用的场景不一样。对于音频来说,无论是语音还是音乐,码率通常需求比较低,尤其是语音,此时ARC的应用场景并不是特别大。

     

    比如董明珠首秀采用边走边播的方式,信号频繁切换,带来的问题就是在移动的状态下,信号的强弱变化让网络不稳定,数据传输会容易出现丢包,而弱网对抗是基于 TCP 协议直播无法很好解决的问题,直接导致直播爆卡问题。

    2

    网络抖动

    网络抖动,是指数据包的到达顺序间隔发出时不一致。比如说,发送100个数据包,每个包间隔1s发出。结果第27个包在传输过程中遇到网络拥塞,造成包27不是紧跟着26到达的,而是延迟到87个包才送达。在直播中,这种抖动的效果实际上跟丢包是一样的。因为不能依照接收顺序把内容播放出来,否则会造成失真。

    网络抖动,会造成播放延时对应增大。如果网络中抖动较大,会造成播放卡顿等现象。 

    当把目光放在更长远的国际市场时,无论是音视频直播平台,还是在线教育、游戏、社交等领域在未来几年都将迎来视频点播市场的巨大增量据全球市场观察公司于5月31日发布的《视频点播市场需求预测报告》指出,视频点播(VOD)行业的市场估值有望在2026年达到1750亿美元所以,对于专业的音视频测试的需求也有望进一步打开浪奔,浪流吧,后浪。

    今日问题

    如果你是用户,你认为音视频直播软件最重要的特质是什么? 

    (欢迎在留言区发表你的看法)

    留言福利:

    抽取截止至6月8日留言点赞最多的一位幸运er,可获得:Docker微服务架构与实战

    (幸运er名单将在下周一推文的置顶留言处公布)



    以上


    That‘s all

    更多系列文章

    敬请期待

    ITester软件测试小栈

    往期内容宠幸

    1.Python接口自动化-接口基础(一)


    2.Python接口自动化-接口基础(二)


    3.Python接口自动化-requests模块之get请求


    4.Python接口自动化-requests模块之post请求


    5.Python接口自动化之cookie、session应用


    6.Python接口自动化之Token详解及应用


    7.Python接口自动化之requests请求封装


    8.Python接口自动化之pymysql数据库操作


    9.Python接口自动化之logging日志


    10.Python接口自动化之logging封装及实战

    想获取更多最新干货内容

    快来星标 置顶 关注

    每周一、三、五 07:30见

    <<  滑动查看下一张图片  >>


     后台 回复"资源"取干货

    回复"21天打卡"一起打怪升级

    测试交流Q群:727998947

    点亮一下在看,你更好看

  • 相关阅读:
    python学习第三 天-字典
    购物车
    python学习第二天-字符串
    python学习第二天-元组
    git 工作流中的 Sourcetree 和命令行操作对比
    服务端推送通信技术及其优劣势
    关于立即调用的函数表达式(IIFE)
    序列化和反序列化
    mac 使用 brew 安装 nginx 及各种命令
    前端安全问题之CSRF和XSS
  • 原文地址:https://www.cnblogs.com/ITester520/p/13203286.html
Copyright © 2011-2022 走看看