webrtc 资源收集
webrtc 资源收集
2020-06-23 13:28:10短期爆发音视频需求背后的技术与发展趋势解读
2020-06-23 10:05:18特殊时期，音视频在短期内成为了很多人的“刚需”：在线学习、远程工作、联系亲友等众多场景下都离不开音视频技术。那么，音视频究竟是短期刚需还是未来趋势呢？3月5日采访间，为本次活动压轴专场线上公开直播，邀请到腾讯云视频通信业务总经理李郁韬、学而思网校架构师&腾讯云最具价值专家（TVP）刘连响作为嘉宾，LiveVideoStack联合创始人&主编包研作为主持人，深度剖析音视频技术发展。
文 / 李郁韬 刘连响 包研
整理 / LiveVideoStack
包研：欢迎大家来到「云加社区沙龙online」 采访间，我是LiveVideoStack主编包研，感谢云加社区的邀请，让我作为今天活动的主持人与大家互动。同时，今天我们也有幸邀请到了两位重磅嘉宾，分别是腾讯云视频通信业务总经理 李郁韬和学而思网校架构师 刘连响。
下面请两位先向观众做一个简单的自我介绍。
李郁韬：大家好，我是李郁韬，目前是腾讯云视频通信业务的负责人，很高兴能在云加社区与大家见面，这也是我人生第一次做直播，有些紧张。
刘连响：大家好，我是学而思网校架构师刘连响，目前主要负责RTC和直播相关的业务，最近几年的关注方向也主要集中在这些方面，包括推动WebRTC的大规模应用以及直播应用的探索。
包研：由于业务指数级暴增和大量的新业务对接，相信过去几周大家过的并不轻松，能否和大家分享下这段经历？
刘连响：我这边从春节到现在应该可以说是各种赶节奏，需要我们对多个项目进行同步支持，功能或者模块的开发时间被压缩的非常短，基本一到两天就要求交付。又因为是远程办公，所以处于全天工作的状态。印象比较深刻的是做小程序直播的时候，我们在晚上五六点钟立项，之后找到腾讯伙伴做小程序直播权限插件的升级、CDN的配置等工作，最后在第二天上午完成了上线，整个项目从立项到上线只花了十几个小时。
可能对于大多数国人来说，这个春节过得并不轻松，可以说是非常难忘的一个春节，李郁韬那边的情况想必也是一样。
开源流媒体服务器：为何一定得再撸个新的
2020-06-23 10:03:22作为开发者，我们需要有一个服务器来支持新视频行业的互联网化，有哪个开源方案能支持新爆发的业务？该方案需要支持哪些关键的能力或需求？本文由自阿里云RTC服务器团队负责人杨成立在LiveVideoStack线上分享的内容整理而成。
文 / 杨成立
整理 / LiveVideoStack
视频回放：
https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=7955f5f3e1c942fa9ae4314b991beb1c
大家好，我是来自阿里云的杨成立，本次分享将会和大家详细介绍开源流媒体服务器的关键技术及未来发展。
我从2009年开始从事FFmpeg流媒体相关工作，2012年开始参与流媒体服务器的开发，2013年开始做开源流媒体服务器SRS，至今也有七年多的时间了。在这短短几年间，随着视频直播的爆发，SRS也迎来了快速增长。2017年我来到阿里云之后换成了WebRTC方向。我们可以看到目前Live WebRTC在整个视频的应用非常广，包括在线办公、在线教育、在线娱乐等各个行业都大展拳脚，音视频已经成为当前互联网交流与信息传播不可或缺的媒介手段。
这次的分享内容将主要围绕SRS的诞生与历程、SRS接下来的发展计划等，带领大家深入研究SRS存在的价值与意义。
得益于我国通信基础设施的日趋完善，尤其是Wi-Fi、4G网络的下沉普及，我国互联网市场音视频产品服务在2015～2018年经历了爆发式增长。当时消费者普遍拥有的可以观看视频的带宽大约为1M，网络环境较为稳定。
直播背后的技术早在功能机时代就落地成熟。例如2010～2012年，消费者主要通过PC上的Flash来观看网络直播视频，因为Flash可以跨主流PC端浏览器。而移动端尽管也支持Flash，但效果很不好。移动端如Android或iOS则主要支持HLS，早期Android对HLS的支持效果并不佳，后面有明显改善。
webrtc笔记(3): 多人视频通讯常用架构Mesh/MCU/SFU
2020-06-23 09:25:40问题：为什么要搞这么多架构？
webrtc虽然是一项主要使用p2p的实时通讯技术，本应该是无中心化节点的，但是在一些大型多人通讯场景，如果都使用端对端直连，端上会遇到很带宽和性能的问题，所以就有了下图的三种架构。
WebRTC 媒体服务器中使用单端口
2020-06-23 08:42:46目前为止已经有几个减少端口使用的策略:
- rtp/rtcp复用端口的方案rtcp-mux.
- 音视频的boundle, 可以让音视频复用连接通道.
- 包括后面出现的多路流复用单peerconnection的plan b和unified plan方案, 最新的webrtc标准都已经转向了unified plan.
这些策略都在不断的在消减端口的使用, 但即使上面的这些策略全部开启, 单个用户还是要占用最少一个端口, 如果一个WebRTC服务器要服务1000个用户, 就要开启1000个端口.
WebRTC网关服务器单端口方案实现
2020-06-22 14:50:21标准WebRTC连接建立流程
这里描述的是Trickle ICE过程，并且省略了通话发起与接受的信令部分。流程如下：
1） WebRTC A通过Signal Server转发SDP OFFER到WebRTC B。WebRTC B做完本地处理以后，通过 Signal Server转发SDP ANSWER到A。
2）A、B同时向STUN Server发送Binding request请求自身的外网地址，并从STUN Server回包的MAPPED-ADDRESS中得到各自的外网地址；
3）A、B收集完内外网ICE Candidate，并通过Signal Server发送给对方；
4）双方开始做NAT穿越，互相给对方的ICE Candidate发送STUN Binding Request；
5）NAT穿越成功，A、B之间的P2P连接建立，进入媒体互通阶段。在这个过程中，我们看到了有三个核心的部分，SDP协商、ICE Candidate交换、Stun Binding Req/Res的连通性检查。
WebRTC 开发实践：如何实现 SFU 服务器
2020-06-22 14:08:081 什么是 SFU ？
首先，我们再看一次 SFU 服务器的定义，什么是 SFU ？
SFU 的全称是：Selective Forwarding Unit，是一种路由和转发 WebRTC 客户端音视频数据流的服务端程序。
webrtc sfu实现原理
2020-06-22 14:07:19High-performance WebRTC SFU
基于WebRTC的SFU多人音视频通话（服务端+客户端）
--------------------------------------------------------------------------------
SFU(Selective Forwarding Unit)，如果不太了解自行谷歌。
SFU服务器起到了router的作用，已占用较小的cpu和内存实现更为灵活的多方通话，这个特
性有别于MCU。
本系统包含基于WebRTC开发的SFU服务器，以及windows端基于webrtc实现的客户端；
使用方法
--------------------------------------------------------------------------------
1、启动SFU服务器(Server.exe)，默认端口是6666。不建议修改端口，客户端不支持设置端口。
记住SFU服务器的IP地址，如：192.168.1.101。
2、分别在不同的机器上启动客户端Client.exe。然后点击加入频道，输入服务器IP地址，以及
房间号（房间号可以自己随意填写），房间号相同的人会进入相同的房间；同理，房间号不
同的人会进入不同的房间。
特性
--------------------------------------------------------------------------------
1、多个会议室、多人参与。
2、用到的协议ICE / DTLS / RTP / RTCP等协议。
3、支持IPv6。
4、高效率 (使用c++编码，考虑到内存和性能)。
5、支持录制，或者加载媒体文件分享给伙伴（未完成）
WebRTC网关服务器搭建：开源技术 vs 自行研发
2020-06-22 09:12:00大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：
● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？
● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。
● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。
● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。
为什么需要WebRTC网关
在WebRTC 1.0标准还没有定稿之前，这个标准只具备雏形，在很多方面都有缺陷。而随着1.0标准的定稿，WebRTC逐渐完善，到现在已经可以在网页端使用，换句话说，已经有基于WebRTC的实际应用。下面主要结合不同的应用场景来说明为什么需要WebRTC网关。
即构自研WebRTC网关服务器架构实践
2020-06-22 09:06:03Zego-Gateway架构的改进
在加入WebRTC网关之前，即构自研系统架构如下图所示，主要分成两部分，左边是低延时用户，而右边是围观用户。低延时用户主要是通过ZEGO的实时传输网络进行推拉流。
