Dernière mise à jour le

Stadia doit faire oublier le trajet jusqu’au centre de données

Stadia a été lancé le 19 novembre et je voulais attendre de voir le service en marche avant d’écrire. Le streaming de jeu se juge mieux quand de vraies commandes passent par de vraies connexions Internet.

L’idée de Google est simple à expliquer : le jeu roule dans un centre de données, alors le joueur n’a pas besoin d’une grosse console ou d’un PC puissant à la maison. Le matériel ne disparaît pas; GPU, CPU et mémoire sont déplacés près du réseau du fournisseur.

Le budget entre le bouton et le pixel

Le trajet entre le bouton et l’image est pas mal moins simple :

manette → réseau local → Internet → serveur de jeu
        → simulation → rendu GPU → encodage vidéo
        → Internet → décodage → écran

Pour viser 60 images par seconde, le serveur dispose de 16,7 ms par frame avant même l’encodage et le transport. Un budget fictif montre vite le problème :

commande vers le centre de données       20 ms
attente + simulation + rendu             16 ms
encodage                                  6 ms
vidéo vers la maison                     20 ms
buffer + décodage                         8 ms
écran                                     8 ms
                                         -----
ordre de grandeur                         78 ms

Ces étapes ne sont pas toujours simplement additionnées — certaines se chevauchent — et les valeurs changent selon le jeu et l’équipement. Elles montrent quand même pourquoi vingt millisecondes de plus se sentent. La latence locale d’une manette et d’un téléviseur compte autant que le ping affiché par le fournisseur.

Envoyer une vidéo qui change à chaque frame

Le GPU rend une image brute beaucoup trop grosse pour Internet. À 1920×1080, trois octets par pixel et 60 images par seconde, on obtient environ :

1920 × 1080 × 3 × 60 ≈ 373 000 000 octets/s
                       ≈ 3 gigabits/s avant compression

L’encodeur vidéo cherche les ressemblances entre les frames et envoie surtout les différences. Les scènes calmes se compressent bien. La fumée, l’herbe, les particules et les mouvements de caméra rapides demandent plus de débit ou perdent des détails.

Pour garder la réponse rapide, le service ne peut pas accumuler plusieurs secondes d’images comme un film en streaming. Le buffer doit rester petit. Il absorbe moins bien la gigue, soit la variation du temps d’arrivée des paquets. Si un paquet est perdu, attendre sa retransmission peut arriver trop tard; continuer sans lui peut créer un bloc ou forcer une image de référence plus coûteuse.

Le système adapte alors le débit, la résolution ou la qualité. Une connexion annoncée à 100 Mbit/s peut quand même mal fonctionner si le Wi‑Fi perd des paquets, si un autre appareil sature l’envoi ou si la route réseau change. La stabilité et la latence comptent autant que le débit maximal.

Mesurer toute la chaîne

Je voudrais enregistrer pour chaque session :

  • temps aller-retour et gigue;
  • pertes de paquets;
  • temps de simulation et de rendu;
  • temps d’encodage et de décodage;
  • bitrate et résolution réellement livrés;
  • images perdues et changements de qualité;
  • type de réseau local et modèle d’écran lorsque disponible.

Le chiffre utile est la latence input-to-photon : du moment où la commande change jusqu’au moment où le pixel correspondant apparaît. Un test peut filmer à haute vitesse une DEL qui s’allume avec le bouton et l’écran qui réagit, puis compter les frames entre les deux. Ce n’est pas parfait, mais ça mesure le trajet que le joueur ressent.

Le service a aussi besoin de reprise. Si l’instance tombe, peut-on restaurer la session ou seulement recommencer? La sauvegarde de la partie doit être confirmée séparément du flux vidéo. Une coupure après une action mais avant la synchronisation ne devrait pas corrompre la progression.

Google contrôle le centre de données, l’encodage et une partie du réseau. Il ne contrôle pas chaque routeur, le Wi‑Fi de la maison ni le mode d’image du téléviseur. L’expérience dépend donc de toute la chaîne. Une résolution un peu moins bonne peut passer; une commande en retard se sent immédiatement.

Après une seule semaine, c’est trop tôt pour déclarer une victoire ou un échec. Le test que je ferais est très concret : jouer la même séquence en Ethernet puis en Wi‑Fi, capturer pertes, gigue et latence, et voir à quel moment le service réduit la qualité ou devient difficile à contrôler. Le défi de Stadia est de rendre tout ce trajet assez stable pour qu’on cesse d’y penser.

Mise à jour de 2026

Stadia a cessé de donner accès aux jeux le 18 janvier 2023. La diffusion pouvait fonctionner sur le plan technique, mais il fallait aussi un catalogue, assez d’utilisateurs et un modèle commercial qui tient.

Dans son annonce de fermeture, Google explique la suite de sa stratégie de streaming. La latence n’était donc pas le seul problème à régler.