妇幼医院网站建设方案seo培训优化课程
1、如果让我来设计webrtc框架
我在分析源码的时候，都喜欢做这样一件事情：如果让我来设计它，我会怎么做？大家可以紧跟我的思路，分析一下WebRTC为什么如此设计。
为了对整个框架有有一个全面的了解，我们首先要做的事情是拆解模块。如下图所以，这里我们根据数据流动，将WebRTC拆解成多个模块，这里有些模块相对比较复杂，我们做了简化。整体的框架如下图所示：
WebRTC标准与框架
大家也许已经发现，我针对一些模块，圈出了一些更大的模块，毕竟，相比零碎的模块，我们喜欢简单。因此，对于一条流来说，它的整个流程便简化为：
简化后的框架
这里简单地对概念做一些解释：
track，用于处理原始媒体流。对于本地的track来说，它的作用是接收采集的视频帧完成处理和编码，得到编码后的数据；对于远端的track来说，接收编码的视频流完成解码处理，送去渲染。
rtpsender，接收编码后的数据，完成打包和一些冗余策略等。rtpsender和本地的track是一一对应的。
transport， ICE相关，完成传输通道的管理。
rtpreceiver，接收网络报文，输出编码数据用于后续解码。rtpreceiver和远端的track是一一对应的。
在这里track的作用是处理原始的媒体流，rtpsender和rtpreceiver可以完成对媒体打包做一些控制，transport是对传输通道的控制。有了这样的抽象，我们的pipeline就会更加清晰。
这里我在track基础上圈出了mediastream的概念，这个是WebRTC的老接口使用的概念，现在都是推荐使用track来操作。对于MediaStream的理解大家可以看下标准，一般来说，对于普通的音视频通话，一个MediaStream包含一路音频track和视频track，其实拿1v1的通话来说大家可能更容易理解为什么要把他们绑定到一起了。一般同属于一个MediaStream的流是需要做音视频同步的。
https://www.w3.org/TR/mediacapture-streams/www.w3.org/TR/mediacapture-streams/
2、ORTC的设计
哈！如果你了解下ORTC的设计思想，你就会发现，还有一群更聪明的人早就想到如此设计整个RTC了！
ORTC（Object API for RTC）的设计思想：
ORTC标准
可以看到，ORTC中，也是抽象成了Track、RtpSender、RtpReceiver、Transport几个概念。ORTC设计的是一套面向对象的接口，外部通过和RtpSender、RtpReceiver、Transport交互，来达到对RTC的控制目的。ORTC标准的出现，也规范了WebRTC的代码框架。
3、WebRTC PeerConnection（PC）接口
WebRTC对内部的各个模块都有经过封装，比较推荐的是使用PeerConnectionn接口来对外交互，我们上面的设计还是很贴近PC了，大家可以多看看这个标准：
https://w3c.github.io/webrtc-pc/w3c.github.io/webrtc-pc/
目前的WebRTC标准里面pc接口为了兼容planB和unified plan，接口相对比较复杂，如果我造轮子，肯定会甩掉历史包袱，只保留一套接口了。unified plan支持对每一个track配置，相对更灵活。因此，我们围绕track、rtpsender、rtpreceiver、transport增加一些接口即可。
AddTrack：用于增加本地的track，输入为视频源接口，可以是内部采集，也可以是外部采集（我们可以自己实现采集功能）。远端的track是协商之后由信令触发。
SetLocalDescription ：设置本地SDP能力
SetRemoteDescription： 设置远端SDP能力
CreateOffer：添加好track，设置好本地能力后，便可以向接收端发起协商。
CreateAnswer：接收端响应offer，协商完成后会创建一个rtpreceiver用于接收媒体报文，并且会对应床架一个远端track，用于解码和显示。
以上接口接口可以保证整个流程能够运行起来：
peerconnection流程
实际上这里还缺失了ICE协商相关的接口，这里没有做详细介绍了。
原文https://zhuanlan.zhihu.com/p/484971820
★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。
见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓