体验共享含义及其与RTC技术的关系

虽然音视频技术日趋成熟，但是不同场景对音视频的需求有不同侧重。为了将体验做到极致，音视频技术平台也面临着很大的挑战。今天我们邀请到了即构科技邱国钦老师，为大家介绍多媒体场景中新的体验场景面临的挑战，以及该如何应对这些挑战。

大家好，我是邱国钦，本次与大家分享的是“体验共享”。首先做一下个人介绍，我大学毕业于通信专业，而后进入腾讯从事互联网软件、QQ相关的工作，2015年进入即构科技负责SDK研发，目前专注于整体解决方案，包括理解平台细节、客户需求，并从商业角度根据需求驱动研发。这是一项极具挑战的工作，应综合考虑到需要满足的点，包括基本功能需求、稳定性需求、性能需求、成本需求等。有关需求的落地，具体做法就是使客户能够获得收益。

本次分享包括四个方面。第一，体验共享的含义及其与RTC技术的关系；第二，RTC服务的优化思路（优化到适配诉求及满足各场景各种需求）；第三，RTC业务的体验优化经验；第四，总结与展望。

Part 01

体验共享与RTC技术

首先介绍体验共享的含义。

体验共享在线下是一个自然而然的概念，举几个体验共享的例子：大家在看电影时，喜剧片会一起笑，恐怖片会一起尖叫。共享体验需要立即看到对方的反馈，感受到对方，得到精神的放松并有所收获。第二个例子是线上教育，其实大多数人偏向线下教育，因为可以更好地互动，老师可以从学生的反应中得到信息并指导学生成长，学生之间也可以通过互动促进学习。以上例子的特征是都具有很强的互动性，大家可以看到对方的行为反应，获得某种感受、认知，并从中得到快乐、成长和学习。

RTC技术（Real-time ）就是实时互动，是这类应用的基础，所以RTC良好的体验可以很大程度上影响整个APP体验。今天介绍的是基础RTC体验的优化，以及如何做好线上共享体验的APP。

Part 02

RTC服务的体验优化思路

正式进入今天的主题。首先介绍基础的技术——RTC服务本身的优化。

2.1 RTC体验刻画

我们会从哪些方面评价RTC的体验（王老师讲了第一个方面——画质、视频的质量）。从观众的角度来看，画质和音质非常直观，但RTC还有另外两个维度，也是直观的体验：

第一个是延迟的高低，如果延迟很高就不是Real Time；

第二个是卡顿，如果卡顿较多，即便是很高的画质，体验感也会较差。这些所谓直观的评价越好，付出的成本越高，基于成本之上，这三者需要做权衡。可能时延更低，但流畅性有所欠缺；或是高画质，然而时延较高，这些都是权衡利弊的结果，要根据场景而定。

以上指标虽然直观但很有效。比如作为一家RTC服务的供应商，客户可以使用这些直观的指标对供应商进行考核。如客户可以看某个区域、某个时间段整体的时延分布、卡顿占比，而且时延、卡顿都有指标来考核服务质量。

从服务本身出发，如果要做更好的RTC服务，只考核这些指标还不够，还要继续探索提升整体三个维度质量的问题点，所以要看需要用哪些更细的数据提升RTC服务的水平。

2.2 RTC系统特征

实际上RTC系统还是分布式的网络系统。比如做一个大并发，要做高可用的设计，这些都很关键，如果成不了并发，或是系统不可靠，服务可能无人使用。即构之前也做过高可用架构设计主题的分享。本次重点是从RTC体验本身出发，探讨哪些因素会影响到过程，以及在系统可用的情况下如何提升体验。

首先，从数据流动的角度看。其实这个过程是采集、编码的前处理、编码、通过网络发送到对端、对端收到并解码、后处理、渲染，最终使别人听到、看到。这是一个串联的过程，也意味着其中某一步出现问题时，整体质量就会受到影响。

第二个是从信息生产消费的角度看。RTC是信息实时生产、实时消费的过程。它包括两点，首先是生产消费模型，这个模型很常用，中间的一个环节总是作为上一个环节的消费者、下个环节的生产者，再将它们串起来。其次，它是实时的系统，生产的数据到对端有时效要求，过期会失效。这里会相互矛盾。刚刚提到的各个环节之间可能出现不稳定的因素，解决这个问题的手段通常是加缓冲，比如网络传输容易出现不稳定，接收环节加一个Delay Jitter Buffer来对抗上游（网络传输）的不稳定。缓冲就意味着引入延迟。刚才提到的时效性的要求，本质上就是和缓冲矛盾的，我们需要针对不同的系统目标来做这两者的权衡。

另一个是不同环节可能出现生产速率的不匹配，可能有一端生产非常快，比如我们可以做全高清采集、编码，但网络无法及时传输这么大的码流，这里存在生产和消费的速率不匹配。通常做法是做流控，让消费者速率指导生产者，另一个是做分层编码，或加入转码环节，输出不同大小的码流，让消费者根据自身情况选择消费。

刚刚描述的是RTC业务生产消费串行过程，结合实时性要求，这些特征可以指导我们去做系统观测。我们需要观测这个系统的运行情况，才能识别出它的问题把系统做好。这需要各种数据去支撑，观测各个生产消费环节，刻画整个过程。

2.3 RTC系统质量问题分析思路

2.3.1 全链路跟踪

基于上文提出的基础想法，刚刚是一个比较High Level的讲法，我们是从生产和消费的角度去看。那么在做质量问题分析时，需要做哪些事情呢？

从即构的一些实践出发，我在这里提出两个点。

第一是做全链路的跟踪，出发点很直接，要知道系统处于什么状态，大部分问题可以通过分析每个环节究竟是如何运作的来得到初步想法，再基于此作推测攻关。得到数据的基本机制是事件跟踪，这个大部分人都知道，也有许多优秀实践。比如Linux的Ftrace就是做好事件打点、Google的Perfetto、Apple的Signpost、Windows的ETW，这一系列就是提供了工具去打点数据和后面的事件展示。当然这只是思路，即构内部有类似工具的实现。这里的基本概念是需要记录两类东西，第一类是所谓跨度事件——Span（开始时间、结束时间）、第二类是独立事件（发生时间）。然后基于这一系列事件构造出从一端到另一端发生的事情，做起来很复杂，因为有很细的数据，量也很大，关联性很难做好，因为要串系统。这些核心工作量在于整个监测点的梳理，这就深究到业务了。因为数据量大，我们需要做上报机制，要分级别，分目标做好控制。

应用上分为两类。第一类是做性能分析的时候，我们要知道它发生了什么事情，在开发过程中需要判断各个过程的速率是否稳定，或者是否出现设计的方案导致一端消费的不及时或者其它问题。有些情况中，问题可能没那么明显，比如1秒少了一帧或是10秒少了一帧，单单靠感官很难发现；第二类是耗时分析，特别是启动耗时，一帧进去之后什么时候出来，如果是一个百毫秒级别的，串着看很难发现，还是要进行数据分析，而启动耗时可能大家都会遇到一个问题，第一帧什么时候能够出来是非常关键的。

接着是做业务分析，这是运营系统所需要的，因为我们总会遇到些问题，那么怎么做运营系统分析，打点数据从一端到另一端，这整个过程应该有个展示的东西，图中是我们运营系统的一部分，告诉用户从推流端到拉流端的各种数据情况。打点信息需要足够丰富，包括设备异常、操作行为等信息，这很关键。

2.3.2 主动探测

接下来介绍主动探测，这是一个基本的想法。对RTC系统来说，很重要的一部分是网络，而我们认为网络实际上非常复杂，复杂到无法控制，只能适应，这里的适应分两块：第一块是客户端到接入的服务器这一层如何适应；第二块是服务节点之间如何适应。

所以我们的基本思路是既然不能掌控那就探测，改变调度策略和接入措施。这里的探测就要提到主动探测。我们收集的数据是很基本的，包括RTT、丢包率、抖动（Delay Jitter）。另一块重要的数据是实际业务传输数据，这里就造成很大的困难，因为量很大，需要做一套很强的系统消费它、计算出来。而且不能让它有很高的时延，要做到实时计算。

基于此，要做一些分析，包括Bad case的分析，这是很正常的，因为整个做法上线之后总会遇到很多问题，特别是在国外，也会进行一些按区域、时间、力度划分的各种数据分析对比。通过这些分析得到一些想法，继而去指导系统设计的策略，当然这些东西都很细节，有时候没有很契合的理论支撑。这都是在运营系统时必须要做的事情。

此外还会做一些大数据分析的情况，让机器帮我们找到特征，但在探索之中，这都要和人工结合在一起，无法完全依赖机器。

主动探测方面有些细节想和大家分享，比如客户端探测服务器，探测的行为包括客户端探测接入点和服务节点间的相互探测。服务节点间的探测比较好做，客户端发起的探测比较复杂，什么时机探测？是业务开始前探测，还是业务过程中持续探测、采样探测，还是业务遇到问题了才探测？要用多大流量探测？如果流量大了，会不会影响主业务？流量小了，会不会不准确？内部的做法通常是做A/BTest，做一些选择，得到概率性数据。

接入探测

接入探测就是客户端到服务器探测的应用经验。黑色的图显示的是我们在某个区域监测网络质量的情况，以丢包率来看。最上面的线表示零丢包的情况，可以看到15：05时，零丢包率下降，掉到了接近60%，很难解释下降的原因，所以只能适应，那么如何适应呢，我们在SDK做了探测，如果发现这时的接入出现异常，那么考虑有无更好的连接点选择，SDK可以自主地找到更好的路。第二，SDK探测得到的信息还会用来指导服务调度策略调整，让后续其他用户不用重蹈覆辙。主要是两个策略，第一个是服务器下发的指导调度，反映综合最优，第二个是当遇到问题，调度服务吸收实时接入质量反馈，可以自动更新策略，恢复到正常水平。

图中点虽然看起来下降很大，实际上是算法同时在补救，对业务来说、对整体上层体验来说影响不大。做探测的目的是不能让算法解决整件事情，算法只是应急使用，网络才是基础。虽然我们的传输控制算法能够在70% 丢包下工作，但我们不希望我们服务一直处于极限情况运作。这也是一个很基础的想法。

全球IDC探测

另外一个应用是SDN。SDN在即构RTC服务网络中的作用非常大。首先我们的架构是混合云，图中是我们的部分部分供应商的节点情况，包括腾讯云、阿里云、亚马逊、微软等，这些点是我们可以用的，那么如何管理这些点、找到足够好的链路也是需要思考的，比如从一端到另一端有足够好的RTT、足够少的丢包、足够稳的抖动等。

这两张图展示了SDN的效果。左边的图表达的是从深圳到香港两个节点间直连的效果，丢包明显，RTT很大，在170ms左右。右边是经过了SDN后的效果，只有偶发少量丢包，并且RTT下降明显，基本在20ms左右。

为什么深圳到香港会有这样的问题，这其实是跨域的情况，如果不做优化，跨域调度的网络流量会随着运营商对成本的考虑而变化，比如到香港之前可能会先绕去日本，如何发现问题？就是要主动探测，根据实时探测的结果，找到一条综合最优的链路，把数据转发到这条路上去。这就引发一个实际问题——怎么转发。需要在网络层转发？还是理解业务在应用层转发？这两个方法我们都试验过，第一个在网络层，我们认为是合适信令业务的。这种包的时效性和要求不高，所以可以在三层做转发，拦截系统的IP包，在IP包一层的指定点做转发。在流媒体层，三层转发是不足够的，流媒体层更注重时延，如果中间跨了很多层，发现丢包会经过很多层，会变慢。所以我们倾向于信令直接在网络做，流媒体单独在应用层部署专用应用做转发。

Part 03

RTC业务的体验优化经验

系统的稳定性和性能很大程度上基于以上两个思路进行优化。下面介绍RTC业务的体验优化经验。

3.1 线上教育

首先是教育场景，看起来非常普通的场景，没有特殊的玩法，最基本的要求是保持稳定的通话。这个场景大多是付费场景，用户付了钱，并且目的很明确，需要学到东西。任何一点阻碍他们沟通的问题都很烦人。有哪些东西比较容易出问题呢？分为两大类：第一是设备问题，教育场景有各种各样的设备；第二是网络兼容问题，怎样减少网络抖动和音视频卡顿。这里的设备主要是指采集设备和播放设备。如果采集失败了，那之后的环节都没有意义了，同样，如果渲染失败了，那前面的努力就白费了。

因此，需要做好广泛的设备兼容。首先要有多套采集渲染方案，然后针对不同的设备选定合适的方案。其次，需要做好设备故障实时监控，针对异常需要能够自动恢复。比如当前正在使用的设备被其他应用打断了，需要有个时机恢复异常：打断、后台等。最终，设备兼容通常是case by case，我们会不断兼容新的case，到这时，加上一些有云控，需要策略随着新设备出现及时演化，比如去年出台的SDK要兼容今年的新设备，比如iPad，它的变化比较大，那如何设置它的3A参数，就是通过这种策略来设置的。

另一个是网络，网络通过刚刚提到的主动探测已经解决了很大的问题，传输调优指的是针对教育场景的特点做好参数调节。教育场景对稳定性要求高，但是对时延没有太特殊的要求，通常300ms是能够满足需求的。因此可以利用好这样的资源减少卡顿。设置一个最低下限的Jitter Buffer的Level；另一个，通常教育可以提一个更高成本的方式，SDN可以有更大范围的寻路，每多转发一层就会多一份出口的流量。更大范围的话，比如再多一跳，增加成本是否有用，用处有多大？这都是需要权衡的，如果要求系统稳定，那么多转发一层是没有必要的。

还有一个点是音质，音质有各种理解，包括保真、音量、底噪、回声，这些都是特定场景下的需求。对教育场景来说音量够大是基本需求，所以3A策略需要更激进。

这里我想强调的一点是，教育场景最核心的诉求是稳定，而稳定需要很多细节积累。

教育场景里，教具比较丰富，也有些特殊的需求，比如白板和音视频通常不走同一个通道，并且数据行为模式也不一致，如果不特殊处理，可能出现音视频和白板动作对不齐的情况，这个问题可以通过将时间戳埋到流中做同步来解决。录制也需要结合教具，即构提供了一套关于录制的方案，有各种选择。同时，教育场景有挺多屏幕共享的操作，有不少是文字的场景，我们针对性地做了编码优化，让文字更锐利。

另一个需求是小班课，特别是低龄的学生，很活跃，老师们为了鼓励学生开口说话，通常会有齐声朗读的场景。如果二三十个人一起说话，现场会十分混乱，基本没有办法听清楚。即构去年前往开设小班课的公司体验，发现学生们很喜欢说话，老师们虽然鼓励孩子们说话，但并不希望他们吵闹，所以我们做了焦点语音功能，可以凸显老师的声音，同时自适应协调学生的声音，既保证了氛围，又不至于太吵闹。这个功能需要一些门槛和细节，比如某些学生的声音是否应该被放出来或被抑制。功能上线后，得到了老师们的良好反馈，提升了小班课体验。

同时教育场景的稳定需要运营工具支持，比如如何识别问题，做好一系列配套的事情。即构棱镜就是这样的一个平台，用于做问题分析和数据运营，可以发现端到端中各种情况和统计类数据。

3.2 一起KTV

接着是即构一直在努力改进的场景——一起KTV。这个场景提出已经很多年了，每次提出都有新东西出现。2019年，提出了串行的方案：首先一个人演唱，将声音传给另一人，第二个人再将自己的声音混进整合后传给听众，这个方案比较简单而且对网络要求不高，市面上很多音乐平台的落地应用已经真正在线上使用了，但即构想做的是真正的合唱，就是实现KTV中的多人合唱，这是一个很具吸引力的场景。我们在实时合唱方案上打磨已久，在近期行业内首发了多人实时在线合唱的解决方案。

下面介绍一下优化，最终效果是合唱者体验优良，端到端感官极致低延迟，结构更适合多人合唱，对观众端无特殊要求。这里的主体结构分为几个部分，下面这部分是RTC网络，RTC网络就是提出极致低延迟，我们做到IOS 76ms，Android 因为采集渲染的原因做到延迟111ms，Windows 92ms。这个时延是比较低的，这里指的是从采集到真正从喇叭播放出的时间，包括端到端真正的时间，不只是网络。

基于上述两个部分，分别介绍一下具体的操作流程。

首先要做端到端时延的压榨，第一是分析链路情况，要做好事件的打点，从整个链路来说，包括采集、前处理、编码、传输、对端解码、后处理、渲染，这里的耳返时延是一个硬的约束，如果约束突破不了，时延有100ms或200ms，那么网络就不可用了，因为还要叠加下面一部分编解码和传输的时延。

为了应对每个环节处理的不稳定，我们会加缓存，大家倾向于多加缓存来追求稳定。如果开发者是分人开发的话，他会希望自己的模块稳定，但这就会给整个系统引入很多时延，我们需要判断缓存是否必须。

另一个是整个算法的时延，就是系统设计出来本身需要的时延，比如右图是Codec引入的时延，纵轴表示时延，横轴表示码率。对于Opus，它的时延可以做得很低，Opus有两类编码方案，分别是基于时域和基于频域的。如果是基于时域的SILK，可以将时延做到极低——5ms左右，但因为时域的基于语音模型，效果不太好，无法达到高质量。另一个基于频域的方案，默认帧长情况下时延极限可以做到20ms左右（默认一帧20ms，Lookahead 2.5ms）。当然可以减帧长。

总结一下，首先我们要看算法时延，音频系统一定会有算法时延，要选择更好的算法，更好的Codec。我们还要Review整个Pipeline缓存的水平是否必要或者权衡用什么东西去降缓存。

第二个方案是基于一个前提，我们希望每个人都可以自己唱，这样的话没有因果关系，不需要等前一个人唱完，这里引入一段时延。那么如何做好这件事情？方案是做时钟同步，这是很老的概念。首先要有可靠的时钟源，一般是原子钟、GPS，这个成本很高，但有公用服务可用；其次是同步总会存在误差，怎么过滤坏的点、找到好的点，包括多个服务器探测，多次探测选择好的点，同时需要注重细节，包括一些系统本身的API始终分辨率不高，本身误差就达到十几毫秒。

除了演唱者，还要从观众的角度来看。对观众的网络要求不能过高，因为大部分人网络都没有较好的保障，那如何做好观众效果？观众效果会遇到什么问题？比如演唱者的演唱已经非常同步，但是观众听到的不同步，原因包括观众与两个主播的距离不同，或是某人的网络突然抖动，总会存在一些不稳定的情况。我们的想法是在服务端将云端回流对齐，想法很基础，通过加缓冲，用延迟换对齐，另外还要加播放的伸缩让整个过程更平滑。

这是一个Demo，展示视频的第一部分是19年方案的效果，主唱无法实时听到副唱，兴致减半；第二部分是我们做到的效果，犹如线下KTV的体验共享。

即构主要希望不同端、不同地域的人在一起唱歌时都像是在KTV唱歌，内部测试在普通要求下已经可以达到KTV效果了。同时提供Demo在展台体验。（Demo下载地址：https://doc-zh.zego.im/scene-plan/26）

Part 04

总结和展望

以上都是基于基础设施做的，优化方面除了功能优化，还要有基础设施的优化包括更好的Codec、更强大的终端、VR、AR帮助方案落地。LVS也搞过线上的大会，现在疫情缓和了，大家也来参加线下的大会了。当然一方面国内对疫情的控制做得很好，另一方面还是因为线下体验确实比线上更有吸引力，在线下能够更自由地交流。这其实也说明了线上体验确实还有很多值得改进的地方。如果有选择，大家会倾向于线上参加LVS大会吗？我相信随着基础设施的演进，我们在实际场景中历练方案，不但可以将线下个各种体验场景复刻到线上，还将演进出更多线上独有的体验，给大家更多的选择，做到真正的体验共享。希望整个行业一起努力，让音视频技术、RTC技术融入于生活无形。

原文标题：体验共享——技术实现瓶颈与突破

文章出处：【微信公众号：LiveVideoStack】欢迎添加关注！文章转载请注明出处。

责任编辑：haq