DeskStream 2 Release Candidate 1.8

Hi,
bissl was zur Technik bzgl "Kompression".
Zur Zeit ist nur eine SEHR einfache, und demnach kurze Kompression implementiert.
Die Bandbreite der Netzwerkverbindung ist wie üblich, der massgebliche Faktor! Je weniger Bytes übertragen werden müssen, desto besser!

Angefangen hatte es mit einem Vergleich zweier aufeinander folgender Screenshots Pixel für Pixel.
Die Farbe des geänderten Pixels wurde zusammen mit der Position (Adresse) des Pixels einfach aneinandergehängt, und vom Server zum Client geschickt. Dort wurde das geänderte Pixel einfach an die übertragene Adresse geschrieben. Das Datenaufkommen war daher pro geändertem Pixel 32 Bit für die Farbe und 32 Bit für die Adresse, also insgesamt 64 Bit. Wurden mehr als 50% der Pixel geändert, wurde die komplette Bitmap gepackt und verschickt.

Die 64 Bit pro geändertem Pixel habe ich folgendermassen reduziert:
Angenommen, die maximale Grösse für einen Bildschirmscreen ist 2048x2048 Pixel, das wären 2^11 mal 2^11 = 2^22 Pixel.
Die grösste Adresse wäre also 2^22, also in 22 Bit darstellbar. Die Farbe besteht aus 4 Byte AARRGGBB. Der Alphakanal ist unnötig, klasse, schon mal ein Byte weniger! Durch den "Steganographie"-Thread inpiriert, habe ich die niederwertigsten Bits pro Farbe einfach gestrichen. Das führt dazu, dass Rot=5 Bit, Grün=6 Bit und Blau=5 Bit gross ist. Insgesamt also 16 Bit für RGB.
22Bit Adresse und 16Bit für die Farbe sind 38 zu übertragende Bits/Pixel, gegenüber den 64Bit pro Pixel am Anfang eine Einsparung von 40%!

Das ist zzt. der Stand der Dinge, allerdings ist, da jedes geänderte Pixel für sich übertragen wird, seitens der Pixel noch garkeine Kompression vorhanden.
Die einfachste Methode ist, aufeinanderfolgende gleichfarbige Pixel zusammenzufassen:
100 gleichfarbige aufeinanderfolgende Pixeln benötigen jetzt 100x5Byte, also 500 Byte.
Wenn man nun die Anzahl der Pixel in einem Byte zählt, und zusammen mit den 5 Bytes Farbe und Adresse verschickt, reduziert sich so die Datenübertragung von 500 Byte auf 6 Byte....nicht schlecht für den Anfang.
Besser wird es, wenn man 2 Pixel betrachtet, und zählt, wie oft diese Kombination nacheinander vorkommt. Dann bekommt man mit einem Byte als Zähler nicht nur 255, sondern 510 aufeinanderfolgende Pixel übertragen, mit dem Vorteil, dass auch 2 unterschiedliche Pixel (und Pixelfolgen) erkannt werden. Das macht u.a. bei den Scrollbars von Fenstern Sinn, denn diese sind "gerastert" aus einem Dunklen und einem Hellen Pixel.

Die Geschwindigkeit bzw die Kompression ist noch gewaltig zu erhöhen, jedenfalls bei "normalen" Fensterinhalten. Wenn allerdings ein extrem schnell geschnittenes Video übertragen werden soll, bieten sich andere Verfahren an....wir bleiben dran!

Zitat

ggf. Sollte man noch Pixel die sich ähnlich sind einfach mitzählen.

das wird ja automatisch erledigt, wenn die 16Bit- statt 32Bit-Darstellung des Pixels verwendet wird!

Eine weitere Idee, die du relativ einfach umsetzen kannst! Bei der Betätigung vom Mausrad im Clientfenster wäre es schön, wenn sich der Fensterinhalt bis auf die Orginal-Auflösung vergrösser würde, man hätte so zwar nur einen Bildausschnitt, aber der wäre dafür 1:1

/Edit/ weiterhin wäre es sinnvoll, wenn der Server bei einer verlorenen Clientverbindung aktiv bleibt und auf den nächsten connect wartet

Zitat

funktioniert der server nun nichtmehr da mir ein include file fehlt

welches include fehlt?

Das AssembleIt-include kannst du auskommentieren, die brauchst du nur, wenn du am Assemblercode etwas ändern willst, ansonsten auch einfach die Funktion SetInfo() komplett auskommentieren, aber wenns dich interessiert, HIER der Link...

Rechtsklick --> Run/Compile Script (x86)
oder an den Anfang vom Script
#AutoIt3Wrapper_usex64=n
setzen

@sprenger, die maximale Structgrösse steht ja Aufgrund der Auflösung fest!
Und die Länge der zu komprimierenden Daten wird ja vom Assembler in $bytes zurückgegeben.
Also reiss trancexxens Funktion in kleine Stücke und bau was passendes!

/Edit/ hatte dir ein Update der Server-ASM geschickt....