Prise de contrôle à distance -> 3fps

Bonjours, alors voilà j'ai réalisé un programme de prise de contrôle à distance avec java se.

J'utilise la class Robot avec la méthode createCaptureScreen pour capturer l'image de l'écran. J'envoie alors en rafale (boucle infinie) chaque nouveau bufferImage retourné par la fonction pour "simuler" un flux vidéo. Puis j'envoie par socket ces images en rafale au client.

Seul problème j'envoie environ 190 images par minute, soit du 3 fps (image par secondes) en moyenne. (J'arrive a 1800 capture d'écran sans envoie par le réseau).

Comment faire pour obtenir un framerate convenable, c'est à dire minimum 24 images par secondes ?

De plus, avec la boucle infinie qui capture et envoie immédiatement les nouvelles images vers le client, la consommation CPU est très importante !!!

Bref comment faire pour corriger ces problèmes ?
Utiliser les socketChannel au lieu des socket traditionnel apporte t-il vraiment des gains en performance ?
Comment font les programme type VNC pour obtenir un taux aussi élevé en image par secondes ? Peut être utiliser le protocole UDP mais je suis pas sure que cela améliore les performances, car il me faudra vérifier dans tout les cas l'intégrité des données reçu chez le client avant d'afficher l'image via le GUI.

La fonction createCaptureScreen fait des appels systèmes d'après ce que l'on ma dit, et donc rend le processus long.Dois-je utiliser jni pour accéder à l'api win32 pour faire moi même l'appel à une fonction système pour capturer l'écran ?
Je pense que ca reviendra au même...

Comme vous le comprenez, je dois non seulement parer ce problème de performances minables, tout en gérant les ressources CPU qui sont énorme.

Si vous avez des idées, merci d'avance pour votre aide ;)

1024*768*3*8*24 = 432 Mbits,
Il va falloir compresser les données si vous voulez un débit correct.

1024*768*24bits*24images/secodes = 432 Mbits,
Il va falloir compresser les données si vous voulez un débit correct.

Bonsoir et merci pour votre réponse, j'ai fait une compression comme vous me l'avez suggéré. Je la fait avant l'envoie, puis la décompression a lieu chez le client à la réception.
J'ai obtenu un gain de 20 images par minute soit du 0.333 fps :cry:
Voici le code utilisé pour la compression:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public byte[] compressData(byte[] data) throws IOException{ Deflater compressor =new Deflater(); //essayé aussi avec Deflater.BEST_SPEED compressor.setLevel(Deflater.BEST_COMPRESSION); compressor.setInput(data); compressor.finish(); ByteArrayOutputStream bos =new ByteArrayOutputStream(data.length); byte buf[] =new byte[4096]; int n; while(!compressor.finished()){ n =compressor.deflate(buf); bos.write(buf, 0, n); } bos.close(); return bos.toByteArray(); }

---

Je désespère, je ne vois pas du tout comment faire.

Pourtant, les autres logiciels de prise de contrôle à distance, type VNC, etc, fonctionne très bien, il doit bien avoir moyen de résoudre ce problème de lenteur et de surconsommation du CPU. :?

Merci dans tout les cas pour l'aide apporté. Si vous avez d'autres idées, je suis preneur !

ben oui, ces outils travaillent directement avec la couche système. Quand on déplace une fenêtre, ils envoient, en gros, au client "déplacement de cette zone de X pixels vers la droite et vers la haut" de même quand une fenêtre se redessine, il n'envoient que les zones redessinée.Bref au lieu de tenter d'envoyer X screenshot par secondes, ils s'orientent vers les transfert des événements sur la couche réseau, ce qui est plus performant.

Citation:

---

Envoyé par vieks

Bonsoir et merci pour votre réponse, j'ai fait une compression comme vous me l'avez suggéré. Je la fait avant l'envoie, puis la décompression a lieu chez le client à la réception.
J'ai obtenu un gain de 20 images par minute soit du 0.333 fps

---

Une simple compression de type gzip ne fera pas gagner énormément en taille. il vaut mieux utiliser une compression adaptée aux images telle que le png ou le jpeg disponible via la classe ImageIO.

Citation:

---

Envoyé par tchize_

ben oui, ces outils travaillent directement avec la couche système. Quand on déplace une fenêtre, ils envoient, en gros, au client "déplacement de cette zone de X pixels vers la droite et vers la haut" et même quand une fenêtre se redessine, il n'envoient que les zones redessinée.

---

Il me semble que VNC n'envoie pas des événements système, Il arrive a se débrouiller en envoyant des fragments d'image.
Donc ca doit être réalisable en Java. Il faudrait analyser les différences entre l'image capturée et la précédente pour déterminer les zones à redessiner et n'envoyer que celles ci.

il les traduits dans des actions basées uniquement sur les images. Mais juste faire des screenshots à l'aveugle n'est, je pense, pas suffisant et surtout pas performant. Analyser 24 fois / seconde une image de 1280x1024, ca va mettre le processeur sur les genoux. D'ailleurs les implémentations performantes de serveur VNC injectent des modules dans Xorg sous linux.

Pour jouer encore sur la vitesse brute, sans autres optimisation, il ne faut pas oublier que la plupart des client de ce type permettent de reduire le nombre de couleurs ... ce qui permet deja de gagner pas mal (genre diviser par 3 le debit en utilisant 8 bit au lieu de 24 pour les couleurs)...

Ensuite oui, il faut analyser les changements entre les images pour ne pas devoir reenvoyer toute la frame a chaque fois. (Donc envoyer un ou des petit carré qui ont changés)