CCtalk高可用多媒体服务技术选型与实现

  • 时间:
  • 浏览:0
  • 来源:5分11选5APP下载_5分11选5APP官方

1、主流直播方案

文 / 杨福强

而CCtalk也不没法 另1个多支持多种教学工具的实时大规模并发教学平台。在最结束了英文实现四种 平台的然后,亲们儿采用了否则 开源方案,如webrtc,但我应该 发现直接使用开源方案无法为完全满足教育直播的需求,否则 亲们儿自研发了一套客户端AV引擎:

从图中能不还都还还可以看到,所有的客户端与信令系统之间有另1个多TCP长连接,来实现PPT、白板笔、答题卡、文字聊天等等教学相关的小工具;所有的用户与媒体服务之间有一路TCP或UDP的连接,实现老师与学生之间的双向实时音视频互动,比如说老师上课的然后,将产生的实时音视频数据发送到媒体系统,媒体系统按照一定的路径将媒体数据发送到学生端;否则 学生端也上麦了,没法 学生端产生的音视频数据也会经过媒体系统转发到老师端,原来就完成了另1个多教学场景下的双向音视频互动。共同,媒体服务会旁路推流一路RTMP到CDN,学生端能不还都还还可以在HTML5网页里直接观看实时单向直播,原来就满足了在大型直播中网页传播的诉求。另外媒体服务器会将上课时产生的音视频数据发送一路到录制服务,共同信令系统会将上课时产生的PPT、白板笔以及文字聊天等内容发送一份到录制服务,录制服务收到所有上课内容后,将它们以元素的形式存储下来,存储下来的四种 格式叫做OCS回顾,便于课后回顾。

四种 架构分为两大部分:信令系统和媒体系统,整个架构中的所有服务设计功能单一、特性简单,否则 所有节点支持线性扩展,理论上它能承载的人数是没法 上限的,你假若加机器就能不还都还还可以了,所有的节点支持失效自动转移,这套系统亲们儿用了很长一段时间,但在使用的过程中还是发现了否则 大大问题,以媒体系统为例,首先另1个多是大大问题是处在中心节点,这就意味着着所有的数据不是先经过代理节点转发到中心节点,再发送到代理节点,最后发送到学生端,否则 四种 路径是固定的,所有的数据不是走没法 长的路径,此外,系统之间有一定的耦合。为了处理那先 大大问题,重新设计了新的媒体架构:

整个媒体系统设计原则有两点:一是尽最大的否则 找一条最优的路径,将数据尽快的发送到对端;二是在服务出现大大问题的然后,尽量的保证服务的可用性,否则 让用户没法 感知。

消峰处理的原理是将比较大的数据分成若干个包,在一定时间内发送出去。但这会带来延时的增大,否则 不还都还还可以 控制发包的间隔大小。最后,当数据在传输当中否则 误码等因素意味着着丢包时,亲们儿还不还都还还可以 丢包重传的机制来进一步的提升网络的质量。总结下来,嘴笨 整个客户端引擎的网络部分,嘴笨 也不在做一件事:在实时性与质量之间权衡,否则 四种 权衡具有一定的自适应能力。

3、服务端架构演进

RTP一般是各家自研,相比于传统的直播方案来讲,自研方案不支持CDN加速,且成本贵,延迟一般是3000到30000毫秒之间。

 

1) 精简信息+完全信息

3,服务端架构演进

4,录制回顾以及旁路推流

首先,亲们儿把信令系统与媒体系统之间解耦,也也不说亲们之间相关的操作如加入房间,建立房间,完全放上去客户端的AV引擎去实现;另外,亲们儿上加了中心节点,加入了转发节点的概念,所有的转发节点不是对等的,否则 转发节点会将收到的音视频数据通过另1个多智能寻路算法自动找一条最优的路径。

教育直播-CCtalk是基于RTP协议自主研发的,它的传输层支持UDP和TCP有四种 土妙招,支持网师之间以及任意观众之间的连麦互动,连麦延迟和观众延迟不是毫秒级的,共同它支持PPT,白板笔,答题卡,文字等多种不同形式的教学互动。下面介绍CCtalk的软件架构图:

2)HTTP-FLV

2)进入教室慢

5,高并发场景案例分析

3)HLS

今天我会从三个白方面来给亲们儿介绍:

下面我会针对引擎的网络部分做另1个多简单的介绍,主要介绍用到的有几个关键的技术。首先思考另1个多大大问题:当客户端在使用媒体引擎的服务时,不还都还还可以 做的第一件事是那先 呢?

四种 拥塞控制能不还都还还可以分为发送端基于丢包的网络估计,以及接收端基于延迟的网络估计两部分,总结下来,也不根据丢包率以及延迟控制发送端的码率。除此之外,当亲们儿的码率结束了英文降低的然后,是必须总爱降低下去的,否则 码率降低意味着着音视频质量的下降。亲们儿还不还都还还可以 另外一套补充机制,叫做消峰处理:

主流的直播方案,我把它分为四类:RTMP,HTTP-FLV,HLS和RTP

1,主流直播方案介绍

1)客户端速度消耗过多

RTMP的优点是CDN加速性性性成熟 图片 期期 图片 的句子的句子,成本低,可用的开源库,以及开源工具比较多,延迟一般在2到5秒。

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/81124938

4)RTP

HTTP-FLV的原理是服务器在响应HTTP请求然后,不返回Content-length字段,它使用HTTP协议来实现,不容易被防火墙拦截,延迟略低于RTMP,但不是秒级的。

2,客户端AV引擎



4、录制回顾以及旁路推流

高并发场景的案例分析,四种 部分与实际的音视频没法 过多的关系,但却处在教育场景当中不得不面对的否则 大大问题,我首先举个例子,希望不不还都还还可以对亲们儿有一定的启发。亲们儿来想另1个多大大问题:同另1个多教室里,有116万人共同在听课,亲们儿会遇到那先 大大问题,亲们儿该如保处理那先 大大问题?假设有116万人在同另1个多房间,每另一方携带的数据量是300字节(类式:用户列表、用户ID、昵称等等),假设每台网关承载三千人,没法 大慨不还都还还可以 66台网关,正常请况下,假设每秒有30000人进出房间,没法 负载到每个网关上也不12人每秒的瞬间吞吐,过多算下来当有另1个多用户进房间,没法 他拉取的四种 数据量也不45Mb,他进房间的四种 瞬间不还都还还可以 拉没法 多的数据,每台网关承载的实时的吞吐量是554Mb,当出现异常时,比如说某台网关宕机否则 脱离了核心服务,亲们儿的负载均衡服务会将出现的大大问题的大慨三千人负载到剩余的64台服务上,此时的网关负载增量是46.8人,异常时的网关瞬间流量是2Gb。总结下来处在的大大问题如下:

答:不还都还还可以 找另1个多网络质量较高的边缘节点接入。

本文来自沪江技术中心开发经理杨福强在LiveVideoStackCon 2017上的分享,并由LiveVideoStack埋点而成。杨福强于2012年加入沪江,主要从事教学互动平台CCtalk的开发,今天他将为亲们儿分享高品质教学平台的否则 技术难点和处理方案。

如上图所示,假若亲们儿有一百个边缘节点,用户不还都还还可以 从四种 百个里面选另1个多到他的网络质量较高,没法 该如保选择呢?否则 你首先想到的是DNS解析,但嘴笨 只靠DNS解析是不足英文的,亲们儿还不还都还还可以 一套自动寻路机制,如下图所示:

以小网络为例,它的每次DNS解析的结果否则 是变化的,亲们儿无法保证它寻到的结果一定是最优的。当用户接入到边缘节点然后,在使用过程中,用户的网络在不断变化的,否则 亲们儿还不还都还还可以 有另1个多动态检测的机制,否则 引擎检测到网络波动较大的请况,没法 不还都还还可以 再次启动自动寻路机制,再给它找另1个多网络质量较高的边缘节点接入。此外,否则 网络总爱在变化,为了适应四种 不断变化的网络,亲们儿还不还都还还可以 一套拥塞控制机制,在这里我推荐Google的GCC拥塞控制算法:

5、高并发场景案例分析

1)RTMP

2) 提供数据的版本机制,在一定范围内,只处理变化的数据。

在四种 过程中,亲们儿使用的转码服务,前期用户量不大的请况下,亲们儿使用CPU转码,单台16核的机器的并发数量能不还都还还可以达到40路,里面随着业务增长,对于转码集群的要求不断增大,过多亲们儿改用了GPU转码,并发请况如下:

关于CCtalk

下面讲一下录制回顾以及旁路推流,架构如下:

埋点 / LiveVideoStack

这张图的上半部分在前面否则 介绍过了,也不客户端的引擎部分,下半部分是对应的媒体服务器的否则 功能。最初的CCtalk服务系统是由第三方提供的,开发简单,成本低,但嘴笨 处在否则 大大问题。我应该 亲们儿自主研发了一套服务端体系,架构如下:

否则 教育直播架构须具有的以下特性不还都还还可以满足需求:

录制OCS回顾视频过程如下:

具体如下,当 Server收到指令以及数据时,会将音视频数据发送到服务端的音视频引擎,服务端的音视频引擎会对那先 数据做否则 处理,压缩成另1个多大视频,将大视频存成MP4,并保存到云端,共同,将四种 实时的视频流以RTMP的形式推到CDN,原来,HTML5页面就能不还都还还可以在线观看实时的网页直播;共同媒体录制服务器会将上课时产生的所有内容以元素集合的形式存储一份,亲们儿把四种 存储格式叫做OCS。下面也不直播或录播的流程图:

下面介绍一下本人的特点:

HLS的优点是CDN埋点容易,成本低,能不还都还还可以在HTML5页面中直接打开观看,但它延迟一般大于12秒。

CCtalk是沪江旗下的支持互动教育平台,它提供网师服务,支持老师签约入驻,拥有基于云,大数据和AI的个性化课程推荐,共同也支持社群化学习,能不还都还还可以通过课前预习,课后答疑和视频回放等来沉淀学习用户,否则 还有非常富足的教学工具,包括实时多向音视频服务,双向白板,屏幕分享,讲义,教学小工具等等。

没法 ,亲们儿的应对策略是:

亲们儿还有一套专门的OCS编辑器来帮助对OCS回顾进行二次编辑,编辑器能不还都还还可以将编辑然后的结果再次传到云端,原来学生就能不还都还还可以观看编辑然后的内容。

3)服务并发处理量过多

2、客户端AV引擎