当前位置:   article > 正文

WebRTC音视频开发_webrtc开发

webrtc开发

 1、前言

  自研实时音视频(RTC)系统的架构在客户端、服务端、运维、测试和质量监控上都存在很多难点

  一个实时音视频应用共包括几个环节:采集、编码、前后处理、传输、解码、渲染等很多环节。每一个环节又有更细分的技术模块,比如前后处理环节有美颜、滤镜、回声消除、噪声抑制等,编解码有VP8、VP9、H.264、H.265等。 

2、方案

  基于WebRTC开发

  webRTC是由Google发起的一个实时通讯解决方案。它涵盖了音视频采集、通讯的建立、信息传输、音视频显示等整套的实现方案。


  2.1 优点:


  1.开源免费
  2.包含使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术,并支持代理
  3.WebRTC还可以录制音视频到本地文件
  4.WebRTC提供音视频加密功能

 2.2 缺点:

  1.没有对群聊进行专门优化和支持,虽然功能上可以扩展实现群聊,但是需要每个人连接到其他任何一个用户,消耗可想而知。(可采取集中式服务器,每个用户只需要和这个服务器建立一个连接,你可以通过这个服务器控制所有的流量)
  2.对Native开发支持不够,webRTC顾名思义,主要面向Web应用,虽然也可以用于Native开发,但是由于涉及到的领域知识(采集、处理、编解码、实时传输等)较多,整个框架设计比较复杂


 2.3 媒体服务器


  WebRTC被认为是一种点对点技术,浏览器或客户端可以直接通信而无需任何类型的基础设施。此模型足以创建基本应用程序,但难以在其之上实现诸如组通信,媒体流记录,媒体广播或媒体转码之类的功能。因此,需要使用媒体服务器。
  媒体服务器好处:
  1.扩展了系统性能和功能,来支持更为复杂的应用场景
  2.所有媒体流经由媒体服务器可以进行记录
  3.可以方便的和第三方系统进行集成
  4.可以对媒体流进行额外的加工处理

 2.4 架构模式


  1.Mesh:每端与其他短互联,群聊人数多的情况下带宽高cpu占用高,不能支持太多人


  2.MCU:每个端与服务器相连,服务器负责所有的视频编码、转码、解码、混合等复杂逻辑,每个用户端只要1个连接,可以支持跟多人同时音视频通讯。(服务器压力大,需要较高配置,成本高,延迟问题)



  3.SFU:仍然有中心节点服务器,但是中心节点只负责转发,不做太重的处理,服务器的压力会低很多,配置也不象Mixer要求那么高。但是每个用户端需要建立一个连接用于上传自己的视频,同时还要有N-1个连接用于下载其它参与方的视频信息,带宽消耗大(适合1对N)



  小结:Mesh首先排除,SFU 相比于 MCU,服务器的压力更小(纯转发,无转码合流),灵活性更好(可选择性开关任意一路数据的上下行等),受到更广泛的欢迎和应用。也可以组合使用 SFU + MCU 的混合方案,以灵活应对不同场景的应用需要。
 
 2.5 服务器开源方案对比 
 

    1.Jitsi (SFU) 官网: Free & Open Source Video Conferencing | Jisti Projects    gitHub: github.com/jitsi/jitsis:/

              使用Java构建的服务端,底层也是使用c/c++,使用Java语言所以性能上没有使用c/c++的表现好

              Jitsi 平台是非常活跃的开源视频会议平台,其对标的视频会议产品是zoom,Google meet等视频会议平台。其视频会议功能意见非常完善,包括终端,服务器端,会议桥和录像,屏幕共享,即时消息,SIP网关接入/电话入会等功能

              官方提供的移动端SDK不支持自定义UI,自行编译SDK使用的是Rect Native

    2.Kurento(MCU/SFU) 文档:https://doc-kurento-zh.readthedocs.io/zh/latest/index.html#   gitHub:Kurento · GitHub

             使用java和C++

             Kurento的主要组件是Kurento媒体服务器(KMS),Kurento提供的功能包括媒体的处理与传输、音视频实时通信、实时转码、服务器端录制、合流、广播等,它允许WebRTC将非常有趣的功能进行集成,如计算机视觉(识别QR码、面部检测)、实时媒体修正和与RTP(VolP)服务的交互,还可以在单个实例中配置成SFU或MC。

             功能丰富,文档齐全,不怎么维护了,活跃度低

            安卓使用案例:GitHub - nubomedia-vtt/nubo-test

            iOS使用案例:GitHub - nubomediaTI/Kurento-iOS: Kurento Toolbox for iOS

    3.Janus 文档:Janus - General purpose WebRTC serverGitHub - zevarito/Licode-ErizoClientIOS: IOS Erizo client library for Licode WebRTC Framework gitHub:GitHub - meetecho/janus-gateway: Janus WebRTC Server

          以 Linux 风格编写的服务程序,采用 C 语言实现,支持 Linux/MacOS 下编译、部署,但不支持 Windows 环境

          Janus 分为两层,即应用层和传输层。每个应用都是一个插件,可以根据用户的需要动态地加载或卸载掉某个应用。插件式架构方案是非常棒的一种设计方案,灵活、易扩展、容错性强,尤其适用于业务比较复杂的业务,但缺点是实现复杂,成本比较高

          官方提供iOS和安卓SDK

   3.Mediasoup(SFU)  官网:mediasoup   gitHub:versatica · GitHub

           由应用层和数据处理层组成。应用层是通过 Node.js 实现的;数据处理层由 C++ 语言实现

           推出时间不长的 WebRTC 流媒体服务器开源库,包括 DTLS 协议实现、ICE 协议实现、SRTP/SRTCP 协议实现、路由转发等

           官方无android和ios的SDK,需要自己实现

   4.Licode(SFU/MCU)  gitHub:https://github.com/lynckia/licode

         由 C++ 和 Node.js 语言实现。其中,媒体通信部分由 C++ 语言实现,而信令控制、用户管理、房间管理用 Node.js 实现

         Licode 不仅仅是一个流媒体通信服务器,而且还是一个包括了媒体通信层、业务层、用户管理等功能的完整系统,并且该系统还支持分布式部署。

         官方无android和ios的SDK,需要自己实现(github上有别人实现可参考)

  5.ion gitHub:GitHub - ionorg/ion: Real-Distributed RTC System by pure Go and Flutter

       基于pion的开源媒体服务器, GO+Flutter的分布式RTC系统

  • 底子好,前景好:基于谷歌三剑客(WebRTC标准+GO+Flutter)
  • 效率高:纯GO+Flutter/JS开发,高开发效率+运行效率+维护效率
  • 云原生亲和:支持容器,服务端组件也优先选GO系(CNCF)
  • 分布式架构:信令和媒体解耦,易于扩展
  • 覆盖全:多样的SDK+APP(Flutter、JS、Swift)
  • 社区活跃:(最活跃的RTC社区,GO/Flutter的社区都很火)

 

     

参考文献:
WebRTC 流媒体常见开源方案综述 | 社区征文_音视频_liuzhen007_InfoQ写作社区
WebRTC → RTP媒体管理-音视频开发中文网
声网:如何自研支撑百万用户的毫秒级实时音视频系统?_架构_李慧文_InfoQ精选文章
基于Kurento的WebRTC移动视频群聊技术方案-阿里云开发者社区
分布式流媒体系统-ION - 知乎

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小惠珠哦/article/detail/1018579
推荐阅读
相关标签
  

闽ICP备14008679号