通过WebRTC视频流发送静态渲染图像的策略

Question

我正在使用WebGL将2D图像合成到画布中。我还想通过WebRTC在网络上传输这些图像的稍有不同的版本。 我现在正在做的是使用数据通道发送从画布提取的PNG。虽然这可以正常工作，但速度较慢（对PNG进行编码不是免费的，也不是硬件加速的），并且不适用于动画（所做的更改仅会影响约30fps的一小部分图像）。 画布的captureStream()接口允许我从其渲染缓冲区提取视频供稿，然后可以将其供入WebRTC。视频编解码器可以解决我现在必须手动解决的所有效率问题，这非常好。我可以使用它，但是有很多问题：

• captureStream不允许我指定屏幕外渲染缓冲区，因此我必须为每个流打开一个附加的WebGL上下文（每个流都需要加载多个MB的纹理）。
• 初始比特率太低，以至于您只能得到几块模糊的颜色。到目前为止，我所有尝试提高初始比特率的尝试均以失败告终，其中所有选项都是特定于Chrome的，Firefox仍然不支持。
• 如果我多次发送同一张图像，则带宽问题最终会自行解决（目前所有问题都在本地计算机上）。但是：
• 除非建立连接之前图片有变化，否则不会发送初始图像。
• requestFrame()似乎没有任何作用。我读到它需要改变图片。重新渲染整个框架非常昂贵，除非实际情况有所变化，否则我想避免这种情况。
• 当我以15fps的速度显式重新渲染所有内容时，所有功能都可以正常工作，但是浏览器的速度几乎停滞不前。发送完整的静态图像视频供稿也很浪费。

WebGL没有显式的渲染调用（例如某些OpenGL实现中的swapbuffer），那么用于确定图片中实际发生变化的东西是什么？我能以某种方式伪造它而不实际重新呈现任何东西吗？

有人知道这种方法是否有解决方法吗？似乎WebRTC标准会竭尽所能阻止此用例，仅启用网络摄像头视频供稿。