webRTC基础入门

已于 2023-02-06 09:53:34 修改
阅读量4.1k 收藏 29
点赞数 4
分类专栏： ffmpeg 文章标签： webrtc 音视频
于 2022-05-31 00:02:50 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_39736022/article/details/125055801
版权

文章目录

一、webRTC介绍

未来应用趋势，向web浏览器发展
在这里插入图片描述
ffmpeg与webRTC区别：
ffmpeg用于处理多媒体文件的编辑，音视频的编解码
webRTC用于处理多网络抖动，丢包评估，回音消除，降噪
在这里插入图片描述
webRTC可以跨平台

二、webRTC原理与架构

绿色为webRTC核心功能，紫色部分为浏览器提供的js的api层，即浏览器对C++ API做了一层封装
在这里插入图片描述
绿色部分，核心层，分为四层：
C++层，PeerConnection对等连接，其中包含很多API：传输质量，传输数据，传输统计报告，音视频设备管理，采集，等
session层，上下文管理
音视频引擎和传输（音频：编码器/防抖动/回音消除和降噪，视频：编码器/防抖动buffer/图像增强，传输：底层UDP，应用层RTP/SRTP/RTCP）
音频的采集和渲染，视频的采集（没有视频渲染，需要浏览器应用层自己做）【虚线部分允许浏览器自己进行重载】

三、webRTC源码目录结构


在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

四、webRTC信令服务器

1.原理

每个公司的业务模型不一样，因此没有统一规范
信令服务器的作用：
在这里插入图片描述

信令服务器要传输的信息：
1.SDP
2.网络信息，用于建立p2p
3.具体的业务信息

2.信令服务器实现

建议使用socket.io
在这里插入图片描述
为什么使用socket.io
1、socket.io时WebSocket的超集，本身就支持WebSocket的功能
2、信令服务器需要基于TCP协议，因为需要保证可靠性，而WebSocket底层使用的就是TCP协议
3、socket.io本身就带有房间的概念
4、socket.io是跨平台、跨终端、跨语言的，开发方便

五、webRTC传输基本知识

1、NAT（Network Address Translator）
将内网地址转换为公网地址，内网地址无法通讯，通过NAT转换为公网之后，才有通信的可能
2、STUN（Simple Traversal of UDP Through NAT）
充当中介作用，交换两个公网的信息，使得两个公网之间可以建立连接
3、TURN（Traversal Using Relays around NAT）
在云端架设一个服务器，在P2P连接不成功情况下，保证音视频互通
4、ICE（Interactive Connectivity Establishment）
罗列所有通信可能性(STUN、TURN)，选择最优解

1.NAT

NAT网络原理图：
在这里插入图片描述
NAT种类（1到4越来越严格）：
1、完全锥型（Full Cone NAT）
对响应没有限制，外网的任何ip都可以与内网ip访问
在这里插入图片描述

2、地址限制锥型（Address Restricted NAT）
只接收有发送过请求的ip地址相关的响应
在这里插入图片描述

3、端口限制锥型（Port Restricted NAT）
地址限制型基础上，再加上对端口的限制
在这里插入图片描述

4、对称型（Symmetric NAT）
同一主机向不同主机发送请求时，通过NAT映射的外网ip地址和端口不同
在这里插入图片描述
**如何判断当前stun服务的NAT类型：**客户端发送一个ECHO请求到stun服务端，服务端通过同样的ip和端口，返回消息回来，客户端如果未接收到，说明udp不通，如果收到响应判断公网ip地址与本机ip是否一致
在这里插入图片描述

2.STUN协议

2.1 STUN协议概述

STUN存在的目的就是进行NAT穿越
STUN是典型的客户端/服务器模式，客户端发送请求，服务端进行响应
它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。

2.2 RFC STUN规范

RFC3489/STUN：Simple Traversal of UDP Through NAT

    ① 定义：为简单的通过UDP进行NAT穿越的规范
    ② 存在问题：
        - 网络路由器对UDP的限制比较多，有的路由器是不允许进行UDP传输的，导致在使用RFC3489规范在进行NAT穿越的时候，失败率很高

RFC5389/STUN：Session Traversal Utilities for NAT

    ① 定义：一系列穿越NAT的工具
    ② 特性：
            - 通过UDP和TCP两种协议进行NAT穿越

2.3 STUN协议

消息头结构：
① 总共20字节
② 组成：
（1）协议3489
- 2字节（16bit）的消息类型
- 2字节（16bit）的消息长度：注意，消息长度不包括20字节消息头本身
- 16字节（128bit）的事物ID，请求与响应的事物ID相同，用于请求于响应的匹配
（2）协议5389：格式如下图所示
在这里插入图片描述
- 2字节（16bit）的消息类型：
· 消息类型的最低两位必须是00，用来区分复用同一个端口时哪一个时STUN协议(与老版本协议做区分)
· C0和C1用来分类（0b00-请求/0b01-指示/0b10-成功响应/0b11-失败响应）
· 剩下的12位用于定义请求/指示，如下图

- 2字节（16bit）的消息长度：注意，消息长度不包括20字节消息头本身
- 4字节（32bit）的魔法值
- 12字节（96bit）的事物ID，请求与响应的事物ID相同，用于请求于响应的匹配
消息类型
只有六种，分两种方法（最低4bit）：1表示绑定，2表示私密（5389将私密删除了）
在这里插入图片描述
事务ID
如果不是下述的固定值，说明不是rfc5389而是3489
在这里插入图片描述
消息体结构
消息体数据需要为32bit对齐，如果不是对齐需要补0对齐
在这里插入图片描述
在这里插入图片描述
不同消息类型下，对应属性的实现要求如下图（N/A表示不支持，O表示可选，M表示必选）
在这里插入图片描述

大小端模式

大端模式：数据的高字节保存在内存的低地址中
小端模式：数据的高字节保存在内存的高地址中
网络字节顺序：采用大端排序方式

2.3 STUN协议操作流程概述

在这里插入图片描述
如图为典型的stun配置，stun客户端连接到私有网络NET1，通过NAT1连接到私有网络NET2，NET2通过NAT2连接公网，stun服务器部署在公网。
   stun是一个简单的客户端-服务端模型的协议，客户端发送请求至服务端，然后服务端返回响应。有两种类型的请求——一种是Binding Request，通过UDP传输；一种是Shared Secret Request，通过基于TCP的TLS传输。Shared Secret Request要求服务器返回一个临时的username和pazuissword，这个username和password用于后续的Binding Request和Binding Response，保证身份认证和消息完整。Binding Request用于确定nat分配的绑定，客户端通过udp发送Binding Request到服务器，服务器获取到发送源的ip地址和端口，并将其复制到Binding Response中发送回客户端。在Binding Request消息中有一些参数设置使得客户端可以要求服务器在其他地方，或者用不同的ip和端口发送Binding Response。有一些属性用于提供消息完整性和身份验证。
   这些方法就是使用stun来发现NAT的类型以及学习使用Binding。STUN客户端通常嵌入到一个应用程序中，该应用程序需要获得一个公共IP地址和端口，可以用来接收数据，如：应用想通过公共ip和端口获取RTP数据，当应用启动时，内置stun客户端发送一个Shared Secret Request到服务器来获取username和passeword，然后发送Binding Request。通过DNS SRV记录可以发现STUN服务器，一般假设客户端已配置了用于查找STUN服务器的域。通常，这将是应用程序正在使用的服务的提供者的域(这样的提供者被鼓励部署STUN服务器，以便允许其客户通过NAT使用其应用程序)。当然，客户端也可以通过其他方式确定STUN服务器的地址或域名。STUN服务器甚至可以嵌入到终端系统中。
   Binding Request用于发现NAT的存在，以及发现由NAT映射后的公网ip地址和端口。Binding Request通过UDP协议发送到服务器端，在stun客户端和服务器端之间，Binding Request可能会通过一层或多层NAT。最终的结果是，服务器接收到的请求消息的源IP地址和端口，是最靠近stun服务器的那一层NAT映射后的公网地址。服务器将映射后的IP地址和端口复制并填写到Binding Response消息中发送给客户端。
   当客户端接收到Binding Response后，将解析出来的IP地址和端口与本地IP地址和端口进行比较，如果不匹配，则表明stun客户端处于一层或多层NAT之后。此时只是表明stun客户端处于NAT之后，还无法判断NAT的类型，为了进一步决定NAT的类型，客户端会发送第二个Binding Request，这一次是往不同的ip地址发送，如果Binding Response中的IP地址和端口和第一次的Binding Response的IP地址和端口不一样，那么stun客户端处于对称型锥的NAT之后，为了判断是否是完全型锥的NAT，客户端可以发送一个Binding Request并要求服务端用一个不同的IP和端口发送Binding Response，换句话说，如果客户但使用IP为X端口为Y向IP为A端口为B的主机发送请求，stun服务器使用IP为C端口为D向客户端发送回应，如果客户端能收到回应则表明其处于完全型锥。客户端也可以要求服务器使用相同的IP地址但端口不同来发送回应，以此来判断是处于端口限制型锥还是限制型锥。

2.TURN协议

2.1 TURN介绍

通常stun和turn是放在一起使用的
在这里插入图片描述

2.2 TURN原理简介

TURN服务是建立在STUN之上的，消息格式使用STUN的消息格式

TURN协议相当于在服务端架设的一个TURN服务，相当于一个中介，客户端在无法NAT穿越的时候，首先将媒体数据首先传递给TURN服务，通过TURN服务转发给其他的接收者

TURN分为Client端和Server端

TURN Client 会向 TURN Server 发送一个请求，TRUN Server收到请求后，会根据该请求建立一个公共的IP地址和端口Port，用于接收和发送数据

TURN实例如图（50000端口与3478端口形成通道）
在这里插入图片描述

2.3 TURN传输层协议

① TURN Client 向 TURN Server 发送数据：UDP、TCP、TLS over TCP（加密后的TCP）
② TURN Server 向 peer 发送数据：UDP
在这里插入图片描述

2.4 client与server建立链接并保活

① TURN Client 向 TURN Server 发送 Allocate 请求
② TURN Server 对 TURN Client发送过来的请求做鉴权处理
③ 如果请求没有响应的权限，返回401，标识未授权
④ TURN Client 收到 TURN Server发送的未授权响应后，会重新向 TURN Server发送请求信息，本次请求信息中包括鉴权信息
⑤ TURN Server 对 TURN Client 响应成功应答
⑥ TURN Client 会向 TURN Server 定时发送 Refresh 请求，为了保活
在这里插入图片描述
allocate建立连接，refresh request是用来保活的心跳

2.5 TURN发送机制

Send 和 Data，步骤如图所示
send表示上行，data表示下行，当数据转发到peer时，需要去掉turn头（30字节头），仅传输udp数据
在这里插入图片描述
采用通道机制传输：
Channel（创建一个channelID，与peerA绑定，在管道内发送数据，无需携带turn头），步骤如图所示：
send与channel可以并存
在这里插入图片描述

2.5 TURN在webRTC的使用

在这里插入图片描述

五、ICE框架

1.ICE介绍

ICE全称Interactive Connectivity Establishment，即交互式连通建立方式，它是根据RFC5245实现，是一组基于Offer/Answer模式解决NAT穿越打洞的协议集合

2.ICE作用

1.让左侧peer获取到所有能够连接到右侧peer的通路
通路1：局域网内本机的IP地址。通路2：通过nat打洞。通路3：通过relay中转。
2.双方将所有通路收集后，传给对方
3.对三种通路进行尝试
在这里插入图片描述

3.ICE候选者

每个 Candidate 是一个地址，例如： a = candidate:…UDP…192.169.1.2 18106 typ host
每个 Candidate 包括：协议、IP、端口和类型Candidate类型，通过信令中的SDP发送给对方：
类型包括三种
① 主机候选者：网卡自己的 IP 地址
② 反射候选者：经过 NAT 之后的 IP 地址
③ 中继候选者：通过 TURN 服务开通的 IP 地址和端口

4.ICE做了什么

1.收集 Candidate、
① 主机候选者（Host Candidate）：获取本机所有 IP 和指定端口
② 映射候选者（Reflexive Candidate）：使用 STUN 或 TURN 发起请求的时候，获取到的映射后的 ip 和端口、
③ 中继候选者（Relay Candidate）：通过 TURN 服务，发送 accolate 请求申请的 IP 地址和端口

2.对 Candidate Pair 排序
① 一方收集到所有候选者后，通过信令传给对方
② 同样，另一方收到候选者后，也做收集工作
③ 当双方拿到全部列表后，将候选者形成匹配对

3.连通性检查
① 对后选对进行优先级排序
② 对每个候选对进行发送检查
③ 对每个候选对进行接收检查
④ 联通性检测过程如图所示
在这里插入图片描述

六、webRTC端到端交互讲解

1.整体流程

A是发起端，B是接收端，分别与信令服务器建立连接。
A创建PeerConnect，通过getUserMdedia拿到本地视频流，将流添加到连接中去；
A调用create offer来创建SDP，并将SDP设置到槽中，底层发送binding请求，去sturn收集候选者；并将SDP发送到信令服务器；
信令服务器对SDP进行中转给B；
B对SDP做一系列处理，此时B存储两个SDP，自己的SDP以及远端的SDP。底层发送binding请求，去sturn收集候选者；并将SDP发送到信令服务器；
信令服务器对SDP进行中转给A，A再进行存储SDP；
sturn服务将候选者返回给A（onIceCandidate）；
A再将候选者发送给信令服务器转给B；
B调用AddIceCandidate方法将A的候选者数据存储，B从sturn受到自己的候选者数据后再转发给A；
A调用AddIceCandidate方法将B的候选者数据存储；
此时webRTC底层就会进行候选者检测，生成候选者对，排序，连接检测，找到最优线路；
建立P2P通路后，A将流传输到B，B收到onAddStream事件后，可以对流进行显示，渲染等操作；
在这里插入图片描述

2.媒体协商

SDP的交换过程即为媒体协商。
A首先通过setLocalDescription收集候选者（通过STUN和TURN服务拿到候选者），同时创建一个offer，形成SDP报文，通过云端的信令channel传给B。
B收到数据后，调用setRemoteDescription将SDP信息存储到槽中。
B再创建一个answer形成B的SDP，同时也会调用setLocalDescription收集B的候选者，通过云端的信令channel传给A。
A收到数据后，调用setRemoteDescription将SDP信息存储到槽中。
最终A和B都会存储两个SDP，对两个SDP取交集，拿到最好的组合数据
在这里插入图片描述

协商过程中的状态机如下图：
在这里插入图片描述

PRAnswer是一个中间状态（还没有准备好数据），它仅回复候选者等信息，不包含媒体相关信息，表示自己仅能发送数据，还没做好准备，等用户开启媒体权限后，就可以传输媒体数据了。
好处是可以提前建立连接，包括ICE，DTLS跟链路相关的协商都已经建立好了

3.SDP

3.1 webRTC的SDP结构

在这里插入图片描述

3.2 SDP规范

会话层：

包含：会话的名称与目的，会话的存活时间，会话中包括多个媒体信息

媒体层：

包含：媒体格式（音视频），传输协议（RTP，UDP等），传输IP和端口，媒体负载类型（编码类型）

SDP格式
在这里插入图片描述

SDP结构分为会话描述，时间描述和媒体描述

会话描述中的type：SDP版本，会话owner和session标识，session名称，连接信息（ip地址，端口，地址类型，网络类型等），全局的属性（用处不大）
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

时间描述中的type：存活时间，重复次数
在这里插入图片描述

媒体描述中的type：媒体名字和传输地址，连接信息，带宽信息，属性（最复杂的）
在这里插入图片描述
在这里插入图片描述

在这里插入图片描述

3.3 实际分析offer和answer的SDP

1.Offer的SDP

o中的2表示SDP的版本，每使用一次SDP，版本加1，用于区分不同的session

group：BUNDLE 0 表示有一个流进行绑定，如果有音频流，或其他流，则0后面会跟随1 2，BUNDLE表示这些流在一个连接中传输

msid表示媒体流ID，WMS是webrtc media stream缩写

SAVPF 安全，音视频，协议族

ufrag和pwd是在链路检查时，对有效性进行验证，类似用户名和密码

options的trickle，不必等候选者全部收集完再进行连通性检测，在setlocalDesc后每收到一个候选者就筛选一次

fingerprint是指DTLS证书的指纹，当进行证书交换时会验证对方证书的指纹是否一致

setup：actpass是指媒体协商过程中既可以作为服务端，也可以作为客户端，由answer来选定

mid是指媒体ID

extmap是指对于媒体的rtp头的扩展

sendrecv是指既可以发送也可以接收
在这里插入图片描述
rtcp-mux是指复用rtp端口

rsize是指回的rtcp消息能不能减少，告诉对方仅发送丢包多少，收包多少。不发送网络状况，带宽等信息

rtpmap是指对96媒体格式进行说明，rtcp-fb是指支持的rtcp反馈信息

rtpmap的rtx是指在发生丢包时，支持重传，apt是指对96的重传

fec是指冗余包，防止丢包，red时冗余丢包的策略

ssrc是指vp8,vp9,h264等的标识
在这里插入图片描述
在这里插入图片描述

是唯水啊
关注
  • 4
    点赞
  • 踩
  • 29
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
WebRTC零基础开发者教程
11-02
WebRTC零基础开发者教程，难得的入门好资料，不要错过
web前端学习（六）：WebRTC实时通信，掌握WebSocket很实用
qq_50792097的博客
08-27 4520
WebRTC (Web Real-Time Communications) 是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。......
音视频通信为什么要选择WebRTC？
garrylea的博客
09-12 1448
音视频通信为什么要选择WebRTC？ 在网上经常看到有人说：“在线教育直播是用WebRTC做的”，“音视频会议是用WebRTC做的”……；“声网、腾讯、阿里……都使用的WebRTC”。但你有没有好奇，这些一线大厂为什么都要使用WebRTC呢？换句话说，WebRTC到底好在哪里呢？ 这个问题，对于长期做音视频实时通信的老手来说是不言而喻的；但对于新手，则是急切想知道，而又很难得到答案的问题。那么本文我将采用对比法，向你详细阐述一下WebRTC到底好在哪里。 这次我们对比的指标包括：性能、易用性、可维护性、流行
WebRTC简介及实战应用 — 从0到1实现实时音视频聊天等功能
不怕麻烦的鹿丸的博客
03-07 1287
简单来说，RTCDataChannel 就是在点对点连接中建立一个双向的数据通道，从而获得文本、文件等数据的点对点传输能力。它依赖于流控制传输协议（SCTP），SCTP 是一种传输协议，类似于 TCP 和 UDP，可以直接在 IP 协议之上运行。但是，在 WebRTC 的情况下，SCTP 通过安全的 DTLS 隧道进行隧道传输，该隧道本身在 UDP 之上运行。另外总的来说 RTCDataChannel 和 WebSocket 很像，只不过 WebSocket 不是 P2P 连接，需要服务器做中转。
WebRTC零基础开发教程
11-22
C++层开发是，不是WEB开发！详细叙述了webRTC源码开发架构、API、方法
[WebRTC] WebRTC 入门教程 (英文版)
03-02
☆ 资源说明：☆ [Packt Publishing] WebRTC 入门教程 (英文版) [Packt Publishing] Getting Started with WebRTC (E-Book) ☆ 图书概要：☆ Explore WebRTC for real-time peer-to-peer communication Overview Set up video calls easily with a low bandwidth audio only option using WebRTC Extend your application using real-time text-based chat, and collaborate easily by adding real-time drag-and-drop file sharing Create your own fully working WebRTC application in minutes ☆ 出版信息：☆ [作者信息] Rob Manson [出版机构] Packt Publishing [出版日期] 2013年09月25日 [图书页数] 114页 [图书语言] 英语 [图书格式] PDF 格式
Web RTC完美入门教程(康林)
05-04
网页实时通信(Web Real-Time Communication)是一个支持网页浏览器进行实时语音对话或视频对话的技术，在国内资料很少。
FFmpeg4.3系列之16：WebRTC之小白入门与视频聊天的实战
02-27
敬告：该系列的课程在抓紧录制更新中，敬请大家关注。敬告： 该系列的课程涉及：FFmpeg,WebRTC,SRS,Nginx,Darwin,Live555,等。包括：音视频、流媒体、直播、Android、视频监控28181、等。 我将带领大家一起来学习WebRTC原理和编程知识，并动手搭建环境完成网页视频会话和文字聊天。具体内容包括： 一、Html与JavaScript小白入门二、WebRTC小白入门与流程原理分析三、网络打洞STUN和TURN四、信令服务器的原理与实战五、手撕WebRTC流程与代码六、亲自敲码踩坑搭建视频会话   音视频与流媒体是一门很复杂的技术，涉及的概念、原理、理论非常多，很多初学者不学 基础理论，而是直接做项目，往往会看到c/c++的代码时一头雾水，不知道代码到底是什么意思，这是为什么呢？ 因为没有学习音视频和流媒体的基础理论，就比如学习英语，不学习基本单词，而是天天听英语新闻，总也听不懂。所以呢，一定要认真学习基础理论，然后再学习播放器、转码器、非编、流媒体直播、视频监控、等等。 梅老师从事音视频与流媒体行业18年；曾在永新视博、中科大洋、百度、美国Harris广播事业部等公司就职，经验丰富；曾亲手主导广电直播全套项目，精通h.264/h.265/aac，曾亲自参与百度app上的网页播放器等实战产品。目前全身心自主创业，主要聚焦音视频+流媒体行业，精通音视频加密、流媒体在线转码快编等热门产品。    
FFmpeg和WebRTC
weixin_43885541的博客
08-13 4581
FFmpeg和WebRTC的区别 FFmpeg 音视频编辑 播放器（ffplay） 音视频编解码 （aac->mp3 mp3->aac） WebRTC 音视频实时通信 3A处理 网络传输质量 FFmpeg是基础，WebRTC也使用它 FFmpeg更多的用于音视频编辑与播放器 WebRTC更多的用于音视频实时通信 名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。 传输部分可基于TCP/UDP，会话
关于直播、WebRTC、FFmpeg 的那些事~~
音视频开发进阶
04-18 4265
在知识星球中有位同学咨询了关于直播、webrtc、FFmpeg的一系列问题，这些问题都是大家平时关注的问题。为了让大家在从事音视频之前能对相关概念有一个清晰的理解，此前对这些问题做了系统性的回复，这些答案也许会对你有所帮助，也算是抛砖引玉，欢迎大家一起交流。想加入星球的朋友可以通过文章末尾的二维码加入，关于星球的更多内容通过如下链接了解：一个关于音视频领域专业问答的小圈子...
WebRTC简介及使用
明天你好的博客
11-12 7838
WebRTC 只是一个媒体引擎，上面有一个 JavaScript API，所以每个人都知道如何使用它（尽管浏览器实现仍然各不相同），本文对 WebRTC（网页实时通信）的相关内容进行简要介绍。WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音通话或视频聊天的技术，是谷歌 2010 年以 6820 万美元收购 Global IP Solutions 公司而获得的一项技术。WebRTC 提供了实时音视频的核心技术。
webrtc入门与实战视频教程
06-09
webrtc入门与实战视频培训课程是通过作者多年经验总结出的一套webrtc入门教程，学完此课程，你能搭建出一套android互通或者web互通或者android对web互通的webrtc服务器，此课程由浅入深讲解了从编译到完整搭建一套webrtc demo，包括apprtc房间服务、collider信令服务、coturn穿透服务，即便你没有linux基础也能搭建，让你轻轻松松入门。
点对点视频通讯基础WebRTC视频
07-23
点对点视频,基于WebRTC开发的视频通讯。适合入门基本的学习
ffmpeg api推流，谷歌浏览器播放大华、海康威视网络摄像头rtsp视频流方案（hls、m3u8、flv、webrtc、srs、nginx、nginx-rtmp、rtmp）比较
m0_46144966的博客
04-03 2966
ffmpeg api推流，谷歌浏览器播放网络摄像头rtsp视频流方案（hls、m3u8、flv、webrtc、srs、nginx、nginx-rtmp、rtmp）比较 将网络摄像头视频流在主流浏览器中无插件播放，不必局限于ie中使用摄像头厂商自带的插件播放。 尝试了几种方案： ①nginx + nginx-rtmp-module + hls + EasyWasmPlayer.js ②srs + flv + h5 ③srs + flv + EasyWasmPlayer.js ④srs + webrtc + j
WebRTC 基础
好记性不如写博客！
06-22 5559
WEBRTC 基础知识
WebRTC简介
前端御书房
11-16 3649
WebRTC（Web Real-Time Communication）（网页实时通信）是一个谷歌开源项目，它提供了一套标准API，使Web应用可以直接提供实时音视频通信功能，不再需要借助任何插件。
流媒体分析之webrtc协议之ffmpeg 实现
u012794472的专栏
09-13 4186
音视频数据接收:libmetartc 库收到数据，通过g_ff_rtc_receiveAudio 及g_ff_rtc_receiveVideo 接口返回音视频数据。webrtc_open 函数调用yang_create_metaConnection 函数创建webrtc 服务操作接口。webrtc_read_header 调用webrtc_open 连接srs服务器。webrtc_init 函数调用webrtc_open 函数。connectSfuServer 连接srs 服务器。
webrtc基本流程与使用
mabc1234的博客
05-31 3901
WebRTC（Web Real-Time Communication）是 Google于2010以6829万美元从 Global IP Solutions 公司购买，并于2011年将其开源，旨在建立一个互联网浏览器间的实时通信的平台，让 WebRTC技术成为 H5标准之一。感兴趣的小伙伴可以看官网（）的介绍。WebRTC是一个免费的开放项目，它通过简单的API为浏览器和移动应用程序提供实时通信（RTC）功能。并不受限于传统互联网应用或浏览器的终端运行环境。
FFmpeg入门详解之90：WEBRTC讲解
福优学苑@音视频+流媒体
10-18 1887
WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音通话或视频聊天的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。WebRTC提供了实时音视频的核心技术，包括音视频的采集、编解码、网络传输、显示等功能，并且还支持跨平台：windows，linux，mac，android。
webrtc零基础开发者教程
最新发布
03-08
WebRTC（Web Real-Time Communication）是一种用于在Web浏览器之间实现实时通信的开放标准。它提供了一组API，使开发者可以在浏览器中实现音频、视频和数据的实时传输。下面是一个简单的WebRTC零基础开发者教程： 1. 学习基础知识： - 了解WebRTC的基本概念和工作原理。 - 熟悉网络通信协议，如UDP和TCP/IP。 - 掌握HTML、CSS和JavaScript等前端开发技术。 2. 设置开发环境： - 安装最新版本的浏览器，如Chrome或Firefox。 - 使用文本编辑器创建一个新的HTML文件。 3. 创建本地视频流： - 使用getUserMedia API获取用户的摄像头和麦克风权限。 - 将视频流显示在HTML页面上。 4. 建立点对点连接： - 使用RTCPeerConnection API创建一个点对点连接。 - 通过ICE（Interactive Connectivity Establishment）框架进行网络穿越和NAT遍历。 - 使用SDP（Session Description Protocol）交换会话描述信息。 5. 实现实时通信： - 使用RTCDataChannel API实现数据通信。 - 使用RTCPeerConnection API实现音频和视频通信。 6. 处理错误和异常： - 处理网络连接中断、ICE失败等错误情况。 - 使用异常处理机制来捕获和处理异常。 7. 部署和测试： - 将你的应用程序部署到一个Web服务器上。 - 在不同的浏览器和设备上进行测试，确保它们之间可以正常通信。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值