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

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兼容格式）并将其流式传输到客户端。