WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档

webrtc流媒体转发服务器

2020-06-23 13:51:52

georen 2018-12-18 15:27:44 3988 收藏 3

版权
webrtc流媒体转发服务器
定义
难点
建立连接
如何转发媒体流
如何高效转发媒体流
转发后如何保证视频质量
定义
由于webrtc是基于P2P技术的一个协议栈,大多数情况下能满足1-5人的同时并发音视频通讯。但是对于多于5人乃至10、20人的并发,使用P2P技术会造成终端设备无法承受负荷。因此需要将P2P模式改造成能适应大量并发模式,即媒体转发服务(MCU)。

难点
由于webrtc本身是基于P2P的技术,没有MCU的实现。因此需要自己编写MCU的源码。难点有如下几个:

如何与终端设备建立连接
如何接收和转发媒体流
转发如何高效,尽量少的延时
转发后如何保证视频质量
这几点前两点是核心技术问题,如果突破不了则无法实现MCU转发。后两点是如何提高品质的问题,但是品质决定了该技术的可行性。如果视频品质比P2P下差太多,也无实际意义。
建立连接
如何与终端设备建立连接的技术是直接关系到MCU端是否能正常运行的核心技术,为了能使终端设备和MCU的连接简单化,我们把MCU也想象成是一个PEER,那么换言之,MCU只需要完全遵循webrtc的P2P连接过程即可。那么按照此观点,我们需要在MCU服务器端引入webrtc协议栈来进行连接。但是注意,webrtc流媒体连接与转发都是在协议栈内部完成,也就是说我们没法从webrtc的外部接口直接拿到媒体流数据,拿不到媒体流数据也就意味着我们没法做自定义转发。因此该方案被否决。
那么如何能完全模拟webrtc的连接过程同时又能拿到终端媒体流数据呢?那么我们需要去了解webrtc的连接过程。
webrtc是依照叫PeerConnection的连接过程,其连接过程需要四个角色来合作完成,即:

终端设备A
终端设备B
STUN服务器:用于解析终端设备的外部Internet IP,通常部署在云端,需要在设备A和B的交换明文SDP中指定。
Signal服务器:用于在终端设备A和B之间交换连接信息,所有终端设备需要与该服务器保持连接。
一个经典的连接过程包括以下步骤
a. 设备A发送一条SDP消息给Signal服务器,该消息包含需要与设备B进行连接的有效信息即SDP,以及终端设备B的IP地址,表明设备A需要和设备B进行通信
b. Signal服务器设备A发送的SDP信息转发给设备B
c. 设备B将自己的SDP信息发送给服务器,服务器同时转发给设备A
d. 设备A和设备B通过双方SDP中包含的局域网IP、公网IP以及有效端口,选择一条有效路由进行连接
e. 连接成功后设备A和设备B交换媒体流。
基于以上过程,我们不难发现该连接过程是一个经典的P2P连接过程,我们不需要通过webrtc协议栈来完成。通过其他用于P2P连接的协议栈即可完成这个过程。经过实验我们发现NICE库是一个小巧、高效的P2P连接库。但是其实现是基于linux内核编写。也就是说我们必须选用linux做MCU服务器。
NICE库能够完成主叫或被叫的P2P连接过程,但是由于它不处理跟媒体设备相关事宜,而SDP文本中需要包含设备相关信息,因此在MCU端需要自行生成SDP以备和终端设备进行交换。这个SDP生成过程需要去理解SDP文本,并仿造终端设备发送过来的SDP文本格式自行生成。经过实验,在完成SDP文本中关键几个字段的替换(将设备端SDP关键信息替换成MCU端),终于能够正常连接了。
如何转发媒体流
由于NICE库在建立起PeerConnection连接的前提下,可以直接拿到媒体数据,因此接收和转发媒体流相对来说就简单了。
接收数据可以直接从NICE的接口callback得到
转发无非是MCU与多个设备终端同时建立连接,然后通过NICE接口将数据通过转发端的连接发送过去。
由于P2P技术是端对端,只考虑2个设备间的连接,不存在连接管理问题。但是在会议模式下,就要考虑连接管理问题了。因为会议模式下是1+N的连接模式。因此我们引进了一个经典的会议概念,其中有如下几条关键概念:

会议:一个会议包括一个会议ID,以及其下属的多个终端设备或者叫与会者(与会者ID)。
发布:该会议中的其中一个与会者发布自己的媒体流到MCU服务器
订阅:会议中除了发布者外,其他与会者订阅该发布者的媒体流。
按照以上概念,视讯会议就可以简单理解为以下过程
a. 创建会议
b. 进入会议,即所有与会人与Signal服务器建立连接
c. 发布媒体流
d. 订阅媒体流
如何高效转发媒体流
由于P2P连接下,媒体流是直接从终端设备A发送到终端设备B,没有中间过程。在MCU模式下,需要MCU进行中转,因此实时性一定不如P2P。针对该课题,我们需要定义可接受的延时标准,同时在MCU端需要尽量减少程序架构带来的额外延时,亦即我们需要引入高性能服务器编程,来保证高并发、高实时。因此我们引入了连接池、线程池和内存池三项技术。通过测试发现同样的网络环境下,设备A和设备B在P2P和MCU下延时的差别在30%左右,在可接受范围内。

转发后如何保证视频质量
由于webrtc在视频品质控制方面有一套自己的技术,来应对在Internet复杂网络环境下保证传输音视频质量。但是MCU转发服务器模式下,没法直接打通端对端的连接,该机制无法起到作用。如果不在MCU端加入该套机制,在Internet下的音视频品质会大打折扣。因此需要去理解webrtc的流媒体控制机制。
经过查阅资料发现,webrtc主要通过以下三项控制指令来完成品质控制

关键帧请求:主要包括SLI/PLI/FIR,作用是在关键帧丢失无法解码时,请求发送方重新生成并发送一个关键帧。
重传请求:主要包括RTX/NACK/RPSI。这个重传跟关键帧请求的区别是它可以要求任意帧进行重传
码率控制:主要包括REMB/TMMBR/TMMBN。TMMBR是Temporal Max Media Bitrate Request,表示临时最大码率请求。表明接收端当前带宽受限,告诉发送端控制码率。
另外,除了关键帧请求和重传,Webrtc还支持RED/FEC等冗余编码和前向纠错手段来保证视频质量,后续有空了再写。
通过上述介绍大家了解到有三种类型的控制包,只需要将这三种包接收到并转发给对应的连接,MCU端即可兼容webrtc媒体控制技术。通过实验发现该策略是有效的,并且主要是PLI、FIR、RTX三种对品质影响最大。
————————————————
版权声明:本文为CSDN博主「georen」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/georen/java/article/details/85066510

By:rasp | WebRTC概念与基础 |

  • 分类目录

    • WebRTC概念与基础 (225)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (12)
    • WebRTC服务端开发 (23)
    • WebRTC网络与通信 (26)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
  • 最新文章

    • 音视频相关的书籍,多媒体技术
    • SFU级联解决方案——Jitsi
    • SFU级联解决方案——Licode
    • Janus源码分析(6)——Streaming分析
    • janus Streaming插件推流指南
    • 流媒体服务器 
    • WebRTC+libwebsockets+Janus的秒开实践
    • 基于WebRTC的直播CDN
    • 不需要SFU实现WebRTC联播实践  
    • webrtc 开启Simulcast功能
    • Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API
    • WebRTC源码分析rfc4588 RTP重传有效载荷格式
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • 自研WebRTC网关服务器架构的实践之路
    • WEBRTC三种类型(Mesh、MCU 和 SFU)的多方通信架构  
    • janus的videoroom插件
    • WebRTC+libwebsockets+Janus的秒开实践
    • Janus源码分析(7)——videoroom分析
    • Janus源码分析(5)——echotest分析
    • Janus源码分析(4)——信令交互过程
    • WebRTC+libwebsockets+Janus的秒开实践
    • 前向纠错码(FEC)的RTP荷载格式
    • WebRTC 开发实践:从一对一通话到多人会议
    • Distord如何使用WebRTC处理250万用户同时进行的音频交流
    • 了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
    • 基于WebRTC技术的多人音视频解决方案
    • 谁是最好的WebRTC SFU?
    • WebRTC媒体服务器
    • 使用Janus作为对讲服务器的后台框架和业务流程
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.