录屏调研electron录制主屏幕画面（桌面流+混合音频流（系统音频+麦克风）），并每8s切割一次，生成ts片段，最后将

需求： 启用AI会记录制时，录制主屏幕画面（桌面流+混合音频流（系统音频+麦克风）），并每8s切割一次，生成ts片段，最后将ts通过http传递给后台。但是为了方便后期扩展，实现的时候将按照支持指定屏幕/窗口画面的方案进行分析。

分析用以下的方式怎么实现以及有哪些优缺点：

一、Web网页端

窗口选择受限：只能让用户手动选择窗口，无法自动指定或记忆上次选择。
后台录制限制：Chrome 等浏览器在标签页最小化时会自动暂停媒体流（节省资源），导致录制中断；Firefox 允许后台录制但可能触发帧率降低。
性能瓶颈：依赖浏览器内置的 MediaRecorder，高分辨率（如 4K）或高帧率（60fps）录制时，因 JS 主线程资源抢占易出现卡顿，且仅支持 WebM 容器格式，转码 TS 需额外开销。
收集视频流：
1. 通过 navigator 获取桌面窗口列表
2. 通过 getUserMedia 获取桌面流（含系统音频）
3. 通过 getUserMedia 获取麦克风流
4. 将两个流的音轨合并到一个 MediaStream
5. 用 MediaRecorder 录制合成后的流

收集视频流：（Windows/ macOS 共性）
1. 主进程使用 electron.remote.desktopCapturer 获取桌面窗口列表（包含窗口 ID 和屏幕信息）
2. 在主进程用 child_process 调用 FFmpeg查看可用的屏幕和音频设备，命令如下：
3. ffmpeg -f avfoundation -list_devices true -i ""
5. 在主进程使用FFmpeg采集桌面视频流 + 音频，通过指定屏幕和音频设备来采集视频流
  1. "1:2" 表示采集屏幕1和音频输入设备2（如聚合设备/BlackHole）。

macOS 特性:

macOS比较特殊的一点是：音频输入设备要选“聚合设备”或 Loopback 虚拟设备，否则系统音频采集不到，只能采集到麦克风音频
1. 信息来源支撑：
2. - BlackHole 官网
  - Loopback 官网
但是Web/Electron/JS层受能力限制无法创建并切换虚拟音频设备，需要通过底层的c++能力才能实现
1. Web/Electron/JS 层的限制：
2. 只能通过标准 Web API（如 getUserMedia）访问已存在的音频设备，无法创建或管理设备。
3. 不能切换系统默认输入/输出设备，只能选择已有设备。
4. 没有权限访问操作系统底层音频服务。
生成 ts 片段
1. 用 MediaRecorder 录制 webm Blob，每8秒一段
2. 避免前端转吗，在主进程调用本地 FFmpeg 进行转码（而非 ffmpeg.wasm）将 webm Blob 转码为 ts
  1. （优势：利用本地 FFmpeg 的硬件加速（如 Intel QSV/NVIDIA NVENC），转码效率比 wasm 高 5-10 倍，避免 JS 线程阻塞。需询问是否侵权）
3. 将 ts Blob 传到后台

另外起一个服务进程，专门用于视频采集，将音频采集和视频采集隔离开，并需要传屏sdk提供以下接口：

以下是3种方案的优劣对比：

方案	推荐度	优势	劣势
Web网页端	不推荐	1. 门槛低2. 浏览器自带权限弹窗，安全性高	1. 窗口选择受限：只能让用户手动选择窗口，无法自动指定或记忆上次选择。2. 无法后台录制：用户切换窗口或最小化时，录制可能中断或黑屏（部分浏览器）。3. 性能受限：长时间、高分辨率录制易卡顿或丢帧。
Electron端	中	1. 可用 desktopCapturer 获取所有窗口，用户可选择窗口。2. 可后台录制，支持长时间录制。3. 可在渲染进程采集ts片段直接通过socket传递给后台，无需进程间通信损耗4.不同平台使用同套api，更易维护	1. macOS无法采集到系统音频2. 主进程FFmpeg转码，需询问是否侵权
传屏 SDK	高	1. 更高性能2. 更强的窗口指定/自动化能力3.更丰富的底层能力（如采集到macOS系统音频+麦克风混合音频流、硬件加速等）	1. 依赖传屏SDK 团队支持2. 服务进程若有异常崩溃情况，较难排查

视频数据传递：

A. 由采集方写入到本地某个文件，然后前端读取文件内容再传送给后台

B. 由采集方上传到云文件，前端获取下载地址传送给后台