WebRTC开发者社区为开发者提供最新最全的WebRTC资料
目录
  • 首页
  • WebRTC概念与基础
  • WebRTC项目与应用
  • WebRTC教程资料
  • WebRTC开发资源
  • WebRTC源码分析
  • WebRTC服务端开发
  • WebRTC网络与通信
  • WebRTC编码与解码
  • WebRTC问题与缺陷
  • WebRTC-Androd端开发
  • WebRTC-RFC文档

Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API

2020-07-30 10:15:15

There’s new functionality with the new API and the Unified Plan SDP format:

  • Early media: after an offer is sent, the calling side can receive media before receiving the answer
  • Support for multiple or no media streams for a given track
  • With sender objects you can control media with sender.setParameters()
  • With transceiver objects, you can more directly control certain aspects of SDP generation.

More...

WebRTC源码分析rfc4588 RTP重传有效载荷格式

2020-07-30 08:22:09

RTP重传是一种有效的丢包恢复技术,适用于具有宽松延迟界限的实时应用。该文档描述了用于
执行重传的RTP有效载荷格式。重传的RTP分组在与原始RTP流分开的流中发送。假设从接收器
到发送器的反馈是可用的。特别是,本备忘录中假设提供了实时传输控制协议(RTCP)反馈,
该RTCP反馈在基于RTCP的反馈(表示为RTP/AVPF)的扩展RTP配置文件中定义。

More...

WebRTC网关服务器搭建:开源技术 vs 自行研发

2020-07-27 12:44:27

作为实时音视频领域最火的开源技术,WebRTC 点对点的架构模式,无法支持大规模并发。如何在架构中引入服务端,一直是开发者关注的热点。5月20日,即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享,以下是对他演讲内容的整理。

 

大家好,我是黄开宁,来自即构科技,从事音视频开发已经超过10年了,虽然如此,在技术迅速更新迭代的时代,我们还是需要时刻保持学习的状态。今天,我主要跟大家介绍以下四个方面的内容:

● 为什么需要WebRTC网关?对于即构来说,目前所使用的系统已经较为成熟且经过了市场的检验,为什么还要在如此成熟的商用系统中加入WebRTC?

● WebRTC通信模型的对比,分析不同的模型对应的适用场景,以便大家在选型时能结合自己的需求匹配对应的场景。

● 开源VS自研,主要介绍市面上的开源系统及其特点,另外还会分析即构自行研发系统的目的和出发点。

● Zego-Gateway架构的实践,分享即构在开发过程中遇到的一些难题和解决方法。

为什么需要WebRTC网关

More...

WebRTC网关服务器搭建:开源技术 vs 自行研发

2020-07-27 12:44:16

作为实时音视频领域最火的开源技术,WebRTC 点对点的架构模式,无法支持大规模并发。如何在架构中引入服务端,一直是开发者关注的热点。5月20日,即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享,以下是对他演讲内容的整理。

 

大家好,我是黄开宁,来自即构科技,从事音视频开发已经超过10年了,虽然如此,在技术迅速更新迭代的时代,我们还是需要时刻保持学习的状态。今天,我主要跟大家介绍以下四个方面的内容:

● 为什么需要WebRTC网关?对于即构来说,目前所使用的系统已经较为成熟且经过了市场的检验,为什么还要在如此成熟的商用系统中加入WebRTC?

● WebRTC通信模型的对比,分析不同的模型对应的适用场景,以便大家在选型时能结合自己的需求匹配对应的场景。

● 开源VS自研,主要介绍市面上的开源系统及其特点,另外还会分析即构自行研发系统的目的和出发点。

● Zego-Gateway架构的实践,分享即构在开发过程中遇到的一些难题和解决方法。

为什么需要WebRTC网关

More...

自研WebRTC网关服务器架构的实践之路

2020-07-27 12:43:22

我们对他的演讲内容做了整理,整理后的文章分为上下两篇,本文为第二篇,欢迎阅读。

前面我给大家分享了:

第一,为什么需要WebRTC网关。对于即构来说,目前所使用的系统已经较为成熟,也经过了市场的检验,为什么还要在如此成熟的商用系统中加入WebRTC?

第二,WebRTC通信模型对比。分析了目前的WebRTC通信模型以及不同模型的适用场景,以便大家在选型时能结合自己的需求匹配对应的场景。

第三,开源VS自研。分享了目前市面上的一些开源系统及其特点以及即构自研WebRTC网关的目的和出发点。

下面,我将结合即构自研的WebRTC网关服务器方案,分享在开发过程中遇到的难点和解决办法。

More...

WEBRTC三种类型(Mesh、MCU 和 SFU)的多方通信架构  

2020-07-22 11:50:50
WebRTC 本身提供的是 1 对 1 的通信模型,在 STUN/TURN 的辅助下,如果能实现 NAT 穿越,那么两个浏览器是可以直接进行媒体数据交换的;如果不能实现 NAT 穿越,那么只能通过 TURN 服务器进行数据转发的方式实现通信。目前来看,Google 开源的用于学习和研究的项目基本都是基于 STUN/TURN 的 1 对 1 通信。
 
如果你想要通过 WebRTC 实现多对多通信,该如何做呢?
其实,基于 WebRTC 的多对多实时通信的开源项目也有很多,综合来看,多方通信架构无外乎以下三种方案。
 
  • Mesh 方案,即多个终端之间两两进行连接,形成一个网状结构。比如 A、B、C 三个终端进行多对多通信,当 A 想要共享媒体(比如音频、视频)时,它需要分别向 B 和 C 发送数据。同样的道理,B 想要共享媒体,就需要分别向 A、C 发送数据,依次类推。这种方案对各终端的带宽要求比较高。
  • MCU(Multipoint Conferencing Unit)方案,该方案由一个服务器和多个终端组成一个星形结构。各终端将自己要共享的音视频流发送给服务器,服务器端会将在同一个房间中的所有终端的音视频流进行混合,最终生成一个混合后的音视频流再发给各个终端,这样各终端就可以看到 / 听到其他终端的音视频了。实际上服务器端就是一个音视频混合器,这种方案服务器的压力会非常大。
  • SFU(Selective Forwarding Unit)方案,该方案也是由一个服务器和多个终端组成,但与 MCU 不同的是,SFU 不对音视频进行混流,收到某个终端共享的音视频流后,就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。

More...

janus的videoroom插件

2020-07-21 01:13:45

在Janus的众多插件中,大家最感兴趣的恐怕就是VideoRoom插件了。因为它实现的是一个音视频会议的场景,这正是大多数同学所需要的。而且在Janus众多的插件中VideoRoom应该也是最复杂的一个,如果你们撑握了它,再去看其它插件的实现就容易多了。

在VideoRoom中,包括了很多API,这些API是我们打开VideoRoom的一把钥匙,所以本文的重点就是讲解这些API。我相信当你把这些API都撑握之后,再去看VideoRoom插件的代码时就会更加游刃有余了。

VideoRoom插件

VideoRoom是Janus的一个插件,实现了一个SFU(Selective Forwarding Unit)型的音视频会议。如果你从数据转发的角度看,也可以把它认为是一个音视频路由器。

VideoRoom实现的音视频会议是基于发布/订阅模式。每个参与方都可以发布自己的实时音视频流,因此它可以实现几种不同的场景,比如泛娱乐化直播或多人的实时互动产品(如音视频会议、在线教育小班课等)。

考虑到此插件允许一个参与方可以打开多个WebRTC PeerConnection(如每个参与方可以有1个用于推流的PeerConnection和N个拉流的PeerConnection),所以每个参与方需要为订阅不同的流attach到VideoRoom插件几次(每attach一次就会生成一个Handle,每个Handle就是一个上下文)。

因此,对于每个参与方至少要有一个Handle用于管理与插件的关系(如加入一个房间,离开一个房间,静音/取消静音,发布,接收事件)。

每当参与方需要订阅另一个参与方发布的音视频流时,它需要创建一个新的Handle。新创建的Handle在逻辑上属于“从”Handle,它不能像“主”Handle一样可以做取消房间静音这样的操作。因此,从Handle唯一目的是提供一个上下文,在该上下文中创建一个recvonly类型的PeerConnection来订阅发布者的音视频流。

通过上面的描述我们可以知道,主Handle用于管理,而从Handle用于订阅音视频流。

More...

WebRTC+libwebsockets+Janus的秒开实践

2020-07-21 01:08:29

客户端SDK集成了WebRTC和libwebsockets,服务端使用了Janus,需要支持拉流秒开。

关于WebSocket
      Janus作为SFU,使用WebSocket协议与客户端通信。客户端在挑选开源库时其实没有太多选择,C层主要是libwebsockets库,这个也是Janus使用的库,还有Boost的Beast库,不过比较新,不敢踩坑,IOS上有RocketSocket,但不是跨平台,因此最后采用了libwebsockets库。
      libwebsockets库主要的问题是IO接口不太友好,需要自己启动一个线程轮询获取IO事件,在其回调中处理所有事件。

秒开要考虑的问题
libwebsockets IO的优化
      主要是写数据的处理。
      libwebsockets需要调用者自己维护发送队列,调用者调用lws_callback_on_writable来告知libwebsockets有数据要写,然后数据放入发送队列,libwebsockets会通过LWS_CALLBACK_CLIENT_WRITEABLE事件通知可写,这个时候调用者才可以从发送队列取出数据发送,这个是一个异步的过程。
      在libwebsockets的IO事件循环中,lws_service用于阻塞等待IO事件,但是lws_callback_on_writable并不会让lws_service退出阻塞状态,lws_service有一个最大等待时间,如果等待lws_service超时才处理待发送的数据无疑会增加整体接续时间。这里可以通过在调用线程中调用lws_cancel_service方法强制lws_service退出阻塞来立刻处理发送队列中的数据。这里需要用互斥锁对发送队列做一个同步。

More...

Janus源码分析(7)——videoroom分析

2020-07-21 01:02:50

1. 运行效果
https://janus.conf.meetecho.com/videoroomtest.html?simulcast=true

包含:Simulcast功能

视频高等质量(分辨率:1280*720,带宽1.5M+)
视频中等质量(分辨率:640*360,带宽500K左右)
视频低等质量(分辨率:320*180,带宽150K左右)

More...

Janus源码分析(5)——echotest分析

2020-07-21 01:01:46

1、运行效果图
Echo测试演示的是发送给服务器网关的音频和视频,服务器会回传给你,效果如下图所示:


2、代码分析
2.1 代码结构


2.2 源码分析
2.2.1 创建线程
在janus = new Janus()时,调用Janus(gatewayCallbacks)在其中有函数createSession,并且传入下面的回调函数:


createSession创建请求,成功建立一次httpAPICall,输出Created handle: 1747107217737787

More...

last
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
next
  • 分类目录

    • WebRTC概念与基础 (225)
    • WebRTC项目与应用 (33)
    • WebRTC教程资料 (38)
    • WebRTC开发资源 (13)
    • WebRTC源码分析 (12)
    • WebRTC服务端开发 (23)
    • WebRTC网络与通信 (26)
    • WebRTC编码与解码 (15)
    • WebRTC问题与缺陷 (2)
    • WebRTC-Androd端开发 (2)
    • WebRTC-RFC文档 (1)
  • 最新文章

    • 音视频相关的书籍,多媒体技术
    • SFU级联解决方案——Jitsi
    • SFU级联解决方案——Licode
    • Janus源码分析(6)——Streaming分析
    • janus Streaming插件推流指南
    • 流媒体服务器 
    • WebRTC+libwebsockets+Janus的秒开实践
    • 基于WebRTC的直播CDN
    • 不需要SFU实现WebRTC联播实践  
    • webrtc 开启Simulcast功能
    • Migrating your native/mobile application to Unified Plan/WebRTC 1.0 API
    • WebRTC源码分析rfc4588 RTP重传有效载荷格式
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • WebRTC网关服务器搭建:开源技术 vs 自行研发
    • 自研WebRTC网关服务器架构的实践之路
    • WEBRTC三种类型(Mesh、MCU 和 SFU)的多方通信架构  
    • janus的videoroom插件
    • WebRTC+libwebsockets+Janus的秒开实践
    • Janus源码分析(7)——videoroom分析
    • Janus源码分析(5)——echotest分析
    • Janus源码分析(4)——信令交互过程
    • WebRTC+libwebsockets+Janus的秒开实践
    • 前向纠错码(FEC)的RTP荷载格式
    • WebRTC 开发实践:从一对一通话到多人会议
    • Distord如何使用WebRTC处理250万用户同时进行的音频交流
    • 了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
    • 基于WebRTC技术的多人音视频解决方案
    • 谁是最好的WebRTC SFU?
    • WebRTC媒体服务器
    • 使用Janus作为对讲服务器的后台框架和业务流程
  • 链接

    • WebRTC官网
    • xSky 实验室
    • 树莓派技术圈
    • 声网 Agora
    • WebRTC中文网
    • web性能权威指南
    • WebRTC官网
    • webrtc在线源码
    • webrtc在线源码
    • webrtc
    • webrtc示例
    • LiveVideoStack
    • 雷霄骅(leixiaohua1020)的专栏
  • 开源项目


Powered By xblog Copyright 0xsky.com All Rights Reserved.

Copyright WebRTC.ren All Rights Reserved.