文章目录

• 前言
• 一、P2S
• 二、相关工具
• • 1.浏览器
  • 2.流媒体服务器
  • 3. 浏览器测试地址
  • 4.虚拟摄像头
  • 5. 一些小坑
  • • 1）webrtc需要https才可以通过IP或域名访问
    • 2）流媒体服务器的选型
    • 3）如何分解推送和拉取步骤
    • 4）如何理解信令服务器
• 总结

---

前言

本系列文章主要记录实践过程的问题和解决办法，非教学。仅经验分享，不足之处勿怪。参考webrtc概念及常规思路，常规的webrtc及现在互联网可检索到的均使用的是点对点的方式，这种方式的优点很明显，不需要大量资源的流媒体服务器，但是缺点更加明显，在多人通话时逻辑会异常复杂，所带来的带宽和资源开销会随着人数的增加呈指数级增加.下图展示常规点对点流交换

在这种情况下，采用混流或者流媒体服务器用来集中处理就成为解决这个问题的必须途径。

---

一、P2S

本地推流到流媒体服务器，其它用户到流媒体服务器拉流，服务器要承担的则仅仅是上下行带宽。但是存在的缺点也很明显，随着并发数的增加，需要的带宽会逐渐加大，此时需要一定策略结局这个问题

二、相关工具

1.浏览器

此处还是强推谷歌浏览器内核的浏览器，此处有两个原因，一个是其它浏览器的兼容性问题，二是作者需要使用electron进行客户端构建。

2.流媒体服务器

可以自选用，但是作者使用的是开源的m7s，强的雅痞。
天然支持webrtc，而且可以转换吐出多种协议视频流

3. 浏览器测试地址

测试地址

4.虚拟摄像头

虚拟摄像头

5. 一些小坑

1）webrtc需要https才可以通过IP或域名访问

2）流媒体服务器的选型

3）如何分解推送和拉取步骤

4）如何理解信令服务器

总结

以上的小坑会在后续文章逐渐分解。尽量减少篇幅，方便读者快速理解

---

推荐一个作者开发的即使通讯，内含1对1对多的交互流程，求个star 信使

标签：流媒体,浏览器,实践,带宽,服务器,思路,webrtc,小坑
来源： https://blog.csdn.net/kill5921/article/details/123072712