关于webrtc音视频开发的信息

本篇文章给大家谈谈webrtc音视频开发，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享webrtc音视频开发的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、RTC技术（WebRTC）
• 2、WebRTC基于浏览器的开发
• 3、WebRTC简介（一）

RTC技术（WebRTC）

RTC（Real time communication）实时通信，是实时音视频webrtc音视频开发的一个简称，我们常说webrtc音视频开发的RTC技术一般指的是WebRTC技术，已经被 W3C 和 IETF 发布为正式标准。由于几乎所有主流浏览器都支持 WebRTC 标准 API ，因此也让浏览器之间无插件化的音视频互通成为可能， 大大降低了音视频开发的门槛，开发者只需要调用 WebRTC API 即可快速构建出音视频应用。
更广义的RTC技术，不单单局限于音视频，包括IM、图片、白板、文件共享等富媒体在内的实时交互也属于RTC技术范畴。

直播中我们关心的几个点：延迟、质量、成本等。
传统rtmp直播痛点：TCP，延迟高、拥塞导致卡顿问题较多（质量问题）。
互联网网络复杂、延时敏感、实时音视频流畅度及清晰度较低以和运营成本较高等。
没有一项技术能兼顾并解决直播中的所有问题，RTC是时延、流畅、质量、成本等的平衡，成为技术选型落地的模型。
我们在做RTC应用的时候，不应该一味地追求一些点，不应该在某些单点上用力过猛（比如单纯的追求抗丢包能力），导致最终的效果会打很多折扣，不能只着眼于延迟低，画质高，应该把视角放在用户的整体体验上。

RTMP只是TCP上的一个标准协议，所以接入是一个标准体系，推流端可以是OBS这种直播软件工具，也可自开发rtmp推流工具，播放端可以是Flash播放器（Adobe 2020 12月份已经弃用）、服务端有技术成熟的CDN技术和设施进行分发、Native的播放器或者flv.js/hls.js这种开源播放器组件，遵循rtmp、flv、hls标准即可，接入成本比较低。而一个完善的RTC服务应用，需要从推流端、服务端、到拉流端，一整套完整的全链路闭环技术。

视频会议、在线教育小班课、大班课、1v1视频连麦、多人视频连麦互动、语音聊天室、在线面试、在线医疗、云游戏、智能家居、在线签约、在线K歌等，遍地开花。
比如Zoom、腾讯会议、钉钉会议、微信音视频聊天

互动连麦+服务端转推rtmp至CDN，CDN分发给观众。

声网、腾讯云音视频、即构、阿里云RTC、华为云RTC、微吼VRTC、网易云信RTC、保利威RTC、Ucloud RTC、融云RTC、拍乐云等。

5G时代RTC技术满足实时通信的同时，将赋能 AI、AR、VR、智能家居、云游戏、远程辅助驾驶等场景化落地。

WebRTC基于浏览器的开发

WebRTC需要通过长链接查找到通信双方webrtc音视频开发，然后通过 peer to peer webrtc音视频开发的方式传输音频数据。

WebRTC中最主要webrtc音视频开发的就是一个叫做 PeerConnection 的对象，这个是WebRTC中已经封装好的对象。每一路的音视频会话都会有唯一的一个 PeerConnection 对象，WebRTC通过这个 PeerConnection 对象进行视频的发起、传输、接收和挂断等操作。
PeerConnection中包含的属性如下：

PeerConnection 中还包含了一些方法：

RTCSessionDescription 类型中包含了两个属性：

A向B发起通信请求

首先WebRTC需要一个信令服务器，也就是一个socket链接用来发起视频通信，发送WebRTC中的 offer 和回复 answer 。
如何搭建一个简单的socket服务器，可以找我的这篇文章《》，也可以是用webSocket搭建信令服务器。

WebRTC需要打洞服务器（一个 stun ，一个 turn ）来穿透防火墙等，我们需要配置打洞服务器：

WebRTC由于是未来的一种即时通信的标准，所以目前在Chrome、Firefox和Opera浏览器中有内置插件，均提供一个全局的PeerConnection类。

创建PeerConnection的对象：

创建时需要传入打洞服务器的配置信息，如果不穿入打洞服务器的配置信息，则只可以在内网中使用实时音频通讯。

由于PeerConnection是全局的，所以我们可以通过另外的一种方式进行创建：

如何判断浏览器是否支持WebRTC：

WebRTC也提供了一个全局单例来获取本地的音视频信息：

GetUserMedia需要传入三个参数，第一个参数为配置信息，第二个参数为获取成功的回调，第三个参数为获取失败的回调。
获取到视频流之后

创建一个offer并发送给指定的对象：

创建offer时要同时发送打洞服务器配置信息，WebRTC给了一个监听：

返回的参数中有一个 candidate 属性，便是打洞服务器的配置信息。

音频通话请求是通过socket发来的，需要通过socket去监听。

如果收到了offer，那么需要将offer存到自己的peerConnection中，并且创建一个answer发送回对方。
将offer存入peerConnection中：

创建一个answer并返回给对方：

如果收到了打洞服务器的配置信息，那么需要将打洞服务器的配置信息存入到 peerConnection 中：

发送给对方answer后便可以等待接受对方的数据流了：

至此，整个简单的WebRTC的流程就完成了

WebRTC简介（一）

WebRTC（Web Real-Time Communication）也被称为网络实时通信webrtc音视频开发，是由 Google、Mozilla 和其他公司推动的一个开源项目webrtc音视频开发，它通过 Javascript API 实现无插件的实时通信，以及在不需要中介的情况下在浏览器之间交换任意数据。

WebRTC的优点：

WebRTC技术的诞生，有一个很重要的原因在于，在浏览器实现实时音视频通话，需要依赖相关插件或程序，而插件安全漏洞问题则更为关键。浏览器开发人员无法控制这些插件以及更新，因此插件带来的安全风险也相对较大。

在WebRTC诞生之前，开发实时音视频应用的成本是非常高，需要考虑的技术问题很多，如音视频的编解码，数据传输延时、丢包、网络抖动、回音处理和消除等，如果要兼容浏览器端的实时音视频通信，还需要额外安装插件。当然，可以考虑使用第三方成熟技术，比如当时世界顶级的互联网音视频方案GIPS(Global IP Solutions)，支付相应的费用就行。很多知名的应用或者软件服务商也都在用GIPS，如Yahoo，AOL，IBM，SKYPE，QQ等。

WebRTC项目的愿景：实时通信web化，让WebRTC成为互联网音视频实时通信的规范，让开发者基于此规范快速开发出安全、可靠的应用。未来的音视频实时通信，必定是现代化生产活动中极其重要的板块。以下是WebRTC的部分应用场景：

两个不同网络环境的（具备摄像头/麦克风多媒体设备的）客户端（浏览器或APP），要实现点对点的实时音视频对话，难点在哪里？

要实现P2P通信，首先需要webrtc音视频开发了解彼此是否都支持相同的媒体能力，WebRTC默认使用V8编解码器，如果要连接的对方不支持V8解码，如果没有媒体协商过程。那么即使连接成功，把视频数据发给对方，对方也无法播放
比如：Peer-A端可支持VP8、H264多种编码格式，而Peer-B端支持VP9、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264
有一个专门的协议 ，称为Session Description Protocol (SDP)，可用于描述上述这类信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为"媒体协商"。

交换数据会通过一个中间服务来完成，在这里，webrtc音视频开发我们称之为信令服务器
在建立P2P连接时，需要交换的信息有：

最理想的场景

然而，在大多数情况下，两个对等端都是各自处于某个局域网之中，相互之间隔着NAT与防火墙

NAT(Network Address Translation)即为网路地址转换协议

局域网--公网

公网--局域网

可以借助STUN服务器.，穿越NAT

在NAT四种主要类型中有三种是可以使用STUN穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用STUN穿透，这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说，路由器只会接受之前连线过的节点所建立的连线。

可以点对点连接的情况与需要中转的情况（数据来源于Google）

不过在国内大部分局域网无法穿越。 关于webrtc音视频开发和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 webrtc音视频开发的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、webrtc音视频开发的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。