标签：流媒体 浏览器 实践 带宽 服务器 思路 webrtc 小坑
文章目录
前言
本系列文章主要记录实践过程的问题和解决办法，非教学。仅经验分享，不足之处勿怪。参考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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。