明星陪看直播：实时音视频技术的实践应用

//

编者按：爱奇艺近年推出的明星陪看直播业务打造了明星真人与观众围绕影视剧综艺近距离实时互动的新体验，逐渐吸引了用户关注。而在技术落地方面，爱奇艺通过与第三方音视频服务供应商深度合作，各尽其能，最终实现了成本最小化，效果最大化。LiveVideoStackCon 2023 上海站邀请了来自爱奇艺的施幸东，为大家分享爱奇艺明星陪看直播业务的整体技术架构，以及爱奇艺从剧集版权管理、复用已有基础设施、高可用性保障等方面的作出的一些优化考虑 。

文/施幸东

整理/LiveVideoStack

大家好，本次我分享的主题是实时音视频技术在明星陪看直播中的应用实践。

首先做一个简单的自我介绍。我于2013年加入爱奇艺，长期从事即时通信、WebRTC、视频直播等技术的架构设计和研发落地工作。

本次分享将分为以下几部分：首先说明陪看直播业务的出发点，随后介绍陪看直播的一般技术架构，接着从版权、成本、高可用等实际角度介绍我们对一般架构的调整点，最后提出一些我们对前端技术架构的考虑。

-01-

明星陪看模式的业务出发点

如上图所示，爱奇艺的陪看直播模式让明星以直播互动的形式与观众共同观看影视剧和综艺节目。对于流媒体平台，该模式是一种宣传综艺影视剧的助推手段。对于明星，该模式在宣传参演节目的同时有助于提高曝光度，吸引更多粉丝。观众则通过该模式进一步拉近了与明星真人间的距离。

各大流媒体平台针对明星陪看发展了不同的业务形式，例如借由访谈节目让明星与观众在演播室与观众共同观看影视剧片段。我们的陪看模式，注重轻量化、自动化，力求解放运营人力，明星只需要使用爱奇艺提供的APP即可不受场地限制地开始直播。目前我们每月会组织二十到三十场陪看直播活动，频次达到了一天一场。

-02-

陪看直播的一般技术架构

接下来介绍陪看直播的一般技术架构。首先，上图展示了“只有明星聊天，没有陪看点播剧集”这类简单场景的架构。

由于明星侧有实时沟通需求，因此传输协议只能选择WebRTC。而观众侧下行用户的基数很大（数万到数十万），使用WebRTC虽然延时低但成本压力高，使用成本较低的HLS延时又过高，不利于明星实时接收观众的反馈。因此综合考虑，观众侧传输协议我们选择了HTTP-FLV。

上面提到，考虑到成本因素我们无法在全链路使用RTC协议，这导致明星侧和观众侧的延时差距较大。

那么在媒体服务器的选择上，推流涉及流间同步，对延时误差要求高的多路流模式便不再适用，只能采用单路流模式，将明星侧的多流合为一路。该模式受网络条件影响小，但媒体服务器需要具备视频合流能力，在构造上更加复杂。

针对“明星聊天+陪看点播”场景，在前述架构的基础上我们额外引入了VOD视频文件处理模块以及控制模块，前一个模块负责将VOD本地视频文件转化为实时视频流，通过合流模块将其与明星的聊天流合为一路后再推到观众侧。

借助控制模块可以依据实际情况优化剧集和明星直播画面的屏幕布局以及音量比，使屏幕布局更合理，聊天声音更清晰，从而提高观看体验。

虽然爱奇艺自身具备实时通信能力。但考虑到陪看直播活动当前只在夜间部分时段内举行，而明星们所处的网络环境一般又较差，从建造和维护成本最小化的角度考虑，我们最终选择公有云平台负责媒体通信服务。

但视频文件作为爱奇艺的核心资产被保存在内网，公有云无法直接进行访问，因此需要实现一套传输解决方案。

-03-

从版权的角度对架构的调整

现有的传输方式分为离线（如FTP）和实时传输(如RTMP)两种。其中离线传输不需要过多的前期开发，但在直播时占用的人力多，也变相增加了媒资文件的泄露风险。实时传输实现了机器自动化，占用的人力少，缺点是前期开发工作量较大。从泄露风险最小化的角度考虑，我们选择了实时传输方案。

鉴于RTMP是较为常见的媒体实时传输协议，我们决定将处理后的实时视频流通过RTMP服务器推到公有云，从而避免提前泄露媒资文件。图中绿色代表由爱奇艺自行完成的工作。

虽然增加RTMP传输会使视频播放的延时增加，但数秒级的延迟对体验影响不大。明星的聊天互动是基于视频内容产生的，因此一般在合流后不会出现不同步的问题。

-04-

从成本的角度对架构的调整

目前提供实时视频通信服务的公有云一般按实际流量收费，从成本角度考虑，鉴于当前体量尚小的陪看直播对带宽占用不大，那么完全可使用爱奇艺现有的CDN来完成媒体分发，这只需要在公有云和爱奇艺CDN之间架设RTMP服务器即可实现。

最终在公有云实际发生流量的只有明星侧的实时流，这部分流的持续时间不长，清晰度也不高，因而极大节约了网络成本。

-05-

从高可用的角度对架构的调整

为了进一步提高架构稳定性，首先我们对现有风险点进行了分析。综合来看，公有云服务器和爱奇艺的自有CDN都运营多年，已经相对成熟，而负责处理和分发实时视频流的处理模块和RTMP服务器作为新增环节，需要着重考虑不稳定因素。

本着避免新增环节出现单点故障，我们对其采用了多实例方案。由于RTMP的视频转发是实时进行，不涉及保留进度状态，不同实例间无需同步即可无缝续传。而视频文件处理模块的工作具备进度属性，因此一旦出现中断就需要进度同步。

同时我们也考虑充分利用公有云的基础设施，在公有云增设RTMP服务器作为进一步保险。这开辟了多种新的传输路径，也尽可能将故障风险降到了最低。公有云端的RTMP服务器未实际启用也不会发生额外成本。

为了便于不同传输链路间的切换，我们最后增加了链路调度模块，可以通过该模块切换明星侧到公有云、爱奇艺到公有云和爱奇艺内部的各类传输实例。

-06-

前端技术架构的考虑

针对前端我们目前向明星提供了爱奇艺播播机APP，它集成了RTC云服务对应的SDK，可以通过手机摄像头和麦克风采集音视频流并完成实时通信，APP负责画面渲染。

为了满足用户需求（例如美颜），我们与RTC SDK提供方展开了深度合作，让APP参与到音视频通信流程中。RTC SDK采集的画面会先经由APP美颜处理再进行通信，最终明星在手机屏幕上看到的效果就是自身和对方经过美颜后的画面。

总体来看，我们的陪看直播业务充分发挥了爱奇艺和公有云供应商双方的技术特长，同时通过尽量复用基础设施来降低总体成本。最后是做好风险识别并完善了相应预案。

我今天的分享就到这里，谢谢大家！