Créer un systeme de partage d'écran en Python / PHP

a marqué ce sujet comme résolu.

c'est tout con pourtant :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
import pickle
import time


def send(datas):
    socket.send(pickle.dump(datas), addr=('ip', port))


def diff(first, last):
    new = {}
    for i, (fpx, lpx) in enumerate(zip(first, last)):
        if lpx != fpx:
            new[i] = lpx


def screen():
    return lib.create_screenschot().get_pixels()


def start():
    s = screen()
    send(s)

    while True:
        d = screen()
        send(s, d)
        time.sleep(.30)
        s = d
+2 -0

@drulac: J'ai déjà fais un système qui consistait à prendre un screen toute les 2ms, puis qui supprime le fichier ainsi de suite.

Arckazur

Ne serais-ce pas un poil dangereux pour le disque dur ? Un SSD/clé USB/carte mémoire/tout ce qui est flash, pourrait par exemple très mal le vivre, car leurs nombres de cycles (écriture complète, puis formatage) sont assez faible, il est fort probable que l'on réduise leurs durées de vie fortement au bout de quelques heures/jours d'utilisations.

Et pour ce qui est d'un disque traditionnel, il risque d'être rapidement débordé.

+2 -0

Hello.

Au lieu de, comme le dit si bien @nohar, réinventer la roule, tu devrait utiliser une solution telle que gstreamer, qui te permet d'effectuer cela en quelques lignes. Tu peux regarder ce gist et t'en inspirer.

En te servant donc de quelque chose comme

1
2
3
4
gst-launch-1.0 \
        ximagesrc use-damage=false xname=/usr/lib/torcs/torcs-bin \
        ! videoconvert ! videoscale ! video/x-raw,width=1920,height=1200 \
        ! theoraenc ! oggmux ! tcpserversink host=127.0.0.1 port=8080

sous GNU/Linux, en replaçant ximagesrc use-damage=false xname=/usr/lib/torcs/torcs-bin par avfvideosrc capture-screen=true sous MacOS (a priori) ksvideosrc device-index=0 sous Windows. Ensuite, tu peux envoyer les événements (clics, mouvements de souris, etc.) en utilisant des outils dédiés.

À noter que ce n'est peut-être pas la solution ultime. Mais je ne connais pas plus.

Juste une note à côté: c'est bien joli de vouloir faire ça, mais en dehors de l'intérêt technique (que je ne vois pas énorme), il y a beaucoup de précautions à prendre au niveau de la sécurité et il faut être bien à propos pour avoir des performances correctes. Je ne te conseille par conséquent de ne pas te lancer dans un projet tel — sans vouloir te démoraliser —, surtout qu'il existe déjà des solutions efficaces dans ce domaine. De plus, je ne sais pas très bien d'où vient cette volonté de tout transformer en application web, mais ici, l'intérêt est très limité, encore plus dans le sens où tu seras obligé de passer par un serveur central, qui fera du transcoding, et devra offrir des performances importantes (et donc coûteuses), afin de faire communiquer le client et le serveur, alors qu'une solution applicative n'aurait pas ce défaut.

De plus, je ne sais pas très bien d'où vient cette volonté de tout transformer en application web, mais ici, l'intérêt est très limité, encore plus dans le sens où tu seras obligé de passer par un serveur central, qui fera du transcoding, et devra offrir des performances importantes (et donc coûteuses), afin de faire communiquer le client et le serveur, alors qu'une solution applicative n'aurait pas ce défaut.

dab

Il existe des lib Web pour éviter de passer par un serveur. Les websockets pour du texte, ou, pour du media, WebRTC à la rescousse. Exemple qui fait ça.

Et pour ce qui est de la démocratisation des apps web, je trouve ça tout à fait normal : pour convaincre le consommateur, entre installer un logiciel et tester une démo directement depuis le navigateur, je sais ce qu'il va choisir. C'est plus simple de séduire.
Aussi, ça simplifie la platforme : quand on a accès à internet, on peut utiliser le service, quelque soit l'appareil connecté utilisé.

Au cinoche, on a 24 images/seconde, on peut descendre aisément à 20 images/seconde, ça peut être largement suffisent !

qwerty

Au cinéma les images sont adaptées pour avoir quelque chose de fluide avec 24 images par seconde, de même pour les 25 à la télévision. Si tu mes en pause sur une image en particulier, tu vois bien que l'image n'est pas nette, et que tu y trouves une impression de mouvement.

Avec 20 images nettes par seconde, tu n'auras pas quelque chose de fluide, mais la fluidité n'est pas forcément nécessaire.

Il existe des lib Web pour éviter de passer par un serveur. Les websockets pour du texte, ou, pour du media, WebRTC à la rescousse. Exemple qui fait ça.

Non. Les WebSockets font une connexion persistante entre le client et le serveur, ça n'a rien à voir. WebRTC ou, fait ce que tu décris, mais il s'agit d'un draft, ce qui signifie que cela ne sera pas disponible avant longtemps dans certaines entreprises.

Et pour ce qui est de la démocratisation des apps web, je trouve ça tout à fait normal : pour convaincre le consommateur, entre installer un logiciel et tester une démo directement depuis le navigateur, je sais ce qu'il va choisir. C'est plus simple de séduire.

C'est une vision très naïve de la chose, oui.

Aussi, ça simplifie la platforme : quand on a accès à internet, on peut utiliser le service, quelque soit l'appareil connecté utilisé.

Non, c'est loin d'être vrai. Tous les services ne sont pas adaptés à tous les supports, notamment téléphones et tablettes rendent inutilisable certains logiciels. Et encore une fois, je suis navré, mais ces appareils ne sont en général pas conçus pour réaliser ce genre de tâches, à quoi bon s'évertuer à y arriver ?

Et encore une chose, cela fonctionne tout aussi bien avec de l'applicatif, modulo une installation supplémentaire.

Peut-être que l'on peut arrêter le hors-sujet ici ?

+0 -0

Non. Les WebSockets font une connexion persistante entre le client et le serveur, ça n'a rien à voir.

Exactement. Le serveur peut très bien être le PC de celui qui stream, vu qu'il recherche apparemment un usage perso.

WebRTC ou, fait ce que tu décris, mais il s'agit d'un draft, ce qui signifie que cela ne sera pas disponible avant longtemps dans certaines entreprises.

Encore une fois, usage perso. L'OP n'est clairement pas à la recherche d'une solution professionnel.

C'est une vision très naïve de la chose, oui.

Ce genre d'argumentation m'aide clairement à comprendre ton point.

Non, c'est loin d'être vrai. Tous les services ne sont pas adaptés à tous les supports, notamment téléphones et tablettes rendent inutilisable certains logiciels. Et encore une fois, je suis navré, mais ces appareils ne sont en général pas conçus pour réaliser ce genre de tâches, à quoi bon s'évertuer à y arriver ?

Et encore une chose, cela fonctionne tout aussi bien avec de l'applicatif, modulo une installation supplémentaire.

Un stream video sur un site web, n'importe quel téléphone récent peut le lire.

Peut-être que l'on peut arrêter le hors-sujet ici ?

C'est vrai qu'on ne parle plus trop du sujet initial, on peut arrêter.

Ce n’est pas Tleb qui voulait faire ça, et l’auteur ayant posé sa question il y a un peu plus de deux ans et supprimé son compte depuis, je doute qu’il réponde.

Cela dit si ça t’intéresse, tu peux toujours poser tes questions sur un autre sujet (en n’oubliant pas de lire les réponses de celui-ci avant pour éviter de se répéter).

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte