基于WebRTC的“云多视角”直播优酷播放技术分析

来源：爱酷猪责编：网络时间：2024-10-22 08:47:42

基于此，经过研究和探索，最终基于WebRTC实现了低时延、高清多视点直播能力，并在《这！就是街舞》年度总决赛中正式上线。效果视频如下：

点击观看视频：优酷播放技术|基于WebRTC的直播“云多视角”技术分析

方案选型

能否实现低时延切换、高清、全机型覆盖的用户体验，是最终决定采用哪种技术方案的重要标准。业界常用的应用层协议包括：

HLS（包括LHLS）RTMPRTP（严格来说RTP是介于应用层和传输层之间）单流伪多视直播：基于HLS协议，端同时只拉一路流，且改变视角时需要重新切换流地址。开始广播；多流多视点直播：基于HLS协议，终端同时拉取多路码流进行解码渲染，无需切换码流地址即可开播；单流多视角直播：基于RTP协议，同一终端一次只拉一条流，改变视角时无需重新切换流地址开始直播。横向比较

将劣势特征用红色标记后得到的表格：

计划

协议

同时预览

无缝切换

码率

最终绩效负担

增量成本

单流伪多视图直播

HLS

不

普通的

没有任何

多码流多画面直播

HLS

是的

高的

CDN

基于WebRTC的“云多视角”直播优酷播放技术分析

单流多画面直播

实时传输协议

是的

普通的

边缘服务和

流量带宽

经过比较，我们最终决定采用基于RTP的单流多视图直播，这是一种边缘解决方案。

WebRTC 概述

WebRTC，其名称来源于Web Real-Time Communication（英文：Web Real-Time Communication）的缩写，是一种支持Web浏览器进行实时语音对话或视频对话的API。它于2011 年6 月1 日开源，并在Google、Mozilla 和Opera 的支持下纳入万维网联盟的W3C 推荐标准。 WebRTC默认使用UDP协议（实际上是RTP/RTCP协议）进行音视频数据传输，但也可以通过TCP传输。目前主要应用于视频会议和连续麦克风。

WebRTC内部结构

语音引擎音频引擎负责音频采集和传输，具有降噪、回声消除等功能。视频引擎视频引擎负责网络抖动优化和互联网传输编解码器优化。音视频引擎之上是一套C++ API。

WebRTC协议栈

ICE、STUN、TURN用于内网穿透，解决外网映射地址的获取和绑定问题。 DTLS（UDP版本的TLS）用于加密传输内容。 RTP/SRTP主要用于传输实时性要求较高的音视频数据，RTCP/SRTCP用于控制RTP传输质量。 SCTP用于传输自定义应用程序数据。

系统设计

多视点直播整体链路涉及流制作、域名调度服务、边缘服务、汇流服务、直播控制服务等多个环节，整体结构框架如下：

码流制作：直播摄像机采集码流并上传至直播中心，直播中心对码流进行编码和优化；融合服务：多个输入流通过时间戳与音视频对齐后，按照模板输出多个混合流；边缘服务：预缓存合并服务的多个输出流，对输出流进行编码，通过RTP连接传输到端侧；域名调度服务：配置端侧与边缘服务通信的IP和端口；播控服务：提供合并业务请求参数配置、多视图业务能力配置等播放控制服务。详细设计

为了尽可能复用主播控制链路，减少对主播放链路的侵入，终端侧增加了多画面播放器。多视图播放器与其他播放器保持相同的调用接口，播控室根据业务类型决定是否创建多视图播放器。在业务层添加多视图插件，与其他业务解耦，方便挂载和移除。

端侧结构设计如下：

核心流程

用户进入多视图模式的主要启动流程如下：

目前支持3种显示模式，分别是混合模式、覆盖模式和源模式。具体模式及切换流程如下图所示。

侧面命令

终端侧和边缘节点主要通过RTP协议交换指令和传输数据。一般头传输格式如下，PT=96代表H264媒体数据。

连接建立命令：阻塞命令，端侧与边缘节点建立RTP连接，需要等待边缘节点返回响应。如果在一定时间内没有响应，则认为连接建立失败；断开命令：非阻塞命令，端侧与边缘节点断开连接，无需等待边缘节点返回；播放指令：非阻塞指令，端侧发出播放指令，需要传递播放流ID和OSS流配置信息，以便边缘节点找到正确的流。流切换命令：非阻塞命令。客户端发出切换视角命令。为了保持与原始视角的同步，需要将原始视角帧时间戳传输到边缘服务。

项目落地

播放能力调整

基于WebRTC的“云多视角”直播优酷播放技术分析

音频采样率调整WebRTC目前默认不支持48K音频采样率，目前大型直播的采样率比较高。如果不调整就发送到最后，会导致音频解码模块崩溃。

AAC音频解码能力扩展WebRTC中默认的音频编码是Opus，但目前直播大部分都是AAC格式，所以客户端需要在offer SDP中添加AAC编码信息并实现AAC解码器，边缘服务配合传送RTP包数据；

H.264编码支持为了尽可能减少延迟，WebRTC视频编码使用VP8和VP9，需要迁移到更通用的H.264编码；

在传输方式上，WebRTC采用P2P方式进行媒体传输。它只解决端到端的问题。显然不适合大规模PGC和OGC的直播内容。因此网络传输层没有打洞逻辑，采用RTP连接传输。对于流媒体数据，RTCP进行传输质量控制。连接到现有的播放系统

为了尽量减少对主播放器的影响，我们保持与主播放器相同的数据请求流程、相同的播放能力接口、相同的数据埋藏时序：

多视图播放器：封装WebRTC并扩展多视图播放器，专用于多视图视频播放；播控逻辑调整：调整直播旁路数据采集流程，将联服、AMDC等服务返回数据合并到数据流中；播放能力统计调整：保持原有的播放能力和回调接口，并通过扩展接口参数进行区分；扩展错误码：在主要播放器错误规则的基础上，扩展了多视图播放器错误码。解决端侧问题

最终需要实现下图所示的主播放窗口同时渲染多个子播放窗口：

右侧的可滑动列表是使用UITableView（RecyclerView）实现的。每个子窗口中都会添加一个渲染实例GLKView（由RTCEAGLVideoView 包装和管理）。通过在适当的时间创建、删除和更新子窗口的渲染帧，可以流式传输多个透视图。同步直播的效果。

期间我们主要解决了不同视角下闪烁的体验问题以及内存泄漏导致的黑屏渲染的稳定性问题。这里简单介绍一下。

1 播放闪光灯

【问题描述】如果总共有N个视角，那么我们的实现方案总共有N*3个（参见系统设计中的3种展示形式）通道。每次点击切换视角时，实际操作过程是播放器发出RTP 切流命令，边缘节点交换流ID 并发送Sei 返回信息。播放器收到SEI信息后，对每个窗口进行裁剪和更新操作。有问题。视角切换成功后，窗口更新需要一定的时间，这会导致新流的帧数据的第一帧或几帧被真正接收到。第一帧或几帧使用的裁剪方法仍然是旧流的模板，因此用户会看到一瞬间的视觉残留。

【解决方案】播放内核收到切流指令后，设置较短的丢帧窗口期，收到切流成功的Sei信息后恢复渲染。在此期间，由于没有新的帧数据，用户看到的是静态帧，这会阻塞渲染数据，导致子窗口内容混乱。在此期间，上层UI不会看到残帧闪烁，用户体验基本是平滑切换。

2内存泄漏

【问题描述】当用户不断切换视角、刷新列表、重新创建单元格时，内存使用量持续增加，达到上限时出现黑屏窗口。

【解决方案】内存泄漏的原因是cell重新创建过程中，内核中批量创建了新的OpenGL渲染实例，而旧的实例未能及时销毁。第一步要明确，上层业务代码通过removeFromSuperview对UIView对象进行了释放操作，但是lldb打印引用计数后仍然不为0，那么问题出在内核的实例管理上。 __bridge_retained代表OC转换为CF对象后，需要手动释放内存管理，所以在切换视角时，需要调用相关的Filter来实现C++层面的销毁和释放。解析后的内存性能：

服务并发优化

优化前的版本用于支持CUBA相关赛事的直播，但存在很多问题：成本高、切换延迟高、无法支持大规模并发。此次优化的目标是支持大型活动直播，在保证体验的同时大幅降低成本。

1个编码前缀

下图是优化前的链接。可以看到每个客户端都需要重新布局和编码。这两个操作会消耗大量的资源。即使使用T4 GPU，也只能支持20 个同时观看。

图中的Confluence服务只需要生产一次，生产的内容可以被所有边缘服务节点共享。

然而，这种简单的流切割存在一个问题。它无法实现帧级对齐。换句话说，当用户选择不同的视角时，他或她会发现新的视角在时间上与先前的视角不连续。为了解决这个问题，我们要求阿里云Director同学在合流时根据绝对时间戳进行对齐，同时将这个时间戳信息透传到边缘服务。

解决了PTS对齐问题，我们仍然无法实现真正的帧级对齐，因为还存在GOP对齐的问题。熟悉H,264编码的同学都知道，视频编码和解码都是基于GOP的，而GOP的长度可能在1s到10s甚至更长。直播中典型的应用时长为2s。如果用户切换的时候，恰好是在一个新的GOP的开头，那么就可以实现简单的码流切换，但是我们不能询问用户什么时候可以切换，什么时候不能切换。用户想要的是随时切换。我们的解决方案是，如果用户切换时没有可以切换的GOP，则边缘服务会产生一个。

从上图我们可以看到，当用户从视角1切换到视角2时，我们在切换点生成一个新的GOP，这样推流到客户端后，客户端可以无缝解码渲染到新的视角。

通过上面的步骤，我们已经大大减少了编码消耗，但是为了快速响应用户的视角变化，我们必须准备好所有源视角的原始帧（YUV420），当需要新的GOP时可以直接使用。被生成。但需求总是在变化。当有4个视角时，我们可以预解码4*3=12个码流。当业务方需要9*3=27个码流时，可以同时解码27路1080p视频数据，让整个32核机器不堪重负，更何况未来可能需要更多的流量。

2按需解码

用户想要更多的视角，我们需要适应这一点。那么之前所有的预解码方式都要改变，所以我们实现了按需解码，即只有真正需要解码的时候，我们才会为那个码流准备Frame（YUV420）。这里最大的问题是实时性问题，因为当用户切换时，图片可能位于GOP中的任意位置，而我们只能从GOP的起始帧开始解码。但通过多重优化，呈现给用户的延迟将不会被感知。

3客户端动态缓存