组件
该存储库由 3 个独立的组件组成
MembraneRTC- 与Membrane RTC Engine完全兼容的 Membrane WebRTC 客户端，负责交换媒体事件和接收媒体流，这些流随后展示给用户MembraneVideoroomDemo- 使用MembraneRTC客户端的演示应用程序ScreenBroadcastExt- 提供屏幕录制功能给演示应用程序的Broadcast Upload Extension实例
MembraneRTC
客户端的主要目标是尽可能接近 web 版本。就像 web 客户端一样，本机移动客户端非常原始。它尽可能低级，不透露任何 WebRTC 的细节。跟踪房间中所有对等方及其相应轨道是用户的责任。客户端的责任只是通知用户有关与后端服务器之间底层会话的所有更改。
用户需要做的就是提供客户端连接所需的配置，创建本地轨道（音频、视频或屏幕录制），启动客户端并通过 MembraneRTCDelegate 协议监听任何更改。
MembraneVideoroomDemo
是一个非常简单的应用程序，允许测试所有 Membrane RTC Engine 功能。它由 2 个屏幕组成
- 加入屏幕，用户输入房间名称和他的显示名称，然后点击加入按钮
- 房间屏幕，包括一系列控制按钮和一个显示参与者视频的区域
用户以下控制按钮：
- 麦克风静音/取消静音切换
- 摄像头视频静音/取消静音切换
- 离开呼叫按钮
- 前后摄像头切换
- 屏幕录制按钮，显示一个列表，其中
ScreencastBroadcastExt可以用于录制整个设备屏幕
此外，用户可以点击任何可见的视频方块来将它们聚焦为主视频
ScreenBroadcastExt
在 iOS 中，即使应用程序进入后台模式，也不容易共享整个设备的屏幕。为了使其发生，我们必须使用一个名为 Broadcast Upload Extension 的扩展。该扩展负责捕获正在录制的屏幕的视频缓冲区，并在本地执行任意操作，将其发送到其他地方。
在我们的情况下，我们需要启动上传扩展的一个实例，并将创建的视频缓冲区返回给应用程序。不幸的是，扩展是以单独的进程启动的，这迫使我们使用某些进程间通信机制。在我们的情况下，我们使用 CFMessagePort，这是本地机器上线程/进程之间传输任意数据的核心基础机制。
为了执行缓冲区交换，我们需要运行 2 个这样的端口实例
- 本地（服务器模式）
- 远程（客户端模式）
一个进程（服务器）需要创建一个它将监听的端口。另一个进程（客户端）需要创建一个用于写入的远程端口，该端口将指向服务器端口。一旦建立连接，客户端需要使用《Proto Buffers》机制（代码位于《MembraneRTC/Sources/MembraneRTC/IPC》）序列化缓冲区。然后服务器可以捕获并反序列化数据包，这些数据包将转发到《Membrane RTC Engine》以实现全屏共享体验。
重要 扩展程序和应用必须共享相同的App Group，以便正确创建CFMessagePort。
文档
API文档可在此处找到：这里。
必要设置
为了使应用正常工作，必须在《MembraneVideoroomDemo/Utilities/Constants.swift》内设置必要的常量。
一个重要的变量是远程服务器地址 rtcEngineUrl，用户将连接到该地址。
两个变量与屏幕直播功能相关
appGroup- 需要与应用和断言扩展共享的应用组标识符screencastExtensionBundleId- 《ScreenBroadcastExt》的包标识符
注意 《Constants.swift》中使用的 appGroup 必须在《ScreenBroadcastExt/SampleHandler.swift》文件中进行复制。
安装
Cocoapods
将其添加到您应用的Podfile中
pod 'MembraneRTC'
在您的ScreenBroadcast扩展目标中
target 'ScreenBroadcast' do
pod 'MembraneRTC/Broadcast'
end
开发
- 在主目录中运行
./scripts/init.sh以安装swift-format和release-it以及设置git钩子 - 编辑
Debug.xcconfig以在开发中设置后端URL。 - 运行
release-it以发布。按照提示操作，它应该更新podspec中的版本，创建提交和标签，并将新版本推送到Cocoa Pods。
鸣谢
此项目的灵感主要来自LiveKit项目以及他们实现的iOS SDK，项目大量重用了他们的解决方案（主要处理WebRTC SDK，而信令则完全替换为内部解决方案）。
此项目的开发和维护得到了dscout和Software Mansion的支持。
