C# 屏幕流式传输程序

Question

最近我一直在开发一个简单的屏幕共享程序。

实际上，该程序在 TCP protocol 上运行，并使用 Desktop duplication API - 一项很酷的服务，支持非常快速的屏幕捕获并提供有关 MovedRegions 的信息（仅更改其位置的区域在屏幕上但仍然存在）和UpdatedRegions（更改区域）。

桌面复制有 2 个重要的属性 - 2 字节数组 一个数组用于 previouspixels 和一个 NewPixels 数组。每 4 个字节代表 RGBA 形式的一个像素，例如，如果我的屏幕为 1920 x 1080，则缓冲区大小为 1920 x 1080 * 4。

以下是我的策略的重要亮点

1. 在初始状态（第一次）我发送整个像素缓冲区（在我的情况下它是 1920 x 1080 * 3）- alpha 分量在屏幕上始终为 255 :)

2. 从现在开始，我遍历 UpdatedRegions（它是一个矩形数组）并发送区域边界和 Xo'r 像素，如下所示：

       writer.Position = 0;
       var n = frame._newPixels;
       var w = 1920 * 4; //frame boundaries.
       var p = frame._previousPixels;
       foreach (var region in frame.UpdatedRegions)
           {
               writer.WriteInt(region.Top);
               writer.WriteInt(region.Height);
               writer.WriteInt(region.Left);
               writer.WriteInt(region.Width);
               for (int y = region.Top, yOffset = y * w; y < region.Bottom; y++, yOffset += w)
               {
                   for (int x = region.Left, xOffset = x * 4, i = yOffset + xOffset; x < region.Right; x++, i += 4)
                   {
                       writer.WriteByte(n[i] ^ p[i]); //'n' is the newpixels buffer and 'p' is the previous.xoring for differences.
                       writer.WriteByte(n[i+1] ^ p[i+1]);
                       writer.WriteByte(n[i + 2] ^ p[i + 2]);
   
                   }
               }
           }
   

3. 我使用用 c# 编写的 lz4 包装器压缩缓冲区（请参阅lz4.NET@github）。然后，我将数据写入 NetworkStream。
4. 我合并接收端的区域以获得更新的图像 - 这不是我们今天的问题 :)

'writer' 是我编写的'QuickBinaryWriter' 类的一个实例（只是为了再次重用相同的缓冲区）。

    public class QuickBinaryWriter
{
    private readonly byte[] _buffer;
    private int _position;

    public QuickBinaryWriter(byte[] buffer)
    {
        _buffer = buffer;
    }

    public int Position
    {
        get { return _position; }
        set { _position = value; }
    }

    public void WriteByte(byte value)
    {
        _buffer[_position++] = value;
    }


    public void WriteInt(int value)
    {

        byte[] arr = BitConverter.GetBytes(value);
        for (int i = 0; i < arr.Length; i++)
            WriteByte(arr[i]);
    }

}

从许多措施来看，我发现发送的数据非常庞大，有时单帧更新数据可能高达 200kb（压缩后！）。 老实说，200kb 真的不算什么，但如果我想流畅地流式传输屏幕并能够以高 Fps 速率观看，我将不得不在这方面做一点工作 - 尽量减少网络流量和带宽使用。

我正在寻找提高程序效率的建议和创意 - 主要是在网络部分发送的数据（通过以其他方式或任何其他想法打包）我将不胜感激任何帮助和想法。谢谢.

Answer 1

对于 1920 x 1080、4 字节颜色的屏幕，每帧大约 8 MB。使用 20 FPS，您有 160 MB/s。所以从 8 MB 到 200 KB（4 MB/s @ 20 FPS）是一个很大的改进。

我想让您注意我不确定您是否关注的某些方面，希望对您有所帮助。

1. 屏幕图像压缩得越多，可能需要的处理就越多
2. 您实际上需要专注于为一系列不断变化的图像设计的压缩机制，类似于视频编解码器（尽管没有音频）。例如：H.264
3. 请记住，您需要使用某种实时协议来传输数据。这背后的想法是，如果您的一帧延迟到达目标机器，您最好放弃接下来的几帧以追赶。否则，您将处于长期滞后的状态，我怀疑用户会喜欢这种情况。
4. 您总是可以牺牲质量来换取性能。您在类似技术（如 MS 远程桌面、VNC 等）中看到的最简单的此类机制是发送 8 位颜色（ARGB，每个 2 位），而不是您正在使用的 3 字节颜色。
5. 另一种改善情况的方法是关注屏幕上要流式传输的特定矩形，而不是流式传输整个桌面。这将减小框架本身的大小。
6. 另一种方法是在传输之前将屏幕图像缩放为较小的图像，然后在显示之前将其缩放回正常值。
7. 发送初始屏幕后，您始终可以发送newpixels 和previouspixels 之间的差异。不用说原屏和差异屏都会被LZ4压缩/解压。如果您使用一些有损算法来压缩差异，您应该经常发送完整的数组而不是差异。
8. UpdatedRegions 是否有重叠区域？是否可以对其进行优化以不发送重复的像素信息？

上述想法可以叠加应用以获得更好的用户体验。最终，这取决于您的应用程序和最终用户的具体情况。

编辑：

• Color Quantization 可用于减少用于颜色的位数。下面是一些颜色量化具体实现的链接

  • Optimizing Color Quantization for Images
  • nQuant library

• 通常将量化后的颜色存储在Color Palette and only the index into this palette中，然后交给解码逻辑

Answer 2

犀利，

由于您使用的是高分辨率帧并且您希望获得良好的帧速率，因此您可能会考虑 H.264 编码。我在完全依赖 H.264 的 HD/SDI 广播视频方面做了一些工作，现在有点转向 H.265。广播中使用的大多数库都是用 C++ 编写的，以提高速度。

我建议看看类似https://msdn.microsoft.com/en-us/library/windows/desktop/dd797816(v=vs.85).aspx