C＃屏幕流媒體程序

Question

最近我一直在做一個簡單的屏幕共享程序。

其實程序工作在TCP protocol並使用桌面複製API - 一個很酷的服務支持非常快速的屏幕捕捉，並且還提供了有關MovedRegions（即只改變了屏幕上的位置，但仍然領域存在）和信息UpdatedRegions（更改區域）。

桌面複製有2個重要屬性 - 2字節數組數組爲previouspixels和NewPixels數組。每4個字節代表了RGBA形式的像素因此，例如，如果我的屏幕爲1920×1080的緩衝區大小爲1920×1080×4

下面是我的戰略的重要亮點

1. 在初始狀態下（第一次），我發送整個像素緩衝區（在我的情況下它是1920 x 1080 * 3） - alpha分量始終爲255在屏幕上:)

2. 從現在起，我遍歷UpdatedRegions （這是一個矩形陣列），我發送區域邊界和像素這樣的像素：

   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. 我合併在接收側的區域，以獲得更新的圖像 - 今天這個:)

「作家」是我寫的「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×1080的屏幕，具有4個字節的顏色，你是在尋找大約每幀8 MB。 20 FPS，你有160 MB /秒。所以從8 MB到200 KB（4 MB/s @ 20 FPS）是一個很大的改進。

我想把你的注意力集中到我不確定你關注的某些方面，希望它有幫助。

1. 你壓縮你的屏幕圖像越多，處理它可能需要
2. 實際上，你需要把重點放在設計的一系列不斷變化的圖像，類似視頻編解碼器的壓縮機制（SANS音頻雖然）。例如：H.264
3. 請記住，您需要使用某種實時協議來傳輸數據。這背後的想法是，如果你的某個幀以滯後的方式到達目標機器，那麼你可能會放下接下來的幾幀來追趕它。否則，你將處於長期處於滯後的狀況，我懷疑用戶會喜歡。
4. 你總是可以爲了表現而犧牲品質。您在類似技術（如MS遠程桌面，VNC等）中看到的最簡單的機制是發送8位顏色（ARGB，每個2位）而不是您使用的3字節顏色。
5. 改善您的情況的另一種方法是專注於您想要流式傳輸的屏幕上的特定矩形，而不是流式傳輸整個桌面。這將減少框架本身的大小。
6. 另一種方法是在傳輸之前將屏幕圖像縮放爲較小的圖像，然後在顯示之前將其縮放回正常。
7. 發送初始屏幕後，您始終可以發送newpixels和previouspixels之間的差異。不用說原始屏幕和差異屏幕都將被LZ4壓縮/解壓縮。如果您使用一些有損耗的算法來壓縮差異，那麼您經常應該發送完整的數組而不是差異。
8. 更新區域是否有重疊區域？可以優化不發送重複的像素信息嗎？

上述想法可以應用在另一個之上以獲得更好的用戶體驗。最終，這取決於您的應用程序和最終用戶的具體情況。

編輯：

• Color Quantization可以用來減少用於彩色的比特數。下面是一些鏈接，顏色量化的具體實現

  • Optimizing Color Quantization for Images
  • nQuant library

• 一般量化顏色被存儲在Color Palette and only the index into this palette被提供給解碼邏輯

Answer 2

Slashy，

由於您使用的是高分辨率幀，你想你有可能會良好的幀速率看着H.264編碼。我在高清/標清廣播視頻方面做了一些工作，完全依賴於H.264，稍微轉向H.265。廣播中使用的大多數庫都是用C++編寫的，以提高速度。

我建議在尋找這樣的事情https://msdn.microsoft.com/en-us/library/windows/desktop/dd797816(v=vs.85).aspx