WebRTC标准与框架解读(1)

news2024/11/25 4:49:15

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增加一些接口即可。