郑州高端网站定制建设,深圳网站建设 百度一下,电子工程网官方网站,九亭做网站1. webrtc浅析webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁#xff0c;重复的内容我不再赘述。对我来讲#xff0c;webrtc的概念可以有三个角度去解释#xff1a;#xff08;1#xff09;.一个W3C和IETF制定的标准#xff0c;约定…1. webrtc浅析webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁重复的内容我不再赘述。对我来讲webrtc的概念可以有三个角度去解释1.一个W3C和IETF制定的标准约定了Web间实时音视频通信机制通过该标准可开发基于浏览器的、无插件的web多媒体应用一般是js该标准仅设定了点对点无中心的实时会话场景没有强制约束信令协议与内容没有要求有媒体处理的中心服务器主要目标是形成开发者与浏览器厂商良好的生态环境并积极向HTML5靠拢争取被纳入进去2.一群音视频算法和网络适应性算法这些算法囊括了视频会议几乎所有的核心技术包括音视频的采集、编解码、网络传输、播放显示、安全等功能还提供了操作系统系统调用跨平台封装的实现包含WindowsLinuxMacAndroidiOS3.一个开源工程核心由c实现可通过修改、封装、提取代码等方式实现一套视频会议系统客户端可实现为Web js、App或Windows应用程序等多种形式服务端可实现包括业务外的所有服务包括媒体服务、信令服务、穿墙服务、中继服务等等这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。对webrtc的理解与使用我认为有三个境界1.能搭建一个简易的视频会议系统其中客户端部分可以这样做 Windows端Mac端Linuxx86端在自带的peerconnection client或libjingle改一下取决于信令是http还是sip家族信令Android/iOS端在apprtc或licodeAndroidClient及Licode-ErizoClientIOS改一下web端用webrtc 自带js api实现一下。服务端部分可以这样做信令服务器在apprtc的collider改一下穿墙服务器用自带的stun serverturn server部署一下中继服务器在自带的relay server改一下媒体服务器在kurentos、licode、jitsi、Intel Collaboration Suite for WebRTC或janus改一下如果需要和传统的SIP体系互通则在webrtc2sip改一下如果需要关注实时通信过程中的延时、丢包、接通率、掉线率等质量问题可以部署callstats来进行专业监测把所有服务都再部署于云平台的多个虚拟主机上或阿里云的容器云服务完成以上操作就搭建起初级规模的云上视频会议系统原型了。2.能提取、理解并使用webrtc的算法模块即或将算法模块融入到自己的代码中或将自己的算法添加至webrtc里作为开源贡献或自己产品的差异性优势。值得提取的算法模块包括音视频编解码与处理框架vp8、vp9、voice engine、video engine音视频采集呈现封装、音视频预处理NetEq、NS、AEC、Video Jitter Buffer、网络适应性GCC算法、ARQ、FEC、安全性Dtls、Srtp/Srtcp等自己可添加的有视频编码模块x265、nvenc、intel qsv、xavs2、以及其他定制化的网络传输策略。3.能够结合基于rtmp-cdn/p2p等直播技术构建既支持交互互动又支持海量围观可商用、能运营、易扩展、全兼容的音视频PaaS服务平台完成一个多媒体通信的终极产品。Licode是达到第一境界技术层面所需要了解的开源工程它从webrtc代码中提取出了SFU/MCU媒体服务所用到的音视频、媒体传输、信令的功能代码结合libnice与libav实现了ICE与媒体转发功能并封装成了可被调用的js API此外还用js实现了包含全局管理服务、数据库服务、业务逻辑服务与信令媒体的调用服务的业务代码。Licode实现了webrtc开源工程没直接实现的中心侧的媒体服务功能并提供了简单的业务模型与分布式部署方式从而得到了多媒体通信工程师的广泛关注。但是Licode的相关文档与资料非常少故本文是在我个人观察运行调试代码后总结所写的不正确之处希望在留言中能够得以指正。2. Licode系统分析2.1 系统架构Licode的系统架构如下有客户端和服务端客户端包括ErizoClient和NuveClient分别用来进行信令与音视频交互和业务操作类似于终端和会控集成在一起服务端包括Nuve、ErizoController、ErizoAgent和MessageBus分别用来实现业务服务与全局管理服务、信令服务、媒体服务和服务通信其中ErizoController类似于MC、ErizoAgent类似于MP。图1 系统架构图2.2 客户端与服务端交互流程客户端与服务端的交互流程如下图所示其中客户端代码集中在N.API.js与Client.js上服务端代码集中在nuve.js与erizoController.js上。图2 信令交互图3. 系统组成与模块划分3.1 系统组成本系统组成仅指服务端的系统组成包括Nuve业务管理服务ErizoController信令服务ErizoAgent媒体服务ErizoJS媒体转发实体。个人觉得代码在文件命名与文件组织结构上比较乱初学者不易理解如erizo_controller文件夹包括了除nuve以及webrtc的js api之外的所有js代码不仅仅是erizoController此外webrtc核心部分命名为erizo也让人与整个系统相混淆。系统组成如下图所示一个Nuve管理多个ErizoController(以下简称EC)一个EC管理多个ErizoAgent(以下简称EA)一个EA管理多个ErizoJS(以下简称EJ)一个EJ就是一个SFU封装了C实现的webrtc、libav与libnice。图3 服务端系统组成图3.2 Nuve业务管理服务图4 Nuve业务管理服务图5 Nuve各模块用途及对应文件此外这篇文章Licode二Nuve源码分析 - CSDN博客 对Nuve做了更详细的分析。3.3 ErizoController信令服务图6 ErizoController信令服务图7 ErizoController各模块用途及对应文件3.4 ErizoAgent媒体服务图8 ErizoAgent媒体服务图9 ErizoAgent各模块用途及对应文件3.5 ErizoJS媒体转发实体图10 ErizoJS媒体转发实体图11 ErizoJS各模块用途及对应文件3.6 webrtc由于webrtc工程代码本身非常庞大编译工具也很独特Licode并未全部引入仅仅抽取了webrtc的部分代码如下图所示图12 webrtc各组件用途及对应目录由此可见所抽取的代码没有webrtc自带的音视频处理框架(voice engine/video engine/media engine)这是由于SFC只在RTP层进行转发并不解码只需要check一下媒体流属性(如I帧头)即可。抽取代码的亮点在于将webrtc强大的抵抗网络时延和丢包的网络适应性算法和协议都提炼出来了可以供广大研究视频传输的网络适应方向的开发者们单独学习、实验并快速集成到自己非webrtc-based的产品中来。webrtc的网络适应性手段包括丢包重传(ARQ)、前向纠错(FEC)和拥塞控制(GCC)其中自动码率(ARC)在GCC中。对网络适应性有兴趣的朋友可对照代码看如下几篇博文(1). 丢包重传 (ARQ)RFC4585 RTP/AVPF 传输层反馈RFC4588 4585补充 重传包格式RFC5104 4585补充 负载层反馈RFC5124 RTP/SAVPFRFC5450 4585补充 Jitter报告(2). 前向纠错 (FEC)RFC2198 WebRTC中的前向纠错编码 - Red PacketRFC5109 WebRTC 的前向纠错编码 - XOR FEC(3). 带宽检测 (BWE)传统的基于RTCP RR报文中丢包数来进行带宽检测的算法目前被认为是最low的了因为属于事后处理先进的算法是需要事前感知的突发情况除外假定带宽是逐渐变窄的根据信号估计理论可以在网络链路发生丢包以前就监测到网络拥塞,GCC草案REMB草案GCC算法与函数调用 WebRTC基于GCC的拥塞控制(上) - 算法分析 WebRTC基于GCC的拥塞控制(下) - 实现分析带宽估计 WebRTC之带宽控制部分学习(1) ------基本demo的介绍带宽检测 WebRTC 中的带宽侦测 - CSDN博客接收缓冲区延迟估计 WebRTC视频接收缓冲区基于KalmanFilter的延迟模型3.7 libav、libnice、libsrtplibav是从ffmpeg分离出的开发者发布的开源工程与早期ffmpeg有很大相似性对于仅调用api的开发者来说就简单看成是代码量更小、第三方依赖库更少、编译更简单的轻量级ffmpeg吧。这个库在Licode编译过程中有处问题Licode使用版本较旧的libav的接口其中avcodec_alloc_frame和avcodec_free_frame都已经遗弃改为av_frame_alloc/av_frame_free才可编译通过。libnice库基于ICE协议实现的网络层库Licode使用libnice库来实现端到端的ICE连接和数据流发送接收以及candidates(候选地址)和SDP媒体描述文件的相互交换。libsrtp库主要是是用来加密rtp/rtcp的。4. 关键技术4.1 网络收发流水线架构技术网络收发或一个SFU实现并非简单的从一个源地址收到若干个数据包再复制多份发送给多个目的地址正如3.6所描述除了需要堆栈式的ICE地址转换、DTLS/SRTP的解密还需要流水线式的RTP/RTCP的丢包检测与重传、FEC处理、带宽检测与估计、包缓冲区调整以及平滑发送等若干个复杂步骤这个流程在Licode代码中是通过Pipeline-Handler这样的架构实现的由于webrtc仅提供底层算法并未提供SFU架构所以我认为这种架构是Licode最重要的关键技术可供未来想成为软件架构师的开发者参考学习。日后我也再详细分析这个架构看看是否能抽象出一个新的设计模式来。整个网络收发的层级模型图如下图所示其中每一层右侧标注出了关键类。图13 网络收发层级模型Pipeline的类图如下图图14 Pipeline相关类图对Pipeline来说需要全局管理、长时处理或非逐个包处理的流程实现对象叫Service包括Handler的管理、RTCP的计算与处理、当前状态的处理、网络质量的管理以及包缓冲的管理都是Service而需要每次逐包处理的流程实现对象叫Handler包括19项Handler其代码都位于erizo\src\erizo\rtp目录下//新增全局处理的Service pipeline_-addService(handler_manager_); pipeline_-addService(rtcp_processor_); pipeline_-addService(stats_); pipeline_-addService(quality_manager_); pipeline_-addService(packet_buffer_);//新增单次处理的Handler pipeline_-addFront(std::make_sharedRtcpProcessorHandler()); pipeline_-addFront(std::make_sharedFecReceiverHandler()); pipeline_-addFront(std::make_sharedLayerBitrateCalculationHandler()); pipeline_-addFront(std::make_sharedQualityFilterHandler()); pipeline_-addFront(std::make_sharedIncomingStatsHandler()); pipeline_-addFront(std::make_sharedRtpTrackMuteHandler()); pipeline_-addFront(std::make_sharedRtpSlideShowHandler()); pipeline_-addFront(std::make_sharedRtpPaddingGeneratorHandler()); pipeline_-addFront(std::make_sharedPliPacerHandler()); pipeline_-addFront(std::make_sharedBandwidthEstimationHandler()); pipeline_-addFront(std::make_sharedRtpPaddingRemovalHandler()); pipeline_-addFront(std::make_sharedRtcpFeedbackGenerationHandler()); pipeline_-addFront(std::make_sharedRtpRetransmissionHandler()); pipeline_-addFront(std::make_sharedSRPacketHandler()); pipeline_-addFront(std::make_sharedSenderBandwidthEstimationHandler()); pipeline_-addFront(std::make_sharedLayerDetectorHandler()); pipeline_-addFront(std::make_sharedOutgoingStatsHandler()); pipeline_-addFront(std::make_sharedPacketCodecParser()); pipeline_-addFront(std::make_sharedPacketWriter(this));4.2 分布式保活技术Licode的系统设计如3.1所述Nuve管理多个ECEC管理多个EAEA启动多个EJ进程在资源上Nuve负责EC的负载均摊EC负责EA和EJ的负载均摊(毕竟EJ在EA内EA除了监控OS性能并未太多其他工作)故Nuve需要EC分布式保活EC需要EA分布式保活。Licode实现比较简单代码可参考CloudHandler.js与ecCloudHandler.js。例如Nuve每启动一个EC立刻分配id并加入到ECList中并在DB中写入id作为key且在该key对应的value上进行累加此后Nuve的秒级循环中不断check这个value并继续累加如果超过阈值则认为该EC失效将此EC从list中删除。Nuve同时提供keepalive接口EC通过RPC调用此接口不断对数据库中本id的value清零从而实现了分布式保活。EC与EA间方法一样。4.3 资源管理技术这里定义的资源有三个含义设备资源设备简单分为发布设备、接收设备、收发设备、内容资源某地的实时视频或已录制视频以及server处理能力余量例如还能转发的路数还能容纳的新成员。Licode的publish-subscribe模型将信令交互、内容管理源站管理、媒体分发三者分开从而可实现多维度的资源管理。Client 1 发的第一个信令仅起到了一个资源注册的作用即room中存在Client 1的id了Client 1 发的第二个信令表明该id可以发布新内容了内容为Stream 1Client 2 同理room记录了Client 2的id与Stream 2Client 1发的第三个信令表明对Client 2的Stream 2内容感兴趣开始订阅了于是启动了SFU过程Client 3加入room后可以发布资源(Stream3)可以订阅资源(Stream1、Stream2)也可以什么都不做因为任何在该room中注册的设备都可以pubilsh内容资源或subscirbe已publish的内容资源。完全解耦带来的好处是内容资源同设备资源一样也可以轻易管理了在启动SFU过程中server处理能力余量也能得到较好的管理。H.323是紧耦合的信令交互后必须开启媒体交互电路交换的思维信道容量有限申请资源赶紧用用完赶紧释放对内容管理过于依赖于会议逻辑的实现为了实现更灵活的互听互看其逻辑会堆砌的很复杂。然而好的方法也不是万能的publish-subscribe的完全解耦虽带来极大的可扩展性但对于某些传统业务更复杂了。比如MCU两个终端互看就需要启动两个erizoJS互相订阅发布根据负载均摊的算法可能两个erizoJS都不在一个erizoAgent里(不在同一台物理机或虚拟机上)。MCU轮询模式也稍复杂轮询者需要不断的subscribe room中的发布者发布者也要不断的去remove、add切换速度比接收所有流I Frame Check的传统方式要慢的多。5. 总结本文先介绍了自己对webrtc的概念理解与使用参考接下来从系统架构、交互流程、系统组成与模块划分几个角度对Licode进行概要设计级别的分析最后对自己觉得Licode比较有特色的三大技术即网络收发流水线架构技术、分布式保活技术与资源管理技术进行了浅层次的解释。文中表述内容可能会有不准确之处希望能与读者们交流并及时改正。原文https://zhuanlan.zhihu.com/p/40462946★文末名片可以免费领取音视频开发学习资料内容包括FFmpeg webRTC rtmp hls rtsp ffplay srs以及音视频学习路线图等等。见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
