25 Screenshots pro Sekunde

[kurtm1]

Hallo!

Hat irgendwer eine Idee wie ich realisieren könnte, dass pro Sekunde 25 Screenshots meines Desktops gemacht werden? (Die werden dann noch verkleinert und komprimiert)

thx

[MasterC]

:shock:

Mach doch gleich ein Video. :wink:

[Binärbaum]

Wofür baruchst du denn 25 Screenshots in der Sekunde?
Das wäre vielleicht machbar, aber wenn ein Programm damit beschäftigt ist, jede Sekunde 25 Scrennshots zu machen (und wahrscheinlich auch noch auf der Festplatte zu speichern), geht das doch auf die Performance des gesamten Systems.

MfG
Binärbaum

[Aenogym]

Zitat:

Zitat von MasterC

:shock:

Mach doch gleich ein Video. :wink:

ich denke, er will genau dies tun. nur weiß ich dazu jetzt auch nichts. eine suche hier in der DP könnte evtl. ehelfen.

Aenogym

[kurtm1]

Das würde ich eben gerne herausfinden, ob es möglich ist dass ein Programm so schnell arbeitet.

Auf der Festplatte speichern würde ich nicht, da ich die Bilder dann gleich direkt übers Netzwerk an andere PC`s verschicken würde


//EDIT: Letztendlich soll daraus mal ein Programm werden, das sozusagen einen Bildschirm auf einen anderen PC klont

//EDIT2: Das versenden wäre kein Problem, aber primär geht es jetzt mal drum die Screenshots zusammenzubringen

[retnyg]

wenn ich mich recht erinnere kannst du dir mit GETDC(0) das Canvashandle des desktops holen welches du dann z.b. mit copyrect in ein tbitmap laden kannst.

aber wenn du zu faul bist das selber umzusetzen empfehle ich dir eine suche mit google - stichwort screenshot + delphi

[malo]

Dazu gab es mal einen Thread, such doch mal danach. Da wurde auch haargenau erklärt, wie wenig es möglich ist, soviele Screenshots in so wenig Zeit zu machen. Ob hinterher eine Lösung gefunden wurde, weiß ich nicht ;)

[kurtm1]

Screenshot prozeduren habe ich schon genügend gefunden, derzeit rätsle ich nur noch daran wie ich eben genau die 25fps erreichen kann

[Ultimator]

Aber dein Netzwerk kann nur so schnell übertragen, wie die Festplatte deines Gegenübers ist ;-)
Außerdem brauchts halt RAM anstatt von Festplattenplatz.
Und wenn dem PC der RAM zu voll wird, lagert Windows das auf die HDD aus -> Langsam. ;-)

Ich vermute einfach mal, dass es nicht schneller geht, als es gleich auf die Festplatte zu speichern ;-)

[Kidix]

es würden doch auch 2 in der sek reichen odeR?

[Luckie]

Ich würde eher sagen, dass das Problem die Übertragung über das Netz ist bzw. das Umwandeln in eine JPEG und dann das Komprimieren des selbigen. das braucht Zeit, nicht der Screenshot selber. aber das haben wir im Forum schon oft genug diskutiert. Benutz mal die Suche.

[malo]

Zitat:

Zitat von Kidix

es würden doch auch 2 in der sek reichen odeR?

Da würde das Bild aber stark stottern ;)

Hab übrigens den Thread gefunden: http://www.delphipraxis.net/internal...ght=screenshot

Allerdings steht keine Lösung dafür drin :(

[Garfield]

Es gibt Programme, die den Bildschirm 'abfilmen' können. Ich hatte mal eine Freeware gesehen, das war ein Fenster mit durchsichtigen Hintergrund, um einen bestimmten Bereich 'abfilmen' zu können. Der Author hatte es für Kundendienstzwecke geschrieben.

[kurtm1]

keine lösung das ist immer schön..

[kurtm1]

Gibts vielleicht wen, der mit mir eine Lösung suchen möchte?

[Luckie]

Du kannst deinen letzten Beitrag auch editieren. :warn:

[Tubos]

Kein gutes Fernwartungsprogramm macht 25 Screenshots pro Sekunde und schickt noch dazu ständig den kompletten Screenshot.
Übertragen werden sollten nur die Änderungen.

[retnyg]

nimm einen timer der auf 40 ms eingestellt ist. der macht dann immer einen screenshot. was soll daran schwer sein ?

[Aenogym]

Zitat:

Zitat von kurtm1

Gibts vielleicht wen, der mit mir eine Lösung suchen möchte?

ja, der hier hilft meistens dabei.

Aenogym

[Stanlay Hanks]

Zitat:

Zitat von retnyg

was soll daran schwer sein ?

Dass es imho schwer sein wird, in so kurzen Abständen Screenshots zu erstellen.

[kurtm1]

@Aenogym *gg* toller Einfall

Das mit den 40ms Timer funzt nicht, da die meisten Prozeduren viel zu langsam sind

[retnyg]

Zitat:

Zitat von kurtm1

Das mit den 40ms Timer funzt nicht, da die meisten Prozeduren viel zu langsam sind

dann schreib deine prozeduren halt in assembler :twisted:

[Binärbaum]

Wenn du innerhalb von 40 ms einen Screenshot machen willst, ihn in JPG umwandeln willst und dann noch per Netwerk verschicken willst, hat dein Computer ziemlichen Stress. Wenn dazu auch noch im Hintergrund ein Prozess (Virenscanner, oder ähnliches) und/oder eine größere Anwendung läuft, dürfte es fast unmöglich sein, all das in so kurzer Zeit zu bewältigen. Deshalb sollte man lieber überlegen, ob es nicht auch reicht, wenn man nur 10 fps hat. (oder weniger)

MfG
Binärbaum

[kurtm1]

ja das wäre auch schon mal ein anfang. Die fps kann man dann ja noch nachregulieren

[Binärbaum]

Ich wollte damit nur sagen, dass es schwierig wird, soviele fps als Screenshot in so kurzer Zeit zu verarbeiten. Wenn man die Framerate herabsetzen würde, wäre es meines Erachtens wesentlich leichter (und vor allem auch auf langsameren Rechnern machbar).

MfG
Binärbaum

[kurtm1]

ja ist klar. um mal den Anfang zu machen müsste ich einmal ein wirklich sehr schnelle Screenshot prozedur finden

[malo]

Zitat:

Zitat von Binärbaum

Ich wollte damit nur sagen, dass es schwierig wird, soviele fps als Screenshot in so kurzer Zeit zu verarbeiten. Wenn man die Framerate herabsetzen würde, wäre es meines Erachtens wesentlich leichter (und vor allem auch auf langsameren Rechnern machbar).

MfG
Binärbaum

Genau. Um ein "bewegendes" Bild zu erhalten sollten 12 Bilder / sek reichen, um das Bild flüssig laufen zu lassen 18 Bilder / sek. Aber mehr sollten es wohl nicht sein, da das menschliche Auge eh nicht viel mehr Bilder in einer Sekunde warnehmen kann :zwinker:

[kurtm1]

ok umso besser.

Dann braucht man ja "nur" mehr eine Screenshot Prozedur die sehr schnell geht

[Binärbaum]

Zitat:

Zitat von malo

Zitat:

Zitat von Binärbaum

Ich wollte damit nur sagen, dass es schwierig wird, soviele fps als Screenshot in so kurzer Zeit zu verarbeiten. Wenn man die Framerate herabsetzen würde, wäre es meines Erachtens wesentlich leichter (und vor allem auch auf langsameren Rechnern machbar).

Genau. Um ein "bewegendes" Bild zu erhalten sollten 12 Bilder / sek reichen, um das Bild flüssig laufen zu lassen 18 Bilder / sek. Aber mehr sollten es wohl nicht sein, da das menschliche Auge eh nicht viel mehr Bilder in einer Sekunde warnehmen kann :zwinker:

Um genau zu sein: bei mehr als 18 Bildern pro Sekunde merkt das menschliche Auge keinen Unterschied mehr, da die Lichtreize noch etwa 1/18 Sekunde nachwirken. Wenn man also auf ein Bild schauen würde und urplötzlich auf einen schwarzen Bildschirm umschaltet, "merkt" das das Auge erst nach 1/18 Sekunde (hab ich mal von einem Mediziner gehört bzw. gelesen).

MfG
Binärbaum

[generic]

mach dir doch bitte nochmal gedanken über die datenmenge die du bearbeiten willst.

bei einer auflösung von
1280*1024=1310720 Bildpunkte
1310720*4=5242880 (32bit Farbtiefe=4 Byte)
5242880*25fps=131.072.000 Byte/sec

du willst also 131MB pro Sekunde verarbeiten.
ein aktueller PC schaft ca. 2000 mb/s (dual channel)
eine scsi-festplatte ca. 150 MB/s
ein 100MBit Netzwerk aus Erfahrung ca. 7 MB/s.

demnach wirst du deine 131 MB/s auf unter 7 MB/s komprimieren müssen.

Jetzt zu der CPU Power, du willst 131 MB/s aus dem Videopuffer kopieren, Komprimieren und dann noch zur Übertragung aufbereiten.
1 Terraherz Rechner werden erst in 24 Jahren auf den Markt kommen :-(

[mschaefer]

Moin, moin

also Bildübertragung über Netz ist wohl das eigentliche Thema.
Ziel soll hier wohl sein, eine möglichst ähnliche Darstellung zum überwachten Rechner zu bekommen.

Unter TurboPascal konnte man direkt auf Vidooram zugreifen. Ähnlich wird hier der Weg auch sein
(Das Thema Treiberprogrammierung hatten wir aber schonmal). Letztlich wird man das letzte Ramabbild
im Rechner halten und die Differenz zum akutellen ermitteln. Jetzt muß man entscheiden ob es günstiger
ist, das Differenzbild oder das neue Vollbild zu komprimieren (Heuristik). Das Komprimat wird
dann verschickt. Das dürften wohl wesentlich weniger Daten sein als die 25 Einzelbilder. Wenn keine
Änderungen am Quellbildschirm gemacht werden, dann wird eben nichts übertragen. Altes Bild bleibt.
Festplatte ist übrigens nicht relevant, wenn es nur eine Überwachung oder Fernwartung ohne Speichern sein soll, wie bei vnc. Und das läuft bei Farbreduktion klasse, sogar noch mit ISDN über Internet. Das sowas nicht im Netz zum laufen zu bringen ist, da glaube ich nicht dran. Auch Pascal ist eigentlich flott genug dafür. Die Direktspeicherzugriffe und die effiziente Komprimierung sind da ein markantes Problem.

// Martin

[elliot2extreme]

Hallo zusammen,

es gab mal ein Fernwartungsprogramm, welches in Delphi entwickelt wurde. Von diesem wurde auch der Quellcode veröffentlicht. Vielleicht kann dies bei der Lösung des Problems behilflich sein.

Webseite des Autors: www.netcontrolme.de hier gibt es auch den Sourcecode.

Gruß

[Neutral General]

Ich hab selbst mal sowas gemacht und ich kann nur davon abraten :mrgreen:
Nach etwa spätestens 10-20 sek ist ein WIRKLICH GUTER PC in den Knien.
Jedenfalls wars bei mir so. Und dann noch übers Netzwerk......
Naja ich weis nicht ob das überhaupt möglich ist oder ob ich einfach nur wie immer vergessen hab Sachen freizugeben, die dann den Arbeitsspeicher zugemüllt haben ^^

[Tubos]

Zitat:

Nach etwa spätestens 10-20 sek ist ein WIRKLICH GUTER PC in den Knien.

Warum nach der Zeit??

Zitat:

Naja ich weis nicht ob das überhaupt möglich ist oder ob ich einfach nur wie immer vergessen hab Sachen freizugeben, die dann den Arbeitsspeicher zugemüllt haben ^^

Daran wird´s liegen ;)

[kurtm1]

naja so ein Programm wäre auf jeden Fall vielleicht einmal ein Gemeinschaftsprojekt wert

[Binärbaum]

Zitat:

Zitat von kurtm1

naja so ein Programm wäre auf jeden Fall vielleicht einmal ein Gemeinschaftsprojekt wert

Ja, vielleicht wäre das besser.
Allerdings stellt sich anhand der obigen Beiträge die Frage anders:
Wenn solche Überwachungsprogramme auch über ISDN funktionieren, muss man das Programm so einrichten können, dass es nur ein Minimum an Daten verschickt und trotzdem ein möglichst genaues Abbild des zu überwachenden Computers gibt. Die Frage ist, wie geht das?
Dazu müsste man zuerst platzsparende Grafikformate zur Übertragung wählen (z.B. JPG statt BMP). Als nächsten Punkt könnte man, wie schon oft erwähnt, die Framerate runtersetzen. Dabei könnte man soweit gehen, dass man nur ein neues Bild überträgt, wenn sich auf dem Bildschirm auch wirklich etwas verändert hat.
Man könnte es auch auf die Spitze treiben und selbst bei Veränderung des Bilschirms nur die Teile des Bildschirmscreenshots übertragen, die auch verändert wurden. Allerdings dürften das ohne Komprimierung in den meisten Fällen auch noch zu viele Daten für eine ISDN-Verbindung sein. Deshalb könnte man auch einen abgeänderten Ansatz für die Grafikübertragung verwenden: statt die Grafiken als Pixelgrafiken zu übertragen, könnte man auch auf so eine Art "Pseudo-Vektorgrafik" umsteigen. Dabei werden nicht die neuen Screenshots verschickt, sondern nur solche Anweisungen wie "Zeichne in der oberen rechten Bildschirmecke den Mauszeiger neu" an den entfernten Computer geschickt, der diese Anweisungen dann in seinem Programm ausführt und somit das Bild aktualisiert.
Das hätte mehrere Vorteile: zum einen würde sich das Transfervolumen nochmals stark verringern; und zum anderen würde der Rechenaufwand beser auf beide Rechner verteilt werden und es somit auch möglich, dass das Programm auf langsamen Rechnern noch halbwegs flüssig läuft.
Das sind jetzt nur ein paar Gedanken von mir, und ich habe auch keine Ahnung, wie das in den oben angesprochenen Programmen realisiert wurde. Also sagt mir, wenn ich hier nur Unsinn geschrieben habe, aber vielleicht hilft es dem einen oder anderen weiter.

MfG
Binärbaum

[Wheelie]

Zitat:

Zitat von generic

mach dir doch bitte nochmal gedanken über die datenmenge die du bearbeiten willst.

bei einer auflösung von
1280*1024=1310720 Bildpunkte
1310720*4=5242880 (32bit Farbtiefe=4 Byte)
5242880*25fps=131.072.000 Byte/sec

du willst also 131MB pro Sekunde verarbeiten.
ein aktueller PC schaft ca. 2000 mb/s (dual channel)
eine scsi-festplatte ca. 150 MB/s
ein 100MBit Netzwerk aus Erfahrung ca. 7 MB/s.

demnach wirst du deine 131 MB/s auf unter 7 MB/s komprimieren müssen.

Jetzt zu der CPU Power, du willst 131 MB/s aus dem Videopuffer kopieren, Komprimieren und dann noch zur Übertragung aufbereiten.
1 Terraherz Rechner werden erst in 24 Jahren auf den Markt kommen :-(

Zur Farbdefinition reichen immer noch 3 Bytes (RGB): 1280 * 1024 * 3 = 3.932.160
15 FPS reichen denke ich auch völlig aus: 3.932.160 * 15 = 58.982.400

-> unkomprimiert also rund 60 MB/s, da du jedoch auch einen Screenshot dieser Auflösung nicht als Bitmap im Forum posten würdest, fällt das Datenaufkommen durch die Komprimierung jedes einzelnen Frames viel geringer aus. Im 100MBit-Netzwerk dürfte das alles sicherlich auch machbar sein. Trotzdem wäre eine auf tatsächliche Bildveränderungen basierende Lösung viel besser.

[Binärbaum]

Zitat:

Zitat von Wheelie

...
Zur Farbdefinition reichen immer noch 3 Bytes (RGB): 1280 * 1024 * 3 = 3.932.160
15 FPS reichen denke ich auch völlig aus: 3.932.160 * 15 = 58.982.400

-> unkomprimiert also rund 60 MB/s, da du jedoch auch einen Screenshot dieser Auflösung nicht als Bitmap im Forum posten würdest, fällt das Datenaufkommen durch die Komprimierung jedes einzelnen Frames viel geringer aus. Im 100MBit-Netzwerk dürfte das alles sicherlich auch machbar sein.

Trotzdem ist das noch zuviel, selbst für ein Netzwerk, bei 100MBit müsste man die rund 60MB auch noch auf 7-8 MB komprimieren. Deshalb ist die Idee mit dem (vollständigen) Screenshot also nicht das Wahre.

Zitat:

Zitat von Wheelie

Trotzdem wäre eine auf tatsächliche Bildveränderungen basierende Lösung viel besser.

Meine Rede :wink:

[maynard]

Tach...

Ich hab mir auch mal so ein Capture Tool geschrieben. Ich denke den Screen in einzelne (Rechtecke sind vorzuziehen) Bereichen einzuteilen, daran kommst du nicht vorbei. Je nach Leistungsfähigkeit des CPUs hab ich "Rechteck - Auflösung" eingestellt.

Einfach die die Hashwerte der neuen Bildbereiche mit den Werten des Alten abgleichen, die entsprechenden Teile senden und das neue Bild als altes Bild zwischenspeichern. Is kein Hexenwerk. Die Idee wie Binärbaum mir den "Pseudovektorgrafiken" hatte ich auch, wusste aber noch nicht genau wie ich das gut umsetzen kann.

Also auf meinem damaligen P4c Northwood und einem 100MBit LAN waren 12 - 18 Bilder pro Sekunden eigentlich drin ... halt zu Lasten des Hauptspeichers, der reichlich vorhanden sein sollte, weil sonst das Programm ausgebremst wird... die zu übertragende Datenmenge wird ja durch die Einteilung verringert. Komprimierung hilft auch, dauert aber etwas und bewirkt daher eine Verzögerung, heißt es kann passieren, dass der Client mit den Abspielen schon merklich hinterher is.

Viel Spass beim basteln ... hat mir richtig Spaß gemacht!

[supermuckl]

kann es sein, das man die repaint anforderungen von windows an die programme per hook oderso abfangen könnte und somit genau auf die repaint canvas'e zugreifen könnte und dann genau weis, welche bereiche neu gezeichnet werden(wurden) um so eine gezieltere direktere überwachung auf eine bild-veränderung zu realisieren ?

ich denke nicht, das VNC und konsorten haufenweise screenshots machen und die vergleichen (wie auch immer)

ich denke, da ist irgendwas angezapft, da wirklich haargenau die bereiche gerefreshed werden, die auch neu gezeichnet wurden via message
das kann man an den alten VNC versionen in kombination mit einem 10mbit halfduplex lan sehr gut beobachten :)

auch von einer framerate kann hierbei wohl nicht gesprochen werden, da es ereignisgesteuert ist, und keinen konstanten refreshzyklus hat.