创建屏幕共享应用程序的方法

Question

我正在寻找创建一个屏幕共享应用程序。我尝试使用 WebRTC，但面临许多挑战，所以我现在正在考虑采用以下方法。

1. 在主机端，以毫秒为间隔连续使用一些 JavaScript 库（html2canvas 库）截取页面。

2. 以毫秒为间隔将快照连续发送到 Web 服务器。

3. 在访客端，以毫秒为间隔从 Web 服务器读取快照。

在继续构建之前，我只是想知道这种方法是否可以完美运行，否则会导致一些滞后问题。

Answer 1

几年前我实现了类似的东西（使用经典的 AJAX 而不是 websockets 等）。

在发送客户端上渲染图像会消耗大量 CPU。它还会生成一个不灵活的结果（但这可能是您想要的 - 客户端正在呈现的“最精确”的表示？）具有相对较高的数据大小（每个像素都必须明确表示）。

这会引入延迟（包括渲染和传输时间），并且可能会成为带宽瓶颈（必须跳帧才能“跟上”）。

综上所述，在“实验室环境”（您可以控制带宽等所有因素）中，它可能工作得很好。我很想看看你的发现...

我实现它的方式是发送 DOM，然后在接收者的客户端上渲染它（你可以将它作为画布，我只是让浏览器将它渲染为网页文档。只要确保你做什么您不会暴露自己的注入漏洞...）。

CSS 等在开始时被拉取一次。每个“框架”都经过了相当压缩（缩小）的 XML 标记。

如果您采用现有计划的一些想法：

1. 确保在确认前一个帧之前不要尝试发送帧。每秒帧数应该是动态的，因为最难的瓶颈是允许的。

2. 考虑压缩渲染图像数据。 JPEG 通常擅长有损压缩，同时在重要的地方保持足够的细节……（至少对于人眼而言）。例如，请参阅：setting canvas toDataURL jpg quality

3. 为了获得真正优化的体验，请忽略屏幕中未更改的区域。我相信（从我的记忆中）视频编解码器经常采用这样的技术。在发送客户端上，跟踪上一个和下一个渲染帧并比较它们的块（比如说 128x128 像素），并且只发送那些实际上不同的块。充其量只需要发送“无更改”消息（表明当前帧与前一帧相同），更糟糕的是您需要发送所有 128x128 部分。

4. 考虑如何将它们存储在服务器上。它只需要一个非常临时的 FIFO 缓冲区，对吧？不要过度使用 SQL 数据库等...找到有效解决问题的解决方案。
5. 为减少接收客户端的负载，您可以考虑根据各个帧在服务器上渲染视频流（HTML5 兼容格式）并将其流式传输到客户端。