Rediriger la sortie image/audio d'une fenêtre avec des sockets

[invite083844da]

Bonjour,

Avec mon équipe, nous sommes en train de travailler sur un projet raspberry et nous bloquons sur un point.
Comme le titre l'indique, nous voudrions rediriger la sortie image/audio d'une fenêtre vers un autre PC en se servant des sockets.
La communication désirez entre les PCs est le wifi ou le HDMI.

Petit détail qui peut être utile, le projet est réalisé avec l'aide de raspberry pi 3B.
On cherche une solution dans n'importe quel langage de programmation. Le plus simple est le bienvenue ^^

Merci d'avance pour votre aide.
-----

[Jack]

WiFi ou HDMI, ça n'est pas vraiment la même chose. Quant à utiliser une socket sur du HDMI, je n'en ai encore jamais entendu parler

Pourquoi vouloir réinventer la roue? VNC ne suffirait-il pas?

[Ikhar84]

En passant, capturer "le son et l'image" d'un pc, renvoyer le tout à un autre pc par "socket": on a là une bonne base d'un RAT...
Pas sûr qu'on puisse donner un code qui fasse ça ici.

Manquerait plus qu'à capturer le clavier et la souris...

[invite083844da]

Bonsoir Jack et ikhar, Veuillez m'excuser pour le retard.
On va ouvrir plusieurs fenêtres sur le premier PC et transmettre l'image d'une fenêtre vers un autre PC par le biais du wifi ou du HDMI.
Le PC N°1 doit pouvoir transmettre une fenêtre au PC N°2 par le biais du wifi et également transmettre une autre fenêtre au PC N°3 par le biais du HDMI, etc....
Toutes les fenêtres sont générées par le PC N°1 et ce sont des fenêtres qui affichent différentes choses.

[A voir en vidéo sur Futura]

[Jack]

Bon courage alors, parce que je n'ai aucune idée de la faisabilité de ce que tu cherches à faire.

[Ikhar84]

Au lieu de "transmettre une fenêtre" d'un pc à l'autre... ce qui ne veut rien dire... le soft lancé sur le pc1 transmet les données qui seront traitées/affichées sur une nouvelle fenêtre sur le pc cible.

Ce serait plus simple...

Sinon habituellement, on capture l'ecran d'un pc et on envoies cette capture sous la forme d'un flux vidéo (stream) ou une suite de photos (ce qui revient au même avec suffisamment de photos/secondes).
Et ca demande pas mal de ressources en temps cpu, ram et bande passante...

Tu veux faire quoi exactement ?
C'est quoi tes fenêtres ?
Qui a écrit tes softs (accès aux sources ?) ?
Etc...

[invite083844da]

Salut,
Le PC1 est un serveur. Le jeu est installé sur sur ce serveur et également tous les données des joueurs.
Le PC2 récupère le son et l'image de PC1 pour jouer son perso dans le jeu.
Le PC3 récupère un autre son et une autre image de PC1 pour jouer son propre perso dans le jeu.

En fait c'est le PC Shadow que je veut faire. C'est un serveur qui lance le jeu et qui permet de jouer à plusieurs.
Il y aura donc génération de plusieurs flux audio et vidéo par PC1. Et transmettre ces différents flux à PC2 et à PC3.
PC2 et PC3 ne font que récupérer le flux audio et vidéo.

Je sais pas si j'ai réussi à me faire comprendre.

[Ikhar84]

Donc on doit ne pas emettre de flux audio-vidéo depuis le serveur, mais chaque pc s'occupe de son propre joueur tout en envoyant les données au serveur, qui lui les "broadcats" à tous les clients, charge à eux d'intégrer les autres joueurs dans sa propre scène.

C'est pas très clair, mais j'ai eu une grosse journée

[pm42]

Donc on doit ne pas emettre de flux audio-vidéo depuis le serveur, mais chaque pc s'occupe de son propre joueur tout en envoyant les données au serveur, qui lui les "broadcats" à tous les clients, charge à eux d'intégrer les autres joueurs dans sa propre scène.

Pour moi c'est clair mais il semble que falbayrak veuille construire un jeu en réseau sans connaitre les architectures habituelles. Faire ce qu'il décrit existe nécessite beaucoup de puissance coté serveur qu'il n'a pas, n'est pas une bonne solution sauf dans des cas particuliers (jeux en streaming sur le Net).
Quand à l'utilisation de l'HDMI, je ne vois pas ce qu'elle vient faire.

[Ikhar84]

Ben si chaque pc fait sa tambouille dans son coin, et que le serveur stream une fenêtre sans aucun rapport avec chacun des joueurs, il va pas aller très loin !

Et l'HDMI devient la grande mode ces derniers temps sur Futura. Comme le dev de jeux d'ailleurs...

Edit: ok je viens de saisir, il veut refaire une sorte de serveur X mais en mode graphique multi utilisateur...

[invite6486d7bd]

Google prévoit déjà ce nouveau système multijoueur pour dans quelques mois.
On pourra même jouer depuis son smartphone.

[invite083844da]

L'informatique n'est pas du tout mon point fort, je le reconnais. Je tente d'aider deux informaticiens qui m'ont rejoins pour réaliser le projet.
Voici la console que je veux réaliser : http://www.lilazo.com/wazo-fr

Le raspberry pi ne sert qu'à réaliser un mini prototype afin de présenter le concept au public.
Je sais que cela demande pas mal de boulot.

Au cas où je me répète, l'objectif est de réaliser un serveur (console) capable de faire tourner un jeu (multi), envoyer l'image ou le son par wifi (ou hdmi)et recevoir les requêtes des autres appareils connectés (PC, etc...). Rien n'est installé sur les appareils connectés (PC, etc...) à part une application pour lire le jeu en streaming.
Pour l'instant, on se limite aux PCs. Plus tard, on passera aux autres appareils (téléphones, tablettes, etc...)

On peut faire un skype (furkan.albayrak13) pour en discuter plus amplement.

[pm42]

Donc vous demandez du financement à des souscripteurs et ensuite notre aide gratuite ?
Sans être capable de préciser que le HDMI va vers une télé ?
Et en annonçant vouloir streamer des jeux mais en ne sachant pas comment envoyer image et son vers une autre machine ?

C'est beau de ne douter de rien mais perso, j'arrête là.

[invite083844da]

Salut pm42,
Le site date de 2 ans.
J'ai dû mettre le projet en attente pour différente raisons (argent / travail / famille).
Avec mon ancienne équipe, on réalisait la partie communication et la partie prototype en parallèle pour être prêt le jour J.
Le responsable des deux parties m'ont menti du tout au tout depuis le début. Pour la partie communication/commercial, il m'a fait dépenser des trucs qui n'ont pas du tout été utile. Pour la partie prototype, l'ingénieur m'a raconté que des bobards sur l'avancé du projet. Son objectif n'était que de soutirer un peu d'argent.

Bref du coup, j'ai apporté quelques modifications au site avant de le laisser à l'abandon (pour l'instant) et fermer la société que j'avais créer.
Je ne demande rien au souscripteur, je veux créer cette machine une bonne fois pour toute parce que ça pèse sur ma conscience.

[invite44510b00]

Bonsoir Jack et ikhar, Veuillez m'excuser pour le retard.
On va ouvrir plusieurs fenêtres sur le premier PC et transmettre l'image d'une fenêtre vers un autre PC par le biais du wifi ou du HDMI.
Le PC N°1 doit pouvoir transmettre une fenêtre au PC N°2 par le biais du wifi et également transmettre une autre fenêtre au PC N°3 par le biais du HDMI, etc....

Les ports HDMI des PC ne sont pas des ports d'entrée (même si il y a - ou il y a eu- quelques rares exceptions); vous pouvez oublier.

Par ailleurs, le choix que vous exposez enter Wifi et HDMI tend à laisser penser que votre conception est à ce stade totalement inexistante (autant dire que parler du langage à envisager est , disons, totalement prématuré - pour rester correct).

Si vous pouvez utilisez le Wifi, pourquoi ne pas faire simplement du remote control/export display (via VNC -comme déjà suggéré-ou autre) du R-Pi via le PC .

EDIT : j'ai répondu sans avoir lu le reste du fil; ce que je viens de faire. Ce que j'ai écrit fait donc un peu double emploi.

[invite6486d7bd]

Une des problématique, est qu'on peut bien sûr envisager de récupérer les données qui sont dans la mémoire employée pour l'affichage, pour "une fenêtre", et de les envoyer via le réseau à une autre fenêtre.
La puissance du serveur limite sévèrement cette méthode qui ne présente aucune optimisation.

Mais, si ça peut fonctionner, peut-être simplement, avec de l'affichage, sans avoir à gérer la chose au niveau applicatif (le jeu), ça ne fonctionnera pas de la même manière pour le son.
Il n'y a pas de "fenêtre son" et les données relatives au son ne sont pas stockées par fenêtre.

Si plusieurs joueurs sont gérés sur le serveur, pouvant donner lieu à une fenêtre par joueur, le son, lui, sera global.
Il faut donc prendre en compte cette particularité au niveau de l'application (jeu), sans parler du fait qu'il est inutile d'envoyer l'ensemble des sons vers la carte audio du serveur.

[Ikhar84]

Imagines seulement 200 clients/joueurs...

[invite6486d7bd]

Imagines seulement 200 clients/joueurs...

Si vous êtes allé voir le site, il s'agit en fait de faire jouer 4 joueurs maximum.

Mais vous avez raison, car même comme ça, si on veut faire tourner de la 3D (qui nécessite environ 60 images/seconde), ça va poser des problèmes de performance, aussi bien dans le traitement que dans la transmission des données "brutes" (si on considère qu'on a affaire à des séquences d'images).
Mais si on se limite à des jeux plus "statiques", comme par exemple un jeu de stratégie par tour, le projet est réalisable.

[invite083844da]

Bonsoir Fustigator,
Au lieu de tourner en rond, j'aurais dû parler directement du projet pour nous éviter de mélanger les pinceaux.
Le port HDMI du serveur ne sert qu'à transmettre l'image et le son du jeu sur un téléviseur. Il sera donc utilisé en sortie.
Le wifi sert pour la communication entre le serveur et les appareils connectés (PC, smartphone et tablette). Il y aura un échange dans les deux sens (vidéo/son pour l'un et consigne pour l'autre).
Par le biais de python, on a déjà réussi la partie serveur/client entre un PC et un raspberry. On a fait le test avec la webcam du pc. Lecture en temps réelle sur le raspberry du flux vidéo. L'objectif à présent, c'est d'inverser les rôles (raspberry = serveur & PC = client) et multiplier le nombre de client. Si on trouve un autre langage de programmation permettant de faire le travail tout en optimisant, on n'hésiterait peut être pas à changer. On ne ferme pas la porte à d'autres langages de prog.
Si le raspberry n'est pas assez puissant, on peut faire un cluster.
L'idée du VNC est bonne, mais perso je ne vois pas comment faire pour envoyer différentes images vers différents clients sans faire tourner plusieurs fois le même jeu.

[invite083844da]

Salut LeMulet,
Ca ne serait pas mieux de récupérer les données de la taille d'affichage du client et de générer une fenêtre au bonne dimension sur le serveur avant de l'envoyer au client.
Pour la puissance du serveur, on peut soit faire un cluster avec plusieurs raspberry, soit acheter mini pc plus puissant. L'objectif n'est pas de faire tourner des jeux 4k ou HD (pas pour l'instant). Si on arrive à faire tourner des jeux N64, ça serait super ^^
Prenons une console assez connu du public : la WII U. Comment elle arrive à transmettre le son et l'image au gamepad (connecté en wifi à la console) ? Elle est optimisé à 59 images/secondes d'après internet et le son est plutôt bon.
On peut pas associer le son et l'image avant de le transmettre au client ??? Comment le PC ou la console transmettent ces informations ? ça dépend du jeu et non des machines ?
J'aime bien l'idée du jeu statique.

[invite6486d7bd]

Le port HDMI du serveur ne sert qu'à transmettre l'image et le son du jeu sur un téléviseur. Il sera donc utilisé en sortie.

D'accord, et pour être sûr de comprendre, je vais reformuler ce que j'en comprend.

Le "serveur", qui fait tourner le jeu, peut envoyer "le point de vue" du premier joueur (qui est en même temps le joueur qui invite les 3 autres (ou plus ?) joueurs à se joindre à la partie), vers son propre téléviseur.
Les données comprennent l'image et le son.

La connexion HDMI est prise en charge par le Système d'exploitation du "client" (Le serveur est aussi un client, suffit que le jeu envoi les données réseau à sa propre adresse, comme si il était un client réseau, à mon avis, il va les garder en loopback).
Il suffit d'envoyer le stream vidéo vers une fenêtre, et l'image et le son sont transmis comme à l'accoutumé, automatiquement vers le périphérique écran.

Rien à faire donc de ce côté.

Le wifi sert pour la communication entre le serveur et les appareils connectés (PC, smartphone et tablette). Il y aura un échange dans les deux sens (vidéo/son pour l'un et consigne pour l'autre).

D'accord.
Manque donc la partie communication périphérique du client (manette, clavier) vers le serveur, qui renvoi les données au jeu.
Ce qui serait bien, ce serait de définir des spécifications et une bibliothèque de fonctions (genre dll) à laquelle le programmeur du jeu peut faire référence.

Par le biais de python, on a déjà réussi la partie serveur/client entre un PC et un raspberry. On a fait le test avec la webcam du pc. Lecture en temps réelle sur le raspberry du flux vidéo.

Donc vous avez un flux vidéo (comprenant le son puisque produit par la webcam), qui transite bien vers une fenêtre située sur un appareil connecté, que l'on peut donc voir défiler en tant que client.

Mais vous n'avez pas encore défini la manière de créer ce même flux depuis le jeu.
De la même manière, il serait bon de créer des spécifications et une bibliothèque de fonctions auxquelles le programmeur du jeu pourra se référer.

L'objectif à présent, c'est d'inverser les rôles (raspberry = serveur & PC = client) et multiplier le nombre de client.

Ca, je ne comprends pas.
Pourquoi inverser les rôles ? Pourquoi il est tout à coup question d'un PC ?

Pour multiplier le nombre des clients, il suffit de le programmer au niveau du jeu, situé exclusivement sur le poste serveur.
Il produit les flux individuels (comme celui du joueur sur le serveur), et les envoi vers le client (ou vers lui-même, si c'est le joueur "maitre" ayant initié le jeu).

[invite6486d7bd]

Salut LeMulet,
Ca ne serait pas mieux de récupérer les données de la taille d'affichage du client et de générer une fenêtre au bonne dimension sur le serveur avant de l'envoyer au client.

Non, effectivement, à première vue, si vous arrivez à transmettre le flux sans ralentissement (faut voir évidemment lorsque plusieurs clients seront ajoutés), le gros du boulot est fait, et il serait bon d'exploiter cette piste.

Pour la puissance du serveur, on peut soit faire un cluster avec plusieurs raspberry, soit acheter mini pc plus puissant. L'objectif n'est pas de faire tourner des jeux 4k ou HD (pas pour l'instant). Si on arrive à faire tourner des jeux N64, ça serait super ^^

Rester avec du Raspberry me semble plus judicieux, d'autant que si vous avez vu les derniers modèles, ils sont déjà assez costauds.

Prenons une console assez connu du public : la WII U. Comment elle arrive à transmettre le son et l'image au gamepad (connecté en wifi à la console) ? Elle est optimisé à 59 images/secondes d'après internet et le son est plutôt bon.

Faudrait se renseigner.
Mais il ne faut pas oublier qu'une bonne carte graphique fait des miracles, surtout avec des shaders.

On peut pas associer le son et l'image avant de le transmettre au client ??? Comment le PC ou la console transmettent ces informations ? ça dépend du jeu et non des machines ?

C'est ça la question.
Vous avez apparemment mis en place un système qui permet de transmettre un flux vidéo.

Maintenant, il faut arriver à recréer ce même type de flux (que celui que la webcam a généré pour vous), depuis le jeu.
Il faut donc créer les fonctions accessibles au programmeur du jeu, pour lui permettre de créer ce flux.
Ca n'a donc rien à voir avec une simple capture d'écran (qui serait contreproductif, puisque le serveur n'a pas besoin d'afficher les écrans des joueurs additionnels).