【摄像头】虚拟摄像头

可以做成统一产品；Linux 用 v4l2loopback 写入帧完全能覆盖同样能力。 Electron 负责控制面与媒体管线，虚拟摄像头本身必须是平台原生实现。

核心结论

能力	Windows	Linux
虚拟摄像头出现在系统设备列表	DirectShow / MF 虚拟源	v4l2loopback → `/dev/videoN`
多路虚拟摄像头	多实例滤镜 / 多设备	多路 loopback 设备
自定义流（MP4 / RTSP）	Electron 解码后推帧	同左
会议软件直接选用	Zoom / Teams / 浏览器等选设备	同左（走 V4L2）
程序内 API	统一抽象层	同左

对用户来说：装 Windows 包或 Linux 包，界面和接口一致；底层分别走 DirectShow（或 MF）与 v4l2loopback。

关键架构（推荐）

复制代码

┌─────────────────────────────────────────┐
│  Electron（跨平台）                      │
│  · UI：导入 MP4 / 填 RTSP / 管理多路摄像头 │
│  · 解码：FFmpeg / GStreamer              │
│  · 帧调度：分辨率、帧率、多路             │
│  · 本地 API：HTTP / gRPC / Named Pipe    │
└───────────────┬─────────────────────────┘
                │ IPC / Shared Memory（YUV/RGB）
        ┌───────┴────────┐
        ▼                ▼
┌───────────────┐  ┌──────────────────┐
│ Windows 后端   │  │ Linux 后端        │
│ DirectShow 滤镜│  │ v4l2loopback      │
│ （或 MF 虚拟源）│  │ write(/dev/video) │
└───────────────┘  └──────────────────┘

Electron 不能直接当 DirectShow 滤镜。 常见做法是：Electron + 原生插件/子进程推帧；Windows 侧注册虚拟摄像头 DLL；Linux 侧写 /dev/videoX。

统一抽象（对用户/集成方一致）

对外只暴露一套概念，例如：

createCamera({ name, width, height, fps })
setSource(cameraId, { type: 'mp4'|'rtsp'|'raw', url })
listCameras() / start / stop / destroy
可选：pushFrame(cameraId, buffer)（给会议产品在进程内灌帧）

底层：

Windows ：ICameraBackend → SharedMemory → DirectShow 源滤镜
Linux ：同一接口 → open('/dev/videoN') + VIDIOC_S_FMT + write()

多路虚拟摄像头

Linux ：modprobe v4l2loopback devices=8 video_nr=10,11,...，每路一个设备节点。
Windows：每个虚拟摄像头一个滤镜实例（或一个 DLL 多 pin/多设备），需处理好 COM 注册与设备枚举名。

兼容性注意点

Windows 生态：DirectShow 仍被大量会议软件识别；新应用更偏 Media Foundation / Frame Server。长期建议 DirectShow 优先，必要时再补 MF。
Linux ：依赖内核模块 v4l2loopback（安装时需 root / dkms）；部分沙箱/容器环境不可用。
格式：统一内部用 NV12 / YUY2，再按平台转换，减少花屏。
权限与安装 ：Windows 滤镜要注册（常需管理员）；Linux 要装 loopback 并把用户加入 video 组。
"程序里直接获取"：会议产品若只选系统摄像头，走虚拟设备即可；若要进程内集成，再提供本地 API / SDK，两者可并存。

和"纯 Electron"的边界

能跨平台统一的：UI、配置、MP4/RTSP 拉流、多路管理、HTTP/SDK API。
必须分平台的：虚拟设备驱动/滤镜、安装脚本、写帧路径。

所以产品形态应是：一个 Electron 壳 + 两套原生 Camera Backend，而不是"Electron 自己变成摄像头"。

简要建议

这种设计合理，也是 OBS Virtual Camera、许多推流工具的同类思路。若目标是会议软件即插即用 + 可编程控制，按上面分层做即可；先做 Windows DirectShow + Linux v4l2loopback 两条后端，API 对齐，体验就能做到"两种环境安装，用户侧一样"。

如果你下一步要落地，我可以按这个架构帮你拆一版最小可行目录结构（Electron 主进程、FFmpeg 推帧、Windows/Linux backend 接口定义）。