文章讲述了团队在开发Helix AI平台时，为满足企业网络限制（仅支持HTTP/HTTPS端口443），放弃精心构建的高性能视频流方案，转而采用15年前的简单技术grim | curl实现屏幕共享，意外发现其稳定性和兼容性更优。这揭示了新技术并非总是最佳选择，有时传统方案反而更可靠。

标题：我们大规模部署了15年前的屏幕共享技术，效果竟然更好

这是视频流技术系列的第二部分。我们正在开发Helix，一个让AI编码助手在云沙盒中工作的平台，用户需要实时观看AI的操作。

核心挑战：必须在企业网络中稳定运行。企业网络通常只允许HTTP/HTTPS通过443端口，而会屏蔽UDP、WebRTC、自定义端口等。我们最初尝试了WebRTC方案，但在企业环境中因UDP被屏蔽而失败。

技术迭代： 1. 我们开发了基于WebSocket的H.264视频流管道： - 使用GStreamer+VA-API硬件加速编码 - 通过WebSocket传输二进制帧 - 浏览器端使用WebCodecs API硬件解码 - 实现60fps/40Mbps的亚100毫秒延迟

2. 但在网络不稳定时（如咖啡厅WiFi），视频会出现严重延迟：

   • TCP缓冲导致视频落后实时操作30秒
   • 降低码率只会得到模糊且依然延迟的画面

3. 尝试仅发送关键帧（IDR帧）的解决方案：

   • 理论上可以避免依赖前序帧
   • 实际测试中只收到一个关键帧后传输就中断了

意外突破： 在调试时发现，通过HTTP请求JPEG截图能即时获得清晰图像。于是我们实现了一个混合方案： - 良好连接时：使用完整的H.264视频流 - 网络不佳时：切换为JPEG轮询（100-150KB/帧） - 始终保持WebSocket连接处理输入事件

技术细节： - 自适应切换逻辑：延迟超过150ms时自动降级 - 防止模式震荡：降级后需用户手动恢复视频流 - 解决Ubuntu的grim工具缺失JPEG支持问题：通过Docker重新编译

架构对比： | 特性 | H.264视频流 | JPEG轮询 | |-----------|-----------------|-----------------| | 带宽 | 40Mbps恒定 | 100-500Kbps动态 | | 状态依赖 | 强（解码依赖前序帧） | 完全独立 | | 恢复速度 | 需等待关键帧（秒级） | 下一帧即恢复（100ms）|

经验总结： 1. 简单方案往往更可靠 2. 优雅降级是关键功能 3. 输入响应比视频流畅更重要 4. 基础工具可能需要自行编译 5. 优化前应先充分测量

最终系统结合了现代视频技术和传统截图方法，既保证了良好网络下的高质量体验，也确保了恶劣环境下的基本可用性。

（注：原文中部分技术细节和代码示例已简化，保留了核心技术思路和解决方案的演变过程）

以下是评论内容的总结：

1. 对JPEG方案的认可

   • 认为JPEG在低带宽环境下更稳定可靠（评论3, 10）
   • 引用："JPEG is extremely efficient to [de/en]code on modern CPUs"（评论10）
   • 引用："When the network is bad, you get... fewer JPEGs. The ones that arrive are perfect"（评论11）

2. 对H.264方案的批评

   • 认为H.264设置不当导致性能问题（评论11, 14）
   • 引用："H.264 can do a lot better than JPEG with a lot less bandwidth"（评论11）
   • 引用："A single H.264 keyframe is 200-500KB is fantastical"（评论14）

3. 企业网络限制问题

   • 指出企业网络对HTTP/HTTPS的限制导致技术选择受限（评论4, 24）
   • 引用："Corporate networks also love to MITM their own workstations"（评论4）
   • 引用："IT dept will never lift restrictions"（评论4）

4. 替代方案建议

   • 建议使用WebRTC、HLS等技术（评论9, 17, 22）
   • 引用："WebRTC over UDP is one choice for lossy situations"（评论17）
   • 引用："HLS as a escape for hotel/cafe WiFi situations"（评论9）

5. 历史方案参考

   • 提到VNC、MJPEG等历史技术（评论23, 28, 30）
   • 引用："They've invented MJPEG?"（评论23）
   • 引用："VNC has been doing since 1998"（评论30）

6. 工程实践观点

   • 赞赏简单可靠的解决方案（评论18, 19）
   • 引用："Good engineering: when you're not too proud to do the obvious"（评论18）
   • 引用："The boring stuff is what works every time"（评论19）

7. 技术细节讨论

   • 讨论编码效率、网络控制等技术细节（评论20, 21, 26）
   • 引用："Make sure to use a non-ancient kernel on the sender side"（评论20）
   • 引用："I wonder if they just tried restarting the stream at a lower bitrate"（评论26）