DeskStream 2 Release Candidate 1.8

Hab ich das jetzt richtig verstanden? Wenn man auf UDP umstellt muss man nicht umständlich den Router konfigurieren?

"UDP Hole Punching" benötigt auch einen Server in der Mitte, nur läuft der Verkehr dann nach Verbindungsaufbau direkt zwischen A und B.

Zitat

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.

Zitat

Ich selber kenn mich mit Tcp überhaupt nicht aus, aber es müsste doch möglich sein, den Verbindungsaufbau umzudrehen,

Wir hatten den "Server" absichtlich auf die Seite desjenigen gelegt, dessen Bildschirminhalt dupliziert werden sollte.
Wer DeskStream installiert, schaltet die Ports frei bzw lässt explizit den Serverprozess zu.
Somit sind wir schonmal aussen vor, falls es um irgendwelche "Spionage- und Uberwachungsfunktionen" geht, die man mit Deskstream anstellen könnte.....soviel dazu.

Wer Lust hat, installiert den Server auf einem 24/7-Online-Rechner und vermittelt nur die Clients untereinander. Dann ist das Thema Ports/NAT Geschichte (so wie bei Teamviewer o.ä. ).
"Pro"-Kentnisse sind fürs Programme(um)schreiben sowieso erforderlich

Zitat

ist echt sehr gut gemacht vor allem die Kompression hat mich beeindruckt

Die vorliegenden ASM-Anteile reizen die CPU schon aus, mehr ist (pro Thread) nicht drin....jedenfalls nicht mit dem bisherigen minimalen Aufwand!

Das Ende der Fahnenstange ist allerdings nicht erreicht, nochmal 20-30% verlustfreie Komprimierung sind drin. Die dazu nötigen extrem aufwändigen und damit rechenintensiven Verfahren sind mittels OpenCL in den Griff zu bekommen. Die Kernel dazu sind schon fast fertig.....
Leider eignen sich die gängigen Kompressionsverfahren nicht sonderlich gut für parallel-processing, daher ist etwas Gehirnschmalz erforderlich....und das ist Altersbedingt bei mir zzt. in anderen Dingen investiert

Zitat

man is das ding schnell...

für "normale" Desktops mit einigen Fenstern und überwiegend statischem Inhalt reicht die Lauflängenkodierung und meine gebastelte "Kompression" völlig aus.
Auf einem 08/15-Rechner läuft die Analyse auf Bildunterschiede und Kompression in nicht mal 5 Millisekunden, der Rest ist der Datenübertragung geschuldet, im internen Gigabit-Netz merkt man absolut keine Verzögerung.
Bei Internet mit DSL 6000 kann man von 10MBit ausgehen, auch dafür reicht es aus, bei Video-Übertragung muss man einfach extrem große Datenmengen bewegen, da kommt man schnell ans Limit.

Zitat

habs mal mit tcp geschrieben... viel zu lahm..
dann udp... schneller, aber hatte keine vergleich- oder zoom-funktion drin...

Wir verwenden die Standard-AutoIt-TCP-Funktionen, da gibts auch nicht viel zu beschleunigen. Was in AutoIt Zeit kostet, also die Bild-Unterschied-Analyse und Kompression dieser Daten ist ja in einer Handvoll Bytes in Assembler implementiert. DAS kostet in AutoIt ziemlich viel Zeit

Zitat

Es wäre geil, wenn du es irgendwie schaffen könntest, dass man den mauszeiger sieht...
Und: Maustaste gedrückt halten und dann "ziehen"... Markiert er dann mehrere Dateien..?

Keine Ahnung^^. Kommt auf die Geschwindigkeit der Übertragung an....da ich viele verschiedene Features und Versionen von Deskstream habe, aber mit Sprenger120 zusammen nur einige davon released habe, kann es sein, daß "klickziehen" funktioniert.
Aber das Protokoll ist ja einfach aufgebaut, das sollte jeder schnell erweitern können:
Gehaltene Maustaste auf dem Server registrieren, Koordinaten an den Klient übertragen und per Mausfunktionen anwenden.
Genauso überträgt man Tastaturanschläge und alles andere, was man auf Clientseite braucht, z.B. Ton für Voice-Übertragung oder Video-Ton (da würde ich aber eine "dicke" Leitung vorraussetzen, bzw. erstmal wie z.B. bei Youtube o.ä. die ersten 10 Sekunden vorpuffern)

Wieso dll´s?
In Scite F1 drücken um die Hilfe aufzumachen, mit ALT+s den Reiter "Suchen" aktivieren, dort *mouse* ins Inputfeld eingeben, unten den Haken bei "nur Titel suchen" reinmachen und dann auf den "Themen Auflisten"-Button klicken.....
Die dann erscheinenden Maus-Befehle geben alles her, was du brauchst, sowohl auf Server, als auch auf Client-Seite!

grüß dich,
wenn ich den client starten will bekomme ich folgende meldung :

D:\Autoit\Deskstream\Client.au3(24,39) : ERROR: $WM_EXITSIZEMOVE previously declared as a 'Const'.
Global Const $WM_EXITSIZEMOVE = 0x0232
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
D:\Autoit\Deskstream\Client.au3 - 1 error(s), 0 warning(s)

eine idee an was das liegt?
ich nutze die aktuelle version von autoit (3.8.8.0) und win7 x64

Zitat

eine idee an was das liegt?
ich nutze die aktuelle version von autoit (3.8.8.0) und win7 x64

daran wirds liegen...
Kommentiere die Zeile einfach aus im Script, die Konstante wird in einer include deklariert.

Btw, man kann die Scripte natürlich auch auf dem lokalen Rechner testen.
Den Server kompilieren und die SERVER.EXE starten und als IP die 127.0.0.1 (das ist localhost) vergeben
Den Client kann man dann aus Scite mit F5 starten, auch 127.0.0.1 vergeben, fertig.

ja super. nun funktioniert es wieder

danke

ich weiss nicht ob du dich noch daran erinnerst, aber wir hatten mal das vergnügen und ich habe mich bei deinem prog mit einigen zeilen coe bedient.
wenn ich nun mein tool laufen lasse und damit das Media Center im vollbild capture geht das. ich habe das nun mal mit deinem tool versucht und bekomme nur einen schwarzen fensterinhalt.

ich bin da ehrlich gesagt auch nicht mehr so drin wie vor nun fast 8 monaten. hast du eine idee warum das so ist?

Hi,
hat zwar nicht direkt mit DeskStream zu tun, aber was solls^^

Ich hab das in deinem Script verwendete Media-Center nicht, aber jedes andere Windows-Fenster geht ja auch^^
Habe dein Programm gestartet. Am Anfang ist bei mir auch ein schwarzes Fenster, bei dem von links nach rechts senkrechte weiße Streifen durchlaufen, ich tippe auf den vergrößerten Rand des Fensters.
Wenn ich einige der Tasten und auch die linke Maustaste aktiviere, erscheint plötzlich der vergrößerte Fensterinhalt in deiner GUI.

Das Fenster des Mediaplayer wird definitiv Fullscreen von DeskStream gecaptured und übers Netz übertragen, getestet bei XP32, Vista und Win7/64.
Das Betriebssystem von Client und Server waren dabei unerheblichl, d.h. jeder Server auf einem der BS hat mit jedem Client auf einem der anderen BS einwandfrei funktioniert.

Wenn ein Fensterinhalt allerdings in einem extra Framebuffer "an Windows vorbei" (über spezielle Treiber wie z.B. bei bestimmten Spielen oder TV-Programmen ) dargestellt wird, dann erhält man einen schwarzen Screen bzw einen schwarzen Fensterinhalt.

das verstehe ich nicht. ich möchte ja gern das deskstream das macht wie es bei meinem tool lokal auch geht.

hier läuft auf beiden rechnern win7, wobei das entfernte gerät die embedded version von win7 nutzt. das einzige was ich mir nun noch vorstellen kann ist das win7 embedded da irgendwas anders handhabt.
da muss ich doch glatt mal mein notebook aus der mottenkiste holen und gegentesten.

€dit:
auf meinem win7 notebook kommt das gleiche.

Bitte beschreibe nochmal genau, was du machen möchtest bzw. wie DeskStream bei dir arbeitet bzw. in der Kombination mit deinem Programm nicht arbeitet.
-Deskstream auf lokalem Rechner (s.Post 130)
-Deskstream im Netz
-Deskstream in Verbindung mit deinem Programm

ich möchte das media center oder eine seiner alternativen auf dem HTPC im vollbild laufen lassen und auf dem anderen rechner im netzwerk sehen was da gerade passiert.
da mein tool keine netzwerkkomponente hat, kann ich das damit natürlich nicht testen.
jedoch habe ich bei deskstream bemerkt das irgendwas die anzeige verhindert (schwarzes bild), wenn 2 monitore an einem rechner sind und das Media Center im vollbild auf einem der monitore läuft.
dies bekommt jedoch meines hin.

hoffe das ich es einigermaßen verdeutlichen konnte.

Ich versuche gerade vergebens beide Scripte auf Win7/64bit zum laufen zu bekommen.Unter XP/32 lief alles ohne Probleme.

Ich bastel mir per Build die .exe und setze zur Sicherheit "#AutoIt3Wrapper_UseX64=n".Der Server startet mit der Gui und verschwindet nach der Bestätigung der lokalen IP und des default Ports in der Systemtray.Sobald ich versuche mit dem Client zu connecten, crashed der Server mit einer Exception.Lass ich den Server auf einem zweiten lokalen XP/32bit Rechner laufen und versuche dann per Hamachi zu connecten, dann crashed auch der Client mit einer Exception.Zum Schluss hab ich dann beide .exe auf dem XP/32bit compiliert und per Kombatibilitätsmodus unter Win7 gestartet, jedoch ohne Erfolg.

Bei meinem Bruder seinem Win7/64bit funktioniert der Deskstream ohne irgendwelche Probleme.Ich muss dazu sagen, das ich einen zweiten Monitor angeschlossen habe um den Desktop zu erweitern.Ist es möglich das die Scripte mit einem Mehrmonitorsystem nicht klar kommen?

cu, Lesato!

Hi,
imho ist der 2-Monitor-Betrieb doch getestet....
Hatte mal mit Raupi (der hat mehrere Monitore am Start^^) eine Deskstream-Session ohne Probleme laufen!

Zitat von Minecraft-Sprenger

Wie sind die Macros @DesktopHeight und @DesktopWidth bei dir?

Die wird er kaum finden^^

Global $hDLL_User32 = DllOpen("user32.dll")
Global $VirtualDesktopWidth = DllCall($hDLL_User32, "int", "GetSystemMetrics", "int", 78) ;sm_virtualwidth
Global $zoom_w = $VirtualDesktopWidth[0]
Global $VirtualDesktopHeight = DllCall($hDLL_User32, "int", "GetSystemMetrics", "int", 79) ;sm_virtualheight
Global $zoom_h = $VirtualDesktopHeight[0]

im Serverscript ganz oben werden die Multimonitorsysteme auch mit abgefragt. GGF dort mal die Variablen ausgeben lassen...

Zitat von Lesato

Ich bastel mir per Build die .exe und setze zur Sicherheit "#AutoIt3Wrapper_UseX64=n".

Beim Debuggen ist es sinnvoll, nur EINS der Scripte zu kompilieren, und das andere dann per Scite/F5 laufen zu lassen. So kann man die Fehler direkt im Script lokalisieren.

Wenn auch die nichtkompilierten Scripte crashen, dann ist irgendwo der Wurm drin.
Wenn auf dem Rechner ein Debugger (Ida oder Ollydbg usw.) installiert ist, dann würde ich diesen mal auf den Fehler ansetzen, d.h. im Falle eines Crashes wird von Windows der Debugger gestartet und zeigt den Fehler an. Wenn das so ist, bitte mal eine Copy des Debuggerfenster-Inhalts posten!

Ich hab die Server.exe mal in Olly geladen:
http://imageshack.us/photo/my-images/688/deskstream.jpg/

Variablen:
$zoom_w = 2560
$zoom_h = 1024
@DesktopWidth = 1280
@DesktopHeight = 1024

Und noch ein par Details von Windows:
_____________________________________________________________
Problemsignatur:
Problemereignisname: BEX
Anwendungsname: autoit3.exe
Anwendungsversion: 3.3.8.1
Anwendungszeitstempel: 4f25baec
Fehlermodulname: StackHash_0a9e
Fehlermodulversion: 0.0.0.0
Fehlermodulzeitstempel: 00000000
Ausnahmeoffset: 0073b4d8
Ausnahmecode: c0000005
Ausnahmedaten: 00000008
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: 0a9e
Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
Zusatzinformation 3: 0a9e
Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789
___________________________________________________________

Der Server lief in Scite und endete mit folgender Zeile: ">Exit code: -1073741819"

cu, Lesato!