请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 0
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

1、前言


本文接上篇《腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》,继续腾讯公司分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。

每年年初腾讯公司都要制定 SNG 成本优化年度目标,过去三年已经用技术手段为公司节省了超过 10 亿的现金流。产品的架构和容量也越来越健康,继续成本优化变得十分艰难。

但我们在迷茫中仍然定下了再优化 3 亿元的目标。很幸运,2017 年我们实现了这个目标,并再次获得公司级奖励,这是非常不容易的。因为“成本与质量”是个平衡木,而 2017 年 SNG 产品面临着激烈的内外竞争,要降低产品质量是根本不可能的。所以本次文章跟大家分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。

腾讯SNG社交网络事业群介绍:
11.png

腾讯SNG社交网络事业群(Social Network Group,简称SNG)是腾讯七大事业群之一,成立于2012年5月,以QQ和QQ空间为基础平台打造全方位的互联网综合服务。在腾讯大体系中,SNG是很重要的基础平台,也是腾讯产品线中用户量最多的事业群。


2、系列文章


因文章太长,本次分享分为两篇来讲,本文是2篇文章中的第2篇:


相关技术文章:


本文将主要围绕有关图片的优化和带宽压缩方面的内容,请继续往下阅读。

3、关于作者


a.jpg
范晶晶:“我是来自腾讯 SNG 社交网络运营部,简称 DSNO(屌丝 NO.1)团队的一枚大龄女屌丝。”
腾讯高级工程师,08年进腾讯做资源管理和预核算,现在主要从事成本优化工作,为SNG优化项目PM。

4、点播类小视频的流量优化思路


4.1冗余下载


原来 QQ 空间的小视频播放没做任何限速,一旦开始播放就会以用户最快的速度进行下载,一个小视频文件长度大约 80s,在正常网速下不到 20s 就可以下载完成,但往往用户并没有完整看完每个视频,数据显示空间用户的平均播放时长是只有 23s,下载但没有播放的视频浪费了用户和企业的流量。

这种情况很普遍,比如 QQ 音乐里也一样,一首歌平均时长接近 4 分钟,高品质音质文件大小是 9M,下载完一首歌只需要 4s 不到,但经常发生刚听完前奏感觉不对胃口就切歌了。

还有一种场景,在QQ里的长视频(大于 10s)需要先全部下载完才能播放,用户在对话框里收到一个视频,点击后往往要转菊花,等下载完一点开发现其实已经看过或并不感兴趣,这种情况还浪费了用户宝贵的时间,体验更不好。

4.2QQ 空间小视频限制下载速度


对空间的小视频控制下载速度,先尝试限制下载永远只比播放多 40s,卡顿率在1.2%,然后将 40s 改为 20s,卡顿率上升到 2.1%,持续验证,最后调整在 20s。如果用户网速太差,发生二次缓冲则不限速。

4.3QQ 长视频实施边下边播


针对 QQ 的长视频启用边下边播策略,用户点击视频后先全速缓冲 20s 然后再以文件码率进行下载,看一秒下一秒,关闭播放就停止下载。不需要等下载完才能播放,用户平均等待时间从 12.6s下降到了 1.77s 左右,极大地提升了用户体验。现在边下边播已经成了腾讯视频业务的标配,措施完成后,冗余下载比从 65% 下降到 35% 左右。

1.jpeg

4.4空间小视频历史优化策略


关闭自动播放:
过去 2 年空间小视频播放量一直在上涨,造成外网带宽流量也一直上涨,17 年以前已经做的优化手段有“高峰期关闭自动播放“(用户点击才播放,但现在来看只要在WiFi 环境下自动播放用户体验更顺畅,所以也切回去了)。

限制大文件转发次数:
分析下载日志文件大小,有很多大于 1G 以上的文件,这种大文件往往是盗版电影,产品不希望空间是传播盗版电影的平台,所以限制了大文件转发次数。

提高安全打击准确率和及时率:
小视频的头部效应非常明显,少量热点视频就占播放量 50% 以上。当时传播比较火的有色情暴力和搞笑,针对色情暴力提升安全打击的准确率和及时率。

降码率:
搞笑的很多都是小猫小狗,场景比较简单,当时我们认为这类视频流畅比清晰度更重要。所以可以适当的降低清晰度(码率),于是系统根据热度,对每小时 TOP2000的热点视频后台压缩出低码率进行播放,节约了大量的带宽。

2.jpeg

4.5空间小视频H.265技术选型


码率太低,质量变差:
码率是数据传输时单位时间传送的数据位数,同一种编码格式下码率越高越清晰,当时空间热点视频码率压缩到 300kps,不到现在普通手机拍摄的 1/3。码率降到肉眼可识别的程度后用户体验就会变差。但业务持续上涨,需要既节约带宽又保障质量,所以考虑使用新一代视频编码标准 H.265 来提升压缩率。

新一代编码标准H.265:
H.265(又名HEVC)是 2013 年 ITU-T VCEG 继 H.264 之后所制定的新的视频编码标准,仍然是采用块的编码框架,块的大小从 16*16 变大为 64*64,但对比 H.264 创造性采用四叉树架构,以及采用编码单元CU、预测单元PU,变化单元 TU,极大地提高了压缩效率,帧内预测方向从 9 个扩展到 35 个,获得更好的预测特性,相比H.264压缩率提升 40%。

16年当时公司没有业务尝试,除了专利风险外,由于H.265计算复杂度远高于H.264,编解码都需要硬件在性能上支持。

4.6硬解码与软解码


解码有硬解和软件两种,硬解码是使用播放设备(手机和电脑)的硬件解码,比如通过专用的DSP内核解码芯片的功率更低,解码效率更高,现在支持硬解码的手机比例大概在 70%。安卓客户端复杂,不确定是否支持解码。

不具备专用硬件就只能通过软件利用 CPU 解码,软解由于要妥协解码设备的通用性,所以算法上对效率和质量有折扣,相比硬解更耗时,容易造成手机发热和耗电。

微信占用户耗电排行很高,对发热和耗电量都极为敏感,就不适合软件方案。视频普遍比较短才十几秒的话,解码耗时也会影响用户体验。

我们看 QQ 空间是怎么做的?空间在后台搭建转码能力,客户端维护一套自动更新的机型库,综合 H.265 的不同分辨率对不同手机性能进行自动打分,并动态更新,数据显示 95% 以上的手机是支持H.265软解,于是先上线软解方案,并开发了一套云适配的后台兼容方案,可以根据不同的客户端请求尽量给用户下发最适合的码率(高、中、低),尽量让更多人用到。

硬解比软解能减少用户终端 CPU 占用、降低系统开销、减少耗电和发热,所以现在要做软硬结合。经过一整年的运营,整体H.265播放占比从 8% 提升到现在的 30%,压缩比最高 40%。卡顿率没有下降,反而提升,用户体验更流畅。

3.jpeg

5、实时音视频聊天的流量优化思路


QQ 会议视频混音:
视频里还有一种场景是实时音视频通话类,比如 QQ 会议视频,以往会都是有几个人同时说话,接收方就接收几路音频,然后在客户端进行混音操作。混音是把多种来源的声音整合至一个立体音轨或单音音轨中。

客户端混音改为后台混音:
所以如果能够在服务端将一个房间所有的用户声音先混成一路再下发话将大大减少我们和用户的下行带宽,实际上线后节省近 50% 带宽。

节省混音计算资源:
另外,由于混音比较消耗计算资源,一方面对混音编码性能进行优化,一方面对用户的房间数进行性价比分析,对房间数 3 以下的不混音。

质量跟踪:
优化过程中也通过质量评分系统,对用户质量进行监控。质量随着混音灰度逐步微升。

6.jpeg

6、实时音视频直播的流量优化


下图是企鹅电竞正在直播的一场吃鸡,可以看到房间在线人数非常高,清晰度有高清、超清和蓝光,带宽成本一直很高。
111.jpeg

今年春节期间 NOW 直播的答题业务非常火,每天晚上 8 点会在指定房间出题,观众答对可以瓜分每天 100 万的奖金,最高峰值有 90 万观众同时在线,假设平均码率1M,峰值会有 900G 的带宽,成本非常高。
222.jpeg

SNG直播业务很多,根据每个产品不同特点,分别做了不同的优化。

空间直播是熟人社交,房间人数普遍很少,低于 10 人,小房间走 OC 回源率非常高,浪费 CDN 分发资源,所以使用IP直连方式。

NOW 直播的房间稍大(一般数十人到数百人不等),但音频走的DC带宽,OC带宽单价是 DC 带宽的 1/2 还低,所以就推进 DC 转 OC。

前面分享了点播类视频使用 H.265 编解标准节省 40% 的带宽和存储,直播由于实时性要求更强,所以结合 GPU 提高转码性能,GI1(2 块卡)的转码性能是普通24核的CPU 的 9 倍,但采购价格仅是普通 CPU 的 1.6 倍。

分析企鹅电竞的房间大小,Top300的大主播占据了 61% 的用户,考虑转码资源性价比,只对 Top300 的主播进行H.265优化。几万元采购 GI1 设备,可节约成本 600万元/年的带宽,也为非 WiFi 环境下的用户节约了流量。

和点播不同,大主播的设备和网络比较好,一般采用主播上行推2路流,一路H.264 (考虑低端手机硬解能力),一路 H.265。小房间考虑到主播上行带宽限制和转码计算成本,就只出一路 H.264.

NOW 直播答题房间主播同时推 H.264 和 H.265 两路流可以节约总体 30% 带宽,可优化力度很大。

333.jpeg

7、精细化码率优化


带宽优化案例还有很多,结合产品特色各有千秋,就不一一列举了,下面我们看一下现在视频优化的方向。

动态码率:
码率控制有三种:恒定码率(CBR)、平均码率(ABR)、动态码率(VBR),一般使用的平均码率。但平均码率有很多弊端。

根据预测用户网络质量变化:
不同的用户网络质量不同,同一个用户网络质量也会发生变化。所以可以对用户网络质量变化进行预测,如果用户网络要变差,则下一帧切换到低码率流。

根据内容分类:
不同的视频内容需要的码率是不同的,比如体育NBA类就比连续剧需要的码率高,可以在视频上传时进行标签分类,然后给与不同的编码参数,腾讯视频使用这个策略后整体码率节约 10%。

根据场景不同:
但同一个视频里也会出现不同的场景,比如打斗需要的码率要比风景高,可利用深度学习对场景进行分类,在转码时给与不同的编码参数。

根据ROI特征提取,对人眼感兴趣区域重点编码:
人眼一般对人物特别是人脸区域的注意力要大于其他区域,比如看下图是斗鱼一姐冯提莫的直播画面,可以对人脸重点编码、对人身体和衣服次重点增强、对其他区域适当减弱的策略来转码。

自适应分辨率:
动态码率是在用户网络条件允许的情况下,找编码码率的最优解,而如果用户网速限制,但又想为用户提升清晰度的话,可以用自适应分辨率的方式。在相同播放窗口下(显示分辨率相同),相同码率下不同编码分辨率的质量PSNR是不同的,所以在固定码率和显示窗口下,有最佳编码分辨率。比如用户选择高清,用户带宽限制码率在1.2M,在这个基础上可以找到适合用户网速的最佳编码分辨率进行编码。

8、总结一下


结合这些实际案例,带宽优化归纳为一小两少三不变。文件压缩的更小,下载次数少,冗余下载少,质量不变。

常用的管理和技术手段有很多如下饼图:
aaa.jpeg

在优化过程可以运用五部曲:

  • 1)厘清资源消耗构成,在哪些场景,有多少入口,给资源使用建模;
  • 2)对资源消耗 TOP 模块抓大放小,先解决主要矛盾;
  • 3)对架构和算法实现庖丁解牛,了解产品策略,了解技术选型的背后的原因和业界动态;
  • 4)产品策略和技术双管齐下;
  • 5)产品形态和业界技术可能每个月都会有新的变化,所以动态运营持之以恒。

bbb.jpeg

业务运维还有一个非常痛苦的场景就是做预算,利用精细化成本管理思路为产品做带宽预测和优化模型,因为数据会变化,所以可以采集数据,系统自动统计带宽的预算和合理性分析。

333.jpeg

附录:微信、QQ技术文章汇总


[1] QQ、微信团队原创技术文章:
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)
微信团队分享:微信移动端的全文检索多音字问题解决方案
腾讯技术分享:Android版手机QQ的缓存监控与优化实践
微信团队分享:iOS版微信的高性能通用key-value组件技术实践
微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?
腾讯技术分享:Android手Q的线程死锁监控系统技术实践
微信团队原创分享:iOS版微信的内存监控系统技术实践
让互联网更快:新一代QUIC协议在腾讯的技术实践分享
iOS后台唤醒实战:微信收款到账语音提醒技术总结
腾讯技术分享:社交网络图片的带宽压缩技术演进之路
微信团队分享:视频图像的超分辨率技术原理和应用场景
微信团队分享:微信每日亿次实时音视频聊天背后的技术解密
QQ音乐团队分享:Android中的图片压缩技术详解(上篇)
QQ音乐团队分享:Android中的图片压缩技术详解(下篇)
腾讯团队分享:手机QQ中的人脸识别酷炫动画效果实现详解
腾讯团队分享 :一次手Q聊天界面中图片显示bug的追踪过程分享
微信团队分享:微信Android版小视频编码填过的那些坑
微信手机端的本地数据全文检索优化之路
企业微信客户端中组织架构数据的同步更新方案优化实战
微信团队披露:微信界面卡死超级bug“15。。。。”的来龙去脉
QQ 18年:解密8亿月活的QQ后台服务接口隔离技术
月活8.89亿的超级IM微信是如何进行Android端兼容测试的
以手机QQ为例探讨移动端IM中的“轻应用”
一篇文章get微信开源移动端数据库组件WCDB的一切!
微信客户端团队负责人技术访谈:如何着手客户端性能监控和优化
微信后台基于时间序的海量数据冷热分级架构设计实践
微信团队原创分享:Android版微信的臃肿之困与模块化实践之路
微信后台团队:微信后台异步消息队列的优化升级实践分享
微信团队原创分享:微信客户端SQLite数据库损坏修复实践
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)
微信Mars:微信内部正在使用的网络层封装库,即将开源
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]
微信团队原创分享:Android版微信从300KB到30MB的技术演进
微信技术总监谈架构:微信之道——大道至简(演讲全文)
微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]
如何解读《微信技术总监谈架构:微信之道——大道至简》
微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]
微信异步化改造实践:8亿月活、单机千万连接背后的后台解决方案
微信朋友圈海量技术之道PPT [附件下载]
微信对网络影响的技术试验及分析(论文全文)
一份微信后台技术架构的总结性笔记
架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
快速裂变:见证微信强大后台架构从0到1的演进历程(二)
微信团队原创分享:Android内存泄漏监控和优化技巧总结
全面总结iOS版微信升级iOS9遇到的各种“坑”
微信团队原创资源混淆工具:让你的APK立减1M
微信团队原创Android资源混淆工具:AndResGuard [有源码]
Android版微信安装包“减肥”实战记录
iOS版微信安装包“减肥”实战记录
移动端IM实践:iOS版微信界面卡顿监测方案
微信“红包照片”背后的技术难题
移动端IM实践:iOS版微信小视频功能技术方案实录
移动端IM实践:Android版微信如何大幅提升交互性能(一)
移动端IM实践:Android版微信如何大幅提升交互性能(二)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
移动端IM实践:iOS版微信的多设备字体适配方案探讨
信鸽团队原创:一起走过 iOS10 上消息推送(APNS)的坑
腾讯信鸽技术分享:百亿级实时消息推送的实战经验
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事:
技术往事:微信估值已超5千亿,雷军曾有机会收编张小龙及其Foxmail
QQ和微信凶猛成长的背后:腾讯网络基础架构的这些年
闲话即时通讯:腾讯的成长史本质就是一部QQ成长史
2017微信数据报告:日活跃用户达9亿、日发消息380亿条
腾讯开发微信花了多少钱?技术难度真这么大?难在哪?
技术往事:创业初期的腾讯——16年前的冬天,谁动了马化腾的代码
技术往事:史上最全QQ图标变迁过程,追寻IM巨人的演进历史
技术往事:“QQ群”和“微信红包”是怎么来的?
开发往事:深度讲述2010到2015,微信一路风雨的背后
开发往事:微信千年不变的那张闪屏图片的由来
开发往事:记录微信3.0版背后的故事(距微信1.0发布9个月时)
一个微信实习生自述:我眼中的微信开发团队
首次揭秘:QQ实时视频聊天背后的神秘组织
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)下一篇:一文读懂Https的安全性原理、数字证书、单项认证、双项认证等

本帖已收录至以下技术专辑

推荐方案
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部