Schnelle Bildschirmübertragung per Netzwerk

[Zacherl]

Hallo zusammen,

ich suche nach Konzepten für eine schnelle Bildschirmübertragung per Netwerk. Bisher verwende ich das Differenzbildverfahren und komprimiere die Einzelbilder per ZLib(Ex). Momentan verwende ich ein einaches Polling, um die Screenshots zu erstellen (Mirror Driver kommt bei mir leider nicht in Frage) und rechne die Farbtiefe dann auf 16 bzw. 8 Bit herunter. Dies ist zwar im Vergleich zu normalen Bitmaps schon recht performant, aber die erreichten Frameraten sind noch lange nicht mit Remote Desktop oder TeamViewer zu vergleichen.

Gibt es hier noch einfach zu implementierende Verbesserungen bzw. komplett andere Möglichkeiten, mit denen ich eine höhere Performance erreichen könnte?

Bin leider auf TCP beschränkt, weshalb die UDP Variante rausfällt. Allerdings erreicht z.b. TeamViewer auch per TCP Option noch eine deutlich höhere Performance.

Viele Grüße
Zacherl

[Popov]

Ist nicht direkt Antwort auf deine Frage, aber ich hab mich vor etlichen Jahren mal mit einem Codec auseinandergesetzt der für Bildschirm Aufnahmen entwickelt wurde. Der speicherte nicht das ganze Bild, sondern nur die Änderungen. Am besten sichtbar war das bei dem Cursor. Hat sich der Cursor bewegt, wurde nur der Bereich der alten und neuen Position übertragen. Und das war relativ wenig. Letztendlich das alte Bild mit dem neuen vergleichen und nur den kleinsten Bereich speichern der verändert wurde (inc. Parameter). Ändert sich nichts, ein 0 px Bild speichern. Alternativ evtl. so und als Korrektur jedes vierte Bild ein Vollbild. Wobei wenn ich mir die Qualität von z. B. TeamViewer ansehe, hat man da die Möglichkeit die Qualität einzustellen. Und das Ergebnis erinnert mich stak an Jpeg.

[himitsu]

Wobei die Genannten nicht alles direkt als pixeliges Bitmap verschicken, sondern oftmals nur die Zeichenbefehle und wenn es ein Bild ist, dann auch nur den Bildbereich, welcher sich ändert.
Also z.B. statt einem Screenshot von dem bereich wo sich grade ein Label verändert hat, wird nur der entspechende DrawText Aufruf plus Parameter und dem Text geschickt.


Nja, es kommt jetzt drauf an, wie genau das Bild sein muß.
Eventuell kannst du bei großen/vielen Änderungen erstmal nur eine Vorschau schicken und erst wenn sich die Zeit dafür ergibt, dann die Details.
Praktisch so als unscharfes JPeg oder mit "größeren" Pixeln.

Da kannste bei ungenügend Bandbreite oder bei vielen veränderten Pixeln die Datenrate senken, da ja weniger verschickt werden muß.

[p80286]

Wenn Du weißt um was es sich handelt (Deine) Anwendung, dann greif doch auf die alte Terminal Methode zurück, da werden nur ein paar Strings übertragen.

Gruß
K-H

[Zacherl]

Ich möchte den gesamten Desktop bzw. bestimmte Anwendungsfenster übertragen. Deshalb muss ich leider wirkliche Grafiken übertragen und nicht nur Zeichenbefehle.

BTW: Bei meinem Differenzbildverfahren werden alle nicht geänderten Pixel schwarz und lassen sich daher per ZLib recht effizient komprimieren. Daher ist das Verfahren eigentlich schon ganz gut, bloß nimmt die vollständige Kompression natürlich recht viel CPU Zeit in Anspruch und die Menge der zu übertragenden Daten ist trotzdem nicht perfekt. Gäbe dann noch die Möglichkeit den Bildschirm rekursiv in Quadranten zu unterteilen, allerdings muss man dann per Hash Verfahren auf Änderungen prüfen, was auch rechenintensiv ist und bei der Übertragung hat man den Oberhead von X und Y bzw. im besten Falle nur der ID des Ausschnitts.

@popov: Ja TeamViewer hat auch die Möglichkeit JPEG Kompression zu aktivieren. Aber auch der verlustfreie Standard über ein 16 Bit Differenzbild ist irre schnell. Hast du zu dem Codec nähere Infos? Könnte ich sowas z.B. aus einer externen DLL einbinden?

[Dalai]

Da UltraVNC Open Source ist, würde ich mal in dessen Code reinschauen. Der alte RealVNC 4.x Free Edition ist übrigens ebenfalls Open Source.

MfG Dalai

[Zacherl]

Die alten und generell die OpenSource VNC Versionen verwenden ein änhliches Differenzbildverfahren wie ich es mache. Die sind auch nicht wirklich schneller. Dass RemoteDesktop schneller ist kann ich aufgrund der anderen Funktionsweise auch verstehen, aber ich frage mich halt wie z.b. TeamViewer auf so hohe Frameraten kommt. Die verwenden definitiv auch eine Form der direkten Grafikübertragung.

[Popov]

Den eigentlichen Codec kenne ich nicht mehr. Ist schon sehr lange her. Das war noch zu Win95 Zeit, wo Multimedia noch nicht so einfach klappte wie heute und ich eine Demo erstellen sollte die über CD verteilt auf allen Rechnern funktionieren sollte. Deshalb wollte ich etwas eigenes basteln.

Aber paar Jahre später habe ich bei TechSmith (SnagIt & Co) auch einen Codec gesehen der ähnlich arbeitete.

Aber letztendlich bleibt dir wohl nur noch Ockhams Rasiermesser, denn wenn du schon optimiert mit Vollbild arbeitest, aber TeamViewer schneller ist, dann stellt sich die Frage ob TeamViewer mit Vollbild oder mit Bildbereichen arbeitet.

[olee]

Ich habe erst vor kurzem eine sehr einfache aber effiziente Methode der Übertragung von Bildschirminhalt geschrieben.
Das Prinzip war folgendermaßen:

-> Mit Scanline letzten und nächten Frame vom Bildschirm pixelweise durchgehen.
---> Wenn ein (außreichend großer?) Unterschied von beiden Pixeln festgestellt wird, werden in den Stream die Pixelnummer (zeile*width+x) und ein Platzhalter für die Anzahl an Pixeln geschrieben
---> Solange die folgenden Pixel sich von dem Original unterscheiden (+ lookahead von 2 Pixeln) wird jeder weitere Pixel in den Stream geschrieben.
---> Wenn 3 aufeinanderfolgende Pixel wieder gleich sind, wird mit dem schreiben aufgehört.
---> Wenn der Schreibvorgang beendet wird, wird noch die Anzahl geschriebener Pixel an den Platzhalter geschrieben
---> Bei durchgehen aller Pixel werden dabei Zeilenenden ignoriert.
-> Der Finale Stream wird noch mit ZLib gepackt.

-> Das Wiederherstellen des Bildes beim Zielrechner geschieht analog.

Hier mal die beiden Funktionen dafür:

Delphi-Quellcode:

procedure compressStream(input, output: TStream);
var
  xx: TCompressionStream;
begin
  xx := TCompressionStream.Create(clmax, output);
  try
    input.Position := 0;
    xx.CopyFrom(input, input.Size);
  finally
    xx.Free;
    output.position := 0;
  end;
end;

procedure TForm1.WriteDiffPkg(last, next: TBitmap; zipPkg: TMemoryStream);
var
  w, h   : Integer;
  ix, iy : Integer;   
  pixpos : Cardinal;  
  cnt    : Cardinal;

  addr   : Int64;
  pl, pn : PRGBTriple;
  diff   : Boolean;

  pkg    : TMemoryStream;
type
  PLongWord = ^LongWord;
begin
  pkg := TMemoryStream.Create;
  try
    w := last.Width;
    h := last.Height;

    pixpos := 0;
    diff := false;
    for iy := 0 to h - 1 do
    begin
      pl := last.ScanLine[iy];
      pn := next.ScanLine[iy];
      for ix := 0 to w - 1 do
      begin
        If ((PLongWord(pl)^ and $F0F0F0) = (PLongWord(pn)^ and $F0F0F0)) then
        begin
          If diff then
          begin
            inc(pl); inc(pn);
            If ((PLongWord(pl)^ and $F0F0F0) = (PLongWord(pn)^ and $F0F0F0)) then
            begin
              inc(pl); inc(pn);
              If ((PLongWord(pl)^ and $F0F0F0) = (PLongWord(pn)^ and $F0F0F0)) then
              begin
                PCardinal(Integer(Pkg.Memory) + addr)^ := cnt;
                diff := false;
              end;
              dec(pl); dec(pn);
            end;
            dec(pl); dec(pn);
            If diff then
            begin
              Pkg.Write(pn^, 3);
//              pl^.rgbtRed := 0;
//              pl^.rgbtGreen := 0;
//              pl^.rgbtBlue := 0;
              inc(cnt);       
            end;
          end;
        end
        else
        begin    
          If not diff then
          begin
            cnt := 0;
            addr := Pkg.Size;
            Pkg.WriteCardinal(0);
            Pkg.WriteCardinal(pixpos);
            diff := true;
          end;
          Pkg.Write(pn^, 3);
//          pl^.rgbtRed := 0;
//          pl^.rgbtGreen := 0;
//          pl^.rgbtBlue := 0;
          inc(cnt);
        end;
        inc(pixpos);
        inc(pl);
        inc(pn);
      end;
    end;  
    Pkg.WriteCardinal(0);
  finally
    zipPkg.Clear;
    pkg.Position := 0;
    compressStream(pkg, zipPkg);
    pkg.Free;
  end;
end;

procedure TForm1.ReadDiffPkg(last: TBitmap; zipPkg: TStream);
var
  w, h   : Integer;
  ix, iy : Integer; 
  pixpos : Cardinal;
  cnt    : Cardinal;

  addr   : Cardinal;
  ssize  : Int64;
  pix    : PRGBTriple;

  pkg    : TDecompressionStream;
type
  PLongWord = ^LongWord;
begin
  zipPkg.Position := 0;
  pkg := TDecompressionStream.Create(zipPkg);
  try
    w := last.Width;
    h := last.Height;

    ix := 0;
    iy := 0;
    pixpos := 0;      
    pix := last.ScanLine[iy];
    //while Pkg.Position < Pkg.Size do
    while true do
    begin
      cnt := Pkg.ReadCardinal;
      If cnt = 0 then break;
      addr := Pkg.ReadCardinal;

      // Fast-forward to address
      ix := addr mod w;
      iy := addr div w;
      pix := last.ScanLine[iy];
      inc(pix, ix);

      // Write data
      while cnt > 0 do
        If (ix < w) then
        begin
          Pkg.Read(pix^, 3);
          inc(ix);
          inc(pixpos);

          dec(cnt);
          inc(pix);
        end
        else
        begin
          inc(iy);
          pix := last.ScanLine[iy];
          ix := 0;
        end;
    end;
  finally
    pkg.Free;
  end;
end;

Bei Interesse kann ich auch noch eine Variation der Funktion posten, welche per Flag nur jede gerade/ungerade Zeile verarbeitet, um schnellere Updates zu ermöglichen.
Diese Technik hat sich im Praxistest als unglaublich schnell für die Übertragung von Textinhalten erwiesen.
Man kann bestimmt das ganze durch Bittiefenreduzierung noch optimieren...

[Aphton]

Für diejenigen, die diesen Praxitest selber durchführen wollen, hier...

[Jo, die Idee kam ihm als ich vorschlug, dass man Differenzbilder erzeugen kann und diese dann komprimiert; dadurch dass bei der Differenz ein großer Teil schwarz (nicht veränderter Teil) ist, sorgt das für eine sehr gute Komprimierung; daraufhin meinte er, dass man die schwarzen Teile direkt weglassen sollte (also wirklich nur die Daten schicken, die auch verändert wurden)]

Kleine Anmerkung - das ist nur ne Testanwendung; bei Fehlermeldungen ein Auge zudrücken

Implementiert von mir

[olee]

Danke fürs posten ;-)

[Zacherl]

Danke euch beiden, das sieht doch recht vielversprechend aus :) Ich werde mir die Funktion mal selbst für variable Bittiefen anpassen. Die Erweiterung für gerade und ungerade Zahöen ist einfach damit der Empfänger schonmal in der Hälfte der Zeit eine Änderung sieht? Wäre auf jeden Fall auch da an deiner Umsetzung interessiert.

[Aphton]

Joa. Aufjedenfall kann ich mit ihm Videos im kleinen Player auf youtube mit 7-8fps mitkucken!

Bzgl der Aufnahme: bei mir (i7 3.4 ghz) kann ich mit 30~ fps im Schnitt per StretchBlt / BitBlt Bilder mit der Auflösung 1920x1080 aufzeichnen. Deaktiviere ich Aero, so steigt es auf ~150.

Also falls man da noch ein paar Frames rausholen will, könnte man dieses Bottleneck entfernen... DwmDisableComposition()

[olee]

Hi nochmal,

Dein Posting hier hatte nochmal mein Interesse geweckt und da hab ich schnell mal das alte Programm mit Aphton's Hilfe etwas überarbeitet und auch die unterscheidung zwischen den Bittiefen 8 / 24 Bit hinzugefügt, sowie mancher kleiner Extras.
Wenn du Interesse an diesem "Codec" hast, ich habe ihn als Unit angehangen.

EDIT: Schon irgendwie lustig, dass du dieses Thema anpackst, wo wir erst vor kurzem selbst drauf gekommen sind :D
Wäre cool, wenn du das ganze vielleicht noch schneller bekommen könntest!
Testen lässt sich das am besten mit ein paar ausgewählten Bildern, welche man laden, durch den Codec jagen und anschließend nach Paketgrößen prüfen kann.

EDIT-2: Der neue Code ist auch variabel auf einen *übertrage-jede-n-te-Zeile* mit Parameter 'n' einstellbar.

EDIT-3 (man bin ich vergesslich -.-'): Das neue Programm hat sich je nach Scenario sogar schneller als Teamviewer erwiesen. Scheint als wäre das der richtige Weg :D

Viel Spaß damit

MFG

[Zacherl]

Vielen vielen Dank schonmal für die Codec Unit und das Beispielprogramm :) Das Verfahren ist echt schon irre schnell muss man sagen. Lustigerweise gibt es bei mir keinen wirklichen Unterschied bei den Frameraten bezüglich lokaler Verbindung und Verbindung über WAN IP. Ich muss das später von der Uni aus nochmal genau prüfen, vielleicht hat mein Router die WAN IP auch einfach ganz geschickt wieder auf meine LAN IP geroutet. Oder hast du in der Demo Anwendung sowas wie eine Framerate Begrenzung eingebaut?

Ich bastele mir mal eine eigene kleine Demoanwendung und schaue dann, was sich noch optimieren lässt.

[olee]

Auf mehrfache Anfrage hier mal der gesamte Code der Screen-Sharing Demo.
Intern werden dabei meine Net-Messages zur einfachen und effizienten Übertragung von großen TCP Paketen verwendet.

MFG

[arnof]

gibt es hier schon was neues ?

Ich habe mir gerade die Teamviewer Updatepreise angeschaut, da bin ich echt am überlegen, sowas selbst zu machen ....

[Aviator]

Zitat:

Zitat von arnof (Beitrag 1353294)

gibt es hier schon was neues ?

Ich habe mir gerade die Teamviewer Updatepreise angeschaut, da bin ich echt am überlegen, sowas selbst zu machen ....

Musst du da auf Rechner in entfernten Netzwerken zugreifen? Ansonsten schau dir mal TightVNC an. Ich meine da wäre sogar der SourceCode bzw. eine DLL dabei um sowas in das eigene Programm zu implementieren.

Benutzen wir hier in der Firma zur Fernwartung. Funktioniert perfekt. Besser als RealVNC oder UltraVNC.

Nur haben wir das natürlich nicht in einer eigenen Anwendung integriert. Ist aber ja mit TeamViewer auch nicht möglich, oder?

[Zacherl]

Gibt seit Windows 8 tatsächlich etwas sehr Feines: Die Desktop Duplication API.

Über dieses Interface bekommst du direkt von Windows alle Änderungen am Bildschirminhalt zwischen zwei Aufrufen der Funktion geliefert. Dabei sind die Daten sehr geschickt und platzsparend arrangiert. Zum Einen bekommst du eine Liste mit Rechtecken (nur die Position und Größe, keine Bildaten) von gleichgebliebenen Bereichen, die sich allerdings verschoben haben und zum Zweiten erhälst du eine Liste mit Rechtecken (diesmal Position, Größe und Bilddaten) von Bereichen, die sich geändert haben.

[Harry Stahl]

Zitat:

Zitat von arnof (Beitrag 1353294)

gibt es hier schon was neues ?

Ich habe mir gerade die Teamviewer Updatepreise angeschaut, da bin ich echt am überlegen, sowas selbst zu machen ....

Vor der Überlegung stand ich auch vor kurzem, mein Remote-Desktop-Programm (bei Interesse, hier: http://www.pc-network.biz/) auf einen Fernwartungsmodus zu erweitern, denn die TeamViewer-Preise finde ich inakzeptabel.

Habe dann aber anydesk gefunden, das ist sehr preiswert und in einigen Punkten sogar noch besser als der Teamviewer :http://anydesk.de/remote-desktop

Das nutze ich jetzt seit einiger Zeit und bin bislang sehr zufrieden.

[sh17]

Man benötigt auf jeden Fall einen Relay Server für Clients hinter einer Firewall. Bietet TightVNC das? UltraVNC hat sowas.

Bin auch am überlegen wegen weg von TeamViewer. Echt nicht günstig.

[Lemmy]

Als günstige Alternative schmeiße ich mal die Alternative PC Visit in die Runde. Allerdings wollen alle Fernwartungssoftwarehersteller jährlich ihre Kohle.

[Bambini]

Wenn es mit Delphi programmiert sein soll:
http://www.realthinclient.com/details/#tabs-4

[jaenicke]

Zitat:

Zitat von Zacherl (Beitrag 1353297)

Gibt seit Windows 8 tatsächlich etwas sehr Feines: Die Desktop Duplication API.

Ich vermute das ist der Grund weshalb Teamviewer 12 echt sehr schnell zu sein scheint. Ich konnte noch nicht viel testen, aber subjektiv fühlt sich der schon sehr schnell an im Vergleich mit TV 11 und noch deutlicher im Vergleich mit UltraVNC.

[himitsu]

Ein Vorteil von TeamViewer ist, dass man da auch im Windows-Logon und auch in den UAC-Fenstern den Screen sieht und Eingaben tätigen kann.

Aber es macht mir auch irgendwie etwas Angst.
Denn eigentlich sollten der Login-Screen und vorallem die UAC-Dialoge in einem eigenen Desktop laufen, auf den "andere" Programme keinen Zugriff haben, damit z.B. Trojaner, Keylogger und Co. nichts abfangen/einschleußen können. :shock:

[Bambini]

Zitat:

Zitat von himitsu (Beitrag 1353358)

Ein Vorteil von TeamViewer ist, dass man da auch im Windows-Logon und auch in den UAC-Fenstern den Screen sieht und Eingaben tätigen kann.

Aber es macht mir auch irgendwie etwas Angst.
Denn eigentlich sollten der Login-Screen und vorallem die UAC-Dialoge in einem eigenen Desktop laufen, auf den "andere" Programme keinen Zugriff haben, damit z.B. Trojaner, Keylogger und Co. nichts abfangen/einschleußen können. :shock:

Das klappt aber, glaube ich, nur wenn man den Teamviewer auch als Admin mit der UAC Bestätigung startet. Bricht man den UAC Dialog ab, kann man keine "Admin" Fester bedienen.

[himitsu]

Nee, die GUI startet bei uns/mir automatisch im UserContext, aber im Hintergrund läuft der TeamViewer-Service.

[greenmile]

Zitat:

Zitat von Harry Stahl (Beitrag 1353299)

Zitat:

Zitat von arnof (Beitrag 1353294)

gibt es hier schon was neues ?

Ich habe mir gerade die Teamviewer Updatepreise angeschaut, da bin ich echt am überlegen, sowas selbst zu machen ....

Vor der Überlegung stand ich auch vor kurzem, mein Remote-Desktop-Programm (bei Interesse, hier: http://www.pc-network.biz/) auf einen Fernwartungsmodus zu erweitern, denn die TeamViewer-Preise finde ich inakzeptabel.

Habe dann aber anydesk gefunden, das ist sehr preiswert und in einigen Punkten sogar noch besser als der Teamviewer :http://anydesk.de/remote-desktop

Das nutze ich jetzt seit einiger Zeit und bin bislang sehr zufrieden.

Hast Du die Software "PC Network" gemacht? Falls ja ... Respekt!

[Harry Stahl]

Zitat:

Zitat von greenmile (Beitrag 1353362)

Hast Du die Software "PC Network" gemacht? Falls ja ... Respekt!

Hab ich, vielen Dank.

Allerdings kommt mein Programm leider nicht an die Geschwindigkeit von TeamViewer, bzw. AnyDesk heran... (TeamViewer nutze ich ja nicht, aber wenn man AnyDesk im Netzwerk nutzt, dann ist das wirklich mit Null Verzögerung so, als ob man vor dem anderen PC säße).

Zu AnyDesk sollte man noch erwähnen, dass die ein faires Preismodell haben (eine Jahreslizenz schon für 60,--Euro): http://anydesk.de/bestellen

[Mavarik]

Zitat:

Zitat von arnof (Beitrag 1353294)

Ich habe mir gerade die Teamviewer Updatepreise angeschaut, da bin ich echt am überlegen, sowas selbst zu machen ....

Ja das habe ich vor langer Zeit auch mal gemacht...

Ein proof of concept war schnell gemacht... Damit man den Secure-Desktop bedienen kann, habe ich einen Systemtreiber programmiert, der dann per Shared-Memory die Daten an meine Software übergeben kann...

Alles gut und schön...

Bis es fertig war sind aber trotzdem 400h ins Land gegangen...

Gut, ich habe nix fremdes verwendet und bei Null angefangen... Ich brauche zwar mehr CPU-Last auf dem Remote-PC, aber dafür bin ich schneller und muss weniger Daten(gepackt) übertragen als z.B. VNC.

Mavarik