Journal Jouer à distance avec du logiciel libre

Posté par  . Licence CC By‑SA.
9
7
avr.
2021

Bonsoir'nal.

Je cherche à pouvoir jouer, depuis un ordinateur sous GNU/Linux (ou Busybox/Linux), à des jeux tournant sur un autre ordinateur sous GNU/Linux.

Je suis intéressé par un logiciel libre, ou au moins un protocole ouvert et documenté sur lequel il serait possible de développer un logiciel libre.

Spoiler: Je n'ai pas encore trouvé de solution, mais je me suis dit que partager mes tentatives pourrait intéresser quelqu'un·e.

Un peu de contexte

Il y a quelques temps, j'ai reçu une Odroid Go Super. Il s'agit d'une console de jeux portable sur laquelle il est possible de faire tourner une système d’exploitation de son choix, généralement construit sur du Busybox/Linux. Généralement, elle est utilisée pour faire tourner de l'émulation. Je me suis dit que je pourrais enfin jouer à mes jeux vidéos préférés (Minetest, SuperTuxKart) depuis mon lit.

Malheureusement, l'Ordoid Go Super est un peut limité coté ressources. Si des jeux 2D peut gourmand fonctionnent bien, la 3D atteint vite une limite.

Pour contourner cette limitation, j'avais dans l'idée de faire tourner mes jeux sur mon PC et de les contrôler, les voir et les entendre depuis l'Ordoid. J'ai donc regardé les protocoles que je connaissais pour faire quelques testes, avant de choisir quel logiciel utiliser.

VNC

C'est le premier protocole que j'ai testé, car c'est un des plus vieux que je connaisse et il existe pleins de logiciels qui l'implémentent. Mais c'est aussi le premier que j'ai abandonné car il a 2 problèmes majeurs: Le nombre d'image par seconde trop bas et d'absence de synchronisation verticale.

Je n'ai pas cherché plus loin, car ces 2 problèmes sont bloquant. Je n'ai donc pas regardé la questions de la latence ou celle du support des manette coté client.

SPICE

SPICE est un protocole utilisé pour partager le bureau d'une machine virtuelle vers un client. Le client peut tourner sur le système hôte ou sur une machine distante.

SPICE propose plusieurs fonctionnalités intéressantes:
- Support de l'audio et de la vidéo
- Communication chiffrée
- Redirection USB
- Compression de l'image

SPICE est principalement utilisé dans le domaine de la virtualisation, mais il existe quand même un serveur utilisable hors virtualisation:
Xspice

Il s'agit à la fois d'un serveur X et d'un serveur SPICE. Malheureusement, il semble avoir des problèmes de performance. Je n'ai pas encore eu le temps de tester et de voir plus loins.

Du coté client, il existe le client virt-viewer ainsi qu'un widget GTK.

Je n'ai pas encore eu le temps de voir plus loin, notamment si le protocole permet d'avoir un faible latence, un nombre d'images par secondes > 30 et une syncro verticale. Mais ça semble plus prometteur que le VNC.

Waypipe

Waypipe est un logiciel permettant, sous Wayland, de partager des fenêtres pour un accès à distance via SSH. Comme ce qui existe sous Xorg avec ssh -X.

Il s'agissait d'un projet pour le GSOC 2019. Manuel Stoeckl, son auteur, à également écrit un rapport très détaillé. Waypipe est encore développé et est présenté comme relativement stable.

Je n'ai pas encore eu le temps de lire le rapport, mais utiliser cette solution pour jouer à distance semble faisable. Par contre, il faudra trouver une autre solution pour l'audio.

La suite

J'hésite entre Waypipe et SPICE. J'ai encore pleins de testes à faire et de documentations à lire, mais ça me semble faisable.

Et toi, lecteur, aurais-tu des propositions ?

  • # VirtualGL

    Posté par  . Évalué à 5.

    https://www.virtualgl.org/

    C'est du X11 à distance mais le rendu 3D est effectué sur le serveur puis envoyé au client sous forme d'images.

    • [^] # Re: VirtualGL

      Posté par  . Évalué à 3.

      Pour la 3D, ça fonctionne bien, je l'utilise souvent pour faire de la visualisation à distance (paraview).
      Par contre, pour le son je ne sais pas comment ça se passe.

  • # Xpra

    Posté par  . Évalué à 2.

    Ça fait longtemps que je ne l'ai pas testé, mais xpra, semble prometteur.

    • [^] # Re: Xpra

      Posté par  . Évalué à 3.

      Je ne l'ai pas précisé, mais xpra s'occupe aussi de l'audio, la compression, la synchro…

    • [^] # Re: Xpra

      Posté par  (site web personnel) . Évalué à 2.

      J’ai utilisé xpra pour du jeu vidéo déporté, il y a un paquet d’années. De mémoire il en était encore dans une version 0.17.x.

      Sur des jeux ne nécessitant pas de réactivité, comme des jeux en tour-par-tour à la Heroes of Might and Magic, il a même réussi à être surprenamment utilisable à travers un ADSL de campagne rachitique (parfois aussi lent que ~50ko/s).

  • # Audio et bureau distant

    Posté par  . Évalué à 1. Dernière modification le 08 avril 2021 à 09:45.

    tu peux tenter la diffusion via le réseau de pulseaudio. Par contre ça risque d'être désynchronisé.

    J'ai testé XRDP pour de la bureautique, je trouve que ça marche bien même si derrière c'est du VNC. je ne sais pas si sous le capot XRDP optimise VNC. Par contre le transfert des disques locaux et du presse papier marche bien. L'audio semble aussi fonctionner mais il faut installer un complément.

    Il y a aussi le RGS d'HP. Les clients sont gratuits, le serveur est offert si tu possèdes un HP série Z (je ne connais pas le tarif sinon). Ce qui est mon cas au boulot. C'est sensé être optimisé pour les solutions gourmandes en graphisme comme la CAO( SolidWorks pour moi). Les clients et serveurs existent pour Linux et Windows. Je trouve que ça marche plutôt bien, entre mon domicile et le travail.

    Comme tu le vois, je cherche aussi des solutions dans le domaine, je n'ai pas de contrainte au niveau des performances pour le jeu, je cherche surtout quelque chose de complet pour la bureautique et la CAO.

    Du coup merci pour Xspice que je ne connaissais pas ! Je vais enfin pouvoir tester.

  • # Faire le rendu à distance sans problèmes de performance? Compliqué...

    Posté par  . Évalué à 2.

    Tout est dans le titre.

    Si le but est d'utiliser le GPU d'une machine distante, ça veut dire que les trames graphique de ton jeu doivent transiter directement sur le réseau, après "compilation" par OpenGL.
    Concrètement, avec mes écrans (de mauvaise qualité), j'ai une résolution de 1366*768 et 1280*1024, 32 bits par pixel, bien qu'utiliser que 24 ferais le job (utilisons ça pour l'estimation).
    Cela fait donc 3073.5 et 3840 kibioctets par trame.

    Supposons que l'on veuille 60 trames par seconde: ça donne 180 et 225 Mebioctets par seconde à transférer. Avec des écrans de merde.
    Alors, oui, on peu compresser, et gagner un peu de bande passante. Sauf que selon le jeu auquel tu joues, il ya des chances que tu ne gagneras pas tant que ça (les graphismes modernes sont parfois sublimes) sans perte de qualité.
    Au fait… les débit des réseaux sont indiqués en bits par seconde, multiplions donc par… 8: 1440 Mib/s et 1800 Mib/s. Je n'ai pas pris en compte les coûts inhérents aux protocoles (probablement négligeables), ici, uniquement le poids de l'affichage. Même avec une compression de 50% (pas impossible, en fonction du jeu, on peut même aller plus loin, beaucoup plus loin) cela restera extrêmement gourmand en bande passante: ton réseau pourra-t-il l'encaisser?

    Autre problème de performance, la latence: le réseau à une vitesse bien précise. Si tu as fibré entre tes machines, peut-être que c'est négligeable. Moi, ici, en wifi pour contacter la box (littéralement) derrière moi (pour des raisons de câble, je préférerai un bon ethernet mais… bref c'est pas le sujet) j'ai une latence de 130ms (c'est très surprenant d'ailleurs, je flaire le problème, je m'attendais à une poignée de ms, moins de 10).
    C'est évidemment un problème (selon les jeux), puisque même si tu envoies beaucoup de trames par seconde, tu auras un délai évident.
    Si en plus tu ajoutes de la compression pour avoir plus d'images, ben… tu augmentes tes délai, mécaniquement: il faut compresser, puis décompresser.

    Dernier point: l'usage d'un réseau implique de partager la ressource. À la fois avec les autres utilisateurs du réseau, mais aussi avec les autres applications de ton poste. Ce qui va ajouter à la charge de ton réseau, et ce, surtout si tu as des applications qui "découvrent automatiquement", comme des imprimantes, un partage de fichiers, etc… parce que cela fonctionne avec du broadcast, augmentant l'occupation du point central et polluant les ressources des autres machines (bande passante, temps CPU).

    Bref, pour jouer à un jeu en tour par tour, je pense que c'est faisable. Pour jouer à un RTS lent, peut-être. Pour un jeu nécessitant du réflexe et de l'adresse, c'est mort.

    • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

      Posté par  . Évalué à 5.

      Il semblerais que ce soit possible sinon steam link, shadow, geforce now, stadia, … n'existeraient pas.

      Par contre, c'est sûr, ça se limite à du casual gaming.

      • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

        Posté par  (Mastodon) . Évalué à 5.

        Par contre, c'est sûr, ça se limite à du casual gaming.

        Même pas. J'ai joué à "DiRT Rally" pour essayer Steam Link chez moi (mon PC calcule et mon smartphone sert d'écran et de manette), ça marche du tonnerre, tu es certain que c'est un jeu natif de ton smartphone.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

      Posté par  (Mastodon) . Évalué à 7.

      Supposons que l'on veuille 60 trames par seconde: ça donne 180 et 225 Mebioctets par seconde à transférer. Avec des écrans de merde.

      A se demander comment on peut regarder des films 4K en streaming…

      Shadow ? Stadia ? GeforceNow ça te parle ? Et crois-moi, c'est pas fait pour jouer au solitaire tout ça.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

        Posté par  . Évalué à 2.

        Shadow ? Stadia ? GeforceNow ça te parle ?

        Non, désolé.
        Du coup, tu pourrais expliquer dans les grandes lignes comment ça marche?

        Personnellement, je sais que, quand le serveur est un peu trop loin de chez moi, que je passe les 100ms de ping, je commence déjà à le ressentir. Alors c'est sûr qu'il reste de la bande passante de libre (enfin, quand mon FAI merde pas, mais quand il merde de toute façon même "un solitaire multijoueur" ça serait compliqué…).

        Je lis:

        Nvidia recommended a 50 Mbit/s internet connection for the 1080/60p stream, but the service can also stream at 720p/60p for 25 Mbit/s connections,

        ainsi que:

        720p (1280×720 px

        Effectivement, la compression semble impressionnante, sur le papier: le 720p se rapproche de mon écran le plus pourri, sans l'atteindre tout à fait (HD hein?). Par contre, ça consomme quand même du 25Mbit/s, même si mon FAI ne déconnait pas à bloc ces derniers mois, ça me serai impossible ici, et non, le 30 frames par seconde ne serait pas acceptable pour certains jeux.
        Faudrait que j'essaie, pour voir, je suis curieux de savoir à quel point elle l'est: lossless ou pas, pour commencer, et si sans pertes, alors à quel point la dégradation est sensible.

        Et malgré la lecture de l'article nvidia, je n'ai toujours aucune idée des contraintes techniques. Est-ce que le jeu est compilé avec le support d'une implémentation spécifique (voire propriétaire?) de sorte à ne faire que pré-calcul, plutôt que d'envoyer les trames brutes?

        Bref, non, je ne connais pas. J'aimerai bien connaître, au moins d'un point de vue technique.
        Du coup, j'aimerai bien que tu m'en dises plus, tu as l'air de considérer que tout ça est une évidence, et que ça s'applique donc à ce que n'importe qui peut se mettre en place chez lui… tu devrais pouvoir expliquer tout ça à l'inculte que je suis.

        • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

          Posté par  . Évalué à 3.

          Non, désolé.
          Du coup, tu pourrais expliquer dans les grandes lignes comment ça marche?

          Grosso modo (je connais surtout shadow), tu loues un PC à distance (c'est orienté gamer). J'avais entendu qu'ils avaient des difficultés financières.

          Par contre cela necessite bien d'avoir une co bonne et stable. Un de mes proches est abonné à ce service, le conseille que si tu es fibré. Shadow recommande au moins 15 Mbit/s en descendant et 5 MBtis/s en montant et un ping faible (30 ms)

          • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

            Posté par  . Évalué à 2.

            Même un ping inférieur à 40ms s'ajoutera à celui entre le moteur de calcul et le serveur du jeu… bon, ça, en vrai, ça peut faire gagner de la latence potentiellement.

            Je doute personnellement que ça soit "juste louer un PC chez le voisin", mais bon, peut-être…

            • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

              Posté par  . Évalué à 3.

              Je doute personnellement que ça soit "juste louer un PC chez le voisin", mais bon, peut-être…

              En fait dans le cas de shadow tu loues l'équivalent d'un PC qui se situe dans un datacenter. Idem pour la configuration hardware, tu loues l'équivalent d'une config si j'ai bien compris.

              Le datacenter de ton pc distant est très bien connecté à internet, et c'est surtout ta co qui va limiter.

        • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

          Posté par  (Mastodon) . Évalué à 7. Dernière modification le 09 avril 2021 à 10:43.

          Du coup, tu pourrais expliquer dans les grandes lignes comment ça marche?

          Basiquement, c'est la compression du flux vidéo en H264 ou H265 (qui fait bcp, bcp, bcp mieux que 50%). Donc c'est avec pertes, et en plus ils s'adaptent au flux pour être prêts à dégrader fortement l'image s’il le faut mais garder la réactivité.

          Ce sont les algos de compression de la TNT HD (et de la TNT 4K) et du BluRay donc même si c'est "avec perte", quand le débit le permet, le résultat est bon. Pour avoir vu tourner du Battlefield en fullHD, pas de pb de qualité, je te garantis.

          La TNT HD c'est entre 5Mb/s et 10Mb/s. Les fichiers de démo (donc peu compressés pour être bling bling) pour la TV 4K c'est moins de 100Mb/s : ma TV 4K n'a même pas de connexion Gigabit et ça marche très bien la lecture directe sur mon Kodi.

          que je passe les 100ms de ping

          100ms est considéré comme le max acceptable en effet. Mais en fait c'est pas trop le souci, ce serait plutôt la gigue (l'irrégularité du ping). En effet on s'habitue instinctivement à un petit décalage, mais si ça bouge tout le temps, c'est vite énervant.
          Mais en local où le ping est souvent de moins de 10ms (oui tu as un truc bizarre chez toi) et la gigue très faible c'est tout à fait utilisable. Et idem avec une connexion fibre pour un serveur à l'autre bout du monde (qui est le cœur du business model de ces plateformes, même si j'ai vu une démo tout à fait jouable sur un smartphone en WiFi avec un ADSL 40Mb/s)

          Est-ce que le jeu est compilé avec le support d'une implémentation spécifique (voire propriétaire?)

          Non, Shadow est un bon exemple : tu loues un PC avec Windows dessus est c'est tout. Tu y accèdes depuis n'importe où (j'ai un collègue qui en a un c'est comme ça que j'ai vu Battlefield) via différents moyens, dont ton smartphone. Tu peux installer ce que tu veux, Word comme le dernier jeu AAA. Donc les applis sont "normales".

          tu as l'air de considérer que tout ça est une évidence

          Pas la peine de le prendre comme ça… Mais démontrer en long et en large que c'est pas possible alors que en parallèle c'est la course (plus ou moins réussie faut être honnête) chez des gros mastodontes du jeu comme du cloud c'est toujours rigolo à lire :) Que tu n'y connaisses rien c'est pas grave, juste que tu pouvais éviter de répondre à côté de la plaque en étant aussi sûr de toi.

          et que ça s'applique donc à ce que n'importe qui peut se mettre en place chez lui

          Aujourd'hui, pas à ma connaissance mais je ne sais pas tout. Cela dit, les solutions étant uniquement logicielles, on peut très bien imaginer que ce soit un jour déployable par "tout un chacun" via des logiciels libres en prime.

          En tous cas tu peux dès aujourd'hui (sans dépenser un kopek) essayer Steam chez toi avec ton propre matos. Tu verras ça marche très bien.

          Reste à voir si il y a des solutions open source au moins en cours de développement, et il semblerait que oui (je tombe en 2mn sur ça par exemple https://gaminganywhere.org/index.html) comme quoi le mouvement est en marche :)

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

            Posté par  . Évalué à 2.

            Pas la peine de le prendre comme ça…

            En fait, c'est une question de ton et de contenu. D'autres ont répondu un contenu dans la même veine que toi, mais d'une autre façon.

            Je te remets ton message, que tu puisses bien avoir le contexte:

            A se demander comment on peut regarder des films 4K en streaming…

            Shadow ? Stadia ? GeforceNow ça te parle ? Et crois-moi, c'est pas fait pour jouer au solitaire tout ça.

            Voila. Je ne vois rien qui mérite sympathie la-dedans, contrairement au message auquel celui-ci répond. Ce n'est pas un problème, ça m'arrive moi aussi d'avoir ce type de réponses mais, quand on me répond sèchement, je ne suis pas surpris.

            Tu dis:

            juste que tu pouvais éviter de répondre à côté de la plaque en étant aussi sûr de toi.

            puis:

            Aujourd'hui, pas à ma connaissance mais je ne sais pas tout. Cela dit, les solutions étant uniquement logicielles, on peut très bien imaginer que ce soit un jour déployable par "tout un chacun" via des logiciels libres en prime.

            Oui, donc, du coup, c'est bel et bien "compliqué", de mettre en place une telle archi, non? Notamment avec du LL?
            Ce qui est ce que je disais, au final, ça fait même partie du titre.
            Ou alors, je me trompe sur la définition du mot "compliqué"?

    • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

      Posté par  (site web personnel) . Évalué à 5.

      Mouais ; j'ai déjà vu par exemple:

      • 2 streamers Twitch (un à Lyon, un en Belgique) jouer à un jeu 3D d'action (pas hyper récent hein, mais un jeu d'action, pas un jeu d'échec) conçu pour la coopération locale, mais le faire à distance avec le logiciel (malheureusement) propriétaire Parsec (qui fait ça, il streame le jeu qui tourne chez un des 2 joueurs pour l'autre joueur) et ça marchait plutôt bien. Et vu que derrière chacun streamait le jeu sur sa propre chaîne, leurs connexions devaient être bien sollicitées.
      • 1 streamer jouer à un FPS récent sur un PC Shadow ; il était lui même étonné de ne pas ressentir de latence.

      Donc oui, faire tourner un jeu en 4K sur un gros PC et le streamer pour une GameBoy à l'autre bout du monde via un modem 56K ça risque d'être compliqué. Et pareil, si tu fais partie des 0,1% de joueurs qui exécutent des manipulations "frame perfect" tu vas ressentir de la latence. Mais globalement on a dans l'absolu des moyens techniques pour jouer à distance sur un réseau local même à des jeux d'actions ; après existe-t-il des solutions libres actuellement pour le faire ? Je n'en suis pas sûr.

    • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

      Posté par  . Évalué à 4. Dernière modification le 08 avril 2021 à 15:03.

      tu augmentes tes délai, mécaniquement: il faut compresser, puis décompresser.

      Non pas forcément. D'abord il y a des circuits dédiés pour ça, ensuite le multi-cœurs et le multithread parallélisent en occupant le CPU/GPU sur des temps et des circuits qui seraient inoccupés. N'oublie pas que les entrées / sorties réseau (et pas que) sont plus lentes que ton processeur qui attend très souvent, il a donc du temps de calcul disponible (pour paraphraser l'ex-directeur de TF1).

      D'autre part VirtualGL (qui se base sur TurboVNC) est très efficace. J'ai vu une démo du temps du Linux Terminal Server Project dans laquelle ça jouait sans problème.

      • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

        Posté par  . Évalué à 1.

        D'abord il y a des circuits dédiés pour ça,

        C'est vrai.

        ensuite le multi-cœurs et le multithread parallélisent en occupant le CPU/GPU sur des temps et des circuits qui seraient inoccupés

        La plupart des jeux libres que je connaît sont incapables d'utiliser du multi-coeur CPU (ou alors, uniquement de manière très, très parcellaire)…
        BOn, ça implique qu'il y a toujours au moins un coeur qui glande, certes. Reste à voir si tout ça, c'est valable sur un "Ordoid Go Super". Itou pour son réseau, en fait, parce que selon ou l'on habite, le wifi peut être plus ou moins performant, et être une nécessité (location en ville).

        Je ne sais pas à quelle vitesse max ça va, cela dit, je n'ai même pas d'ordre d'idée.
        Il semblerait que l'on parle de 600Mbps pour le 2.5GHz et 1300Mbps pour 5GHz, sauf que mon, ce sont les valeurs maxi, j'imagine, en salle blanche? Parce que la dernière fois que j'ai testé un transfert de disque en conditions réelle, ça allait clairement moins vite que le bout de fil téléphonique que j'utilise en guise d'éthernet, bridé par un switch 10/100.

        Je ne connais pas les specs, mais je pressent l'ARM, qui de mémoire, à une puissance max par coeur moins élevée que l'x86_64?

        Du coup, même si certains ont soulevé de bon points, je reste sur mon opinion pour l'instant: Compliqué. Enfin, pour une "game-boy" ça devrais pouvoir se faire en effet (j'avais zappé cet aspect du journal lors de ma réponse).

        • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

          Posté par  (Mastodon) . Évalué à 5. Dernière modification le 09 avril 2021 à 11:13.

          Le but c'est que le PC joue au jeu (ça…) et en plus encode à la volée. Éventuellement avec de l'aide hardware (les cartes vidéos ont toutes maintenant de l'encodage hardware) mais même sans, ça ira (je mets bcp moins d'1h à encoder un film de 1h donc je dois pouvoir le faire largement en temps réel tout en jouant à TuxKart)

          Ensuite faut voir côté client de décompresser en temps réel.

          Là on est sur un Odroid, voyons voir son GPU https://www.hardkernel.com/shop/odroid-go-super-dim-gray/

          C'est un Mali-G31 MP2. Est-il capable de décoder du H264 en hardware ?

          En cherchant "Mali-G31 MP2 h264" sur Google je tombe sur une tv-box à base de Mali G31 MP2 capable de faire du 4K : https://fr.gearbest.com/tv-box/pp_009379058686.html => Je ne suis pas inquiet, tu vas décoder sans pb ton flux vidéos de 854×480 (résolution de l'Odroid).

          Donc en théorie, ça peut marcher sans aucun soucis.

          Reste à trouver le montage logiciel si il existe, et c'est l'intérêt de journal je pense, pas de démontrer que c'est pas possible avec des calculs plus ou moins fumeux.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Faire le rendu à distance sans problèmes de performance? Compliqué...

          Posté par  (Mastodon) . Évalué à 5.

          cela dit, je n'ai même pas d'ordre d'idée.

          ouais on l'a vu…

          au passage si tu veux faire des essais de vitesse réseau je te conseille de jouer avec iperf3. tu peux l'installer sur n'importe quel Linux, en serveur ou en client. de plus il existe des serveur publics pour faire des essais sur l'Internet. c'est très amusant.

          qques ordres de grandeur dans la vie réelle à la louche du doigt mouillé : compte 10-15Mb/s pour n'importe quelle connexion Wi-Fi, y compris avec du matos assez vieux (les fameux 802.11 b/g d'il y a presque 20 ans maintenant ?) et facilement 50Mb/s pour du matos toujours en 2.4Ghz mais qui utilise le 802.11 n (on dira 10 ans)

          aujourd'hui avec de bons access points 5Ghz en 802.11 ac et un smartphone récent je fais du 200-300Mb/s.

          après, si le seul wifi de la maison c'est une box planquée dans un placard du sous-sol, évidemment, on pourra voir le débit chuter jusqu'à la déconnexion, mais c'est un autre problème.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # LTLJ

    Posté par  (site web personnel) . Évalué à 8. Dernière modification le 08 avril 2021 à 10:54.

    La Tête et Les Jambes ou Linux Terminal Leisure Joyhub C'était l'objet de ce que tu cherches : un serveur qui commande non seulement un, mais des clients légers. Le projet est à l'abandon depuis plus de 5 ans. C'était une association du côté de Troyes qui faisait ça. On va essayer de reprendre le sujet avec l'un des anciens porteurs du projet. Il y aura un stagiaire dessus le mois prochain. On n'est pas contre d'avoir des contributeurs.

  • # Steam Link ?

    Posté par  . Évalué à 3. Dernière modification le 08 avril 2021 à 12:06.

    Bon, Steam n'est pas libre, mais à voir si Steam Link utilise des composants libres pour diffusé un flux vidéo/audio et les inputs avec une latence acceptable.

    • [^] # Re: Steam Link ?

      Posté par  . Évalué à 2.

      Je confirme ça fonctionne très bien et malheureusement je ne connais aucune solution libre avec des performances s'en rapprochant.

      En alternative non libre j'ai aussi entendu beaucoup de bien de Parsec ces derniers mois, mais je n'ai pas pris le temps d'essayer

      • [^] # Re: Steam Link ?

        Posté par  (Mastodon) . Évalué à 4.

        Parsec marche très bien, j'ai une VM sur paperspace que je démarre quand je veux jouer, car aucune envie d'investir dans du hardware de gaming pour une utilisation tant sporadique.

        Par contre ça supporte pas les hardwares un peu spécifique offrant du force feedback comme les volants, donc pour ça il faut passer par des outils séparés qui encapsule de l'usb par le réseau.

  • # ffmpeg

    Posté par  (site web personnel) . Évalué à 5.

    J'ai moi aussi testé différentes choses.
    Steam Link marche bien, je dois l'avouer.

    J'ai eu des résultats pas trop mauvais en utilisant ffmpeg : https://trac.ffmpeg.org/wiki/StreamingGuide

    J'ai été très étonné de voir que ça n'impactait pas tant que ça mes fps (sur un jeu gourmand, je suis passé de 45 à 28 [à la louche et variable]). J'ai utilisé un RPI4 comme client, le codex x264 et un PC serveur avec une GTX1070. Mais il me manque encore une façon simple de connecter une manette ou un clavier souris et de les faire reconnaître par le système hôte et les jeux.

    J'aimerais bien une redirection usb et bluetooth, ou la récupération des entrée côté client et l'envoie à un périphérique virtuel sur le serveur (idéalement une fausse manette de xbox ou un truc bien reconnu). Mais bon j'ai pas trouvé, c'est peut être un bon projet à dev.

    • [^] # Re: ffmpeg

      Posté par  (Mastodon) . Évalué à 4. Dernière modification le 09 avril 2021 à 11:48.

      En cherchant je suis tombé sur ça : https://gaminganywhere.org/index.html

      Jamais essayé, mais comme t'as l'air de chercher activement… tu peux peut-être ajouter ça à tes différents essais !

      EDIT : oulah… ça a l'air vieux et pas du tout supporté… oublie !

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: ffmpeg

        Posté par  (site web personnel) . Évalué à 2.

        Je l'avais vu dans mes recherches, et vu la gueule du truc je l'avais laissé de côté. Merci quand même !

        Y a aussi Moonlight chez Nvidia qui permet de streamer des jeux, mais je n'ai pas réussi à comprendre comment lancer ça sous linux, ça utilise geforce expérience si je me rappel bien. Après c'est pas libre et non compatible avec amd mais bon…

        • [^] # Re: ffmpeg

          Posté par  (site web personnel) . Évalué à 2.

          Désolé du double postage !

          J'ai refais des recherches sur moonlight.
          Alors le serveur semble fermé mais les clients son libres (y en a en QT :!Yeah!/ ).

          Mais du coup j'ai découvert l’existence de sunshine : https://github.com/loki-47-6F-64/sunshine et d'OpenStream : https://open-stream.net/ et https://github.com/LS3solutions/openstream-server

          Le dernier est forké du premier si je suis bien et vise à réimplémenter la partie server qui exploite le protocole Game Stream de Nvidia. Partant de là ça ne dépend plus du fondeur et ça peut tourner sous AMD et autre.

          Je vais essayer de tester tout ça au plus vite, en tout cas ça semble au premier abords se baser sur ffmpeg et x264 et x265.

  • # Beaucoup de "solutions"

    Posté par  . Évalué à 4.

    Il y a aussi Moonlight qui n'a pas été cité : https://moonlight-stream.org/

    Il faudrait faire une page Wikipedia.
    En résumé, pour du jeu à distance, on a des solutions cloud payantes :

    • Sony PlayStation Now
    • Microsoft xCloud
    • Google Stadia
    • Amazon Luna
    • Nvidia GeForce Now
    • Blade Shadow
    • Valve Steam Link

    Des logiciels spécialisés fermés :

    • Parsec
    • Moonlight

    Des logiciels d'affichage à distance ouverts :

    • Xpra
    • VirtualGL
    • NoMachine
    • Xspice
    • Waypipe
    • VNC
    • ffmpeg

    Je crois comprendre que rien de tout ça ne correspond exactement à la demande initiale :
    un logiciel ouvert spécialisé pour jouer sur une petite machine cliente avec un serveur maison.

    • [^] # Re: Beaucoup de "solutions"

      Posté par  . Évalué à 1.

      Steam Link, ce n'est ni payant, ni du cloud. Tu utilises ton propre ordinateur pour lancer le jeu. Mais c'est proprio et nécessite un compte en ligne.

      • [^] # Re: Beaucoup de "solutions"

        Posté par  . Évalué à 2.

        Donc Steam Link est dans la deuxième catégorie (logiciel spécialisé) ?

        Aussi NoMachine (troisième catégorie) n'est pas trop ouvert,
        et Moonlight (deuxième catégorie) n'est pas trop fermé.

        Désolé pour les approximations

        • [^] # Re: Beaucoup de "solutions"

          Posté par  (Mastodon) . Évalué à 2.

          Ouais compliqué de trier, mais je serais globalement d'accord avec tes corrections

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Un journal en parlait il y a peu

    Posté par  . Évalué à 2.

    Lui avait réussi à obtenir quelque chose déjà:
    https://linuxfr.org/users/bubar/journaux/stadia-home-un-cloud-gaming-personnel

    J'espère que cela t'aidera :)

  • # Merci beaucoup

    Posté par  . Évalué à 1.

    Merci beaucoup pour vos réponses. Je vais regarder plus en détails les propositions.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.