背景
目前QQ直播的观众用户众多,在不同网络环境等客观因素下,特别是在移动网络中,观看体验还有很多细分项有待提升。在移动网络、弱网、不稳定网络等情况下,直播播放出首帧的速度非常慢,观看直播过程非常卡顿,不流畅,用户体验差。网络波动,会造成视频帧接收不及时,直播时延增大,造成多人连麦等互动性强的玩法体验大大下降。基于这些现状,开展了QQ直播观看端播放体验优化专项,针对首帧、卡顿等问题,逐个分析解决,提升用户体验。
目标
测试发现在正常网络下,QQ直播和竞品APP的播放体验效果一致。但是在弱网环境下有很大差距,QQ直播播放质量有很大的提升空间。
测试方法:
播放5分钟,统计首帧时长、卡顿次数与卡顿总时长。
优化目标:
提升在弱网下首帧速度、流畅度等指标。
降低播放卡顿率,卡时间占比。
名词解释:
首帧耗时 = 首帧渲染时间戳 - 点击进房时间戳
卡时间占比% = 卡顿时长 / 播放时长
卡顿率% = 卡顿次数 / 播放次数
空间直播功能还在内测,目前只有部分有权限的用户可以开启直播功能,没权限的用户不能发起直播。首先,请大家确保自己手机上安装的QQ空间应用App为最新版本,将App更新为最新版本之后,点击首页面中的“+”按钮。接下来,在打开。
优化效果
解决:一般QQ直播不能播放多是与代理上网、防火墙、播放器版本、网络速度等有关。请检查是否安装了Windows Media Player 9或更高版本,如果没有,请安装。安装后如问题依然存在,请检查您是否使用了代理上网,如果是,则QQ直播目前只支持SOCKS。
注:1Mbps网络下测试播放卡顿效果示意图
QQ直播播放首帧耗时从30秒优化到平均3秒,效果提升了10倍。
播放5分钟的卡顿次数,从平均卡顿次数为24次,降低到平均4次,卡顿次数降低了6倍。
1、用户首先需要更新QQ空间客户端到最新版本,才能进行直播。2、平台不允许直播色情、暴力反动等内容,违反规定会暂时被系统剥夺直播权限。3、网络不佳,不能达到直播要求。4、您的帐号处于危险情况,可以联系直播间客服解决问题。
播放5分钟的卡顿时长,qq怎么直播,从90秒降低到25秒,卡时间占比从平均29.43%,降低到5.33%,卡顿时长降低了3倍以上。
优化前:
不能直播的原因是没有直播权限。无法进行QQ空间直播的具体原因:一、空间直播功能还在内测阶段,目前不是所有的用户都有直播权限。二、没有直播权限不能开启直播,只有部分用户有直播权限。QQ直播的简介:一、简要概述:1.腾讯。
注:弱网优化前数据,弱网播放QQ893版本的播放性能数据表(2022-08-01)
优化后:
注:弱网优化后QQ898版本的播放性能数据表(2022-08-26)
企业回私域直播就是将私域流量和直播相结合的一种形式。私域直播平台首推映目直播,支持企业专属定制直播,适用企业会议直播,电商直播,活动直播,培训直播等应用场景。映目直播是北京韦尔科技有限公司研发的企业直播营销平台,提供视频、照片、图文。
优化方案
一、测试环境与测试方法
使用网络损伤仪设备,搭建了弱网环境,对QQ直播、多款竞品直播APP等产品的首帧、卡顿情况进行测试;
设置弱网环境:1Mbps 延时85ms
二、收集测试数据
测试方法:从大厅页点击进房,测试首帧播放速度,播放5分钟,测试5分钟内视频的卡顿次数与卡顿时间。最后从9组测试数据中求平均得出。
三、 测试结论
弱网下,从大厅页进入直播间,播放出首帧的耗时远远高于竞品,有很大的优化空间。
前3分钟QQ直播卡的时间更多。
播放卡顿体验:其它直播APP的卡顿次数和总时间最小,播放最流畅,体验最好;和其它直播对比,整体卡顿率虽然略微高于其它直播,但其它直播平均卡顿时间基本在1秒左右。
分析问题
QQ直播播放全链路分析
播放器拉流、解码、渲染的链路流程图
经过上述流程分析,我们发现播放卡顿的问题点可能出现在以下环节。
一、开播推流码率不一致问题
在大型活动的直播间,如果将10Mbps的原始流下发,会造成网络带宽的需求急剧升高,同时对于移动网络和弱网的用户,观看流畅度将下降,卡顿率升高。因此通过转码服务器,统一转码模块,将视频流转码为多个不同档位的直播流,来满足不同网络状态的用户需求。
在QQ直播有17个不同的观看入口,每个入口的下发直播地址需要做档位处理。
二、CDN回源问题分析
根据直播监控平台查询,发现QQ直播的域名没有开启异步鉴权的问题。
注:红框中标记的“LiveAuth正常返回”,“首次” 两个步骤处理时间超过900ms,正常情况耗时小于100ms
根据直播监控平台查询回源链路,发现CDN的内部存在回源慢的问题。
注:回源耗时超过10秒,这个是CDN内核偶现问题导致的异常
根据直播监控平台查询回源链路,发现CDN的内部存在回源慢的问题。
注:回源耗时超过1700ms,由于主播数据不稳定导致首帧慢
根据直播监控平台查询回源链路,发现CDN吐流很快但客户端首帧耗时超过6秒。
为排查这类问题,在客户端增加了播放流量上报,每2秒采样一次,30秒上报一次当前周期内的流量开销,协助排查首帧慢的问题。
注:某现网用户访问直播房间的网络采样图,通过上图可以发现网速是逐步攀升上去的,看着有些不太正常。
流量上报的实现原理:
在ThumbPlayer 收流模块中获取到播放器“当前缓冲大小”,通过计算单位时间内的缓冲增量,可以得到“当前网速”,最终按照一定频率上报到服务器,上报格式如下。
字段
含义
time
起始时间戳
freq
频率(实例中2秒采用一个,可配置)
net_data
网速数据数组KB/s
cache_data
缓存数据数组KB
cache_duration
缓存的可播放时长ms
report_time
最佳答案 QQ空间无法直播一般有三个原因:1、开启直播是需要权限。目前QQ空间将会不定时开放直播权限,当有直播权限后,可以开通空间直播。没有直播权限的用户无法开启。
采样30秒个点(可配置)
三、播放器缓冲策略分析
经过反复测试验证,在播放器参数和策略方面存在以下差异点
名词解释:
分辨率自适应:不同网络状态下,播放器自动播放对应档位的清晰度,保证直播流畅度。
首缓策略:首次播放时拉取的直播流大小。
二缓策略:出现卡顿时,播放器需要拉取的数据大小,才开始播放。
预加载策略:为加快直播间的首帧速度,提前使用播放器拉取直播流数据,准备首次播放需要的数据。
优化前QQ直播点击进房预加载所需流量网速如下
优化前QQ直播上下切房预加载所需流量网速如下
从上图可以看出以下问题:
预加载网络开销较大,按照QQ直播的码率计算,12秒时长的字节大小为6MB,计算方法:字节大小 = 时长 * 码率 / 8
在弱网下,没有足够的网络带宽来支持蓝光档位的视频流播放,从这个点来看,弱网下需要降低播放档位。
预加载数据过多,默认预加载12秒视频数据原因:ThumbPlayer配置的最小缓存大小为4秒,开启了追帧后,PlayerCore会默认调整缓存大小为最小缓存的3倍,即12秒缓存,因此这里会预加载12秒的视频数据,预加载数据过长的问题也需要解决。
四、协议栈分析-直播流编码信息
QQ直播流编码信息
目前QQ直播的直播流都是H264编码格式,秀场直播间是20FPS帧率,游戏直播间是30FPS帧率。
竞品直播的码流信息
通过抓网络包等方式,分析视频流的编码信息、帧率、码率等信息。
root过的手机:tcpdump -i wlan0 -w 1.pcap
抓取播放过程的网络包:
找到网络包中的FLV直播流数据,FLV视频流是以“FLV”开头
将数据回包保存为FLV文件,将该文件放至到flvAnalyser中进行解析,即可得到媒体信息
其它直播1和其它直播2,都有H265编码格式。
码流信息分析结果
从对比的媒体数据来看,其它直播1和其它直播2,都使用了H265编码格式,同分辨率下,码率更低。因此QQ直播也可以通过下发H265直播流,来进一步降低直播流的码率。
解决问题
一、解决上述问题的措施
在大厅页,开发测试模块,检测当前网速状态,是否为弱网。
根据网络评估结果,大厅页优先选择播放低码率的视频,提高首帧的播放速度。
根据网络评估结果,决定大厅页是否要自动播放。
根据网络评估结果,决定直播间内是否需要做直播间预加载。
降低标清直播流的码率,当前标清码率为800Kpbs,在1Mbps无法稳定播放,结合清晰度适当降低码率。
当前预加载数据过长,需要解决预加载数据过长问题。
下发H265的视频流,进一步降低播放端的码率带宽要求。
播放器增加IP上报,监控CDN节点是否有聚集性拉流失败问题。
CDN开启异步鉴权,对比同步鉴权,减少CDN回源时长,加快拉取首帧数据的速度。
二、实施技术方案
网络测试模块与MSF测试模块开发,评估网络状态。根据网络状态,判断当前网络状态是否支持预加载播放、已经适合播放的档位。
2. 根据网络状态、判断当前网络是否支持大厅页自动播放,弱网下关闭播放可以提高收发业务信令的速度。
3. 根据网络状态选择对应的清晰度,以及是否支持房间内的预加载。
4. 整体的弱网策略根据Toggle动态下发,根据灰度效果调试出最优的配置参数。
5. 预加载数据过长处理方案,在开始预加载时,启动定时器查询缓存的数据大小,在预加载数据大于4秒(4秒可以配置),暂停下载。等用户播放该直播间时,再恢复下载。
6. CDN回源慢问题监控,对播放器解析连接CDN的IP地址进行上报,开启CDN的异步鉴权功能。对异常CASE实时提醒,实时跟进。
7. 竞品直播都支持H265视频下发预加载,因此QQ直播也进行H265解码验证与测试,灰度测试H265直播流。下发H265的编码视频流,蓝光的码率下降了35%,标清码率下降37.5%。整体码率大幅度下降,在弱网下播放的流畅度更高,同时也节省带宽成本。同时验证了在各个业务场景下的H265解码情况,目前各个场景都是解码正常的。
三、最终效果与数据
整体数据对比:
IOS端部分测试数据:
Android端部分测试数据:
出处: