Chrome与同机进程间比HTTP/XHR更快的IPC高带宽视频传输方案问询

核心问题直接答复 #

• Chrome可以绕过常规HTTP回环传输的瓶颈，不需要走完整TCP/IP协议栈产生额外拷贝开销
• 进程#1与Chrome之间支持通过共享内存实现跨进程通信，性能完全可以覆盖2000x2000分辨率20fps的传输需求（未压缩RGB峰值带宽约229MB/s）
• 上述能力既可以通过Chrome原生开放API实现，也可以基于Chrome扩展层封装实现，进程#1用C++或Python开发都有成熟的适配接口

性能最优方案：共享内存+GPU零拷贝渲染 #

这个方案可以完全规避之前测试遇到的传输慢、putImageDataCPU占用高的问题：

1. 进程#1侧创建系统级命名共享内存段：C++可以用系统原生共享内存API（Linux下shm_open、Windows下CreateFileMapping），Python可以直接用标准库multiprocessing.shared_memory，图像处理完成后直接将RGB帧写入共享内存块，全程不需要做网络序列化、协议封装。
2. Chrome侧接入共享内存有两种可选路径：
   • 无扩展路径：通过Chrome原生File System Access API的同步访问句柄，映射本地内存映射文件，直接拿到共享内存块对应的ArrayBuffer，不需要经过网络层拷贝
   • 扩展路径：Chrome扩展申请文件系统权限后，可直接读取进程#1创建的共享内存映射文件；也可以通过Native Messaging接口传递共享内存句柄，权限管控更灵活
3. 渲染环节完全弃用putImageData：拿到共享内存中的RGB帧数据后，直接通过WebGPU将内存块映射为GPU纹理，由GPU完成最终渲染，全程几乎没有CPU侧拷贝操作，100MB/s级别的带宽负载下CPU占用通常低于5%。

兼容适配方案：本地管道传输+硬件编解码 #

如果不想做跨平台共享内存适配，可以通过以下方式把性能拉到满足需求的水平，规避旧方案的缺陷：

• 传输层弃用HTTP、TCP回环、multipart/x-mixed-replace，改用本地Unix域套接字（Linux/macOS）或命名管道（Windows）传输，协议栈开销比TCP HTTP低70%以上
• 进程#1侧不要做PNG/JPG/BMP软编码，直接调用硬件编码接口将帧压缩为H.264/VP9码流，压缩后2000x2000@20fps的实际传输带宽仅5-10MB/s，远低于带宽阈值
• Chrome侧直接通过MediaSource Extensions接口把码流喂给<video>标签，走系统硬件解码路径上屏，全程不需要JS处理原始像素数据，CPU占用极低

旧方案性能差的核心原因：一是图片编码+multipart/x-mixed-replace本身没有为高帧率流设计，编码开销、协议开销都很高；二是XHR传原始字节+putImageData的组合，每帧都要经过TCP协议栈拷贝、JS堆到渲染进程的内存拷贝、CPU到GPU的纹理拷贝，单帧2000x2000分辨率就要拷贝12MB数据，20fps下连续拷贝的CPU开销自然会占满核心。

避坑提示 #

• 不要用WebSocket传输原始帧，本质还是走TCP协议，开销和XHR没有本质区别
• 所有帧数据的接收、映射操作全部放到WebWorker中执行，不要占用主线程
• 不要在JS侧做任何像素格式转换、逐像素处理，这类操作全部放到进程#1或者GPU侧完成

内容的提问来源于stack exchange，提问作者Basj