Hi zusammen,
hallo UEZ,
ich werkele schon einige Jahre (mit vielen arbeitsbedingten Unterbrechungen) an Deskstream, einem schnellen Programm zur Übertragung von Bildschirminhalten übers Netzwerk in Echtzeit.
Teamviewer macht das auch, aber arschlangsam....jedenfalls in der damaligen Version :o)
Problem u.a. war das Screenshotten in einer halbwegs guten Geschwindigkeit. Alles was mit GDI(+) zu tun hat, fällt damit schon mal raus, in den letzten Jahren hatte ich dazu schon etliches gepostet.
Nach bissl rumsuchen stolperte ich über die Interface-getriebene Microsoft Duplication API . Diese transferiert Bildschirminhalte in den Speicher, sobald sich auch nur ein Pixel geändert hat. Wenn sich nichts ändert, gibt es auch keinen neuen Screenshot! Die Geschwindigkeit ist im Vergleich zu anderen Methoden atemberaubend, ich habe eine Bildschirmauflösung von 2560x1440 und kann problemlos bis zu 120 Frames pro Sekunde an meinem Desktoprechner aufnehmen...
Auf einem Uralt-Win10-Tablet (Acer Switch10 von 2014) grabbe und blitte ich den Bildschirminhalt mit bis zu 55fps...wenn der Bildschirm gedreht wird, erkennt die API das und "dreht" mit.
Was ich als Beispielcode zur API vorfand, auch orginaler M$-Code, war gelinde gesagt eine Katastrophe und meist nicht (richtig) lauffähig. Die Interfaces waren teilweise falsch beschrieben, Implementierungen von Funktionen haarsträubend...nur sehr wenige Beispiele haben mehr als einen Frame gecaptured.....
Egal, ich habe mich reingekniet und hatte nach einigen Monaten(!) lauffähigen AutoItcode. Das schwierigste war die Implementierung und Umsetzung der Interfaces. Dabei habe ich etliche Optimierungen zu den Beispielcodes herausgefunden, die wichtigste Optimierung war imho, dass ich (entgegen ALLER verfügbaren Beispiele und Programme) nur EINMAL sämtliche Pointer und Interfaces initialisiert habe, statt ständig in einer Schleife alle Pointer und Interfaces für jeden einzelnen Frame neu zu initialisieren....wieso ist das noch keinem anderen Programmierer auf der Welt aufgefallen?!
Anbei ein kleines Beispiel.
Es wird eine GUI erstellt in welche der aktuelle Bildschirminhalt geblittet wird. Die GUI verändert Ihre Größe und parallel dazu auch den Zoom des Desktops. Dank D2D/D3D-Anbindung (auch der API) funktioniert das auch in nativem AutoItcode sehr flott. Da NUR GEÄNDERTE Bildschirminhalte von der API erfasst werden habe ich so etwas Bewegung auf den Screen gebracht. Man merkt sofort den Unterschied in den FPS, wenn man die Maus bewegt, dann steigt die FPS von 60-75 (ich habe einen 75HZ Monitor) auf über 120 FPS....
Wer mag, kann ja mal "nebenbei" ein 4K HDR-Video auf Youtube im Fullscreen laufen lassen und dabei die AutoIt-GUI einblenden.
Programm wie immer bei mir etwas chaotisch :o), Fragen dazu gerne, ich habe die letzte Version vor 3 Jahren bearbeitet 
Es wird aktuell das erste von der API gefundene Device (Monitor) benutzt, das kann aber bei Multimonitorsystemen eingestellt werden.
Die API-Funktionen, wie immer bei mir, NICHT in einer der "schönen" UDF-Versionen (wo ist der "Fuck off"-Smilie
)
egal, Deskstream läuft in Autoit als Client/Serveranwendung, captured "natürlich" auch Fenster und Regions und nutzt eine OpenCL-basierte BC1-Kompression und Dekompression.
(MUSS sein)) , lokal auf einer Maschine (Netzwerk = loopback Adapter 127.0.0.1) werden 60 FPS in 1440p "übertragen". Übers WLAN sind immer noch stabile 30+ FPS drin, das reicht um x-beliebige Bildschirminhalte auf bspw. einen Fernseher zu streamen (soviel zum "geschützten" 1&1-TV im Browser....)
....aber da werde ich wie seit Jahrzehnten wieder auf Unverständnis seitens der Programmiererzunft stoßen. Der einzige Grund, wieso "Programmieren" so kompliziert war und immer noch ist, ist die Profilneurose und Featuritis der Programmierer(zunft). Wieso müssen immer und immer wieder etliche Funktionen und Aufrufe getätigt werden, um eine simple und milliardenfach abgefragte Aufgabe abzuwickeln? Ist da niemand in der Lage, einen Wrapper zu schreiben, der die Aufgabe in einer Zeile Code abliefern kann? Stattdessen schreibt einer vom anderen ab (heutzutage c&p), produziert millionenfach immer die gleichen Zeilen Code und wundert sich dann, wieso sein Job von einer strunzdummen, wahrscheinlichkeitsoptimierten "KI" übernommen werden kann....und wer jetzt quiekt sollte sich fragen, wieso mittlerweile Jahresgehälter im acht- bis neunstelligen Bereich für talentierte "KI-Forscher" bezahlt werden. Wieso wird deren Job nicht von einer KI übernommen
,
