-->
您的位置 首页 > 加盟资讯

webrtc webgl,webrtc技术原理

0 前言

这篇文章我主要讲解一下之前webrtc的概况以及我做项目的经历。为了帮助您更好地理解本文,我们还提供了之前文章的参考列表,例如:

WebRTC一对一通话原理(一)

一对一通话实践及webrtc原理(二)

一对一通话实践及webrtc原理(三)

webrtc原理详解(一)

WebRtC音视频通话AppRTC实用版(二)

WebRtC音视频通话AppRTC实践(一)

一步步实现WebRtc 1:1视频通话(七)

webrtc实践中打开摄像头和麦克风

一步步实现WebRtc 1:1视频通话(五)

一步步实现WebRtc 1:1视频通话(一)

一步步实现WebRtc 1:1视频通话(二)

一步步实现WebRtc 1:1视频通话(三)

一步步实现WebRtc 1:1视频通话(九)

一步步实现WebRtc 1:1视频通话(六)

一步步实现WebRtc 1:1视频通话(四)

一步步实现WebRtc 1:1视频通话(8)

WebSocket基础知识(2)

WebSocket聊天练习(一)

WebSocket聊天练习(三)

WebSocket基础知识(1)

WebSocket聊天练习(四)js补充

1.WebRtc基本介绍

WebRtc支持主流浏览器、Android、IOS、Win、Linux的原生API。例如,它支持js/API/java/obkect-c/c++。 Flutter 跨IOS/Android。 IE(微软)不支持WebRtc。新的IE也使用了Google的内核。

刚开始学习时不要编译WebRtc源码。为什么?

(1)首先,国内网站无法访问WebRtc官方网站。

(2)接下来,你需要绕过墙壁。如果你绕过墙,你将能够访问它,但你可能无法下载它。您可以在外部服务器上编译并将编译后的文件复制回您的大陆服务器。这个过程非常繁琐。

(3)最后推荐Agora镜像,我也尝试下载了好几天,但期间要搭建各种网络环境,完全无法下载。因此,这个过程非常耗时。

如果不需要修改源代码,网上有直接编译的库可以使用。

WebRtc 技术细节

分辨率限制

比特率限制

呼叫多人

网上查的很多文章都不够详细。稳健性也不是很好。还有很多知识点。

2、单人通话模型

P2P是指A端和B端在传输数据时是点对点的。设备A和设备B直连成功,则p2p成功。如果失败,必须按顺序转移。 P2P成功,节省了服务器带宽。您必须自己构建转弯服务器和信号服务器。

3.多人通话模型

3.1 网格模型

对于N方呼叫,终端A在任意终端发送的数据通道数为N-1。对于Mesh模型,无论P2P是否成功,都必须传输N-1个通道的数据。如果有7 个人在通话,任何客户端都有6 个上行流,那么这里的带宽压力将会非常大。不支持传输N-1数据,仅中继和转发数据。 N-1 数据的传输由SFU 模型完成。开发Mesh模型相对容易,我们在之前的WebRTC体验中也使用过这个模型。

完美的场景:

Mesh解决方案无法容纳多方通话(P2P预计成功可以节省客户端上行带宽,但P2P成功率并不是100%成功)。也无法满足用户多样化的视频处理需求。服务器(比如录音(服务器上没办法做到这一点))一般只适合少于三方的通话。一些公司表示,他们最多可以处理六人的通话。

3.2 网板模型

您还需要自己构建SFU 服务器。如果N方正在通话,任何设备只需发送一次设备A的数据。这类似于发布/订阅模型。如果C需要监听A和B的数据,则需要订阅A和B的数据。这种方法减轻了客户端上行带宽的负担。与上面的例子类似,如果使用7个通道,则上行带宽只有1个通道,这对客户端的负担要小得多。市场上大多选择SFU型号。开发SFU很困难。

: 请注意,微信通话质量仍然一般。和圣王对比一下,可以看出差距还是蛮大的。

完美的场景:

与MCU相比,SFU对服务器的负担较小,适合纯传输,无需转码或合并,并且可以对任意通道的数据进行上下行切换。 SFU也是比较主流的解决方案。流行的开源SFU服务器包括Licode、janus、jitsi、mediasoup、Medooze等。欲了解更多信息,请访问官方网站。

3.3 单片机型号

MCU模型,也称为混合模型,是另一种策略。该模型的特点是将不同客户端的上行视频流合并为一条流转发给其他客户端。与传输N-1个数据的SFU相比,该模型减轻了下行带宽的压力。然而,收敛需要进行转码操作(服务器必须解码然后编码),这给服务器带来了很大的负载。另外,发送到客户端的流是固定的Confluence 屏幕,不太灵活。这种模式对客户非常友好。 SFU单独拉取A\B\C流,而MCU拉取ABC混合数据。特别是,随着通道数量的增加,MCU 解决方案对服务器的负载也会增加。 MCU开发难度大。

完美的场景:

适用于服务器性能良好、混合流媒体、语音视频通话量较少的解决方案。一般情况下,可以根据情况选择SFU+MCU的混合解决方案,灵活满足不同场景的应用需求。

Agora 目前最多支持17 个频道。如下图

这主要是结合负责控制的业务系统来完成的。

正常情况下,学生客户端视频是关闭的,仅打开音频。当学生举手并得到老师确认后,学生客户端就可以开始视频并在最后推流。然后业务系统通知其他客户端和老师拉流。

请注意: 中列出的17 个频道。一般来说,并不是所有客户端都会拉16个通道,这种可能性很小。

QQ基本上是p2p通话。想要提高打孔的成功率是非常困难的。开源方案的成本比QQ的打洞方案要小,难度也大得多。

4.WebRtc多人会议系统框架

无论您使用什么解决方案,您都需要重新开发您的信令服务器。

5.WebRtc应用领域

6、基于WebRtc的开源方案对比

对于janus、licode、jitsi、AppRtc、kurento方案的比较,根据不同的使用场景进行使用如下:

Janus得到了很好的支持,可以直接应用到您自己的商业解决方案中,也可以使用C语言进行开发。 Licode是使用C++开发的,但是开发难度比较大。 Jitsi 很少使用,也不是音视频流的主流解决方案。 AppRTC 是Google 开源的,允许您使用JS 方面的想法并从您的JS 代码中学习。不建议3 人或以上的群聊。也就是说,构科技和融云正在使用kurento解决方案。如下图

在上图中,服务器的录音功能非常重要。极果科技与融云之间的语音、视频通话均双向计费。如果您有多个通话,只要您正在通话,就会向您收费。视频拍摄也需付费。当大规模使用时就变得非常困难。如果您正在从事政府部门项目并需要构建私人服务,您永远不会使用声网这样的公司的解决方案,因为您不能信任他们的隐私。如果没有足够的经验和专业知识,尤其是小团队或者团队,全国各地的用户想要使用或者用户数量较多的时候,很多问题就会浮现出来。

7、国内语音/视频通话解决方案公司

Agora目前做得比较好。尤其是如果你有海外业务需求,比如从印度到中国,声网效果最好,腾讯的解决方案无法比拟。阿里云还有很多直播服务,比如RTMP服务。

圣王的js代码是打包的,没有办法看到实际的源码。

8. 用于WebRtc 开发的SFU 级联

如果没有SFU级联,选择服务器位置就变得非常困难,尤其是跨境呼叫。下图中,A要向SFU1发送数据,SFU1向SFU2发送数据。直接从服务器发送更加流畅。这里的SFU2充当订阅模型,C和D直接拉取SFU2支持的A的码流。因此,SFU地点的选择也非常重要。

9. AppRtc基本原理

AppRtc官方demo测试地址:

https://appr.tc/

(1)浏览器通过HTTPS访问Web服务器的加载页面,请求加入房间。

(2)本优惠适用于加入xxx房间的信令服务器。如果房间号已经存在,则直接添加。如果不存在,则会创建房间号。

(3)将该响应发送至信令服务器,用于加入xxx房间。如果房间号已存在,则直接加入并通知同房间的其他参与者。

(4)Offer和Answer通过信令服务器以SDP的形式交换媒体信息。 SDP包括音频、视频格式等。

(5)如果offer和answer都应用于STUN/TURN/ICE服务器进行洞穿透并且成功,则offer和answer必须经过TURN中继服务器。转接力服务。

(6) 如果上述步骤成功,报价和应答将包括语音和视频通话。

信令服务器代码路径在apprtc/src/collider,Web服务器在apprtc/src/web_app/js,turn服务器使用开源coturn解决方案。最有价值的参考是Web服务器的js代码。您还可以参考信令服务器。

请注意,APPRtc : 通常用于一对一呼叫。 AppRtc框架包括google_appengine、Python和nodejs。信令服务器还包括go语言。

在Web端,需要使用https来获取打开摄像头和麦克风的权限,所以有人使用Nginx作为代理。如下图

(1)大多数浏览器只能用HTTPS协议打开摄像头,所以Web服务器必须提供HTTPS访问,但APPRtc的Web服务器是基于HTTP协议的,是直接竞争的,所以应该使用Nginx作为协议。使用HTTPS 代理访问AppRtc 的Web 服务器。

(2)HTTPS方式访问时,访问信令服务器一般需要域名才能使用wss协议中的WebSockets。因此,客户端在访问信令服务器之前也作为代理连接。接下来,Nginx访问订单服务器。

(3)开放端口TCP/UDP 3478 和UDP 端口30000 以上可在Turnserver 范围内配置。

注意:对于:云服务器,可以使用nc命令检查端口是否开放。数控-l 8099。如下图

10.WebRtc通信的基本信令设计

主要包括媒体洽谈+网络信息候选人+房间人员管理。

(1)加入加入房间

(2) resp-join:加入房间后,如果发现已经有另一个人,则返回该人的uid。如果您是唯一的,则不会退回。

(3)leave:离开房间当服务器收到离开信号时,检查同一个房间内是否还有其他人,如果有,则通知其他人离开房间。

(4)new-peer:服务器收到new-peer后,通知客户端有新人加入,并发起连接请求。

(5)peer-leave: 服务器通知客户端有人要离开。

(6)answer:转发应答SDP。

(7)candidate:转发候选人。

: 信令服务器是专有的,通常可以用js/go 开发,但很少用C++ 开发。大多数信令服务器接口都是WebSocket。如果您使用C++,问题就会增加,因为必须移植WebSocket。使用Go进行开发嵌入了WebSocket模块,使您的设计更加高效。

为什么信令服务器使用WebSocket协议?

Web端常见的有http(轮询机制,很少用)、https、websocket、socketio。

请注意,Janus 等: 媒体服务器使用开源解决方案进行眩晕和转身。例如,apprtc 使用网格模型。

对于我们开发者来说,这包括客户端开发(web比较简单)、信令服务器开发等。

11.WebRtc学习资源

WebRtc学习资源有:

根据上面的讨论,您可以看到,在运行WebRtc 时,仅了解C++ 是不够的。我需要能够编写一些简单的js/go。稍后会提供一些学习链接。

12. 总结

这是上一篇文章的总结。欢迎您关注、转发、收藏、点赞。

了解更多即将开展的项目,请关注我们的微信公众号“安东尼奥记录世界”。

本站涵盖的内容、图片、视频等数据,部分未能与原作者取得联系。若涉及版权问题,请及时通知我们并提供相关证明材料,我们将及时予以删除!谢谢大家的理解与支持!

Copyright © 2023