写点什么

腾讯会议如何构建实时视频传输算法架构,来实现用户体验质量最优?

2021 年 1 月 17 日

腾讯会议如何构建实时视频传输算法架构,来实现用户体验质量最优?

一、腾讯会议的架构为优化 QoE 服务


    腾讯会议总体的架构比较大,主要分成左边和右边两部分。左边是腾讯会议的主体,包括四个 PC/Android/Mac/iOS 的客户端以及后台,右边是通过转码服务器连接的外部服务。


    我们知道业内很多同行可能用的是 WebRTC,但腾讯会议不是。腾讯从 QQ 时代过来,在音视频实时传输系统的搭建和优化上有很多年积累。腾讯多媒体实验室基于这些积累,重新编写了一个跨平台而且高效的引擎-xCast。这里面的网络传输层被称为 Pere, 它其实是一种飞的比高铁还快的神鹰的名字。



    今天讲的着重涵盖 Pere 这部分, 搭建 Pere 架构围绕 QoE 最优化。QoE 是什么? 说 QoE 就不得不说 QoS, QoS 一般来说是指单独的网络指标,比如延迟、丢包率、用户可用带宽等,这些是用来侧面反映当时的网络和系统的质量。


    QoE 指的是用户在终端上实际体验到的质量。它其实主要依赖线下用户主观测试,获取意见来得到的。但是在线上做优化的时候,实际上没有时间和条件来搜集用户的实时反馈,所以现在有很多的算法和模型,尝试通过一些指标侧面衡量 QoE 大概的水平,然后针对性地来做优化。腾讯会议架构的一切都是为了优化 QoE。



二、在影响 QoE 的指标之间取舍

 

    QoE 包含信号质量和交互性两个方面。信号质量指视频和音频质量,也就是用户实际上看到这个媒体的时候,觉得它的流畅度、清晰度怎么样的,还有它跟源信号的对比。交互性主要是指沟通的耗时,交互的便捷度,任务达成的难度,还有社交习惯的再现度等等。


    在互联网上传输东西是通过 IP 网络,这个过程中包可能会迟到,甚至直接丢了。那么如果一个视频会议系统做的不好,一旦发生丢包,它的画面可能就会卡顿,甚至会有一些花屏,用户就会觉得信号质量降低了


    1. 延时与交互性取舍


    有很多信道层次保护方法,可以在包迟到或者丢包的时候做质量恢复。一个是 Jitter Buffer,那些包虽然来的有早有晚,但是可以用 Buffer 让包在出的时候变得平滑均匀。另外一个是 FEC,通过冗余技术,来传一些额外的包来补救。当然还可以通过重传的方式来让一些丢了的包再出现。通过这些方法,可以保证系统的信号质量。


    但是,信号质量提升的同时,交互性变差了。这是为什么呢?下面的图是在线下的面对面双人交流中,A 跟 B 在同一个世界,他们看到的东西是同一个,所以只要 A 说话,B 立刻能听到 A 的话语,B 说话的时候反之亦然。在这里大家的话语的传递很及时,沟通也没有什么困难。


    而在对应的线上双人会议中,因为有传输延迟,也有一些为了提升信号质量而做了重传或者很长的延迟,A 说话的语音跟画面,可能过了一段时间才到 B 那边,反向也是这样。这个会导致什么问题?


  • 首先他们两人交互的总耗时变长了,增加的时间会改变端到端延迟引入的。

  • 另外,会改变说话的对称性,人们在这种情况下,会觉得自己反应很快,但对方的反应很慢。说话方看起来说话很快,听到后立刻响应,但是很久之后才能听到对方的回应,这样其实会带来交流上的困难。

  • 更严重的是,在 A 等待 B 的话过来的时候,感到不耐烦了,偏要说话,那就会出现两个人同时说话的场景,在音频传输上一般称为双讲。



    端到端时延传统上认为占大头的是传输跟缓冲,但是实际上我们在实践中发现,无论是采集渲染还是编解码,都是要耗一定的时间的,而且有时候时间还不小,尤其是在一些特定的移动平台上


    ITU G.114 指出,端到端时延在超过 150 毫秒时,就已经能开始察觉到了,超过 400 毫秒的话,很多用户就觉得不可接受了。所以说端到端的时延很重要。



    好在端到端时延是一个可变参数,可以通过调整缓存时间,调整策略来使时延变长或者变短。而通过调整时延,能在信号质量和交互性中间找到更好的平衡


    在一些情况下也会根据交流的内容进行取舍。比如老师给学生们讲课,基本上是老师在讲,那么如果学生说话回的慢一点,一般也不容易被察觉,就可以把学生说话的时延稍微调大一点,来保证质量。


    2. 质量与抗性取舍


    质量指原来音视频展示的清晰度和帧率,而抗性一般指特定损伤网络下卡顿率的高低。


    从信道方面来看,在可用带宽受限时,源数据和冗余数据其实是竞争关系。源数据更多的话,清晰度会更好,而冗余数据更多的话,在网络有损伤的情况下会更容易恢复,所以这里要做一个权衡。


    另外信源本身也能提供一些抗性。视频里主要是可以通过编 I 帧,可以做帧内刷新,用 SVC,或者是选择参考帧来获得这些抗性,这样它其实是把一部分的编码的资源用在冗余上,也会导致清晰度下降。


    3. 核心问题:有限资源的分配


    这里的核心问题就是,时延和带宽有限,不能无限增加,那么应该怎么分配。下面的图只是举个例子,这里的数字不代表腾讯会议系统就是这样做的。


    例如说时延里有 30%用来做网络传输的固有时延;那么当网络不好的时候,就要占一部分时间来做重传;当网络有抖动的时候,还需要一些平滑时间来平滑一下那些帧;还有一部分是采集渲染编解码的时间。如果不能针对性地分配时间,就可能出现抗性不足的问题。


    带宽可能大部分是用来传源数据,但因应网络损伤场景,也要留一部分给冗余数据。



三、将最优化问题与系统控制关联


    1. QoE 最优化问题


    腾讯会议 QoE 的最优化,实际上是在各种控制参数上,找到一个最优的参数组合。


    这里其实涉及三个问题,这三个问题都不太简单:


  • 怎么评估、怎么获得 QoE;

  • 第二,QoE 在实时系统上到底应该怎么算;

  • 第三,给定了算式后,应该怎样做最优化。


    下面重点介绍一下第三个问题。



    QoE 最优化主要是考虑这些方面:卡顿,端到端时延,画面质量,音画同步,变化平稳度,下面图中是影响这些方面的因素。而它的约束主要有三点:时延约束,发送码率,接收码率


    这里的难点在于,很多指标的估算都涉及概率方面的统计,而很多指标不是独立分布的,要算准一个期望很难。在期望算不准的情况下,最终的效果就会跟预期的差很远。在这里腾讯会议也花了很大的力气来做一些调整。



    2. 时延约束 


    因为时间有限,今天只讲其中两个最重要的约束,分别是时延约束和带宽约束。


    端到端时延与 RTT、重传次数、抖动、目标卡顿有关。在腾讯会议的系统上它是这样的,在发送端就已经决定好一个最优组合策略,来指导上下行所有参数的调整,而接收端会根据策略大方向,在必要的时候做一些紧急补救。


    实际上跑下来发现,因为预测大部分情况下都足够准确,所以那些紧急补救使用机会不是特别多。同时因为重传是一个比较节省流量的抗性策略,所以在时延和丢包的模式允许的情况下,腾讯会议会优先使用重传,不足的地方采用 FEC 来补救。这样的话,可以看到腾讯会议的时延其实最大的部分就是网络本身的延迟,还有重传的延迟。下行可能会多一个 Jitter Buffer 抖动的平滑延迟,之后还有一个音画同步的时延,这部分就组成了腾讯会议整个端到端的时延。 


    在做这个时延优化的实践里,我们发现还有很多需要考虑的地方。比如说媒体服务器不是一个点,它们之间传输需要时间,而且它们可能也不是百分之百可靠。另一方面就是因为腾讯会议做的是一个全平台的方案,可能遇到有一些平台,它的处理比较弱,在视频路数比较多的时候,很容易处理不过来,造成延时约束被打破。在这些地方腾讯会议都投入了很多精力来做微调的优化。



    3. 带宽约束


    一个视频会议里面,带宽的分配达到了“斤斤计较”的程度,这是因为无论是原来的码率,带内冗余、带外冗余还是重传的码率,都要使用带宽。而带宽如果超出了正常的范畴,视频的丢包率和抖动都会突然上涨


    腾讯会议针对网络的类型来使用不同的拥塞控制算法,来保证带宽约束不被破坏。我们发现在大部分网络下面,拥塞之前数据都会先排一下队,那么在这种网络下,我们会做以延迟为主的拥塞控制。但是在一些网络上,主要是跨运营的网络,在有拥塞的情况下,很容易会立刻丢包,给它传的越多它丢包越厉害,那么在这种情况下就不能盲目的通过重传 FEC、超发等方式来做网络抗性,要针对性地做一些不同的拥塞控制。


    下行方面会相对复杂,因为一个上行可能对应很多下行。那么我们会靠一些粒度相对粗放的策略做拥塞控制,做完探测之后,通过一些时域、空域的 SVC,或者通过 FEC 增减,来进行拥塞控制,使得下行流量在控制范围内,而且不会比预测的可用带宽小太多。



    总结一下,腾讯会议的整个架构都是为优化 QoE 而服务的,要在这些 QoE 指标之间进行取舍。在实践中,腾讯会议会把控制跟最优化问题做一个关联,然后在各个模块上布置各种算法,基于最优化 QoE 做出决策,驱动算法。


头图:Unsplash

作者:许景禧

原文:https://mp.weixin.qq.com/s/_PvC58_zRlCbQOsKC-P-5w

原文:腾讯技术开放日 | 腾讯会议如何构建实时视频传输算法架构,来实现用户体验质量最优?

来源:腾讯多媒体实验室 - 微信公众号 [ID:TencentAVLab]

转载:著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

2021 年 1 月 17 日 22:12981
用户头像

发布了 36 篇内容, 共 24448 次阅读, 收获喜欢 14 次。

关注

评论

发布
暂无评论
发现更多内容

宝藏!Github上标星45K+的《Java核心神技笔记整理》,吃透消化,面试跳槽不心慌!

Java成神之路

Java 程序员 架构 面试 编程语言

阿里中间件团队技术官手撸笔记,全新演绎“Kafka部署实战”,已开源

Java架构之路

Java 程序员 架构 面试 编程语言

electron实战练习-三个文件实现一个命令行终端

OBKoro1

node.js Electron electron实战 命令行终端 electron学习

智汇华云 | 安超OS为企业数字化转型构建坚实的云基座

华云数据

Java 异常处理

学个球

Java java异常处理

从美国《拜杜法案》到中国供应链体系形成的内在逻辑

JiangX

供应链 28天写作 制造

顶级!13位专家力荐Spring5为企业级开发提供一站式方案

996小迁

Java spring 编程 架构 面试

工业传感器:工业互联网的第一道门

浪潮云

工业互联网

如何对AD和Exchange进行安全加固满足护网需要?

嘉为蓝鲸

安全 asm AD 邮件系统 权限

Java 程序经验小结:用私有构造器或者枚举类型强化Singleton属性

后台技术汇

28天写作

Serverless 在 SaaS 领域的最佳实践

Serverless Devs

Serverless 云原生 SaaS

看图学NumPy:掌握n维数组基础知识点,看这一篇就够了

华为云开发者社区

Python 机器学习 数组 Numpy

重学JS | 异步编程 Generator()

梁龙先森

前端 编程语言 面试题 28天写作

我以为自己够牛逼了,直到看到了Alibaba专家的面试笔记,我学习了三个月,却入职京东,税前36K

Java架构之路

Java 程序员 架构 面试 编程语言

毕业3年,月薪从10K到30K,万分感慨 “数据结构与算法真实太TM重要了!”

Java成神之路

Java 程序员 架构 面试 编程语言

快速入门案例实战:电商网站商品管理(一)

escray

elasticsearch elastic 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

科技赋能传统产业:工业绿色可视化—核电站工艺流程组态仿真

一只数据鲸鱼

物联网 数据可视化 组态软件 绿色工业 核电站

太牛了,Alibaba出品的这份《Java并发编程实践》文档,每一步操作都直击你的内心!

Java成神之路

Java 程序员 架构 面试 编程语言

新鲜出炉!阿里内部开源SpringCloud Alibaba全解(全彩版)全网首发

Java架构追梦

Java 架构 面试 学习笔记 SpringCloud Alibaba

APICloud的发展和应用

anyRTC开发者

ios android 跨平台 sdk APICloud

快抛弃你错误的坚持

石君

生活随想 28天写作

研发管理101军规#003 实战规模化敏捷:从8人到百人的敏捷之路

PingCode

程序人生 Scrum 敏捷开发

林昊获中国计算机学会杰出工程师奖,阿里中间件再获高度肯定,“三位一体”推动技术普惠

阿里巴巴云原生

阿里巴巴 阿里云 开发者 云原生 中间件

2020DevOps状态报告——变更管理

陈琦

DevOps 运维 开发 趋势 自动化测试

跨越全场景统一架构三大挑战,MindSpore亮出“四招”

华为云开发者社区

深度学习 联邦学习 mindspore 算子 ai框架

软件测试--selenium安装使用

测试人生路

软件测试

太牛了!Alibaba架构师耗时72天总结整理的700页Java进阶架构师宝典。

Java成神之路

Java 程序员 架构 面试 编程语言

盘点2020| 开启小马哥的新未来

小马哥

盘点2020

高频量化交易机器人系统开发|高频量化交易机器人APP软件开发

开發I852946OIIO

系统开发

再造淘宝电商项目落地,从零开始搭建亿级系统架构笔记,直接让你拥有高并发设计经验!

Java成神之路

Java 程序员 架构 面试 编程语言

阿里P8内部架构核心学习知识笔记在各大互联网上流传,限时开放下载

Java架构之路

Java 程序员 架构 面试 编程语言

OCR技术的未来发展与演进

OCR技术的未来发展与演进

腾讯会议如何构建实时视频传输算法架构,来实现用户体验质量最优?-InfoQ