Curieux de savoir comment Google a construit techniquement Stadia, son offre de cloud gaming ? Plongez donc dans la retranscription – en quatre parties – de la présentation « Stadia Streaming Tech: A Deep Dive » qui a eu lieu lors du Google I/O en 2019. Nous continuons notre série avec l’intervention de Rob McCOOL qui nous explique comment fonctionne le Streamer de Stadia. Bonne lecture.
Avant de parler du Streamer, Rob McCool tient à dissiper quelques idées fausses suite à des rumeurs qui ont circulées.
- L’équipe derrière Stadia n’utilise pas d’intrication quantique dans l’implémentation de l’architecture. Il n’y a pas d’action flippante réalisée à distance dans Stadia. Cela signifie donc que les latences dans Stadia sont strictement non nulles.
- Ils n’ont pas encore trouvé le moyen de canaliser les tachions au travers de conduits en cuivre ou de la fibre. Rappelons que les tachions sont, bien sûr, pour les geeks de science-fiction, des particules qui se déplacent dans le temps. Les latences sont donc toujours strictement non négatives.
- Stadia prend en charge de nombreux types de réseaux différents, de nombreux standards ouverts, mais ne prend pas en charge la RFC 1149. Pour rappel, cette RFC définit la transmission IP grâce aux transporteurs aviaires, types pigeons, oies, etc. RobMcCool explique qu’ils ont essayé mais que cela a été un énorme gâchis et que le service technique ne répond toujours pas à ses appels… En effet, la RFC 1149 était un poisson d’avril 🙂
Qu’est-ce que le Streamer ?
Le Streamer est un moteur de diffusion spécialement conçu pour les jeux vidéo. C’est un logiciel qui fonctionne en parallèle du jeu et qui prend les informations du client ainsi que celles du réseau de diffusion de contenus de Google. Il prend des décisions en temps réel sur la façon de maximiser la qualité tout en gardant une latence imperceptible. Il repose sur des normes ouvertes, comme par exemple les arts en ligne que vous voyez, et prend en charge de nombreuses plateformes, y compris les navigateurs, les appareils de salon et les téléphones portables.
Adaptation des ratios pour la diffusion en continu de jeux vidéo
Le Streamer surveille et estime en permanence les conditions du réseau en temps réel, comme la bande passante, la perte de paquets et le retard. Ainsi, il adapte en temps réel la transmission des jeux et le flux des médias en conséquence. La diffusion en continu de jeux vidéo depuis le cloud est donc basée sur un système complexe et comporte de nombreux acteurs et de nombreuses variables qui ne sont pas directement observables.
Le cloud gaming ressemble à une partie de jeu de stratégie en temps réel tel que Warcraft ou Starcraft. Dans ce genre de jeu, il y a un mécanisme appelé brouillard de guerre où vous ne pouvez pas voir ce qui se passe à un endroit tant que vous n’avez pas envoyé une unité pour aller l’observer. Le cloud gaming y ressemble beaucoup. Il y a un tas d’informations que vous ne pouvez pas voir tant que vous ne les avez pas observées. Et vous ne savez donc pas si elles ont changé depuis la dernière fois que vous les avez regardées. Et tout comme dans un jeu de stratégie en temps réel, vous devez prendre des décisions tout le temps. Sur quoi allez-vous vous concentrer ? Allez-vous vous focaliser sur l’économie ? Sur les unités de guerre ? Et pour la diffusion de jeux, allez-vous vous concentrer sur la qualité ou sur la latence ? Si vous n’avez pas assez de bande passante et que vous vous concentrez sur la qualité, vous risquez de prendre du retard.
Il n’y a donc pas une seule bonne réponse. Il n’y a pas d’optimisation unique pour faire la parfaite technologie de diffusion en continu de jeux dans le cloud. Il s’agit toujours de trouver un équilibre entre plusieurs compromis. Ainsi, si on améliore quelque chose, c’est souvent au détriment de quelque chose d’autre. La solution n’est donc pas un algorithme élégant que l’on peut décrire avec quelques lignes de symboles grecs pour en tirer peut-être une thèse de maîtrise. Elle se présente sous un jour très différent.
Avoir le bon algorithme, c’est une base importante. En ce qui concerne les jeux de stratégie en temps réel, combien de personnes ont déjà mis en œuvre la technique de recherche d’itinéraire dans un jeu ? Quand vous implémentez la recherche d’itinéraire, vous devez commencer par la fondation d’un bon algorithme. La méthode en étoile a tendance à être l’une de celles que les gens utilisent. Donc, une fois que vous l’avez implémenté, vous constaterez qu’il y a un tas de cas marginaux. Vous avez des unités qui marchent dans les murs. Vous avez différentes choses qui se passent. L’algorithme a besoin d’un petit peu d’aide. Donc vous mettez une étoile, vous ajoutez d’autres algorithmes, vous ajoutez des heuristiques et vous avez un produit qui fonctionne.
Google est particulièrement bien placé pour résoudre ce genre de problèmes complexes, désordonnés et, parfois, extrêmement affreux. La recherche a fortement influencé la culture de Google. De nombreuses approches utilisées par la recherche, y compris le mélange de nombreux algorithmes, l’utilisation d’heuristiques, l’utilisation d’humains ainsi que des mesures automatisées pour évaluer la qualité, la modélisation de situations complexes du monde réel avec des simplifications utilisables par la machine, les systèmes prédictifs et l’apprentissage par renforcement sont toutes des choses qui sont vitales pour créer une plateforme de streaming. La recherche suit le même schéma d’algorithme décrit plus haut.
Le système de classement de pages web est en fait très simple. C’est un algorithme très puissant, très facile à définir. Et c’est une base importante. C’est comme ça depuis longtemps. Mais ce n’est pas suffisant d’utiliser ce classement par lui-même. Il est nécessaire de le combiner avec d’autres choses pour qu’il fonctionne dans toutes les situations. L’équilibre y est donc également important. Dans le domaine de la recherche, il est possible de faire preuve de précision en filtrant les résultats pertinents pour être sûr que tout ce qui est montré est correct. On peut aussi se concentrer sur le principe de rappel qui permet de montrer de nombreux résultats mais dont certains peuvent être erronés.
Ainsi, tout comme pour le calcul d’itinéraires ou le cloud gaming, il est indispensable de trouver un équilibre. il faut aller au cœur de la question et trouver ce que le produit doit être. La recherche c’est la même chose. Google a beaucoup d’expérience dans ce domaine et cela fait aussi partie du cloud gaming.
Comment créer un moteur de jeu dans le nuage ?
Il faut d’abord choisir un algorithme comme base. Ensuite, ce qu’il faut trouver, c’est un équilibre.
L’un des équilibres importants concerne le rapport entre la latence et la qualité. Guru Somadder aime d’ailleurs rappeler que si tout ce qui vous intéresse c’est la qualité, c’est très facile à faire. Il suffit de diffuser une image par seconde. La latence sera horrible, mais ça sera joli. Et si vous ne vous souciez que de la latence, il suffit de diffuser en continu à 2 mégabits. La qualité sera épouvantable, mais ce sera vraiment réactif. Il est donc nécessaire de trouver un juste milieu et c’est là que se trouve l’équilibre. Il faut utiliser des signaux incomplets et bruyants pour déterminer ce qui se passe et ensuite faire un choix sur ce qu’il faut faire en fonction de ces informations.
Mais il ne faut pas toujours enlever une chose pour en augmenter une autre. Les améliorations technologiques sont telles la marée montante qui soulève les bateaux. Si on considère ces améliorations comme un nouveau codec vidéo tel que AV1 par exemple, alors grâce à ce codec, vous pouvez obtenir une bien meilleure qualité pour des débits binaires équivalents et cela améliore l’expérience à tous les niveaux.
Les bases de l’encodage vidéo
Voici donc un aperçu du fonctionnement des encodeurs vidéo et des différents types d’images vidéo. Afin d’utiliser le plus petit nombre de bits, un encodeur vidéo envoie d’abord une trame qui contient tout ce qu’il faut. Ensuite, il n’envoie que ce qui a changé. Ces images complètes sont appelées des i-frames et elles sont comme les images jpg que votre appareil photo numérique ou votre téléphone peuvent produire. Parce-qu’elles sont très volumineuses, les encodeurs produisent ensuite des images qui ne contiennent que des différences par rapport aux images précédentes. Ces images sont appelées des p-frames et vous pouvez continuer à afficher la vidéo tant que vous ne perdez aucune de ces p-frames. Si vous en perdez une, vous devez définir une nouvelle i-frame complète pour recommencer le décodage. Il existe un autre type d’image, appelées les b-frames, qui ne peuvent pas être décodées avant l’arrivée d’une autre image. L’utilisation de ces images augmenterait la latence à des niveaux perceptibles sur Stadia et ne peuvent donc pas être utilisées.
Les encodeurs ont donc un travail très difficile à faire : imaginez que vous êtes dans le menu du jeu. Vous choisissez l’action pour démarrer le jeu, vous appuyez sur un bouton et tout l’écran explose. Et il y a des éclats de verre, du feu et des explosions, et peut-être même, un accord de guitare épique qui fait « bram ». Ces vidéos sont appelées des scènes de coupe. L’encodeur doit pouvoir produire un flux régulier, que le flux ait un peu ou beaucoup changé. Afin de préserver une qualité visuelle constante, l’encodeur est autorisé à produire des images parfois plus grandes et parfois plus petites. Il est extrêmement important de paramétrer ce comportement dans le domaine du cloud gaming.
De nombreux encodeurs comportent également des étapes de pré-analyses très lentes et coûteuses en terme de calcul afin de déterminer la meilleure stratégie d’encodage. L’une des approches les plus courantes consiste à encoder une trame plusieurs fois avec plusieurs stratégies, puis à choisir la bonne par la suite. Et dans le cas extrême, les personnes qui encodent les disques blu-ray réalisent en fait une explosion combinatoire où elles essaient toutes les différentes possibilités. Elles suivent ensuite un chemin entre ces possibilités pour obtenir la meilleure qualité possible au débit le plus bas possible. Ils ont donc des semaines pour le faire. En comparaison, dans le cloud gaming, on ne dispose que d’une poignée de millisecondes. Il est donc nécessaire de faire très attention aux types d’analyses qui seront autorisées ou non.
Comment fonctionne le réseau ?
Voici un aperçu simplifié de la manière dont un réseau s’articule réellement :
Parce-que la route est longue informatiquement parlant entre un data center et un joueur, les data centers de Stadia doivent se trouver à la périphérie du réseau, le plus près possible des joueurs, la vitesse de la lumière étant prise en compte dans les calculs de latence.
Le réseau est constitué d’un ensemble hétérogène de dispositifs interconnectés qui ont leurs propres caractéristiques et stratégies de mise en mémoire tampon. Les connexions entre chacun de ces composants ont chacune une capacité qui se mesure en bits par seconde et elles doivent couvrir une distance physique qui introduit une latence minimale. Chaque appareil est également doté d’un tampon qui absorbe les paquets qui ne peuvent pas encore être envoyés à cause d’une vitesse de transmission trop lente. Certains de ces tampons peuvent être peu profonds, comme ceux des datacenters, mais d’autres sont plus profonds. Les tampons profonds ont donné naissance à un terme qui était populaire il y a peu de temps, à savoir le phénomène de surcharge des tampons. Lorsque ces tampons se remplissent, c’est la congestion. Et lorsque des paquets attendent dans des tampons et ne sont pas envoyés, on obtient de la latence. Si ces tampons débordent, alors les paquets sont perdus et doivent être retransmis.
Donc du côté du récepteur, Stadia utilise des extensions Web RTC fournies par leur équipe en Suède pour désactiver la mise en mémoire tampon et déplacer les paquets dès qu’ils arrivent. Il est vital, que ce soit pour Stadia, son contrôle et la congestion, de maintenir une mise en mémoire tampon aussi basse que possible.
Stratégie du contrôle de la congestion CUBIC
Voici une des stratégies de contrôle de la congestion les plus répandues sur Internet aujourd’hui : CUBIC.
CUBIC est une très ancienne stratégie de contrôle de congestion mais qui est encore très courante parce-qu’elle permet d’obtenir de très bons résultats. Son fonctionnement est assez complexe mais pour simplifier, disons que le principe est d’augmenter sans cesse le débit de transmission jusqu’à ce qu’il provoque une perte de paquets. Lorsque l’algorithme s’en aperçoit, il réduit un peu le débit et le choisit comme état stable. De nombreux sites de streaming vidéo tels que YouTube utilisent encore TCP avec un algorithme de contrôle de congestion CUBIC.
Mais si CUBIC était utilisé pour le cloud gaming, ce serait une catastrophe car à chaque fois qu’il y aurait une perte de paquets, le joueur verrait une image figée jusqu’à ce qu’il puisse la restaurer. Et cela prendrait des centaines de millisecondes. CUBIC est un algorithme relativement ancien et qui convient bien à ses objectifs puisqu’il est toujours utilisé, mais il est nécessaire de trouver quelque chose de plus approprié pour le streaming de jeux vidéo.
Stratégie du contrôle de la congestion BBR
Dans les années 1980, Il y avait un informaticien nommé Van Jacobsen qui était en train de sauver l’Internet de l’effondrement de la congestion. Van Jacobsen, qui travaille désormais chez Google, a réalisé que CUBIC a été conçu à une époque où les routeurs avaient des tampons beaucoup plus petits. La perte de paquets en tant que signal n’a de sens que si vos tampons sont peu profonds. Ces dernières années, il a donc mis au point un nouveau système de contrôle de la congestion appelé BBR, qui signifie « bottleneck bandwidth and round trip time » (goulet de bande passante et temps du signal). Le BBR fonctionne en utilisant le retard comme signal au lieu de la perte de paquets.
Le principe consiste à émettre d’abord en dessous de la vitesse du maillon le plus lent de la chaîne, appelé le goulot d’étranglement de la bande passante, puis de continuer à transmettre des débits de plus en plus élevés jusqu’à ce que le RTT augmente. Vous savez maintenant que vous avez commencé à remplir un tampon et que vous avez atteint la limite en bande passante du goulot d’étranglement.
En choisissant ce mode de transmission stable, il est possible de maintenir une faible latence tout en utilisant au mieux la connexion. C’est donc très proche de ce dont un service de cloud gaming a besoin. Le BBR se situant juste à la limite de l’induction de la mise en mémoire tampon mais pas au-delà, il est donc possible d’obtenir le meilleur débit binaire tout en maintenant une latence imperceptible. Vous pouvez en savoir plus sur le BBR ici.
La Diffusion Dynamique Adaptative par HTTP (DASH)
DASH est une technologie très résistante, très polyvalente et très répandue. Elle est agnostique aux augmentations de latence, stable dans de nombreuses situations défavorables comme la migration d’un réseau du Wi-Fi vers un réseau cellulaire. Elle permet de diviser la vidéo et l’audio en un ensemble de morceaux, généralement cadencés à des intervalles de 5 à 10 secondes. Chacun de ces morceaux est transmis en rafale au débit maximum de la ligne. Cela signifie donc que même si votre vidéo n’est encodée qu’à 10 mégabits, elle enverra des salves de 150, 150, 150, si votre ligne supporte une telle vitesse. Lorsque le réseau ne peut pas transmettre les données assez rapidement pour que le client les mette en mémoire tampon, un événement de remise en mémoire tampon se produit. Les lecteurs utilisant la technologie DASH passent alors à un flux à débit plus faible mais ces changements de qualité ont tendance à se produire à un intervalle de temps relativement grossier, mesuré en dizaines de secondes habituellement. Les flux DASH doivent également être interrogeables et contenir des i-frames fréquents comme vous pouvez le constater sous forme de lignes oranges sur le graphique ci-dessus. Bien évidemment, toutes ces caractéristiques sont très inappropriées pour le cloud gaming.
Le cas du cloud gaming
Voici comment un moteur de jeu de type « cloud gaming » fonctionne réellement lorsque les conditions du réseau sont bonnes. À chaque trame, le contrôleur de congestion demande un débit binaire cible spécifique. Il choisit la cible en fonction de ce qu’il perçoit comme étant l’état actuel des tampons le long du réseau. Contrairement au système DASH, les p-frames sont utilisées de manière cohérente, à moins que quelque chose de fâcheux n’arrive. Les i-frames sont envoyées uniquement à la demande et sont réglées pour être de très petite taille, il y a donc une petite touche de qualité pour cela.
Le contrôleur ajuste constamment le débit binaire cible en fonction des signaux de rétroaction pour chaque paquet qui arrivent du dispositif récepteur. Le contrôleur utilise une variété de filtres, de modèles et d’autres outils. Il les synthétise ensuite en un modèle décrivant la bande passante disponible et choisit un débit binaire cible pour l’encodeur vidéo. Ainsi, lorsque les tampons se remplissent, comme c’est le cas vers la cinquième image sur le graphique ci-dessus, le contrôleur le remarque et réduit son débit de transmission pour vider les tampons. Contrairement à un algorithme traditionnel de contrôle de la congestion, celui de Stadia doit suivre les trames de média et non les octets. En effet, s’il ne devait suivre que les octets, il pourrait retarder la deuxième moitié de l’image vidéo au milieu de la transmission et cela introduirait alors de la latence.
Voici maintenant un exemple illustrant un problème.
Le contrôleur de congestion doit donc prendre des mesures rapides pour y remédier. Dans ce cas, après la transmission des p-frames 3 et 4, un flux concurrent a rempli les tampons malgré nos tentatives de réduire le débit de transmission de 20 mégabits vers 15 mégabits puis vers 12 mégabits et, enfin, vers 6. Nous constatons qu’à la trame 5, nous avons simplement perdu trop de paquets et nous ne pouvons pas les restaurer assez rapidement pour préserver une latence imperceptible. Nous devons donc demander une i-frame pour vider les tampons et restaurer une expérience de qualité totale à la frame 6.
Le contrôleur de congestion doit faire face à de nombreuses situations différentes, à de nombreux réseaux différents et à de nombreux dispositifs de réception différents. Et il doit les traiter aveuglément, sans information explicite sur ce qui se passe. Il utilise donc ce modèle pour préserver une expérience de haute qualité avec une latence imperceptible.
Un équilibre déliquat
L’expérience de Google en matière de conception d’algorithmes, de modélisation de situations extrêmement complexes dans le code et le travail à l’échelle avec une latence de quelques millisecondes la place donc dans une position idéale pour permettre cette expérience aux joueurs. Des réglages sont effectués au niveau de la milliseconde voire parfois de la microseconde et des choix éclairés doivent être faits en temps utiles pour maintenir une latence imperceptible tout en maximisant la qualité. C’est le mélange de nombreux signaux, modèles, rétroactions, apprentissage actif et de capteurs différents, dans une boucle de rétroaction étroite qui produisent une expérience réglée avec précision.
L’équipe «Jouabilité» travaille en étroite collaboration avec le matériel et les encodeurs vidéo pour régler leur fonctionnement dans un réseau conscient et sensible en utilisant des modèles prédictifs et des algorithmes avancés pour savoir à quoi s’attendre sur les réseaux Wi-Fi et cellulaires chaotiques et s’y préparer, sans réagir de manière excessive ni agir avec un conservatisme excessif.
La prochaine partie de cette série sera consacrée au Project Stream et à la présentation de l’infrastructure qui permet de rendre tout cela possible. Si vous ne voulez pas rater cet article, abonnez-vous au blog. Sinon pour continuer cette discussion technique, n’hésitez pas à vous inscrire sur le Discord Stadia Fr si ce n’est pas déjà fait.