1. 背景介绍

直播和RTC（Real Time Communication）技术一直是以两种完全不同的形态发展的。直播通常应用于广播电视、体育赛事直播、游戏直播、秀场直播等场合，而RTC视频通话最典型的场景就是视频会议和传统的视频通话。随着近些年直播引入更多的互动方式，直播和RTC技术的界限也越来越模糊。

从信息传输的角度，直播是单向的信息传输，而RTC是双向的信息传输，但这个并不构成本质意义上的区别，因为双向的RTC可以拆解成两个单向的信息传输流。带来本质差别的是对延迟的要求，不同的延迟对底层传输协议和分发网络有不一样的挑战。早期的互联网的底层基础设施较差（低带宽、高丢包率、高延迟），通过互联网公网来传输无法满足RTC的指标要求，使得传统RTC应用都采用专网或专线的方式来实现。而大规模的直播技术则利用成熟的CDN基础设施来实现直播的功能（牺牲一定的延迟），比如苹果推出的HLS协议，就是把视频流切成一段一段的分片，利用传统的文件CDN网络来实现分发。

移动设备和4G网络的普及让手机直播成为流行的一种方式，各CDN厂商为了抓住商机，也纷纷进入直播CDN的建设。为了进一步降低延迟，各CDN厂商普遍采用以Adobe公司的RTMP和FLV协议为主要传输协议，铺设了新一代的直播CDN分发基础设施。这套基础设施在秀场直播、游戏直播、体育赛事直播领域获得了巨大的成功。

当直播成为一种主流的应用形态后，各种各样纷繁复杂的变化随之而来。最显著的就是引入了主播与粉丝的互动。不管是文字聊天、礼物打赏、直播答题，无一例外的都是更加强调互动的实时性。主播能在第一时间回应粉丝的动作，让观众获得了参与感，极大的提升了用户黏性。更进一步，当观众可以请求与主播进行“现场连麦“时，更是直接以“面对面”的方式进行交流。现场连麦其实已经进入RTC的场合了，只不过在这个场景下，底层技术实现还是以两种不同的架构体系来完成的。

再来看纯RTC最典型的视频会议场景。视频会议的参与方都能与其他人以“完全实时”的方式进行语音、视频、共享桌面等方式进行沟通、交流与互动。对于近几年来兴起的云视频会议，则还可以把会议房间里的音视频流转推出来进行“直播”，供不在会议房间里的人观看。这个时候，整体的参与者就分成了两个部分，一部分是房间内的成员，他们之间是“完全实时”的，另一部分，就是房间外的普通观众。这就构成了一种新型的“场内”和“场外”模式，场内的人能相互感知，场内的人则无法直接感知场外的人，但所有的一举一动又可以被场外的人观看到。

直播可以加入RTC连麦互动，同样视频会议可以转推出来进行直播，不管从哪一个场景，都在往另外一个方向进行延伸。从用户的视角，这两者的界限在逐渐模糊。

2. 直播和RTC融合统一方案

2.1 SFU分发网络是基础，RTC分发CDN化是趋势

传统的视频会议或多人视频通话软件，一般都限定在几十个人以内。直播系统则不然，通常可以几万甚至上百万的人在同一个房间，不太可能一台机器上处理一个”房间“里的所有转发任务，必须通过级联或完全分布式的网络结构来承载。直播体系采用的是类似消息队列中的Pub和Sub的语义，传统的WebRTC本身是点对点通信的语义，需要有SFU服务来承载放大的流量转发任务。除了流量放大，还要解决节点覆盖问题，让不同地域、不同运营商接入的用户都能找到比较近的点接入，而SFU内部的网络结构，则是分发厂商自己构建。

当前各个云厂商都有自己的RTC分发网络，虽然当前还不能完全实现互联互通。但是未来应该是会朝着标准化的方式发展。比如都会提供网关，支持以WebRTC的协议标准接入进行推拉流。虽然当前WebRTC的标准在视频体验上和私有传输协议的厂商们相比还有一定的差距，但随着5G、WIFI6等网络基础设施的改进，这方面的差距会越来越小。

2.2 典型的应用方式

以常见的秀场直播和教学培训场景为例，主播和互动嘉宾都采用RTC的分发网络进行低延迟的互动。对于支持RTC的普通观众同样能用RTC网络加入网络，只订阅下行的流，从而获得超低延迟的体验。当前的RTC-分发网络也能支持超大规模的RTC方式直播。而对于不支持RTC的观众，则只能观看通过MCU合流转推出来的直播流，和原有的普通直播保持相同的体验。

2.3 主要的障碍

设备兼容性问题

对于RTC而言，既有编解码、又有音频的3A算法（回声消除、降噪、自动增益控制），这些实现如果都用软件方式实现，会非常消耗CPU资源。通常情况下，设备端系统会自带一些编解码硬件加速、系统自带的3A算法，一方面能降低CPU消耗，另外一方面系统自带的实现能更匹配硬件设备获得更好的效果。在实际的应用中，苹果的iOS设备系统自带的硬件加速编解码和RTC的音频3A算法表现都比较好，但Android生态的设备，这方面的表现相对比较差，有很多兼容性的问题。

对于直播而言，不会有回声消除、降噪等方面的问题，单纯只对解码有加速需求，整体来说兼容性就好很多。如果用RTC技术来做直播，会带来更多的兼容性问题。

直播与RTC的切换问题

RTC和直播本身可以完全统一，按相同方式管理，但存几个问题:

1）Web端支持问题

在不支持WebRTC的浏览器版本上，只能用传统直播来播放，一方面延迟会较高，另一方面无法参与推流（也就是只能当观众，无法成为主播或嘉宾），降低了Web端用户参与的程度。

2）成本问题

通常来说，有一定量级的直播业务会采用95%分位的峰值带宽来计费，而RTC通讯则是通过通话时长的方式计费。如果都换算到带宽方式，RTC的价格会比直播的价格高出很多。这个是由于RTC要保证低延迟的分发效果，同时还要满足跨运营商、跨地域的访问，一般采用的是BGP机房，而普通的直播则采用的是价格更加低廉的单线机房（BGP机房的带宽成本是普通机房的5-10倍）。

3）切换问题

出于成本考虑，可以把不参与互动的普通观众切换到普通直播上来。 这种方式确实带来成本的节省。但是普通观众的身份不是固定的，他可以通过申请以“连麦”的方式加入到直播间，与直播间的主播进行实时的音视频连线互动。但是由于底层使用的分发网络是基于不同基础设施，在终端上需要有一个切换过程。而这个切换并不是“无缝”的，用户会有明确的感知。这里就需要在成本和用户体验之间做一个权衡。

3. 新一代编码技术AV1在互动直播场景下的应用

目前广泛应用的视频编码标准是H.264，HEVC也逐步普及。但是编码器的发展没有停下脚步，H.266、VVC、EVC、AV1等新的编码标准逐步涌现。其中AV1编码标准因为其零版税、优异的压缩效率以及开源社区的支持，越来越受到人们的关注。

AV1编码除了压缩效率有较大的提升外，还有一个特别适合视频会议、在线教育的场景的特性，就是SCC（Screen Content Coding）技术。在会议和教学培训场景，通常都会播放ppt内容。ppt内容有三个方面的特性：1. 内容很少变化：只有翻页时才会有画面变化；2. 绝对不变：屏幕内容，不会像传感器一样对光线变化敏感（拿摄像机去拍静止不动的真实画面，得到的图像数据还是会有细微的变化，而屏幕生成的内容是每个bit都一样）；3. 大部分是文字。对于屏幕内容，一般编码器都有一些tune可以进行一些优化。尽管有这些方面的优化，但是对于屏幕上的文字内容，效果还是不那么好。HEVC在扩展的标准（extensions)里提供了SCC的编码工具，专门用来编码屏幕内容，但是主标准的Profile里并未支持。AV1则把SCC工具放到了主标准里，不用再担心是否支持扩展标准的问题了。

3.1 直播如何应用AV1

1）直播CDN对AV1的扩展支持

Adobe公司当初发布的标准并不支持新一代的编码标准，无法在RTMP协议和FLV容器里面使用诸如HEVC(H.265)的新编码标准。苹果在2017年发售的设备里支持了HEVC，很多直播厂商都开始尝试基于HEVC的直播。早期的直播CDN厂商为了支持新的编码标准，自己对RTMP、FLV协议做了扩展。由于各厂家都按同样的方式进行了支持，形成了行业内的事实标准。

2）云端转码

对于终端设备上不能进行实时编码的场合，可以在云端进行转码。内容生产端可以用H.264或HEVC以较高的码率推流到云端，云端再实时进行转码，以AV1的格式进行输出。虽然云端转码需要消耗服务端的算力资源，消耗一定的成本，但当观看的人数规模上去后，节省的带宽成本就会远超转码成本。合适的做法就是只针对热门观看的直播流进行云端的转码，至于如何判断热门也有两种方式：一种是根据主播粉丝数预测，另外一种就是根据实际的观看人数后触发，保障转码开启后新进入的用户能看到AV1的直播流。

3）客户端直接推AV1码流

除了云端转码，还可以终端直接编码实时的AV1码流。当前主要是在PC端，分辨率不是太高的场合可以采用这种方式。对于上行直接推AV1的场合，PC和移动端就可以直接从CDN拉流播放了，对于不支持AV1解码的，还需要在云端转一路H264出来。随着时间的推移，未来这种方式会越来越占主流。

3.2 WebRTC中如何应用AV1

前面提到，目前Google的WebRTC项目已经整合了对AV1的支持。当前AOM联盟已经给出了AV1码流在rtp协议上的payload format建议文档（https://aomediacodec.github.io/av1-rtp-spec/），同时也规定AV1的SDP信息描述。下面是个简单的例子。

m=video 49170 RTP/AVPF 98
a=rtpmap:98 AV1/90000
a=fmtp:98 profile=2; level-idx=8; tier=1;

不过，普通的用户能使用上支持AV1的Chrome版本，估计还需要一段时间。由于当前AV1的编码需要很大的计算能力，AOM开源的编解码器性能都不是非常好，很难做到实时编解码。在解码端，dav1d是目前解码性能最好的AV1开源解码器，解码AV1的开销已经可以和HEVC的解码相当。Web端上由于有WebAssembly的支持，也可以实现在Web端的AV1支持了。在编码端，虽然Google已经把AV1的支持整合到了WebRTC之中（使用的aom的编码器，Chrome的90版dev），但目前AOM的AV1编码器在终端设备上还无法进行大分辨率的实时编码。不过已经有一些厂商推出了闭源的编码器，性能已经可以在PC端实时编码720p的视频。

4. 最后

直播和RTC技术越来越走向融合，本文讨论了直播和RTC融合的典型应用方案和主要障碍。另外也讨论了新一代编码标准AV1在直播和RTC中的落地方案与挑战。相信在不久的将来，用RTC技术来做超低延迟直播的方式会越来越普遍，直播与RTC也不会有清晰的界限。同时大家也能在不久的将来享受AV1给我们带来的用户体验提升。最近谷歌也宣布了一个基于人工智能的语音编码器Lyra，和AV1配合起来能做到以极低的码率实现视频通话。科技是第一生产力，视频技术发展也让我们的生活更美好。