http://www.ox-holdings.com

照着做就能解决用户报的这些问题,而且市面上能够提供这种连麦互动直播功能的应用还非常少

摘要因为音视频通话 = 音视频处理 + 网络传输,而公共互联网不是为了实时通信设计的。所以说开发真正可用的实时音视频服务,从demo到生产上线,中间还差1万个WebRTC。前言  WebRTC开源之前,实时音视频通信听起来好高级:回声消除、噪声抑制……对于看到傅里叶变换都头疼的工程师很难搞定这些专业领域的问题。  Google收购了GIPS,开源了WebRTC项目之后,开发者可以自己折腾出互联网音视频通信了。下载、编译、集成之后,第一次听到通过互联网传过来的喂喂喂,工程师会非常兴奋,demo到万人直播现场只差一步了。  但是,电信行业要求可用性4个9,而刚刚让人兴奋的“喂喂喂”,1个9都到不了。某公司在展会上演示跨国音视频,多次呼叫无法接通,自嘲说我们还没有做网络优化嘛。这就等于互联网全民创业时期的”就差个程序员了“,本质上是和demo与真正产品之间的差距,是外行与内行之间的差距。  小红说家里WIFI聊QQ、打斗地主毫无压力,用你的音视频通话就卡的不行。想开发分享到微信这个功能,百度个文档照着一步步干就好了;但是找不到这样一个文档,照着做就能解决用户报的这些问题,进而把音视频通话做到电信水平。  音视频通话对教育、社交、约会类APP是刚需功能,上述问题会迫使用户使用更稳定的skype或微信来沟通。技术原因造成用户流失,是每个工程师都不愿意看到的事情。实时音视频难在哪?  因为音视频通话 = 音视频处理 + 网络传输,而公共互联网不是为了实时通信设计的。难点如下:协议方面:tcp有无法忍受的延时,udp有丢包延时抖动乱序。政治方面:各个国家出口光缆屈指可数,带宽也有严格限制。商业方面:由于成本原因,跨运营商的网络传输惨不忍睹。用户设备:无线路由器从802.11G开始才支持实时通信模式;多个路由器使用相同的频段会造成信号污染;2G网络上行带宽只有20kbps。架构方面:公共网络每个节点都不可靠,后台工程师熟悉的mtr命令可以分析哪个路由节点丢包高,如果此时正在传输音视频,质量必然受到影响。  要在这样一个公共互联网上传输音视频数据,却没有做任何网络传输的工作,不遇到问题的话可以买彩票了。网络传输要怎么搞?老师没讲过、网上搜不到,是不是有一种深深的无力感。具体怎么解决?可以从以下几个方面入手:质量评估:声音卡成翔,首先需要通过网络参数来评估语音质量。数据统计:用户的使用情况到底怎么样,需要完善的数据统计模型和支撑系统,不然开发者就是睁眼瞎。智能接入:影响质量的原因——不同的ISP会有不同的丢包水平,需要多线服务器。智能路由:随着用户扩张到海外,比如电信用户和美国用户通话时丢包大,没有一边电信一边美国这种多线服务器,可能通过日本转发过去就不丢包了,这就是智能路由。虚拟专线:智能接入加上智能路由,可以媲美网络专线的质量了,这就是所谓的虚拟专线。丢包对抗:用户抱怨明显少了很多,还剩下一些自己网络不给力的用户。用户x一直用2G,用户y在公司里很多WIFI有信号污染,那么就需要丢包对抗机制。网络可用性:用户报虹桥机场打不通,小发现公共场所WIFI有很多限制,所以需要考虑网络可用性。后台高可用:用户没问题了,但各种互联网公司事件让运营者担心自己服务器电源也被挖掘机铲断,所以需要后台高可用。

本文内容来自学霸君资深架构师袁荣喜的技术分享。

作者:吴桐,网易云信音视频实时通话项目与互动直播项目负责人。先后参与网易UU网游加速器、易信音视频实时通话等项目,在高性能服务器、网络传输技术、实时音视频多媒体与直播技术各模块有资深的实践与经验。

本文内容整理自腾讯专家研究员 & 微信视频技术负责人谷沉沉在 2017 ArchSummit 全球架构师峰会上的技术分享。

1、前言

实时视频直播经过去年的千播大战后已经成为互联网应用的标配技术,但直播平台的成本却一直居高不下,各个平台除了挖主播、挖网红以外,其背后高额的带宽费用也是他们最大的一块成本。

现阶段直播技术在传输方面分为两块:

CDN :负责流媒体的分发传输;
连麦系统:负责解决同时多个主播间互动的实时通信传输问题。

我们始终认为基于 CDN+ 连麦系统的直播技术是一个高成本高消耗的技术,从各大直播平台纷纷亏损来看就验证了这一点。除了带宽成本,延迟问题也是现在直播技术的一个硬伤。我们很早就意识到现在这种传统的直播技术是无法大规模进行在线教育互动直播的,所以学霸君从 2016 年下半年就开始研发基于 UDP 和 P2P 技术的互动直播系统。

整个系统的设计目标是:

端到端延迟控制在秒级范围之内;
在不影响视频质量的情况下尽力节省分发带宽。

基于 P2P 技术的整个分发架构在一个 10W+ 直播平台上进行了 9 个月的测试和调优,初步达成了设计目标。

那整个系统是怎么设计的?使用了哪些技术来达成目标?接下来我来重点分享一下架构设计和技术细节。

(本文同步发布于:http://www.52im.net/thread-1289-1-1.html)

 

2012 年 7 月,微信 4.2 版本首次加入了实时音视频聊天功能,如今已发展了 5 年,在面对亿级微信用户复杂多变的网络和设备环境,微信多媒体团队在每个技术细节上不断地深耕细作,为微信用户提供了高质量的视频通话。

2、分享者介绍

 

 

 

图片 1

 

袁荣喜:学霸君资深架构师,2015年加入学霸君,负责学霸君的网络实时传输和分布式系统的架构设计和实现,专注于基础技术领域,在网络传输、数据库内核、分布式系统和并发编程方面有一定了解。

一、前言

今年腾讯全球合作伙伴大会上发布的《2017 微信数据报告》显示,到 2017 年 9 月,微信日成功通话次数 2.05 亿次,月人均通话时长 139 分钟,月人均通话次数 19 次。无论是通话次数还是通话时长都比去年增加了一倍多,这个增长速度远远高于微信用户量的增长,这与微信多媒体团队在音视频技术上的努力是分不开的。

3、基于P2P的实时视频直播分发网络架构

 

图片 2

3.1 基本架构

传输分发网络中我们把连麦系统和分发系统合二为一,将分布式推流与边缘节点分发作为一套传输体系,通过服务之间的 P2P 通信和路由选择来实现连麦的最小时延。

架构如下图:

 

 

 

图片 3

 

整个传输分发网络分为三部分:

推流部分;

服务之间 P2P;

客户节点 P2P。

这个传输网络有一个系统锚点:假定推流者 speaker 推到 Edge server 上是不会发生丢包和延迟的,Edge server 会通过服务间 P2P 快速将收到的流数据分发到其他的 Edge server,而且在这个过程也不会发生延迟和丢包。

为什么需要这样一个锚点?因为在客户节点的 P2P 网络需要保证流畅性和最小延迟,也就是要求所有的 Edge server 在最短时间周期内拥有完整的数据,至于为什么要这样,后面我们在流补偿环节重点介绍。

我将通过整个流数据传输过程来解析具体的技术细节,但在这之前首先要解决的就是媒体数据分片问题,所有的传输过程会基于分片 (segment) 来设计。

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

本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案,同时分享在实时音视频聊天中的视频编码器研发的方法和经验。

3.2 媒体数据分片

媒体数据分片是整个分发传输系统中最为基础的部分,我们在设计分片时主要考虑的是时延和消耗的问题,分片如果太大,传输的时延就会越高,例如 HLS;如果分片太细,网络中回馈报文就会很多,对 P2P 网络来说额外的消耗也是个问题。

最后我们借鉴了 RTP 和 FLV 中的经验,采用按帧来做数据分片,这样做有以下几个好处:

按帧分片延迟粒度小,可以在帧传输进行延时优化;

实现简单,与编解码器编码原则一致;

组合灵活,可以实现播放 buffer 无缝结合。

每一个分片称作为 segment,用一个自增长的 32 位 ID 来表示唯一性,传输过程都是以这个 ID 为标示来确定数据的完整性。

 

在本次正式技术分享前,谷沉沉作为受访嘉宾,接受了InfoQ的技术专访,技术专访内容请见《专访微信视频技术负责人:微信实时视频聊天技术的演进》。

3.3 推流与连麦

确定好了媒体分片就可以进行推流了,我们把推流和分发的路径合二为一,上麦者是将流数据 segment 推送到离自己最近的 Edge server 上,而不是推送到专门的连麦系统上。我们推流传输使用的是 RUDP 传输算法,这个 RUDP 是采用了类似 BBR 基于延迟和丢包来设计的拥塞算法,并且对报文做了拥塞丢弃。

示意图如下:

 

 

 

图片 4

 

关于 RUDP 的细节可以参考我的另一篇文章《怎么让不可靠的UDP可靠?》。至于为什么不采用 RTP 或者 RTMP/TCP 来推流,因为 RTP 虽然是基于 UDP 的,但需要通过 RTCP 和 NACK 来保证可靠性,需要设计拥塞算法,也需要对 RTP 进行改造扩展,而且还受 RTP 协议本身的限制,所以我们并没有直接采用 RTP。使用 RTMP/TCP 来设计是很简单的,但在弱网环境延迟很大,而且容易引起重连,所以在设计之初也否定了。

图片 5(移动直播火爆) 

(本文同步发布于:

3.4 Server 间的 P2P

因为整个传输分发网络是分布式的,由多个 Edge server 组成,所以基于系统锚点,媒体数据分片到 Edge server 上必须尽快分发到其他 Edge server 上。最早我们是统一用 BGP server 来中转,这样耗费的 BGP 带宽很多,而且 BGP server 一旦异常,整个 Edge server 之间的通信就中断了。

其实大部分时间跨运营商的 Edge server 之间延迟也没有想象的那么大,这可以考虑使用 Edge server 之间点对点通信来解决问题,所以我们设计了一个基于 RUDP 无窗口多路径的传输模型来进行 Edge server 之间的通信,如下图:

 

 

 

图片 6

 

上图的通信模型是一个多路径并联通信模型,我们在 RUDP 发送前添加了一个路径路由表,这个路由表记录了各个路径的分发概率,RUDP 每次向接收端发送包时会通过路由表中的概率来选取路径。那么确定路由表概率就是一个非常重要的事情。我们通过 RUDP 实时 ACK 反馈和路径实时 ping 探测来得到网络的状态 (丢包、延迟、抖动),再将网络状态参数输入到逼近函数 f(x) 来确定各条路由的概率,这里有条原则:如果 Edge server 之间直连的延迟和丢包足够小的情况下,直连通信路由的概率将会接近 100%,如果某一条路由出现周期性断开或者延迟超过 200ms,它的概率会接近 0。

以下是整个路由概率评估的过程示意图:

 

 

 

图片 7

 

 

学习交流:

4、基于P2P的实时视频直播网络构建过程

媒体流数据通过 Edge server 间的 P2P 多路径传输网络到达各个 Edge server 上,接下来每个 Edge server 需要将流数据分片下发到各个客户节点上,我们针对上麦节点做了传输特殊处理让时延更小,过程和普通的 RTC 通信模型相似,这里就不赘述了。观看节点上分发采用自组织 P2P 网络,既然是通过 P2P 下发的,那么就要在客户节点群构建一个 P2P 网络,这个网络是怎么构建的?具体分为三步:连接、评估、分层。

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

- 即时通讯开发交流群:320837163[推荐]

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》

4.1 连接

客户节点程序是运行在客户机上的,大部分客户节点都会在路由器或者 NAT 后面,他们之间要相互建立连接,必须穿越彼此的 NAT 和防火墙。虽然现在穿越 NAT 的方法有很多,如 STUN、ICE 等,但穿越连通率始终是一个问题,如果穿越率太低,会让很多优质的节点资源得不到充分利用。

在设计穿越方案时我们将直连连通率放在第一位,通过修改 STUN 协议设计了一种基于端口多次猜测和尝试的穿越机制。首先通过类似 STUN 协议判断 NAT 类型、NAT 端口变化规律、NAT 是否有黑名单机制等信息,然后将这些信息存到辖区连接中的 Edge server 中,当有伙伴节点来与它穿越,会交换彼此的这些信息,不同的排列组合会有不同的穿越策略,每一次穿越的过程和结果都会记录到我们的后台数据库,我们会周期性地将这些数据进行分析并调整协商穿越策略。如下图:

 

 

 

图片 8

 

穿越完成后,节点之间就会进行连接握手和身份证书认证(关于为什么要证书后面细讲),建立通信联系和邻居关系。那么邻居关系是怎么动态变化的呢?

 

图片 9▲ 图中为本文分享者:谷沉沉

4.2 邻居关系与评估

【邻居问题】:

连接一旦完成,节点与节点之间就成为邻居,彼此会进行状态交换和心跳,那么问题来了,一个直播系统有成千上万的节点参与,如果都两两相连的话光心跳通信就可以将客户节点的上传带宽占满。我们设计了一个节点 LRU 淘汰链表,链表中保持 40 个联系的邻居节点,老的节点会退出,新的节点会加入,LRU 会根据邻居与自己的通信状态来进行 LRU 新增和淘汰,原则如下:

就近原则,内网优先,同城同一运营商网络次之;
周期性评测延迟和媒体分片命中率,末位淘汰;
当 LRU 列表中节点不足 40 个时会从备用节点列表中选取新的节点进行连接并加入到 LRU 中。

【节点评估】:

每个客户节点的计算能力、通信能力和网络分区等都不一样,这使得我们必须对每个节点做一个评价,对一个节点的评价分为两部分:邻居节点对自己的评价和自己对自己的评估。

邻居评价主要是:

RTT;
丢包率;
请求命中率。

通过这三个参数会对每个邻居计算出一个亲和力分值 score,这个值会用于后面的分发选择。

主要评估自己这几点:

CPU、内存;
网络类型:WIFI/4G/ 有线网络;
上传带宽。

节点会周期性计算这两类参数,通过一个网络 QOS 收敛函数 f(x) 来计算节点能力和对邻居 QOS 策略。

 

谷沉沉:腾讯专家研究员 & 微信视频技术负责人。

4.3 节点分层

节点评估最终的目的是让有能力的节点成为超级节点(super node)来分担 Edge server 的分发压力。

那么一个节点成为超级节点的条件是什么呢?有以下几个条件:

有足够的上传带宽,4G 和弱 WIFI 下不能成为超级节点;

有空闲的 CPU 和内存,计算能力不够的低端移动设备不能成为超级节点;

对邻居通信友好,不是通信孤岛;

得到 Edge server 的任命,和 Edge server 之间通信顺畅。

超级节点如果性能衰减了怎么办?答案是会退化成普通节点,因为节点评估是周期性实时进行的,如果发现节点性能衰减,Edge server 会让其退化。

既然任命了超级节点,那么超级节点是怎么工作的?每一个超级节点在被任命时都会分配到一个分组 ID,Edge server 会根据自己辖区的超级节点数量进行分组,每个分组由多个超级节点组成,分组内的超级节点负担自己分组的媒体分片分发。例如:有 5 个超级节点分组,这时单位周期内有 1 ~ 20 个 segment,那么第一个分组负责 1、6、11、16 编号的 segment 分发,以此类推第二组负责 2、7、12、17 ……这样做是为了防止单个超级节点失效,增强了 P2P 分发的稳定性。

示意图如下:

 

 

 

图片 10

 

二、连麦互动直播是什么

2007 年硕士毕业于哈尔滨工业大学,在校课题研究期间参与过 AVS、H.264SVC 等视频编解码标准技术研究。加入腾讯后也一直从事视频图像相关的技术研发工作,先后主导过 QQ、微信、手机 QQ 视频通话、腾讯视频等产品的视频技术研发,目前主要负责微信视频通话、朋友圈视频图片等业务相关的视频图像技术研发和团队技术管理。

5、基于P2P的实时视频直播流媒体分发过程

通过上面的 P2P 网络构建过程我们知道整个 P2P 网络其实是一个分层有向图分发网络,那么具体是怎么进行流数据分发的呢?也分三步:先推 (push)、后拉 (pull)、再补偿。下面来仔细解释是怎么实现的。

 

拥有丰富的视频技术研究与应用实战经验,在国际视频领域知名学术会议刊物上发表多篇论文,数十项视频技术领域的发明专利在国内外获得授权,其中两件独立发明的专利荣获中国专利奖。

5.1 push

在介绍超级节点时有提到会根据 segment ID 将数据推到对应的超级节点分组群上,超级节点收到这些 segment 后怎么进行处理呢?按照 P2P 设计的原理应该将数据转发到其他分组的超级节点或者普通节点上,但是如果都这样推有可能会造成网络发送冗余而消耗过多的带宽。

为了解决这个问题我们设计了一个预先订阅机制,原理就是每个 P2P 客户节点会根据自己缓冲区最大的 segment ID 来进行预订,提前预订 10 秒以后的媒体数据分片,预订请求要根据节点评估出来的亲和力值 score 做权衡,收到这些请求的超级节点会将预订的分片请求信息保存下来,等到 Edge server 推送这个分片到这个超级节点,它就会无条件转发这些被预订的报文给发起预订的节点,如下图所示:

 

 

 

图片 11

 

从上图中可以看出以下几个原则:

从 Edge server 到所有节点路径最多两层,这样做是为了控制链路延迟;

不同分组 super node 之间会相互订阅对应分组的 segment;

普通 node 只会向 super node 发起订阅。

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

图片 12

5.2 pull

数据 segment 通过预先订阅的方式进行 push 推送到各个客户节点,但网络是会丢包的,super node 也有可能会中途退出,这样就会造成最终的节点发生丢包,那丢包了我们怎么办?

我们设计一个向邻居拉取缺失分片的机制,大致的流程如下:

节点周期性检查丢失分片的信息和收到分片的信息,构建一个 gossip 协议向邻居交换缓冲区信息;

节点收到邻居的 gossip 信息,将对方拥有的分片信息记录到本地;

本地根据记录邻居的分片信息查找自己丢失的分片,通过邻居亲和力值 score 进行权衡随机选取邻居,并向选取的邻居发起 pull 请求;

收到邻居拉取分片请求,将分片发往请求的节点。

整个步骤会周期性尝试多次拉取,示意图如下:

 

 

 

图片 13

 

这里值得一说的是因为会周期性交换缓冲区的 gossip 信息,这意味着缓冲区的 gossip 信息越小越好,我们设计了一个类似 bloom filter 来描述 gossip 信息,不仅可以减小 gossip 报文的数据大小,而且比对速度也很快。

 

与很多互联网视频应用类似,互联网视频通话的应用目标也是希望用尽可能低的成本使视频更加清晰与流畅。

5.3 补偿

因为 P2P 的客户节点是不稳定的,有可能某个 segment 通过拉取多次还是没有收到,这个 segment 又临近播放位置,那么缺失这个 segment 的节点会直接向 Edge server 请求补偿让其尽快传送这个分片,这样做的目的是防止因为 P2P 通信造成丢包的卡顿。这也就是说每个 Edge server 需要拥有所有分片数据,这也就是系统的锚点。

流程如下图:

 

 

 

图片 14

 

这个流程大部分情况下没有问题,但如果同一时刻大部分客户节点都缺失某几个 segment 分片,会有大量的补偿请求到 Edge server 上,这会造成网络风暴。我们在应对这个问题时设计了一个稀缺评估和拒绝服务的机制。这个机制是指当单位时间内太多个补偿请求到达 Edge server,那么这个 Edge server 会拒绝自己承受能力之外的请求,只重发承受范围之内的分片。而且这个过程还会对补偿请求做稀缺评估,如果某个分片大部分节点都没有,它会主动将这个分片通过 super node 群再推送一次。

图片 15

上图右边互联网视频应用的代价成本包含两个维度:

5.4 缓冲 buffer 与时延控制

通过上面的三个阶段可以将所有数据 segment 分发到每个客户节点上,但客户节点需要一个缓冲 buffer 来配合这个三个阶段和本地的播放,buffer 如果缓冲时间过长,会引起不必要的延迟,如果过短会造成卡顿和三个阶段不完整。

为此我们设计了一个三阶段 buffer 动态缓冲区,如下图所示:

 

 

 

图片 16

 

下边解释一下上图各个区间的意思:

push 区间:因为分片是通过不同的 super node 推送过来的,那么必然会造成一定的抖动,所以在 buffer 最开始的头上会有一个 jitter 缓冲阶段,直到第一个邻居节点 gossip 信息中有这个分片 push 位置结束,这个阶段一般持续 100 ~ 300ms;

pull 区间:分片时序进入 pull 区间后,会周期性检查丢失的分片,根据 gossip 掌握的邻居进行权衡拉取,会进行 3 次尝试,每一次尝试时间是本地节点与邻居之间的 RTT 值。3 次失败则进入补偿区间;

补偿区间:分片时序进入补偿区间后,也会周期检查丢失的分片,根据丢失的分片 ID 直接向 Edge server 请求拉取,尝试 4 次,每次尝试时间为一个本地节点与 Edge server 之间的 RTT。如果 4 失败则进行 waiting 状态,等待邻居 gossip 或者 Edge server 主动推送;

过期区间:被播放后的分片会放到这个过期区间中而不是立即删除,为什么呢?因为每一个节点的播放时间点不同,有可能本地播放的分片正是其他节点丢失的分片,有可能其他节点会通过 pull 来拉取,所以我们会把播放后的分片放在过期区间 3 秒后再删除。

 

一是带宽成本:包括客户端用户的流量成本,以及服务器端带宽成本;

二是计算开销:表现在服务器端的设备投入量,以及客户端的 CPU 占用、耗电量等,而对于性能较差的客户端设备,控制客户端的计算资源还可以保障这些设备也能支持基础质量的视频通话。

5.5 秒开问题

上面分发的三个阶段和 buffer 控制解决了流持续分发和播放延迟控制问题,但现阶段所有的直播技术必须要有秒开,其实 P2P 分发在解决秒开问题上比单纯的 Server CDN 转发要更加简单。秒开就是用户进入直播间时瞬间能看到主播的视频图像,秒开的宗旨是新进入的客户节点要求服务端边缘节点从视频的上一个 GOP 关键帧开始发送数据,客户节点再根据视频编码器从这个 GOP 关键帧零等待加速播放。我们在 P2P 分发网络中新进入的节点会收到 Edge server 的上一个 GOP 关键帧分片 ID,客户节点根据这个 ID 从各个邻居中快速拉取整个 GOP 分片数据,而不是单纯地让 Edge server 来发,秒开的速度平均缩短了 100 毫秒。

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

图片 17

6、基于P2P的实时视频直播内容授权

直播分发技术除了传输分发以外,还需要考虑内容防盗和授权,P2P 系统中更加需要考虑系统安全性。我们引入了 CA 证书和双端协商加密方案来保证链路的合法性。大致的做法是每个合法的节点单元(Edge server 和所有的客户节点)会向 CA 发起合法校验,如果检验通过,CA 会根据节点的 ID、节点 RSA 公钥、授权起始时间和授权终止时间等信息利用 CA 的 RSA 进行证书生成。每个拿到证书的节点单元需要和其他的节点进行通信,先交换证书,校验对方证书的合法性,然后利用证书中 RSA 公钥加密算法的 KEY 返回给证书方,证书方收到加密的 KEY 后会用 RSA 私钥解密得到对称加密的 KEY,这样双方就完成了合法性校验并利用这个交换的 KEY 进行报文加解密通信。

流程如下图:

 

 

 

图片 18

 

                    

上图中谷沉沉列举了四类互联网视频应用,其中视频通话应用相对于短视频分享、流媒体直播和媒体存储来说有三个特殊的挑战:

7、线上数据对比

上面的技术分析只是帮助读者理解这个系统的运作机理,除此以外,当然需要公布一下线上数据来佐证下系统可行性,下图是一个 10W+ 在线直播平台使用了这套 P2P 系统后线上的对比数据。我们在同一个 Edge server 上的同一个直播间对象中,把一半的用户节点关闭 P2P,一半的用户开启 P2P,来观察一天中同一个 Edge server 上这两部分用户群的带宽消耗情况。

 

 

 

图片 19

 

从上图可以看出,P2P 模式带宽消耗只有不开启 P2P 模式的 1/4,我们这个 P2P 系统节省了 75% 的带宽成本。这个数据的视频样本是单路 480P 800kps 码率的直播流,高峰期真实节点数 1000+,最终所有终端的平均延迟是 1.07 秒。

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

第一:由于微信视频通话集中在移动端,这就要求系统的计算复杂度尽可能低;

第二:由于视频通话是高度实时的应用,决定了视频数据一般采用不可靠传输,这就要求视频传输具有一定的鲁棒性,比如抗丢包的特性,另外,由于没有缓冲机制,视频发送码率要尽可能平稳;

第三:由于很多用户在 3G、4G 等移动网络下使用,对流量比较敏感,所以视频通话带宽占用要尽可能低。

8、本文小结

到这里关于 P2P 分发网络的技术解析就结束了,P2P 技术从产生到现在已经经历了 19 年,而且 P2P CDN 也是下一代 CDN 的主体技术,P2P 技术和模型也一直变化改进。我们在直播分发领域使用 UDP 和 P2P 是想从成本和延迟上来解决我们教育场景互动的问题,出发点不一样,也就会得到不一样的结果,如果你遇到成本和延迟的困扰,可以尝试使用这种技术来解决问题。

 

最左边三点是微信视频通话作为海量级用户产品具有的特殊难点:

附录:更多实时音视频技术文章

[1] 开源实时音视频技术WebRTC的文章:
《开源实时音视频技术WebRTC的现状》
《简述开源实时音视频技术WebRTC的优缺点》
《访谈WebRTC标准之父:WebRTC的过去、现在和未来》
《良心分享:WebRTC 零基础开发者教程(中文)[附件下载]》
《WebRTC实时音视频技术的整体架构介绍》
《新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?》
《WebRTC实时音视频技术基础:基本架构和协议栈》
《浅谈开发实时视频直播平台的技术要点》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
《简述实时音视频聊天中端到端加密(E2EE)的工作原理》
《实时通信RTC技术栈之:视频编解码》
《开源实时音视频技术WebRTC在Windows下的简明编译教程》
《网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?》
>> 更多同类文章 ……
[2] 实时音视频开发的其它精华资料:
《专访微信视频技术负责人:微信实时视频聊天技术的演进》
《即时通讯音视频开发(一):视频编解码之理论概述》
《即时通讯音视频开发(二):视频编解码之数字视频介绍》
《即时通讯音视频开发(三):视频编解码之编码基础》
《即时通讯音视频开发(四):视频编解码之预测技术介绍》
《即时通讯音视频开发(五):认识主流视频编码技术H.264》
《即时通讯音视频开发(六):如何开始音频编解码技术的学习》
《即时通讯音视频开发(七):音频基础及编码原理入门》
《即时通讯音视频开发(八):常见的实时语音通讯编码标准》
《即时通讯音视频开发(九):实时语音通讯的回音及回音消除�概述》
《即时通讯音视频开发(十):实时语音通讯的回音消除�技术详解》
《即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发(十二):多人实时音视频聊天架构探讨》
《即时通讯音视频开发(十三):实时视频编码H.264的特点与优势》
《即时通讯音视频开发(十四):实时音视频数据传输协议介绍》
《即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发(十六):移动端实时音视频开发的几个建议》
《即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生》
《实时语音聊天中的音频处理与编码压缩技术简述》
《网易视频云技术分享:音频处理与压缩技术快速入门》
《学习RFC3550:RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究(论文全文)》
《声网架构师谈实时音视频云的实现难点(视频采访)》
《浅谈开发实时视频直播平台的技术要点》
《还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡》
《如何用最简单的方法测试你的实时音视频方案》
《技术揭秘:支持百万级粉丝互动的Facebook实时视频直播》
《简述实时音视频聊天中端到端加密(E2EE)的工作原理》
《移动端实时音视频直播技术详解(一):开篇》
《移动端实时音视频直播技术详解(二):采集》
《移动端实时音视频直播技术详解(三):处理》
《移动端实时音视频直播技术详解(四):编码和封装》
《移动端实时音视频直播技术详解(五):推流和传输》
《移动端实时音视频直播技术详解(六):延迟优化》
《理论联系实际:实现一个简单地基于HTML5的实时视频直播》
《IM实时音视频聊天时的回声消除技术详解》
《浅谈实时音视频直播中直接影响用户体验的几项关键技术指标》
《如何优化传输机制来实现实时音视频的超低延迟?》
《首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?》
《Android直播入门实践:动手搭建一套简单的直播系统》
《网易云信实时视频直播在TCP数据传输层的一些优化思路》
《实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器》
《P2P技术如何将实时视频直播带宽降低75%?》
>> 更多同类文章 ……

(本文同步发布于:http://www.52im.net/thread-1289-1-1.html)

 

1)用户的网络状况和设备性能差异巨大,所以微信视频通话要适应不同的网络和设备;

2)由于用户版本更新存在一定的周期,这就需要考虑新技术对旧版本的兼容性;

3)另外,海量并发用户对服务器端造成的带宽成本压力也是必须要考虑的。

三、连麦互动直播功能流程

所以,互联网视频通话是各种互联网视频应用中约束条件最多、最苛刻,也是实现难度较大的一种互联网视频应用。

 

图片 20

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

据谷沉沉透露,现在微信视频通话是基于微信多媒体团队自研的多媒体应用综合引擎——WAVE (Wechat Audio&Video Engine)。该引擎的底层——内核层是由传输、视频、音频三大类跨平台技术构成的。在此之上,针对不同应用类型的特点做了一些接口封装和应用逻辑设计,形成应用层,目前支持三类不同的应用:第一类是实时通话应用,目前用于微信的点对点和多人视频通话。第二类是多格式的图片处理,主要用在微信朋友圈、公众平台以及表情等图片的压缩和处理上。第三类是音视频文件压缩,应用于朋友圈视频、语音和视频消息的压缩和处理等。

 

经过多年的技术积累,WAVE 引擎支持了每天数亿的视频通话、数十亿的视频播放、数千亿的图片查看,所以整个引擎在压缩效率、计算速度、音视频质量等方面的性能都经过了微信亿万用户的考验,是业界比较领先的多媒体引擎。

① 主播正常开始直播,普通观众看到主播的单人直播画面;

谷沉沉表示他们团队现在还在不断提高引擎的处理速度、压缩效率等性能,希望能用最合理的成本为广大用户提供最好的多媒体体验。

郑重声明:本文版权归新匍京a奥门-最全网站手机版app官方下载所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。