停课不停学,优酷直播如何将网课点名延迟降到0.6s?

简介: 受疫情影响,各中小学校延迟开学,优酷宣布发起“在家上课计划”,为无法到校教学的老师们提供免费的直播授课工具,直播课程将于2月10日开始陆续上线,在直播过程中如何提升和保障流畅的互动体验?优酷直播流媒体团队做了低延时流媒体技术的探索实践,实现了在用户体验不下降的基础上,让主播与主播延时<300ms,播与粉丝延时<600ms,解决了直播间各类互动问题。接下来,阿里文娱的乾戒将具体介绍探索过程。

1.jpg

一、行业的用户体验分析

互动直播场景中有主麦主播、辅麦主播、粉丝三个要素,这三者之间关系构成了直播间的各种互动场景。

1.主麦主播、辅麦主播可以无障碍地进行音视频通话,通常延时在300ms以内;

2.(主麦、辅麦)主播与粉丝互动场景;主播说话,而粉丝以文字、图片、送礼物等方式进行互动;这种差别造成一次互动的延时在3000ms以上,想象一下如下互动场景:

进场特效播放完依然没有收到问候;

当主播与粉丝一起玩“王者荣耀”时需要偷塔时,无法满足;

当主播与主播PK时,其中一个主播最后几秒想拉票时,无法满足;

... ...

如何提升直播过程中三个要素之间的互动,让主播与主播之间、主播与粉丝之间达到一致的用户体验?优酷直播流媒体团队做了低延时流媒体技术的探索实践,实现了在用户体验不下降的基础上,让主播与主播延时<300ms,播与粉丝延时<600ms,解决了直播间各类互动问题。

二、作茧自缚:传统解决方案

传统直播解决方案中主播之间以实时通信的方式传输延时小于300ms,但是主播与观众之间通过链路传输、CDN分发整个延时往往在3000ms左右,如下图:

2.png

从图上我们可以看到产生延时的主要原因就是RTMP传输链路、CDN环节、观众播放器缓存三个环节产生;如果想要提升用户的体验,就必然从这三个环节上做改动,尤其是CDN把持了传输链路环节,然而CDN不是你想改就能改的。

基于这样的分析我们可以得出这样的结论:

视频CDN大大减少了开发人员的工作量;

你能做多好,取决于你控制的链路有多长;

CDN侧不可控,所以等待CDN的改变也遥遥无期;

CDN侧不可控,所以做一个和服务器交互的低延时播放器也没戏;

传统的解决方案是一张温柔而又可怕的温床。

三、蜕变之痛:低延时直播系统

针对上面的问题,我们解决方案简单粗暴:做一个全链路都可以控制的流媒体传输系统,如下图:

3.png

  1. 山重水复疑无路——项目挑战

想好就做,但是蛮干往往没有好结果。这个设计使用CDN的思想改造了整个实时通信系统,既兼顾CDN的大并发分发,又兼顾实时通信的低延时。无论是谈实时通信系统还是谈CDN都不是个小题目,何况两个融合的系统,这里面“水很深”“坑很多”。

4.jpg

然而挑战还不止这些,实际的工程中,如何降低延时、如何保证流畅率往往有是相互矛盾的话题,降低延时就要降低播放侧buffer和服务侧的buffer,随之卡顿率就会上升;而想流畅率上升就要增大buffer,随之延时就变得更长;无论怎么调整buffer,问题都这里,如何解决呢?

5.jpg

  1. 柳暗花明又一村——解决方案

低延时直播系统根据具体业务需求,融合CDN、私有实时通信协议、WebRTC、云原生等技术完美解决了项目的各类苛刻要求,把问题模型转换为技术角度看:

10.png

2.1 延时的产生及可控性分析:

7.png

从上图我们可以看出来,可控的唯二也就是传输层、播放器buffer两部分了。在低延时项目中RDN系统控制了整个传输过程,优化了每一个细节,把延时降至118ms以内,低延时播放器自适应动态控制buffer大小、严格控制音视频加减速,保证流畅率的基础上又使延时在415ms以内。通过控制播放侧目标延时实现流畅优先、延时优先两种策略,满足主播连麦互动、粉丝互动两种业务场景。

2.2 CDN进阶为RDN系统

传统的CDN、视频会议系统可以自行查看网上的方案,RDN系统是一个融合CDN架构,并以视频会议媒体服务器为节点的系统。RDN在进行媒体传输采用懒加载的方式进行,当主播把流传输至接收的边缘节点,此时如果有观众播放流,会通过GSLB返回最近的边缘节点并进行资源的索引把流快速的下发至播放侧的传输SDK。媒体流的分发示意图如下:

8.png

2.2.1 唯快不破——传输延时如何降至最低

传输延时、播放侧延时是唯二可控的部分,且看我们如何把传输降到最低:

9.jpg

2.3 播放器进阶为低延时播放器

低延时播放器是系统中延时控制的重要环节,是系统中唯一延时可控且可调的部分。相比于传统播放器功能既要满足流畅率、秒开率、音画同步等用户指标,又要保证延时足够低。低延时播放器架构图:

10.png

2.3.1 用户体验第一——低延时场景下如何保证用户体验

低延时播放器通过定制优化后的neteq,抵抗网络的抖动、丢包等问题,显著提升弱网情况下的用户体验,通过滤波后的音画同步方案,保证在音视频快速加减速同时又能保证用户的体验。

11.jpg

2.4 扁鹊全链路监控系统

扁鹊系统收集端侧、服务器侧日志,不但整个链路的服务质量,也用于排查各类线上问题。

12.png

四. 羽化之美:数据报告

在流畅率、秒开率不低于传统直播方案的场景下,互动延时指标大幅降低86%。系统自2017年稳定运行至今,为直播用户提供了低延时互动、点击即见、清晰、流畅的高质量互动直播间。并支撑了来疯秀场PK,低延时直播各类场景,保证了来疯两年多的各类比赛顺利进行。

五. 回顾历史:我的思考

低延时直播系统是由传统直播技术、实时通信技术、WebRTC技术融合,专为互动直播而生的系统。达到了文字和音视频同步的效果,像“欢迎大哥”“拉拉票”、“打他”这些欢迎、拉票等直播互动再也不需要等待。回顾整个系统的诞生,我的技术思想也在逐渐的变化,回想初次接触这三个技术:

传统直播技术 = RTMP、CDN、ijkplayer

实时通信技术 = MCU、SIP、RTP/RTCP

WebRTC技术 = JSEP、P2P 、SFU、ICE、SDP、neteq

后来深入了解这些技术细节、互动直播业务的需求、开发过程中的痛点,开始思考可以用这些技术再往前走一步,自研一套低延时直播系统一劳永逸的解决这些问题。经过前期详细论证确定正确方向后,虽然过程困难重重,秉着“只要路对了就不怕远”“只要精神不滑坡,方法总比困难多的”精神,最终还是安全的抵达了对岸。

目录
相关文章
|
9月前
|
开发框架 前端开发 JavaScript
元框架
【10月更文挑战第5天】
243 56
|
7月前
|
供应链 NoSQL Java
关于Redisson分布式锁的用法
Redisson分布式锁是实现分布式系统中资源同步的有效工具。通过合理配置和使用Redisson的各种锁机制,可以确保系统的高可用性和数据一致性。本文详细介绍了Redisson分布式锁的配置、基本用法和高级用法,并提供了实际应用示例,希望对您在实际项目中使用Redisson分布式锁有所帮助。c
1023 10
|
Cloud Native 安全 持续交付
计算巢是什么?计算巢提供了哪些服务?
本文简要介绍了计算巢和计算巢提供的服务。
|
12月前
|
存储 缓存 监控
Redis问题之使用Guava Cache相比自己设计本地缓存有哪些优势
Redis问题之使用Guava Cache相比自己设计本地缓存有哪些优势
132 0
|
监控 搜索推荐 Go
万字详解!在 Go 语言中操作 ElasticSearch
本文档通过示例代码详细介绍了如何在Go应用中使用`olivere/elastic`库,涵盖了从连接到Elasticsearch、管理索引到执行复杂查询的整个流程。
264 0
|
设计模式 消息中间件 存储
性能优化:关于缓存的一些思考
利用缓存做性能优化的案例非常多,从基础的操作系统到数据库、分布式缓存、本地缓存等。它们表现形式各异,却有着共同的朴素的本质:弥补CPU的高算力和IO的慢读写之间巨大的鸿沟。
性能优化:关于缓存的一些思考
|
Java 中间件 测试技术
研发效能的思考总结
很多时候,我们一直在思考如何高效支撑业务这个课题上。阿里技术分享平台或者网上都有非常多的文章分享,每个TL针对自己团队的状况也有一套自己的方法论。本文作者将结合自己所面临的状况,把自己的思考总结分享给大家。
研发效能的思考总结
|
架构师 程序员 开发者
关于技术能力的思考和总结
要解释清楚什么是技术能力还得看透技术能力的本质,从源头上来做剖析。本文将挑选几个程序员日常的工作问题来做个剖析比对,从我们的日常感观中来辨识下哪些是有技术能力的做法,哪些是没啥技术能力的做法。
关于技术能力的思考和总结
|
架构师 前端开发 流计算
阿里10年沉淀|那些技术实战中的架构设计方法
上周我写的一篇文章《关于技术能力的思考和总结》引起了大家的关注,好多读者的评论“以写代想、以想促真、以讲验真”,大家的感受很深刻,基于上次的文章,这篇文章我其实更想跟大家聊聊一些常用的思考方法,思考问题的方式对了,往往可以帮助大家少走弯路。
阿里10年沉淀|那些技术实战中的架构设计方法
|
监控 网络协议 Ubuntu
eBPF 深度探索: 高效 DNS 监控实现(上)
eBPF 深度探索: 高效 DNS 监控实现(上)
800 0
eBPF 深度探索: 高效 DNS 监控实现(上)