C# Programma di streaming dello schermo

Question

Ultimamente ho lavorato su un semplice programma di condivisione dello schermo.

In realtà il programma funziona su un TCP protocol e utilizza il Desktop duplicazione API - un servizio cool che supporta la cattura schermo molto veloce e anche fornire informazioni su MovedRegions (aree che hanno cambiato solo la loro posizione sullo schermo, ma esistono ancora) e UpdatedRegions (aree modificate).

La duplicazione desktop ha 2 Properties- 2 matrici di byte improtant una matrice per la previouspixels e una matrice NewPixels. Ogni 4 byte rappresentano un pixel nel RGBA forma così per esempio se lo schermo è 1920 x 1080 la dimensione del buffer è di 1920 x 1080 * 4.

riportano i principali dati importanti della mia strategia

1. Nello stato iniziale (la prima volta) invio l'intero buffer di pixel (nel mio caso è 1920 x 1080 * 3) - il componente alpha è sempre 255 sugli schermi :)

2. Da ora in poi, iterato su AggiornatoRegioni (è una matrice di rettangoli) e invio i limiti delle regioni e Xo'r i pixel al loro interno qualcosa del genere:

   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. I Comprimere il buffer utilizzando il wrapper lz4 scritto in C# (fare riferimento a lz4.NET@github). Quindi, scrivo i dati su un NetworkStream.
4. ho fondere le aree del lato ricevitore per ottenere l'immagine aggiornata - questo non è il nostro problema oggi :)

'scrittore' è un'istanza della classe 'QuickBinaryWriter' ho scritto (semplicemente quello di riutilizzare la stessa buffer di nuovo).

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]); 
    } 

} 

Da molte misure, ho visto che i dati inviati è davvero enorme, e, a volte per un singolo aggiornamento fotogramma i dati potrebbero arrivare fino a 200KB (dopo la compressione!). Siamo sinceri: 200kb non è proprio nulla, ma se voglio scorrere lo schermo in modo fluido e poter guardare in alta frequenza Fps dovrei lavorare un po 'su questo - a minimizzare il traffico di rete e l'utilizzo della larghezza di banda .

Sto cercando suggerimenti e idee creative per migliorare l'efficienza del programma, principalmente i dati inviati sulla parte di rete (imballandola in altri modi o qualsiasi altra idea), apprezzerò qualsiasi aiuto e idee. Grazie.

Answer 1

Per il vostro schermo di 1920 x 1080, con 4 colori di byte, si sta cercando di circa 8 MB per fotogramma. Con 20 FPS, hai 160 MB/s. Quindi ottenere da 8 MB a 200 KB (4 MB/s 20 FPS) è un grande miglioramento.

Vorrei attirare la vostra attenzione su alcuni aspetti su cui non sono sicuro che vi stiate concentrando, e speriamo che ciò sia d'aiuto.

1. Quanto più si comprimere l'immagine dello schermo, più il trattamento potrebbe essere necessario
2. In realtà è necessario concentrarsi su meccanismi di compressione progettato per la serie di immagini in continuo cambiamento, simile a codec video (sans audio però). Ad esempio: H.264
3. Ricordare che è necessario utilizzare un tipo di protocollo in tempo reale per il trasferimento dei dati. L'idea alla base di questo è che, se uno dei tuoi fotogrammi raggiunge la macchina di destinazione con un ritardo, potresti anche rilasciare i prossimi fotogrammi per recuperare il ritardo. Altrimenti sarete in una situazione perennemente in ritardo, che dubito che gli utenti possano apprezzare.
4. È sempre possibile sacrificare la qualità per le prestazioni. Il meccanismo più semplice che si vede in tecnologie simili (come MS Remote Desktop, VNC, ecc.) È di inviare un colore a 8 bit (ARGB ciascuno di 2 bit) invece del colore a 3 byte che si sta utilizzando.
5. Un altro modo per migliorare la situazione sarebbe concentrarsi su uno specifico rettangolo sullo schermo che si desidera trasmettere, invece di eseguire lo streaming dell'intero desktop. Questo ridurrà le dimensioni del telaio stesso.
6. Un altro modo sarebbe quello di ridimensionare l'immagine dello schermo su un'immagine più piccola prima di trasmetterla e ridimensionarla alla normalità prima di visualizzarla.
7. Dopo aver inviato la schermata iniziale, è sempre possibile inviare il diff tra newpixels e previouspixels. Inutile dire che lo schermo originale e lo schermo diff saranno tutti compressi/decompressi in LZ4. Ogni tanto dovresti inviare l'array completo al posto del diff, se usi un algoritmo lossy per comprimere il diff.
8. Does UpdatedRegions, hanno aree sovrapposte? Può essere ottimizzato per non inviare informazioni duplicate sui pixel?

Le idee sopra possono essere applicate l'una sull'altra per ottenere un'esperienza utente migliore. In definitiva, dipende dalle specifiche della tua applicazione e dagli utenti finali.

EDIT:

• Color Quantization può essere utilizzato per ridurre il numero di bit utilizzati per un colore. Di seguito sono riportati alcuni link a implementazioni concrete di quantizzazione di colore

  • Optimizing Color Quantization for Images
  • nQuant library

• Di solito i colori quantizzati vengono memorizzati in una Color Palette and only the index into this palette è dato alla logica di decodifica

Answer 2

slashy,

Dal momento che si sta utilizzando un res alti frame e volete un buon frame rate è molto probabile che andando a essere guardando la codifica H.264. Ho fatto un po 'di lavoro con i video broadcast HD/SDI che dipendono totalmente da H.264, e un po' spostandomi su H.265. La maggior parte delle librerie usate in broadcast sono scritte in C++ per la velocità.

mi piacerebbe suggerire a guardare qualcosa di simile https://msdn.microsoft.com/en-us/library/windows/desktop/dd797816(v=vs.85).aspx