HelixML 是一款在云沙箱中运行自主编码代理的企业级 AI 平台，其内置远程屏幕共享机制可实时监控AI 助手的操作。虽然屏幕共享通常通过流式传输 H.264 编码视频实现，但其开发团队在一篇博文中阐述，他们通过截取并发送 JPEG 格式的屏幕截图，成功解决了低带宽环境下无法共享屏幕的问题。
WebRTC 是一种可用于通过屏幕共享发送和接收视频的系统。然而，由于企业网络中 UDP 协议常被阻止或降级处理，而 WebRTC 因采用 TURN 协议需依赖 UDP 传输，因此很容易遇到视频无法连接等问题。
为解决此问题，HelixML 绕过所有代理和防火墙，转而采用基于 WebSocket 传输视频帧的方案：通过GStreamer 配合 undefined 实现硬件 H.264 编码，并利用浏览器端的 WebCodecs 进行硬件解码。从而实现了 60 fps 的帧速率、40 Mbps 的比特率和小于 100 毫秒的延迟的视频传输。
尽管这套视频流媒体系统在开发环境中运行良好，但在咖啡馆等不稳定的 Wi-Fi 环境中却出现了问题。这是因为 TCP（WebSocket）保证数据传输顺序，当网络拥塞时，由于 TCP 缓冲导致延迟累积，造成视频与实际操作出现数秒甚至数十秒的延迟。
最初，为了解决这个问题，开发团队尝试创建一种只发送“关键帧”的模式。
视频流媒体常用的H.264编解码器为节省数据，并非将所有帧作为完整图像发送，而是传输“差异数据”——即仅包含相较前帧变化部分的信息。包含完整信息的基础帧称为关键帧，而以差异形式呈现的帧则称为 P 帧。
对于 60fps 的视频，通常每秒发送60帧，但我们将其设置为丢弃所有 59 个 P 帧，只发送剩余的 1 个关键帧。这会导致视频以 1fps 的速度断断续续地播放，但可以显著减少传输的数据量。
然而，实际运行后，屏幕在显示第一帧后就完全冻结了。这是由于通信所用的 Moonlight 协议的规范所致。Moonlight 协议有一条规则：“如果一帧未被处理，则不会发送下一帧”，因此它无法正确处理部分帧的丢弃。
这个问题通过使用一个专为调试而准备的屏幕截图 API 得到了解决。
该 API 每秒多次检索轻量级的 JPEG 图像，每张图像大小约为 100KB 到 150KB。在浏览器中打开它，即可立即显示一张 1080p 的桌面 JPEG 图像，并且反复刷新可以以大约 5fps 的速度显示精美的静态图像。
由于 JPEG 图像是独立的，因此它们在到达时总是以完整的图像形式显示，并且不太可能像视频那样出现“等待下一关键帧”或“解码器状态损坏”等问题。此外，虽然 H.264 关键帧的大小为 200KB 到 500KB，但 70% 质量的 1080p JPEG 图像的大小约为 100KB 到 150KB，因此在某些情况下，JPEG 在每帧传输体积方面实际上可能更轻。
因此 HelixML 采用了混合配置方案：“在网络良好时使用 H.264，网络不佳时切换为 JPEG 轮询传输”。当网络良好（往返时间 RTT 低于 150 毫秒）时，系统会流畅显示 H.264 视频；但当 RTT 超过 150 毫秒时，视频会自动停止并切换为 JPEG 图像传输。
然而当 H.264 流媒体停止时，WebSocket 负载减轻导致 RTT 改善，监控逻辑误判线路恢复而重启视频。但视频恢复后线路再度拥塞，画面又切回截图状态，形成约每 2 秒持续切换的循环。基于此，HelixML 开发团队决定取消 H.264 流媒体的自动恢复功能，改为需用户手动点击按钮触发。
通过此次经历，开发团队得出结论：“在严苛的现实环境中，古老简单的解决方案有时比复杂尖端的技术更有效”，并盛赞这项15年前的老技术成为解决当下问题的关键，称其为“矛盾却卓越的解决方案”。
与此同时，在网站 Hacker News 上，出现了诸如以下观点：
- “延迟累积的根本原因是拥塞控制和带宽估算机制薄弱，因此应通过初始带宽探测和传输延迟增加作为拥塞信号，实施控制措施来降低比特率和帧率。”
- “为何不采用 HLS 传输视频分块，并利用自适应比特率播放根据线路状况切换画质？”
- “与其将屏幕作为视频发送，为何不将其作为文本等应用数据传输，在接收端重建画面？”
- 以及“即使采用 TCP 协议，也应设计防止发送端帧数据堆积的机制，并实施基于反馈假设的传输控制。使用 FFmpeg 等底层库也是可行方案，其行为逻辑更易于理解。”
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/63986.html
