直播系统开发
背景和需求
在直播系统开发刚刚兴起时，直播中的互动环节较少，主播单方面控场，因此延迟十几秒对用户体验影响较小。常见的直播大部分采用RTMP、HLS、FLV协议，技术成熟、兼容性较好、支持大规模并发等优点，但端到端延时最低只能控制在4-6秒，降低了直播的互动体验，也阻碍了直播在一些场景的落地推广，不利于直播应用生态系统的繁荣。
随着“直播+”模式在各行各业的加速发展，电商直播、在线课堂、体育赛事、互动娱乐等多样化互动直播的形式出现，让用户对实时互动性有了更高的要求，端到端延时跨入毫秒级直播时代。
- 电商卖货：主播开始喊商品“秒杀行动”，3-2-1喊完后要等5秒后才有观众的评论区反馈和交易下单，延时耽误了买卖双方的互动热情，降低商品的成交转化率。
- 在线课堂：现场老师已经讲到下一个知识点了，学生在评论区提问上一个知识点的问题，老师得中断返回来回答。
- 体育赛事：在旁边电视直播的观众呐喊声中你知道进球了，你自己在观看的直播还是实时直播吗？
- 秀场直播：用户为自己喜欢的主播打赏，若出现较大延迟的情况， 用户5秒后才能听到主播的口播感谢，弹幕和礼物的UI展示效果可能早就过去了，影响双方互动积极性。
- 在线答题：(1).部分用户可通过卫星直播系统比抖音网络直播系统提前看到主持人的题目画面了，所以优先在评论区发布答案了。(2).基于TCP拉流播放情况下，后进直播间的观众会比先进的观众延迟长，导致大家看到题目的时延存在较大差距，答题的公平性得不到保证。
目标
- 直播端到端延迟小于1200毫秒。
- 支持线上大规模、千万级高并发场景的低延时直播能力。
- 成熟稳定、全链路核心业务指标可监控。
- 保障低延时、低卡顿率、秒开流畅的极致直播观看体验。
- 简单易用、业务方基于现有的播放SDK集成RTSSDK，不需改变大的推拉流架构，现有直播业务能够平滑迁移升级到低延时直播系统，可通过配置控制开关，方便AB测试以及Fallback回落兜底。
- 能从直播无缝切换到连麦场景，再从连麦无缝切换到直播场景，音视频媒体流不中断。
方案特性
直播系统开发中低延时直播系统RTS(Real-Time Streaming)，基于RTC实时音视频引擎和传统RTMP直播系统的基础上，分别对直播推流端、播放端、边缘节点嵌入RTC模块，集成最新的RTP推拉流协议和实时媒体传输策略，提供易接入、毫秒级延迟、高并发、高清晰度、流畅的音视频直播和连麦服务。随着网络带宽和CPU计算成本的逐步下降，国内外各大云厂商大规模化部署、研发和技术成熟度的提升，低延时直播系统一定是未来的技术发展趋势。
传统直播方案
基于TCP/RTMP/HTTP协议，延时较大，抗弱网能力差。
HLS：10-20秒
HTTP-FLV：3-5秒
RTMP：3-5秒
复制代码
低延时直播方案
N对N实时音视频会议： 基于UDP/RTP协议，采用MCU或SFU会议模式架构系统，延时800ms之内，一个会议室中参与的多方可以进行视频通话, 每个参与者可以看到其他参与者，也能听到其他参与者说话。每个参与者既有推流，又有拉流播放，数据是双向的，CPU计算与网络带宽消耗随着参与人数增加呈现指数级上升。所以参与人数不允许太多，一般不能超过20个。 
1对N低延时直播： 基于UDP/RTP协议，但仍属于传统广播式直播业务架构, 只是延时比较低, 在400-1500ms之间，低延时直播的业务模型相对简单, 数据单向传输，一个主播推流，拉流的观众人数没有限制，成百上千万的观众同时播放都可以。 
2对N低延时连麦直播： 基于UDP/RTP协议，融合了实时音视频会议+传统广播式直播两种业务架构, 延时比较低, 在400-1500ms之间，连麦双方通过MCU节点进行音视频实时通信，观众通过传统CDN网络拉取连麦参与者的合流画面和混音。该方案兼顾实时互动连麦和低成本直播需求，支持成百上千万的观众同时拉取混合画面。 
系统架构图
低延时直播融合架构图
- rtmp推流与rtp推流/连麦音视频链路并存。
- flv拉流与rtp拉流播放的音视频链路并存。
- CDN节点与RTC节点并存融合，提高服务器和网络带宽资源的复用率。
就近接入与智能调度系统
1.传统RTMP直播推拉流过程： 
- 由SLB全球负载均衡系统负责CDN边缘节点的调度和就近接入。
- L1边缘节点一般是移动、联通或电信的单线接入服务器（成本较低、布置数量较多），L2大区节点一般是多线接入服务器（成本高、布置数量较少）。
- BGP多线服务器的费用往往数倍于单线接入服务器。所以在选择用户接入的节点时，以及选择用哪些机器构成整个网络拓扑时，我们既要考虑用户到节点的接入效果，节点间的网络情况，也要关注费用，需要做好效果和费用的平衡，产品才能持久。
2.RTS直播与RTMP直播并存的推拉流流程图： 
- 除了最开始一公里的RTP边缘推流和最后一公里的RTP边缘拉流，其他媒体流链路都是RTMP协议。
- RTP推流端与MCU节点、RTP播放端与L1融合节点之间都做平滑发送、Nack重传和FEC抗丢包、带宽预测与码率自适应、视频JitterBuffer与音频NetEQ防网络抖动策略。
直播系统开发推流端架构
- 纯直播推流端
- 主播与主播连麦端：
- 主播与粉丝连麦端：
播放端架构
传统播放器：接收基于RTMP/TCP协议的数据帧，依靠播放器的缓冲区抵抗网络抖动，延迟较大。 
低延时播放器：接收基于RTP/UDP协议的数据包，依靠网络防抖缓冲区和弱网对抗策略来抵抗网络抖动，延迟较小，播放器缓冲区设置为0。 
传统直播延时分布
低延时直播延迟分布
关键环节改造点
RTC音频编解码要支持AAC
- 目前CDN和直播中心普遍只接受AAC音频码流，而RTC客户端默认是Opus编码。
- RTC客户端的音频编解码要从Opus编码改成AAC
- MCU服务端的音频编解码处理也要改成AAC
RTC视频编解码要支持B帧
- 传统RTMP直播普遍都支持B帧，同等码率下能达到更高清晰度。
- RTC默认不支持B帧，为了不降低低延时直播系统在同等码率下的清晰度标准，我们要求把推流端、播放端和边缘节点都改造成为支持B帧，
- 另外在开启连麦过程中，主播与主播或主播与粉丝之间的RTC实时视频通信这段媒体流链路又要关闭B帧，因为B帧会加大连麦参与者之间实时通信的延迟。
RTC支持外部音频采集和播放
- 外部PCM音频帧输入接口的设计和实现。
- PCM格式音频帧输出接口的设计和实现。
- 采样率、帧时长、每帧编码采样点数、声道数的适配和对齐。
RTC支持外部视频采集和渲染
- 外部YUV视频帧输入接口的设计和实现。
- YUV格式视频帧输出接口的设计和实现。
- YUV具体格式(I420/NV12)、帧的尺寸、帧率等的适配和对齐。
流媒体传输Qos策略
RTP推流端与MCU节点、RTP播放端与L1融合节点之间要建立RTCPeerConnection连接，然后做平滑发送、Nack重传和FEC抗丢包、带宽预测与码率自适应、视频JitterBuffer与音频NetEQ防抖动缓冲区。
- 平滑发送和丢帧策略：
- Nack重传和FEC抗丢包： 视频丢包使用Nack重传，音频丢包需要从做RS-FEC前向纠错保护。
- 带宽预测与码率自适应： 采用混合的拥塞控制算法，基于丢包率和基于延迟进行码率控制。当播放卡顿时，会让发送端降码率。
- 视频JitterBuffer防抖动机制：
- 音频NetEQ防抖动机制：
TCP与UDP重传策略
- 当网络抖动出现丢包的时候，TCP是ACK确认机制，也就是发送方发送一包之后，一定要等过对方回应，才会继续发。如果说网络一旦出现丢包，就会在一个RTO(Retransmission Time Out)之后重传，RTO的值和RTT(Round Trip Time)有关，并且RTO的最小值是200ms。如果想保证流畅性，你的播放端一定要至少能容忍200ms以上的抖动，但播放端的jitterbuffer太多又无法满足低延时的要求。
- 当网络抖动出现丢包的时候，RTP是NACK确认机制，也就是发送方发送一包之后，不用等过对方回应，可以继续发送其余的包。如果说网络一旦出现丢包，接收方通过Nack形式的RTCP包返回丢失包的序列号，发送方重新发送这些网络中丢失的包即可，传输效率和延时大大降低。
信令和媒体建连过程优化
- 去掉STUN打洞过程： 商业化场景，边缘节点都有公网IP地址，省略STUN打洞过程，直接从信令服务器获取边缘节点的IP和端口号，直接填入SDP信息然后发起ICE媒体连接。
- 去掉DTLS加密过程： 去掉DTLS加解密过程，通过信令通道得到安全保障，节省信令建连协商次数。
- 去掉SRTP/SRTCP加密： 不同于音视频会议的内容相对要求私密，直播媒体流内容一般都公开对外发布，所以SRTP/SRTCP加解密过程可以去除，既减少CPU计算消耗，也节省建连的协商次数。
RTC视频流支持SEI信息
- SEI信息在推流端生成，在播放端解析并使用。
- SEI的JSON格式：
-
"BizCode":"Live|Linkmic", "BaseWidth":720, "BaseHeight":1280, "VideoRect":[0,80,720,640], "LinkmicType":"BBLink|BCLink|BBLink_PK", "CallerId": 26368040117, "CalleeId":211997614285, "LinkmicStatus":0|1|2, // 0-连麦开始 1-连麦中 2-连麦结束 “BCLinkLayout”:0|1|2, // 0-主播大画面粉丝小画面 1-主播小画面粉丝大画面 2-左右并排等画面 "BBLinkPKSession":{ "PKId":123, "PKType":0|1, // 0-点赞 1-加购 "PKDuration": 5*60, //PK时长，单位秒 } 复制代码
播放端改造
播放器端的改造有两种方式：
优势 | 缺点 | |
已有播放器集成RTC网络下行模块（FFmpeg Demux插件形式） | 保持原有播放器框架和流程；复用已有数据埋点、指标监控并保持一致性 | 延迟不是最低； 集成后整体性差；网络缓冲区与音视频取帧播放割裂，不能很好的联动；若一个App中既有低延时推流或连麦、又有低延时播放，则会出现两个WebRTC组件及符号冲突 |
使用全新的低延时播放RTSSDK (基于WebRTC下行播放链路) | 延迟最低；集成后整体性好；JitterBuffer/解码/取帧播放三个环节形成很好的整体联动；一个App中只要一个WebRTC底层组件，低延时推流、连麦、播放功能全部具备 | 有一定的接口适配工作； 数据埋点和指标监控需要统一 |
播放端实现逻辑： 
- 播放链路建连优化：需要让播放端先给媒体服务器发送播放请求, 让播放器跟自己所在的NAT网关建立映射关系，媒体服务器就可以直接把RTP数据发送给播放端了，双方不需要进行STUN打洞了。
- 播放链路断开问题：由于UDP无连接，也就没有TCP的连接断开时的挥手确认连接关闭的机制。如果播放端不再观看，媒体服务器仍然会将数据发送给播放端指定的IP和端口，这就产生了很多无效的传输。最终会反映到流量和计费日志上。我们会采用RTCP报文的方式，对于播放和推流连接的断开进行通知，节省网络资源消耗, 避免流抢占等问题。
推流端改造
基于历史遗留包袱问题，推流端的改造也有两种方式：
优势 | 缺点 | |
已有推流端集成RTC网络上行模块（对应OBS的RTMP模块） | 保持原有OBS推流框架和流程； 保持已有数据埋点、指标监控一致性 | 集成后整体性差； 采集后丢帧逻辑/分辨率和码率自动调整与拥塞控制/平滑发送等割裂，不能很好的联动；若一个App中既有低延时推流或连麦、又有低延时播放，则会出现两个WebRTC组件及符号冲突；推流与连麦切换时中途有断流 |
使用全新的低延时推流RTSSDK(基于WebRTC上下行全链路) | 集成后整体性好； 采集后丢帧逻辑/分辨率和码率自动调整/编码/拥塞控制/平滑发送等几个环节形成很好的整体联动； 一个App中只要一个WebRTC底层组件，低延时推流、连麦、播放功能全部具备； 推流与连麦无缝切换、不断流 | 有一定的接口适配工作； 数据埋点和指标监控需要统一 |
音画不同步问题
- 客户端和服务端都需要把音频帧与视频帧的时间戳打点上报后台大数据服务器，并通过图形化方式展示出来，方便开发测试人员发现与定位问题。
- 一般都采用客户端的原始采集时间戳，有音视频时间戳相差超过一定程度时(假设1秒以上)需发出告警提示。
边缘节点就近接入
- 边缘探测：
- 通过信令服务器定期下发到节点服务器和客户端的Ping包，以及客户端与边缘节点之间的媒体包的丢包率和RTT等信息，对客户端和边缘节点网络情况进行探测，并将探测数据发送服务器，从而为SD-RTN节点网路建设提供大数据依据。
- 调度服务器每隔一定周期会根据搜集到的丢包率和RTT等探测结果，进行大数据计算，给每个客户端分配一个最佳的边缘接入节点。
- 边缘就近接入
- 首先会采用就近原则、运营商匹配原则和负载均衡原则，为用户选出理论最佳的多个节点；其中就近原则和运营商匹配原则的规则，会定期由真实客户端上报的连接情况数据（丢包、时延和卡顿数据）触发做出优先级调整。
- 用户拿到分配列表后，在客户端本地会开始对各节点做一个快速的测速，选择出本次的最佳节点，去接入。其它节点会作为Failover时快速接入的选择。
- 采用这种策略，我们做到了理论分配、大数据分析与实际测速相结合，并保证了服务器不可用时的，用户快速连接恢复。
推拉流配置参数下发
- 配置下发有两种策略：
1.客户端主动Pull。 客户端定期去服务器获取配置信息，并更新本地缓存。 2.服务器Push下发。 服务器通过控制信令，通知客户端更新配置。 复制代码 - 在现有的直播业务基础上新增一个RTS播流域名，一个推流，RTMP/RTP两种方式并存拉流。
- 通过配置白名单，推流端和播放端都可以通过业务服务器进行版本灰度发布。
质量监控和评测指标
指标名称 | 指标定义 | 备注 |
端到端的延时 | 一帧音视或视频数据，从推流端的采集开始，经过中间处理和传输过程，最终在播放端被渲染呈现所经历的总时长。 | 影响观众和主播交互实时性 |
百秒卡顿时长 | 两帧间隔大于XXX毫秒算一次卡顿，将所有播放行为的卡顿时长归一化至播放时长100s下的卡顿时间，如一次播放观看时长为10s，卡顿1s，则该指标为10s | 由于卡顿发生的概率较低，该指标将大部分是0/1值 |
百秒卡顿次数 | 两帧间隔大于XXX毫秒算一次卡顿，将所有播放行为的卡顿次数归一化至播放时长100s下的卡顿次数，如一次播放观看时长为10s，卡顿1次，则该指标为10次 | 由于卡顿发生的概率较低，该指标将大部分是0/1值 |
首帧时长 | 从DNS解析、建联、收到数据包、解码到渲染出第一帧的时长 | 首屏时长是指从用户点击或滑动到该直播到渲染出第一帧的时长。 在上下滑（slide）情景下，由于存在预加载的情况，因此首屏时长小于首帧时长；而在用户直接搜索点击进入（click）的情景下，首屏时长大于首帧时长。 |
秒开比 | 首帧时长在1s以内的播放次数比所有拉流成功的播放次数 | 对于单个用户指标意义不大，假设用户只播放一次，则该比率只可能是0/1 |
拉流成功率 | 用户拉流播放，首帧渲染成功的播放次数比所有播放次数 | 对于单个用户指标意义不大，假设用户只播放一次，则该比率只可能是0/1 |
- 相同网络状态、相同推拉流设备场景下，不同的拉流链路数据对比：
- RTS拉流的端到端延时降低了75%+
- RTS拉流的播放错误率降低x%
- RTS拉流的秒开占比提升0.x%
- RTS拉流的卡顿率基本持平。
落地部署步骤
先改造推流端/先改造播放端
1.先改造推流端： 主播的并发数量一般只有几万，而播放者有成百上千万，相比较改造起来，RTS推流节点服务器数量远小于拉流节点服务器数量。另外上行链路的带宽往往小于下行链路，上行推流链路卡顿会导致全部播放用户都卡顿。
2.先改造播放端： 降低延迟明显。但需要改造和部署的拉流边缘节点服务器较多，成本会更高。不能解决上行推流链路卡顿导致的直播间全部用户卡顿问题。
RTS直播与RTMP直播并行存在
RTMP传统直播成本低廉，现已大规模部署稳定运行，在对延时要求不高的直播场景继续保留使用。
RTS直播主要用于对延迟要求高实时互动直播场景，小范围灰度、逐步迭代，稳步并行推进。
网络损伤仪和音频质量评测仪
使用Ixia网络仿真仪器，支持实验室环境下模拟上下行链路的随机丢包、突发丢包、带宽受限、加大延时和延迟抖动等弱网场景。
使用MultiDSLA语音质量评测仪，可以在各种丢包和时延抖动情况下，通过PESQ/POLQA等MOS评分，对比测试两种方案的客观语音质量。 
语音质量测试原理图
抖音直播集成RTS后测试结果
1. 直播系统开发成本对比：
- 基于SD-RTN网络构建的双向+网状拓扑式的低延时直播系统，技术不成熟、全球化和规模化部署少，费用较高。是传统CDN直播费用的2-3倍。
- 基于CDN改造的单向+广播+级联式的RTS低延时直播系统，成熟+大规模+全球化部署，费用高于传统CDN直播，但相对于SD-RTN实时音视频网络会大幅降低。
2. 直播端到端延时对比：
- 抖音直播测试效果：左边推流源(参考时钟)，中间RTS拉流(延时800ms)，右边flv拉流(延时5000ms)，端到端延时、首帧时长等直播核心指标RTS拉流比FLV拉流优势非常明显。
3. 直播核心指标和用户体验对比：
- 经验证，低延时直播核心指标表现优异：(1).相同卡顿率下，RTS低延时直播相比RTMP传统直播延时从6秒降低到1秒，降低80%以上。(2).在相同网络延时和丢包率下，RTS低延时直播的百秒卡顿时长和次数、拉流成功率、秒开率、首帧时长等指标表现均有2-20%程度的提升，大幅提升了直播实时互动体验。
转载仅为分享干货知识，如有侵权欢迎联系云豹科技进行删除处理
