DeskStream 2 Release Candidate 1.8

Hi,
nur mal kurze Zwischeninfo, ich bin hier weitab vom Schuss ohne AutoIt und ohne Internet

Die übertragenen Daten setzen sich folgendermaßen zusammen:
Ich sags gleich, durch das verdammte little Endian (da hats der Assemblerprogrammierer gut^^) könnte es etwas stressig mit dem dekodieren werden!

Es gibt 3 Sorten von "Paketen".
1. Paket: Es werden aufeinanderfolgende Pixel mit unterschiedlichen Farben zusammengefasst.
Datenformat: 3 Byte Adresse (Offsetadresse in einer 32-Bit-Bitmap), 1 Byte Anzahl Pixel, 2 Byte Farbe, 2 Byte Farbe, 2 Byte Farbe usw.....
Da man für das Offset der Adresse nur 22 Bit braucht, sind Bit 22 und Bit 23 (Bitnummern starten bei null! ) für die Identifikation der Pakete verwendet!
Wenn Bit 22 gesetzt ist (also im gelesenen ersten Dword (4 Bytes)), dann sind Bit 0 bis 21 die Adresse des ersten Pixels.
Die PixelFarbe habe ich auf 16 Bit komprimiert, AA (alpha) ist einfach weggelassen, bei RR(rot) werden nur die 5 höchsten Bits verwendet, bei GG(grün) die 6 höchsten Bits, und bei BB (blau) wieder die 5 höchsten Bits.
Das Word (2 Byte Farbe) müsstest du dann per Bitschiebeoperationen in 32 Bit "extrahieren", also aus den 16 Bit BBBBBGGGGGGRRRRR dann die 32 Bitfarbe AAAAAAAABBBBB000GGGGGG00RRRRR000 machen
So, und jetzt so lange die dekomprimierten Pixel nacheinander in die Bitmap schreiben, bis die Anzahl (s. Datenformat, das vierte Byte) erreicht ist.

2. Paket: Es werden Pixel mit gleicher Farbe zusammengefasst.
Datenformat: 3 Byte Adresse (Offsetadresse in einer 32-Bit-Bitmap), 2 Byte Farbe, 1 Byte Anzahl
siehe oben, allerdings identifiziert sich dieses Paket durch das gesetzte BIT 23 im ersten Dword!
Bit 0 bis 21 sind wieder die Offsetadresse, die Farbe wird wie oben aus den 2 Byte extrahiert und so lange hintereinander in dei Bitmap geschrieben, bis die Anzahl (6. Byte im Paket) erreicht ist.

3. Paket: Nur einzelne Pixel,
Datenformat: 3 Byte Offset (22 Bit), 2 Byte Farbe
wie gehabt, Offsetadresse ermitteln (Bit 22 und 23 sind NICHT gesetzt!), und extrahierte Farbe in die Bitmap schreiben.

Der Server schickt natürlich nur diejenigen Pixel, die sich während 2 Frames geändert haben, wenn sich wenig bis garnichts ändert, sind die Daten entsprechend gering!

Uhhhhhh, bevor man die "rohen" Pakete bekommt, muß man natürlich die durch die zusätzliche Komprimierung verkleinerten Pakete entpacken.
Ich würde es daher zum Testen so machen, daß die Komprimierung (durch die Windowsfunktion _LZW_Compress() imho) erstmal im Server abgeschaltet wird. GGf gibts ja eine Java-Komprimierungsfunktion, die besteht dann sicher auch für Windows, diese könnte man dann einsetzen!

Hab leider zzt kein Internet/AutoIt, da weitab vom Schuss einquartiert, sonst hätte ich die Entpackungsfunktion mal in AutoIt geschrieben^^

Hi,
bin zzt. etwas weit ab vom Schuss, nächste Woche aber wieder öfter online. Da gibts dann auch eine "Speedversion" (ich werde den/die "externen" Packer _LZW_Compress() / Decompress ) komplett in SSE schreiben ggf doch auch mal den Huffmann-Filter probieren )
Dann braucht man die "externe" Windowsfunktion nicht mehr und ich kann mich mal im optimieren austoben....
Leider ist dann der Punkt erreicht, wo ich meinen liebgewonnenen PIII@1,2Ghz nicht mehr zum Testen nehmen kann *schnüff*, da SSE2 und SSE3-Befehle nicht unterstützt werden (wurden)

Zitat

Nachdem der Client connected ist, lässt der Server meinen CPU (leider noch Athlon X2) auf 40-50% laufen.

Da sollte auch noch was zu machen sein, auf meinem Stromspar-Athlon 4850 läuft der Server auch mit ~50%. Das liegt aber an der DO/UNTIL-Schleife im Server, die auf eine Antwort vom Client wartet , schreib da ein sleep() rein, oder besser, ich mach für die nächste Version ein "Minisleep" (irgendwo war da doch ein Script aus dem eng. Forum um kurze Sleeps zu machen...)
Selbst bei 1680x1050 braucht der Asm-teil zur Berechnung der Bilddifferenzen nur ~1 ms...daran liegts also nicht^^

Ja, den Handshake hab ich mir auch vorgenommen, da geht dann auch noch was (Übertragung während der Rechenzeit beim Packen spart bei Full-Video ca. 50-100ms/Frame! )
Weiterhin werde ich mal dem Protokoll per Wireshark auf den Pelz rücken, irgendwas ist bei der AutoIt-TCP-Übertragung faul, angeblich habe ich bei AutoItverbindungen über TCP wesentlich weniger Netzlast, was nur heissen kann, dass die Daten langsamer übertragen werden!? Kann das jemand bestätigen? Also als Test ein 100MB-File auf einen anderen Rechner per AutoIt-TCP dauert länger wie eine "Kopie" im Explorer.

Zitat

Ist es erlaubt euer Script umzuschreiben und in sein eigenes einzufügen, wenn man das Copyright dran lässt?

Ich spreche mal nur für mich....."wer soll dich daran hindern?"
Im Ernst, wenn du sinnvolle Erweiterungen einbaust, stell die Version irgendwo zur Verfügung (ggf auch an uns senden) damit alle davon partizipieren können!
Wenn das Script Teil eines größeren Projekts werden soll , um so besser...dann war die ganze Arbeit doch nicht für die Katz^^

Hi,

Zitat

Ach jetzt doch ?

leb mal 6 Wochen solo in div. Pensionen/Hotels ohne einen privaten Rechner, ohne i-net und rotiere 12h am Tag auf Arbeit...da kommste nach 2 Wochen zur Ablenkung auf Jogging und nach weiteren 2 Wochen tun sich im Kopf Algorithmen auf, wie man bestehende Scripte umbauen könnte^^

Zitat

Edit: Mache am besten direkt einen DllCall zu recv und setzte MSG_WAITALL

ja, gute Idee! Falls sich nicht bestätigt, daß MSG_WAITALL unter XP nicht funktioniert!

Wirklich interessant das Script.
Ich wollte etwas zum Thema Javascript-Client im Browser sagen.

Ich habe mich mal näher (anderes Projekt) mit Pixelakrobatik (Canvas) in Javascript beschäftigt. Die Performance ist schon überraschend gut, es gibt sogar Beispiele (für Firefox) wie mit Javascript Videostreams live verändert werden. Allerdings würde ich Javascript dennoch nicht die Dekodierung von Grafikdaten in dieser Form übernehmen lassen. Soo ideal ist das dann auch nicht.

Eine andere Möglichkeit wäre, die Grafiken in einem Standardformat zu übertragen, so daß diese von Javascript schlicht angezeigt bzw. in eine Canvas gerendert werden können. Das wäre z.B. PNG, wo man dann über die Transparenz/Alpha-Kanal die unveränderten Bildschirmbestandteile "weglassen" kann. Das würde natürlich die Server-Seite verkomplizieren.

Eine zweite Möglichkeit wäre, ein zusätzliches Programm für die Grafik-Übertragung zu verwenden. Mir fällt da spontan der VLC ein, welcher als Streaming-Quelle auch "screen" kennt. Der Browser könnte dann den Stream schlicht "abspielen". Javascript und dem Autoit-Server bliebe dann das Maus/Tastatur-Handling.

Steuerung ist in Ansätzen möglich, ich wurstele gerade an einer Impelmentierung von OpenCl (nicht Gl) in AutoIt, damit kann man die Datenkompression auf einer geeigneten Graka laufen lassen, das sollte die übertragenen Datenmengen nochmal reduzieren und somit schnellere Bildraten bringen....lasst euch überraschen...

Zitat von Andy

...lasst euch überraschen...

Auf jeden Fall

Hey hab mir die Teile mal gezogen und muss sagen Hochachtung, ist echt sehr gut gemacht vor allem die Kompression hat mich beeindruckt hab das auch mal versucht und bin kläglich gescheitert XD
Hab das Programm mit meinem Rechner und lappi übers Internet getestet und festgestellt dass es doch relativ unpraktisch ist, dass man beim "Server", der ja das Bild sendet, vorher noch Portregeln etc. erstellen muss, damit das übers Internet klappt. Ich selber kenn mich mit Tcp überhaupt nicht aus, aber es müsste doch möglich sein, den Verbindungsaufbau umzudrehen, damit ich als Helfer meine Portweiterleitung konfiguriere und derjenige der das Bild sendet nur meine Ip eingeben muss. Hintergrund ist natürlich dass ich Portregeln erstellen kann, der hilfesuchende damit aber meistens schon an den Rand des Wahnsinns gebracht wird.
Naja wollte nur wissen ob das prinzipiell möglich ist und wenn ja ob sich ein "TCP Pro" finden lässt, der das umstellen kann.

Siehe:
http://www.heise.de/security/artik…hen-270856.html
http://en.wikipedia.org/wiki/STUN
http://en.wikipedia.org/wiki/UDP_hole_punching
http://de.wikipedia.org/wiki/Stateful_Packet_Inspection

Natürlich gibt es noch andere Fernwartungstools, die entweder mit Proxies/Repeatern arbeiten (so daß beide Seiten NAT nutzen können) oder zumindest deren Serverkomponente aktiv Verbindung zum Fernwarter sucht und daher auf Serverseite kein Portmapping benötigt.
"Teamviewer" ist da recht bekannt, privat kostenlos nutzbar, beruflich so zwischen 500,- und 1000,-
Heise bietet eine vnc-basierte Lösung an: http://www.heise.de/netze/tools/fernwartung
Ich verwende ChunkVNC, welches mit einem Repeater/Proxy arbeitet: http://www.chunkvnc.com

(sorry für das Off-Topic)