Ich habe schon verstanden, der Speicher ist zu groß. Eventuell könntest du aber so dein Problem ein wenig beheben. Die Methode von Mogel ist natürlich sehr geniall. Bzw. hast du deine Frage im Falschen Unterforum glaube ich (was ja erstmal egal ist).
natürlich nicht - so in etwa funktionierte aber der C# Code
du musst auch immer durch alle Pixel durch - wie willst Du sonst feststellen ob sich was zum vorherigen Screenshot geändert hat? Es geht um die Laufzeit und die ist bei mir Konstant - egal wie viel sich Subframes sich ändern - also O(n) und nicht O(n²) oder schlimmer.
Naja, ich überprüfe es per Hash^^
Das multithreading geht jetzt auch bei 16-32 Threads ne cpu auslast von 12-15^^
Emm kennst du oder ein anderer ein guten Algo. fürs Komprimieren ? Ich möchte mit den Bytes so weit wie möglich runter gehen^^
Dann solltest du einen verlustreichen Codec benutzen, z.b. hoch komprimiertes JPEG. Allerdings kannst du dann natürlich Artefaktbildung bekommen.
Naja ich benutze ja im Moment JPEG^^
Meinst du mit Artefaktbildung diese Bild Fehler, die so ähnlich sind wie von meinem Screenshot ?
Die habe ich ziemlich häufig leider, nur ich weiß nicht genau woher die kommen. Ob die jetzt von JPEG oder so kommen ka…also am senden liegt es nicht^^
Weil das mit der Byte Größe die gesendet wird, ist halt das größte Problem grade 
wozu?? wenn Du einmal über alle Pixel gehst und einen einfachen IF-Vergleich machst, verbrauchst Du weniger CPU Leistung als wenn Du das Ganze nochmal durch eine Hash-Berechnung jagst. Selbst CRC8 ist Rechenlastiger (und nicht Aussagekräftig) als ein IF Vergleich
ja - es gibt zwei Arten zu komprimieren. Verlustbehaftet, z.B. JPEG oder nicht Verlustbehaftet, wie BMP mit Lauflängen Kodierung (welche kaum [eher nie] benutzt wird). Bei den Verlustbehaftet Komprimierungen wird dann bei der Rekonstruktion auf Grundlage von mathematischen Formeln geschätzt was da mal war.
Naaj der Hash zieht keine Rechenleistung. Ich habe ja geschrieben das es jetzt bei 16-32 Threads mit 13cpu auslast läuft 
Mit komprimieren meine ich nicht das Bildformat, sondern die Bytes die gesendet werden müssen.
Meine beiden Probleme sind halt nur noch Bildfehler und die Größe der Packets
Du rechnest mit Luft?!
was meinst Du wie wenig Auslastung du hast, wenn Du Hash nicht mehr verwendest
ein ZIP wird nicht noch kleiner wenn es nochmal gezippt wird
Naja meine beiden Hauptprobleme sind aber immer noch die von eben und
ich Komprimiere es bis jetzt aber noch nirgendswo nochmal^^(Das Format zähle ich nicht mit, da es Standard ist)
Meine beiden Probleme sind halt nur noch Bildfehler und die Größe der Packets
Dann wirst du wohl auf Komprimierungsverfahren von Movie-Kompression zurückgreifen müssen VP1 z.B.
Mmm jo. muss ich wohl^^
Hat einer ne Idee wegen den Bildfehlern ?
Wenn die beim Server ankommen sind die so (Hab die Bilder abspeichern lassen und alle durchgeschaut…also an Graphics oder Image in pb setzen liegt es nicht^^)
Ist jetzt eig. nur noch das letzte große Problem, da es sehr oft kommt 