针对直播痛点的关键技术解析

良好的直播体验一直是直播产品留住用户的关键流量密码。

国内直播行业已呈现一片红海，各直播产品的用户增长速度在逐渐放缓，行业内竞争进入白热化阶段，急需通过在直播体验上的精细化运营来保障平台营收。如针对重大活动、头部主播进行直播体验优化保障。

对于出海 APP 来说更是如此，复杂的网络环境、机型设备等问题，导致直播产品面临诸多体验问题，如首帧加载时间过长、画面模糊、卡顿等，极度影响了用户的直播观看体验，导致头部主播离家出走、营收下降、用户流失严重、APP 活跃度下降等问题，而以上问题出现的原因通常可以从网络、设备、成本三方面来进行归纳。

1、直播体验拦路虎

• 网路环境复杂
• 地区之间网络差异巨大
• 存在跨网等情况
• cdn 质量不稳定

• 终端设备机型种类繁多
• 部分地区低端机型占比高、问题复杂

• 使用 RTC 做直播效果好，但成本较高
• 画质高清带来成本增加，还容易引发卡顿，该如何确定合适的画质是让人头疼的问题
• 全链路数据监控系统复杂
• 如何将有限的资源更好的用在高收益的地方

2、「畅直播」全链路升级一站式直播服务

面对直播体验困扰，2022 年 6 月 20 日，全球云通讯服务商 ZEGO 即构科技发布了「畅直播」全链路升级一站式直播服务，助力当前直播行业进行直播体验升级，打造直播体验优化的理想态 —— 以用户为核心，在秒开、高清、流畅等评价角度之间取最优解；在精细化提升用户体验的同时，帮企业节省成本。

「畅直播」服务方案重点针对首帧耗时长、画质模糊、直播卡顿等常见直播现象进行了全链路优化。同时以 All-in-one SDK 的服务方式，集直播、实时音视频、AI 等全音视频能力于一体，一次流畅接入 SDK，不仅能覆盖全场景直播需求，还能实现实时音视频和直播等多场景的切换。

本篇文章将针对秒开、清晰度、流畅度这三个技术方向进行技术解析，带你了解 ZEGO 即构科技在畅直播服务方案上的核心技术优化思路。

直播行业通常更加关注打开直播时的首屏加载时间，音画的流畅度和清晰度等是直接关系到用户体验的指标。这好比我们在观看电视台时，无法接受从央视 1 频道切换到央视 2 频道的时候，需要等待几秒才能看到画面，同时也无法将自己沉浸在画面模糊甚至是卡顿的影音世界。

为降低频道切换的响应延迟，增强用户体验，秒开技术成为了刚需。

我们先分析一下用户从点击进入直播间，到用户看到画面听到声音大致经过的步骤：首先要为用户分配一个接入点，用户从该点拉流，分配接入点的过程我们称之为接入调度；然后客户端需要与接入点间接进行拉流；接入点如果不存在该流还需要从其他服务器将该流引入接入点，我们称之为回源；这些都完成后，客户端才可以收到音视频内容，进行播放。

这些步骤中的每一步都会影响秒开体验。

1、可定制化的调度策略

首先说一说接入调度。接入点的好坏直接影响拉流质量，也直接影响建连速度。如果客户端与接入点的网络较差，比如存在 200ms 的 RTT，那么即使能在一个 RTT 内完成建连和拉流，这里至少也需要 200ms 后才能看首帧画面。如果存在丢包，可能会引入更大的延迟。传统的 CDN 是使用域名解析的方式来指定接入点。一定程度上解决了就近接入和负载均衡的问题，但是仍然无法实现更精准的可定制化的调度策略。

ZEGO 为了解决这些问题，自建了调度系统。该系统可以根据客户的业务模型定制最合适的调度方案。即构自建的统一接入层，负责解决全球用户第一公里的接入质量，能保证用户接入到时延质量最优的接入节点。

例如我们实现了可以精确到人级别的调度能力，这样可以在资源有限的情况下，优先保证热门主播直播间的体验。简单的说就是，热门主播会得到标记，标记后的热门主播会得到全网最好的接入资源，观众因为拉取热门主播的流，同样可以得到最好的接入资源而带来更好的观看体验。

再例如 ZEGO 的调度系统可以结合源的位置给出最合适的接入点：比如主播在深圳推流，如果单纯的根据就近接入的原则，那么这个观众大概率会选择广州的接入点。这样广州的接入点需要回源到深圳，这样分发的链路变长，不但增加成本，而且回源也引入了更多延迟和增加了首屏加载时间。ZEGO 的调度系统由于参考了源的位置，广州的观众可以直接从深圳拉流，而无需回源。当然，这里的前提是我们认为广州的观众接入广州或者接入深圳并无链路质量上的差别。域名解析的方式，由于无法带入源信息的原因，无法实现如此精准的调度。

另外，链路的质量可能是时变的，在不同的时间段可能存在不同最优接入点，由于 DNS 缓存的原因，域名解析的方式也很难及时的给出时变的调度结果。总之，ZEGO 的调度系统考虑到了空间，时间，运营商，热度，位置等信息，给出最优的调度结果。

2、建连和回源

然后我们说一说建连和回源。由于 TCP 协议三次握手的存在，建立一个 TCP 链接至少需要 1.5个 RTT，加上应用层的数据交换，用户至少要在 2 个 RTT 之后才能看到首屏画面。而 ZEGO 通过优化私有协议，可以实现 0 RTT 建连，最少可以在 1 RTT 后即可展现首屏。

另外，一种直观的回源方式是逐级回源，可以看成是串行的方式：A 回源到 B，B 发现自己并不存在该流资源后再回源到 C。这种多级跳转在跨国线路中普遍存在，有时需要 4-5 跳才能实现很好的传输效果。但多跳的链路会使得串行的回源方式显得低效，回源的总时长为各跳之和。

以上打通了整个传输链路，拉流端可以接收到音视频数据。

3、播放器的自适应缓冲技术

影响秒开的最后一个环节是播放器。

目前很多开源的播放器为了减少卡顿，都需要预先设置一个播放的缓冲区，填满缓冲区后才开始解码渲染。缓冲区设置的太小容易频繁卡顿，缓冲区太大，填满缓冲区的时间变长，直接影响秒开体验。

而 ZEGO 的播放器则采用了自适应的缓冲技术，在播放过程中，实时的根据网络的好坏即时的调整缓冲区的大小来应对网络的变化。也不存在填满缓冲区才开始解码播放的问题，可以理解成，首帧收到的那一个刻已经开始解码渲染。相比填满缓冲区才开始解码渲染，假定设置 1 秒的缓冲区大小，即使拉流初期以 5 倍于实时码率的速度进行传输，填满缓冲区也要 200ms，这里的优化显著。

秒开方案上线后，国内大盘秒开率达到 99%，在所有的秒开行为中，85.07% 的用户在 500ms 内打开，秒开率相对提升 14.5%，在泰国等网络较好的区域，实现 96.8% 的秒开率。

聊完秒开的问题，我们谈一下清晰度和流畅度的问题。自然地，好的链路质量是保障传输质量的最优途径，好的传输质量使得用户可以使用更大的分辨率和更高的码率，以此来提升视频清晰度，好的传输质量自然也可以提供更好的流畅度的保障。

但是现实可能让人失望，比如在不使用专线的情况，跨国链路总是存在常态的丢包，如中国到欧洲的一些国家总是存在 200 ms RTT 和 30% 左右的丢包。传统的 CDN 使用 TCP 进行传输，即使在接入的第一公里和最后一公里实现了更多类型的协议接入，但在节点之间仍然使用 TCP 协议。TCP 在 200ms RTT 和 30% 左右的丢包几乎不能实时传输，即使是 QUIC 协议也不能很好的工作。

ZEGO通过自研的传输算法和自有协议，很好的提升了弱网表现。

有人认为传输并不难，只要多重传几次，多加些冗余总是能做到可达。事实上，ZEGO 瞄准高效传输，将传输的目标定在每个包在接收端收到且只收到一次。如果收到重复包，重复的包被认为无效传输。无效传输会给网络带来更大的负载，消耗更多的带宽资源，尤其是在带宽受限的时候无效传输越多，就只能通过更大程度的降低音视频的码率来获取通过性。因此，ZEGO 将目标定在了保证流畅性的同时无效传输不能超过 5%。

传输中另一个难点在于，如何区分丢包是拥塞引起的丢包还是一种常态丢包。两者的区别在于如果拥塞引起的丢包，那么适当的降低码率，丢包会有所缓解甚至消失。这样的情况下，需要主动降低码率，以避免更多的丢包而造成卡顿。而常态的丢包则不同，丢包情况并不会因为降低码率而发生明显的变化，换句话说，丢包并不是“你”造成的。这种情况下不降低码率才是更好的选择。在这方面，ZEGO 的工程师下足了功夫，这就是 ZEGO 可以做到 70% 丢包下仍然可以流畅，50% 丢包下流畅的同时，画面质量不会明显降低的秘密。另外，结合 AI 的视频修复技术，即使链路带宽真的只有 100kbps，也可以将因为编码码率不足而产生的块效应去除，提升画面质量，超分辨率技术也为低码高清提供了保障。

另外，ZEGO 在全球近 200 多 IDC 部署了边缘媒体服务，为用户提供最优的接入质量；在海外一些地区网络复杂，质量参次，我们综合使用线上大数据指导，和用户侧主动探测的技术来找到最优的覆盖点，使接入质量达到最优；并且过程中我们会监测质量的变化，质量变差时我们会启用动态探测调整覆盖点，以此来保障直播质量。

畅直播的系统架构，可以灵活高效的解决流畅性全链路问题，支持不同业务场景。一次接入，即可获得 CDN 直播、CDN Plus、L3 等多种服务，并可针对地区、人群等多种维度，通过控制台、API 等设置差异化服务，且平滑切换 RTC 连麦。

All-in-One 全链路升级的一站式直播服务，秒开、流畅、超高清画质，一次接入，畅享直播！

更多技术细节欢迎关注后续内容！

原文链接：https://blog.csdn.net/zego_0616/article/details/125448554?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165934458816782246424718%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165934458816782246424718&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-1-125448554-null-null.nonecase&utm_term=%E8%87%AA%E5%BB%BAcdn