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

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