衡量直播平台的推流效果，主要看这5个指标

近年来，网络直播呈现爆发式增长，上百家平台，超百亿规模，3亿多用户，上市公司和明星企业崛起，俨然成为产业。光环加持的背后，腾讯云直播TLive平台，抓住机遇、持续打磨、不断优化，最终做到了业界领先。现主播作为直播产品的源头，主播推流质量好坏直接影响腾讯云直播体验和口碑。我们致力于使用CDN节点就近资源&协议栈加速等措施，保障主播稳定出流。

那么问题来了，什么是推流呢？

如何保证推流质量呢？

01

推流关键问题分析

腾讯研究院调研报告显示，网络主播群体正从一线二线大城市，向三四线城市乃至农村延伸。并且于此同时，直播游戏化的趋势越来越明显。随着吃鸡游戏的盛行，游戏主播纷纷进入了高码率时代，游戏直播码率动辄8/12/20 Mbps，这对主播上行网络链路提出了不小的挑战。本文主要着眼解决推流的两大关键问题：

（1）弱网推流加速：保障偏远/弱网环境下的主播推流问题，避免发生主播推流慢速。

（2）高码率稳定传输：优化直播推流链路，保障高码率的直播流上行持续稳定；

02

衡量指标

工欲善其事，必先利其器，推流加速开始前，我们需明确主播推流的评价体系，让优化效果有章可循。列举以下推流的关键指标：

1.推流卡顿率

目前行业内没有统一标准的卡顿率定义，Tlive认为服务器5s内收到的音视频数据时长小于4s，视为推流卡顿；推流卡顿率=卡顿时长/推流时长。

2.帧率抖动

5s统计一次直播流视频帧率，1min计算一次帧率方差，方差过大，视为推流帧率抖动.

3.本地覆盖率

主播推流到同省同运营商服务器，视为本地覆盖。跨省和跨运营商视为异地覆盖；本地覆盖率=本地推流次数/推流总次数。

4.转推慢速比

本地接流服务器将流转推给直播中心流媒体处理服务器的过程中，如果应用层积压音视频帧超过一定阈值，视为转推慢速。转推慢速比=慢速流数/总流数。

5.播放卡顿率

目前行业内没有统一标准的卡顿率定义，观众端播放器缓存耗尽无数据可播视为播放卡顿，对应到播放器的loading事件。[T1] 卡顿率=卡顿时长/播放时长 

03

具体技术点

1.贴身服务

主播地理分布广，网络接入环境复杂。主播推流经常需通过公网跨省，走骨干网到腾讯服务器，传输质量得不到保障。我们运用CDN遍布全国各地的OC服务器，实现主播推流的就近接入，俗称“贴身服务”。

通过引入本地OC，Tlive将原本复杂的跨省直播推流，简化为本地服务，缩短了主播接入直播服务的距离，降低主播推流卡顿的几率。复杂的远程传输问题，交由腾讯Tlive专业解决。

2.资源优化

依据“贴身服务”的思想，我们最直接的问题：让主播连接的推流节点不出省。

（1）堆资源

通过增加OC资源覆盖率，提升主播的本地覆盖率；

（2）存优去劣

在OC资源充足的省份，通过质量监控统计分析，选用最优的OC资源服务主播推流；

（3）优化用户资源

出于容灾的考虑，直播客户会同时使用几家的云厂商，主播一般直推其中一家，再由直推的厂商转推其他厂商。通过分析发现，主播是否直推腾讯云，推流卡顿率差别很大。下图是腾讯云某直播大客户的直推和转推慢速对比，直推比转推推流卡顿比要低50%；

主播直推取决于客户的信任，是个长期互信建立的过程。通过高质量的直播服务，方能推动客户多直推，而更多的直推又会进一步提升腾讯云质量，增加客户信任形成良性循环，否则即是恶性循环。

3.精准调度

资源充足了，如何利用好资源，是我们关注的重点。我们致力于通过精准调度，实现主播和资源的最佳匹配，最大限度发挥优质OC资源的效益。

（1）IP调度优化

主播推流常采用DNS域名解析的方式，获取推流服务器IP地址。这种寻址方式过度依赖用户Local Dns配置，主播DNS配置错误，服务端也无计可施；Tlive通过提供IP调度服务，支持HTTP-DNS的寻址方式，精准识别主播地理和ISP信息，为其分配最合适的OC资源。以A数据为例，上线IP调度前后，推流卡顿“降低了80%。

（2）IP库优化

IP调度服务的精准性，取决于用户地理位置和接入运营商信息的识别。实际运营中，我们发现A客户经由某厂商转推到腾讯云直播流，因为ip库不准，导致网络调度不正确，从而导致网络丢包；腾讯云TLive综合腾讯线上多年积累的IP地理数据以及第三方IP库，基本规避了IP库相关的客户问题；

（3）去IP库化

虽然利用IP地理数据思可以降低错误率，但并未从根本上解决调度准确性的问题，各家CDN厂商使用的IP库存在着不一致的情况。在流转推的过程中，绕过IP库解析，自带ISP和位置信息，从根本上保障调度的准确性。此项优化是个长期的过程，目前已经在A业务中上线，其他业务持续推进中。

4.传输优化

通过“贴身服务”、“资源优化”、“调度优化”，我们基本解决了主播稳定出流的问题，但是直播流跨省主干网传输网络抖动的风险依然存在。我们主要从两方面努力：

（1）IDC质量探测

通过IDC机房，部署小文件下载服务，OC每隔一段时间通过小文件下载，对IDC机房进行可用性和质量拨测。OC收到主播推流后，会选用传输质量做好的IDC机房作为转发的目的地。

2）QTCP协议栈加速

主播推流数据是一边产生一边传输，稳定的传输相比爆发式强占带宽更为重要，因为直播画面是有严格的时序，前面的画面数据丢包了，就算后面的数据到了也无法播放，和传统的文件下载场景有很大的区别。针对这一点，我们采取了Pacing发包策略来尽可能的避免丢包。配合协议栈参数的调整，我们将转推慢速比率降低了61%”。

（3）高码率流传输优化

随着吃鸡游戏的盛行，游戏主播纷纷开启了高码率游戏的直播，直播码率动辄8/12/20 Mbps，这对网络链路提出了不小的挑战。鉴于直播特殊的业务场景--“码率稳定，实时产生”不存在抢占链路带宽的风险，我们调整拥塞控制策略，实质性的放弃Cubic拥塞算法，将传输速率控制在码率的1-1.2倍之间。同时，鉴于每路流的码率都不一样，我们需要将应用层的信息以socket参数的形式通知到内核协议栈，确保传输速率符合码率要求。通过高码率的专线优化，平台转推慢速降低了40%。

04

整体效果展示

以A业务为例，我们通过资源、调度、传输的优化实现了，转推慢速比降低了77%。

播放端播放平均卡顿率从4.29%降为3.63%。中度和重度下降则更为明显。