网易云信:直播体验深度优化方案——连麦互动直播

2023-12-29 01:40

本文主要是介绍网易云信:直播体验深度优化方案——连麦互动直播,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

  • 前言

移动直播这把火从2015年一直烧到2016年,毫无疑问直播是当前移动互联网最热门的领域之一,在超大热度的引导下直播领域也吸引了大量的商业资本。在这各大直播应用万花齐放的时刻,也正是直播应用面临的真正风口。站在这个风口上,直播应用只把握好风向标,推出具备高用户粘性的差异化功能,才能在这个不断推陈出新的时代站稳脚跟,获得不可动摇的地位。

图片描述
(移动直播火爆)

当前国内大多数的直播应用,使用的是单主播模式,主播与观众仅仅使用文字、点赞、礼物等方式进行互动。在主播直播时,观众如果能够与其进行实时的视频互动,给观众连麦露脸的机会,这将大大提高用户的参与感与幸福感,增加用户粘性。而且市面上能够提供这种连麦互动直播功能的应用还非常少,这也将成为2016下半年各直播应用的主要竞争领域。


  • 连麦互动直播是什么

为了更直观的阐述互动直播是什么,举个简单的例子。传统直播就像看“新闻联播”,观众只能收看这个节目,偶尔能通过手机短信发信息与节目组进行互动。当然现在基于互连网的直播已经先进得多,可以使用互联网发送文字、点赞、送礼物,消息的实时性也大大提高,但本质上与看“新闻联播”的体验类似。

而互动直播就像到达芒果台快乐大本营的录制现场,观众坐在录制现场的观众席上,可以看节目,同时还有机会被邀请到台上和主持人互动,当然主持人可以邀请多名观众上台进行互动,而互动的内容其他观众也能看到。

图片描述
(连麦互动直播)

图片描述
(传统移动直播)

连麦互动直播相比传统单向直播,给了观众更直接的参与感以及与主播音视频实时互动的满足感,对提升直播应用的活跃度和粘性都有明显作用。


  • 连麦互动直播功能流程

图片描述
(连麦互动直播功能流程图)

① 主播正常开始直播,普通观众看到主播的单人直播画面;
② 需要连麦的观众发起连麦请求,进入连麦申请列表;
③ 主播从连麦申请列表中选择一名或多名观众进行连麦操作,主播与连麦观众进行实时音视频互动,同时互动直播系统生成“合成画面”;
④ 普通观众看到直播画面为包含主播与连麦观众的“合成画面”;
⑤ 连麦结束,恢复主播单人直播模式。


  • 连麦互动直播实现方案

接下来我们探讨一下连麦互动直播的具体实现方案,这部分将主要阐述互动实时性高且具备真实可行性的两种方案。这两种方案网易云信在项目中都有实践,下面会详细分析各自的优缺点。

为了实现互动实时性高的连麦,首先需要有一套实现了类似微信、Skype及Facetime的多人音视频实时通话系统。这套实时通话系统可以选择自主研发或者基于开源软件如:Google的WebRTC做二次开发,网易云信自主研发了一套基于私有协议的多人实时通话系统,下面简单介绍多人实时通话系统的一些重点技术细节。

多人音视频实时通话系统为了降低通话时延,我们使用UDP协议作为传输层协议,众所周知UDP协议是不可靠,为了提高弱网下的实时音视频的通话效果,需要使用相关方案来做QoS保障,主要包括:

a)使用基于网络状态的音视频码率自适应算法,根据当前网络的丢包、时延自适应降低或者升高音频和视频的码率和帧率,通过这个方法来降低网络的拥塞,提高通话质量;
b)使用智能Jitterbuf算法来平滑网络抖动,同时内部使用音频编码的丢包补偿(PLC)算法进一步提升通话质量;
c)使用基于多层参考的视频编解码器,降低视频丢包后的卡顿;
d)整个UDP传输层使用前向纠错FEC算法进行智能保护,最大限度上保证实时音视频通话的效果。根据我们的实际测试,在使用上诉QoS保障策略以后,音视频通话可以抗20%丢包和600ms的网络抖动。

多人音视频实时通话系统为了在保障质量的前提下尽量降低通话流量,音频编解码主要以Opus为主,Opus融合吸收了CELT和SILK编码的各种优点,具备高音质,高压缩率,高抗丢包等特性,非常适合移动网络。视频编解码我们使用OpenH264,OpenH264编解码性能优秀,同时具备:动态码率、动态帧率及时域分层等多项适合移动网络实时通话的特性。同时我们使用了自主研发的降噪算法,配合回声消除、自动增益和舒适噪音等音频处理算法来进一步保证音频的质量。

现在用户对于视频的清晰度要求越来越高,我们的多人实时通话系统能够支持720p,720p下纯软件编解码对CPU开销过大,因此在可以开启硬件编解码的机器上,对于需要720p清晰度的都尽量使用硬件编解码。对于苹果手机硬件编解码基本上只与iOS的版本相关,而Android情况就会复杂得多,不仅与手机硬件相关,还和各个手机的ROM相关,为了解决这个问题需要去做适配。我们在网易强大的移动应用测试部门的配合下,为大多数的Android设备做了适配。

没有覆盖全球的服务器部署与网络拓扑搭建,是不可能构架出一套完善的多人音视频实时通话系统的。依赖网易云在全球范围内的机房节点,我们搭建了多个多线接入网络拓扑,部署了高可用的服务器集群,并利用智能分配算法与路由策略,为跨省、跨运营商、跨国的多人实时通话提供优质的传输通道。

要实现效果理想的连麦互动直播,一套强大完善的多人实时通话系统是前提。在简单介绍完一套强大的多人实时通话系统的需要具备的特点后,接着我们就可以讨论下连麦互动直播的具体实现方案了。

方案一:

传统的直播流程是:主播客户端采集并编码音视频数据以后,直接使用RTMP协议推流到CDN,其它观众使用对应的拉流地址向CDN拉取音视频流。

该方案使用实时通话系统来进行主播和观众的实时互动连麦,通过实时通话通道主播端收到观众端发送的音频和视频数据,主播端将自己的声音和观众的声音做混音,并将自己的画面与观众的画面做视频合成,最后将混合的声音和画面推流到CDN流媒体服务器。架构图如下:

图片描述

方案优点:

主播和连麦观众使用了实时音视频来进行连麦互动,实时性高,观众看到的合成画面里主播和观众的互动也是同步实时的。
方案对原有直播推流客户端改动不大,服务端都不需要修改。方案整体的实现简单,利用现有的系统和SDK就可以快速搭建。

我们在网易BOBO Windows端实现的连麦互动直播就是采用这种方案,该方案在2015年下半年上线后运行稳定。这个方案虽然简单可行但对于移动端来说就有两个比较致命的问题:

一、 主播端的带宽压力很大,从架构图中可以看出,主播端必须通过实时通话系统发送一份音视频数据给连麦观众,同时还需要推送一路流到CDN流媒体服务器。所以相比单人直播,连麦后主播端的上行流量将变为原来的两倍。这个两倍的流量在Windows端稳定的有线网络环境下影响不大,但在上行带宽本来就有限移动网络下,将会大大影响直播的效果。

二、 主播端的视频编解码压力很大,与造成带宽压力大的原因一样,主播必须编码一路视频给连麦观众,同时需要合成并编码一路推到CDN,两次编码对于移动端的性能压力非常大,经过真机测试对于720p的分辨率的连麦互动直播仅在旗舰机型上可以勉强支撑,但发热和耗电会大大增加。
由于上述两个问题,我们认为方案一在移动场景下是不太适用的。

方案二:

为了解决方案一的问题,我们团队用3个月时间来做技术攻关,设计并开发了一个替代方案。架构图如下:

图片描述

本方案作为优化替代方案,方案的关键是:主播不再直接推流到CDN流媒体服务器,而是基于实时音视频通话系统,由实时音视频的中转服务器转发给互动直播服务器,再由互动直播服务器处理后推流到CDN流媒体服务器。

多人音视频实时通话系统,可以实现多人的实时互动,而且多人模式下所有的数据包都是通过音视频中转服务器中转。音视频中转服务器在转发给参与客户端的同时,转发一份到互动直播服务器,互动直播服务器对收到的语音进行混音,同时对视频画面做混合处理,处理完毕以后再推流到CDN流媒体服务器。通过这种方案,将方案一中由主播端做的混音混合及推流操作,转嫁由互动直播服务器来承担。

方案优点:

主播和连麦观众使用了实时音视频来进行连麦互动,实时性高,普通观众看到的合成画面里主播和观众的互动也是同步实时的。
可以实现多人连麦互动直播,功能差异化明显。
所有客户端的上行推流不再依赖基于TCP的RTMP协议,而是使用网易自研的基于UDP的高性能私有协议,传输层的QoS保障更加智能高效。
方案一中主播端的带宽和性能压力不复存在,本方案非常适合移动端的连麦互动直播。

当然本方案虽然有很多优点,但是实现起来也是最困难的。首先本架构涉及到实时通话系统与互动直播系统两大系统的融合,架构和代码复杂度高。特别是互动直播系统,由于要处理视频的混合,对服务器端代码的性能和硬件要求都很高。我们为了解决这个问题,使用了网易机房里多台高性能物理机作为连麦互动直播服务器,并且不断优化服务器端代码架构和处理流程,通过不断的优化,最终满足了业务需求。综上,我们认为本方案是当前最适合移动端的连麦互动直播方案。


  • 展望未来

2016年作为移动直播元年,全球范围内的开发者和公司都在思考如何提供更加优质的服务。我们认为内容永远都是直播发展的王道,作为研发工程师的职责就是为内容的传输保驾护航,提供高清、流畅且延迟低的直播内容。而差异化的功能将成为直播应用的亮点,其中拥有连麦互动的直播应用将会在增加用户的参与度、幸福感的同时提高用户粘性,连麦互动直播的重要性也就不言而喻了。

科技永远都是第一生产力,当前VR虚拟现实技术与直播一样火爆。而VR与直播结合的VR直播能够让观众身临其境,它独特的互动方式或许在不久的将来,就会在直播领域掀起新一轮的变革。而互动直播在未来将是一个以泛生活和场景化直播为主题,充分结合VR技术,全面开启新闻、旅游、教育、医疗等全场景沉浸式“直播+”时代。

(原文:http://netease.im/blog/lmhdzb/)

这篇关于网易云信:直播体验深度优化方案——连麦互动直播的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/547969

相关文章

Python通过模块化开发优化代码的技巧分享

《Python通过模块化开发优化代码的技巧分享》模块化开发就是把代码拆成一个个“零件”,该封装封装,该拆分拆分,下面小编就来和大家简单聊聊python如何用模块化开发进行代码优化吧... 目录什么是模块化开发如何拆分代码改进版:拆分成模块让模块更强大:使用 __init__.py你一定会遇到的问题模www.

Java图片压缩三种高效压缩方案详细解析

《Java图片压缩三种高效压缩方案详细解析》图片压缩通常涉及减少图片的尺寸缩放、调整图片的质量(针对JPEG、PNG等)、使用特定的算法来减少图片的数据量等,:本文主要介绍Java图片压缩三种高效... 目录一、基于OpenCV的智能尺寸压缩技术亮点:适用场景:二、JPEG质量参数压缩关键技术:压缩效果对比

SpringBoot首笔交易慢问题排查与优化方案

《SpringBoot首笔交易慢问题排查与优化方案》在我们的微服务项目中,遇到这样的问题:应用启动后,第一笔交易响应耗时高达4、5秒,而后续请求均能在毫秒级完成,这不仅触发监控告警,也极大影响了用户体... 目录问题背景排查步骤1. 日志分析2. 性能工具定位优化方案:提前预热各种资源1. Flowable

SpringBoot3实现Gzip压缩优化的技术指南

《SpringBoot3实现Gzip压缩优化的技术指南》随着Web应用的用户量和数据量增加,网络带宽和页面加载速度逐渐成为瓶颈,为了减少数据传输量,提高用户体验,我们可以使用Gzip压缩HTTP响应,... 目录1、简述2、配置2.1 添加依赖2.2 配置 Gzip 压缩3、服务端应用4、前端应用4.1 N

Spring Boot + MyBatis Plus 高效开发实战从入门到进阶优化(推荐)

《SpringBoot+MyBatisPlus高效开发实战从入门到进阶优化(推荐)》本文将详细介绍SpringBoot+MyBatisPlus的完整开发流程,并深入剖析分页查询、批量操作、动... 目录Spring Boot + MyBATis Plus 高效开发实战:从入门到进阶优化1. MyBatis

SpringCloud动态配置注解@RefreshScope与@Component的深度解析

《SpringCloud动态配置注解@RefreshScope与@Component的深度解析》在现代微服务架构中,动态配置管理是一个关键需求,本文将为大家介绍SpringCloud中相关的注解@Re... 目录引言1. @RefreshScope 的作用与原理1.1 什么是 @RefreshScope1.

MyBatis 动态 SQL 优化之标签的实战与技巧(常见用法)

《MyBatis动态SQL优化之标签的实战与技巧(常见用法)》本文通过详细的示例和实际应用场景,介绍了如何有效利用这些标签来优化MyBatis配置,提升开发效率,确保SQL的高效执行和安全性,感... 目录动态SQL详解一、动态SQL的核心概念1.1 什么是动态SQL?1.2 动态SQL的优点1.3 动态S

Java进行文件格式校验的方案详解

《Java进行文件格式校验的方案详解》这篇文章主要为大家详细介绍了Java中进行文件格式校验的相关方案,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录一、背景异常现象原因排查用户的无心之过二、解决方案Magandroidic Number判断主流检测库对比Tika的使用区分zip

Python如何使用__slots__实现节省内存和性能优化

《Python如何使用__slots__实现节省内存和性能优化》你有想过,一个小小的__slots__能让你的Python类内存消耗直接减半吗,没错,今天咱们要聊的就是这个让人眼前一亮的技巧,感兴趣的... 目录背景:内存吃得满满的类__slots__:你的内存管理小助手举个大概的例子:看看效果如何?1.

一文详解SpringBoot响应压缩功能的配置与优化

《一文详解SpringBoot响应压缩功能的配置与优化》SpringBoot的响应压缩功能基于智能协商机制,需同时满足很多条件,本文主要为大家详细介绍了SpringBoot响应压缩功能的配置与优化,需... 目录一、核心工作机制1.1 自动协商触发条件1.2 压缩处理流程二、配置方案详解2.1 基础YAML