HardWare.fr


Les solutions de streaming : Streaming local Steam et Nvidia GameStream en test
Cartes Graphiques
Publié le Mardi 26 Juillet 2016 par Guillaume Louel

URL: /articles/950-1/solutions-streaming-streaming-local-steam-nvidia-gamestream-test.html


Page 1 - Un accès distant dédié aux jeux

Profiter des jeux de son PC dans son salon, sans disposer d'un PC dédié ou d'avoir à tout déplacer : voilà la promesse que font les diverses solutions que nous avons testées aujourd'hui. Nous nous sommes en effet intéressés aux solutions de streaming local spécifiques aux jeux PC, afin de voir ce qu'elles proposent en pratique !

Le jeu, un problème spécifique

Le concept de la prise de contrôle à distance d'une machine n'est pas particulièrement nouveau. Passé les terminaux telnet et ssh, des solutions graphiques existent déjà depuis de longues années, comme par exemple le logiciel open source VNC qui permet de manipuler son bureau Windows à distance. Microsoft propose aussi sa propre solution, avec Remote Desktop Connection (RDC).

Particularité de ces solutions, elles exploitent le fait qu'en général, un bureau dispose de grandes zones fixes qui changent très peu d'un instant à l'autre. Au mieux, les modifications sont en général prévisibles (déplacer une fenêtre par exemple) et les solutions exploitent cela au niveau de la manière dont ils transmettent les informations, permettant de limiter massivement la bande passante nécessaire pour réaliser un affichage distant.

Le protocole de VNC est le plus ancien, et n'est pas lié à Windows. Il se contente simplement de transférer les zones de pixels qui ont été modifiées par rapport à l'écran précédent. Microsoft va un petit peu plus loin avec le protocole RDP utilisé par RDC, en envoyant des instructions plus génériques (par exemple, « créer une fenêtre de telle hauteur et telle largeur ») qui dessineront directement le résultat à destination, en plus de la possibilité de transférer des zones de pixels lorsque nécessaire, bien entendu.

Résultat, on peut prendre très facilement contrôle de machines non seulement dans son réseau local, mais même au travers d'Internet avec un confort élevé lorsqu'il s'agit de tâches peu graphiques.

Le H.264 à la rescousse

Etant donné les performances au travers d'Internet de VNC et RDC, on pourrait penser que sur un réseau local, transférer les images d'un jeu serait trivial ! En pratique, la déception est immédiate puisque l'on se retrouve en général… avec un écran noir, DirectX n'étant pas géré.

Selon les versions de Windows de chaque côté, dans certains cas, RDP peut gérer des jeux DirectX (via l'extension RemoteFX ) mais en pratique on a droit en général à un slide show dans le meilleur des cas, une latence effroyable, et un support des contrôleurs de jeu distant discutable.

Pas vraiment de miracle : ces protocoles n'ont pas été conçus pour cela. Le point commun des solutions auxquelles nous nous sommes intéressées aujourd'hui est qu'elles prennent le problème à l'envers : plutôt que de considérer les zones qui changent d'une image à l'autre, pourquoi ne pas directement encoder la sortie vidéo de l'écran, en H.264, et envoyer directement ce résultat sur le réseau ? C'est après tout une technique utilisée par certains logiciels de vidéo conférence, comme Skype.


Les dernières versions de Skype gèrent l'encodage H.264 matériel pour la vidéo conférence, et détournent cette fonctionnalité pour faire du partage d'écran

Conjugué à la multiplication des encodeurs H.264 intégrés dans le matériel (et plus particulièrement, des encodeurs basse latence), c'est - avec beaucoup de nuances comme nous allons le voir - le point de départ utilisé par les solutions locales de streaming de jeux.

Page 2 - Les solutions évaluées

#Les solutions évaluées

Pour réaliser ce test, nous sommes partis d'un besoin : vouloir jouer à distance aux jeux présents sur un PC qui n'est pas forcément dans la même pièce. De quoi profiter par exemple, c'est le cas le plus classique, de ses jeux sur le téléviseur de son salon. Nous avons retenu trois solutions, dont deux en provenance de Valve.

Attention aux jeux UWP !

Avant de commencer, rappelons que toutes les solutions que nous avons testées visent les jeux « classiques » sous Windows. Vous le savez peut être, depuis le lancement de Windows 10, Microsoft tente de pousser les développeurs de jeux à utiliser sa nouvelle Universal Windows Platform (en remplacement du win32/64 traditionnel). Ces jeux sont pour l'instant disponibles via le Windows Store. Au-delà de quelques exclusivités, on retiendra surtout les multiples limitations imposées par UWP qui isole les applications dans une sandbox. D'autres problèmes sur le multi-GPU, ou l'impossibilité de désactiver le V-Sync (un problème corrigé depuis quelques semaines) sont gênants, mais l'on retiendra surtout que l'utilisation d'une sandbox bloque de facto les overlays, mods… ou les outils de capture qui souhaiteraient accéder à la mémoire de l'applicatif.

Pour fermer cette parenthèse, notez que dans le cadre de cet article, il faudra exclure les rares titres UWP disponibles via le Windows Store qui ne sont pas compatibles avec les solutions que nous avons testés. Regardons enfin à quoi elles ressemblent !

Streaming local Steam

Steam intègre directement la possibilité de streamer ses jeux entre plusieurs machines sur un réseau local. Pour activer cette fonctionnalité, il faut aller dans "Paramètres" et choisir à gauche "Streaming Local". Sur la machine "hôte", il faut cocher la case "Activer le streaming".

Pour profiter du streaming local, il faudra installer Steam sur un autre PC (que l'on appellera "client"). Ce dernier doit être connecté au même compte Steam pour que la fonctionnalité marche. Si tous les critères sont réunis, les jeux installés sur le PC "hôte" apparaissent dans votre bibliothèque, le bouton "Jouer" se transformant en un bouton "Streamer". En pratique, la détection est instantanée en réseau local et nous n'avons pas noté de problèmes particuliers sur la reconnaissance des machines, une bonne chose.

Une fois le stream lancé, on pourra prendre le contrôle directement sur le PC "client", soit avec un clavier/souris ou un pad (USB ou sans fil au choix). Steam s'occupe de transférer automatiquement vers le PC source vos actions. Notez que l'on pourra aussi utiliser les contrôles sur le PC source en parallèle si on le souhaite.
Côté configuration, Steam est très riche en réglages même si certains réglages sont obscurs ou non documentés. En ce qui concerne la machine hôte, les choses sont assez simples et tout se passe via les options avancées :

La première priorité consiste à choisir l'encodeur H.264 que l'on souhaite utiliser. Steam gère ceux d'Intel (QuickSync), AMD (AMF) et Nvidia pour lequel une seconde option de capture est proposée (NVFBC, nous y reviendrons). Si l'on décoche l'encodage matériel, un encodage sera réalisé côté CPU avec x264 (via libx264). On pourra choisir le nombre de threads utilisés par défaut. En réglage automatique, sur notre Core i7 6700K, l'encodage s'effectue sur 4 threads.

Côté client les réglages commencent à être ambigus. D'abord il est nécessaire de rappeler que l'on doit choisir les réglages "hôte" sur la machine "hôte"... et les réglages "client" sur la machine "client". Cela parait logique mais étant donné l'imbrication des réglages on peut facilement se tromper (en pratique une machine peut être à la fois hôte et cliente, ce qui complique les choses).

Sur le panneau de paramètres principal du streaming, on retrouve en effet trois choix pour les réglages clients, "Rapide", "Equilibré" et "Beau". Le mode "Beau" est celui a privilégier en pratique, il tente de préserver 60 images par secondes (tout en s'autorisant de passer a 30 images/secondes si nécessaire pour maintenir un niveau de qualité d'images). Le mode "Equilibré" préférera réduire le débit de l'encodage (et la qualité) tout en jouant si nécessaire sur le nombre d'images/secondes. Enfin le mode "Rapide" changera le profil H.264, passant du profil "Main" au "Baseline", réduisant pour le coup encore plus significativement la qualité d'image.

Les options client avancées sont les plus intéressantes :

Le premier réglage est assez obscur, il permet de régler la bande passante utilisée, et donc indirectement le débit du flux H.264. Le réglage automatique par défaut correspond à un bitrate maximal d'environ 30 Mbit/s, soit 4 Mo/s environ de bande passante. Un bitrate important puisque l'on est dans le débit d'un Blu-ray moyen (le débit maximal autorisé pour une piste vidéo sur un Blu-ray est de 40 Mbit/s pour rappel. Si vous vous souvenez de notre test des encodeurs H.264, nous utilisions à l'époque un débit de "seulement" 10 Mbit/s !). Un mode "Illimité" est présent, avec la mention qu'il "augmente la latence". Une assertion sur laquelle nous reviendrons !


Exemple des informations avancées affichées en temps réel sur le streaming par Steam

Outre la configuration du son (et la possibilité de limiter la résolution) on s'assurera que le décodage matériel est activé sur le PC client, dans ce cas Steam utilise Quicksync lorsqu'il est présent. La dernière case à cocher ajoutera en bas de votre écran un overlay vous indiquant quelques détails sur le streaming en cours (la touche F6 permet d'avoir un peu plus de détails, on peut voit l'encodeur et le décodeur utilisé, ainsi que certaines informations sur la méthode de capture et la latence).

Quelques mots sur Big Picture

Steam dispose également d'un mode dit Big Picture qui affiche une interface adaptée à une utilisation au pad. Si elle est pratique, elle a deux inconvénients. La première est d'être relativement gourmande en temps CPU, y compris lorsqu'elle devrait être cachée. Lors de nos tests de streaming sur un modeste Celeron, nous avons noté que passer par l'interface Big Picture pour lancer nos tests ralentit significativement la machine. En cause, une utilisation CPU importante de Steam pour son interface.

Si l'on ne sait pas exactement quelles technologies Valve utilise pour son mode Big Picture, on peut en avoir un petit aperçu en appuyant sur la touche F6 (un choix maladroit, c'est la même touche qui permet de voir les infos de streaming avancées !) qui fait apparaître le debugger. On y découvre une interface qui semble mélanger des technologies plutôt "web" qu'autre chose comme XML et CSS, ce qui peut expliquer le coût CPU élevé (nous pensons que le rendu est CPU pur et qu'il ne s'agit pas d'une interface DirectX/accélérée GPU, quelque chose de logique étant donné l'aspect multi-plateforme de Steam qui est disponible également sur Mac et sous Linux).

En pratique, sur notre Celeron, l'interface n'est en prime pas particulièrement fluide, même si le problème principal a nos yeux reste que cette interface ne se mette pas en pause lorsque l'on lance un jeu !


Le debugger de Steam montre que l'interface utilise des technologies web et visiblement peu accélérées par le GPU, étant donné sa consommation sur des processeurs modestes

Le second problème de l'interface Big Picture est lié à l'utilisation de deux machines. Généralement on voudra lancer l'interface Big Picture sur le client. Dans ce cas l'interface tourne nativement sur la machine client, ce qui semble plutôt une bonne idée sur le papier, même si on le rappelle, en pratique la fluidité et la consommation processeur est bien trop élevée sur notre Celeron.

Là ou les choses se compliquent, c'est que dès que l'on va lancer un streaming de jeu, l'interface Big Picture va se lancer elle aussi sur la machine hôte. Avoir deux interfaces identiques lancées ne devraient pas être un problème... sauf dans le cas ou l'on se retrouve sur le client avec l'interface du PC hôte. Quelque chose qui arrive, par exemple, lorsque l'on quitte inopinément un jeu. De quoi vous poser quelques problèmes si vous allez changer les options...

Très intéressante sur le papier, l'interface Big Picture pose quelques problèmes spécifiques au streaming. Il n'est pas normal que l'interface ne se mette pas complètement en pause lorsque le jeu est lancé par exemple, et la double présence des interfaces fait que l'on peut rapidement se perdre.

Steam Link

La seconde solution que nous avons testée est elle aussi en provenance de Valve, avec Steam Link. Il s'agit d'un petit boîtier rectangulaire de 12.4cm de large pour 9cm de profondeur et 1.8cm en hauteur. Il se distingue par un coin arrondi qui accompagne un logo, le tout pèse 250 grammes ce qui évitera que le boîtier soit trop baladé par les câbles que l'on y branchera.

Côté connectique on retrouve à l'arrière la prise d'alimentation, deux ports USB 2.0, un port Ethernet 100 Mbit/s et une sortie HDMI (1080p). Un troisième port USB est disponible sur le côté droit du boîtier et l'on notera l'absence totale de bouton, que ce soit pour l'allumer ou redémarrer ! Le boîtier gère également le WiFi 802.11ac ainsi que le Bluetooth 4.0.

A l'intérieur on retrouve un SoC Marvell 88DE3005 (également connu sous le nom d'Armada 1500 Mini ). Certains y reconnaîtront une puce qui avait déjà trouvé sa place dans un produit lié au streaming : elle était présente dans la première génération de clefs Chromecast de Google. Marvell ne publie malheureusement pas les spécifications de ses puces (et n'a pas répondu à nos demandes) mais de ce que l'on sait, il s'agit d'un SoC mono core de type ARM Cortex A9, associé à des unités de décodage vidéo capable de décoder le H.264 jusqu'au 1080p profil "High".

C'est là qu'une des incertitudes traîne sur les capacités réelles du SoC, une des limitations de la première génération de Chromecast était le fait qu'elle ne fonctionnait qu'en 30 Hz. En pratique, Valve annonce Steam Link comme permettant de streamer en 1080p 60 Hz. Nous supposons que la différence vient du fait que le profil H.264 "High" - contrairement aux "Main" et "Baseline" utilisés par Steam - n'est pas géré en 60 Hz par le SoC Marvell.

Que fait donc ce boîtier en pratique ? Lors du premier lancement, après avoir rejoint votre réseau local, il vous sera proposé de lancer le streaming vers les machines qui le proposent dans votre réseau local. Une fois choisi, l'interface Big Picture se lance sur la machine "hôte" et cette dernière stream l'interface vers le boîtier Steam Link. Pour le reste, tout est semblable au streaming local évoqué plus haut, si ce n'est que rien ne tourne en local, et que l'on oublie les problèmes de doubles interfaces. Ainsi, si l'on va dans les options de streaming, on pourra régler en simultanée les options du client (Steam Link) et hôte dans la même interface !

En ce qui concerne les contrôles, on pourra brancher un clavier et une souris, ou un pad (USB/sans fil) sur le boîtier Steam Link. Il est possible de brancher un pad PS3 et Xbox One en filaire, et d'appairer sans fil un pad PS4. Le contrôle sur le PC source reste là aussi possible en parallèle. Valve propose aussi son propre pad, le Steam Controller avec un dongle de connexion en USB au standard WiFi Direct (5 GHz).

En pratique, tout est plus logique et l'on en viendra a regretter que Valve ne propose pas, dans le cas du streaming local, d'autoriser un mode de fonctionnement identique entre deux PC qui simplifierait grandement les choses !

Finissons par l'intérêt principal de cette solution : son prix. Comptez 54.99 euros pour le boîtier.

Nvidia Shield Android TV et GameStream

La dernière solution de notre comparatif est en provenance de Nvidia, avec sa technologie GameStream qui, vous l'aurez deviné avec son nom, permet de streamer les jeux ! Pour utiliser GameStream, il faut disposer côté PC "hôte" bien évidemment d'une GeForce, et pour recevoir GameStream, d'un périphérique Nvidia Shield. Pour notre test, nous avons utilisé la Shield Android TV du constructeur.

Le boîtier est plus imposant que celui de Valve, mesurant 21cm de large par 13 de profondeur et 2.5 cm de hauteur. Le tout pèse 648 grammes ce qui évite définitivement les problèmes de câbles HDMI un peu lourds qui tirent et soulèvent le boîtier.

A l'arrière on retrouve une connectique assez riche. Outre le connecteur d'alimentation, on retrouvera une sortie HDMI 2.0 (compatible 4K), un port Gigabit Ethernet (qui nous aura obligé a utiliser un tournevis pour sortir nos câbles réseaux, un comble !), deux ports USB 3.0 un port micro USB 2.0 ainsi qu'un lecteur de carte MicroSD. A l'intérieur le SoC utilisé est un Tegra X1 de Nvidia qui mixe quatre coeurs ARM Cortex A57 et quatre coeurs ARM Cortex A53 à un GPU génération Maxwell. La puce gère de multiples décodages y compris H.264 et H.265 et côté réseau on retrouve 802.11ac et Bluetooth 4.1.

Au cas ou le nom de la Shield Android TV ne soit pas assez explicite, le boîtier fait tourner le système Android TV de Google. Si vous souhaitez plus de détails sur les possibilités d'Android TV en général, nous vous renvoyons vers d'autres tests, nous nous sommes intéressés spécifiquement à GameStream, qui est l'une des applications disponibles dans l'interface Android TV (elle est rajoutée par Nvidia dans sa version d'Android TV).


Ici les réglages permettent juste de se connecter/déconnecter

Pour lancer GameStream, il suffit donc de lancer l'application sur la Shield TV, et d'avoir son PC allumé. De la même manière que pour Steam, il faudra être connecté en réseau local, et que le PC (via GeForce Experience, obligatoire pour le streaming) et Shield TV soient connectés au même compte Nvidia. Notez que nous avons dû déconnecter et reconnecter les deux machines du réseau pour qu'elles arrivent a se reconnaître.


Côté réglages, on pourra ajouter manuellement des jeux qui ne seraient pas détectés automatiquement. Rien pour jouer sur le bitrate de l'encodage par exemple, malheureusement

La nécessité d'un compte pour une utilisation de matériel local est clairement une contrainte (et celle-ci se multiplie malheureusement chez les constructeurs sans raison nécessaire), surtout quand le système n'est pas forcément fiable/rodé. Notez que nous utilisons ici la version "publique" de GeForce Experience, la beta de la version 3 en test actuellement imposera directement la connexion pour son utilisation, streaming ou pas.

Ceci passé, la liste des jeux reconnus par GeForce Experience apparaît directement a l'écran et l'on peut choisir le jeu à lancer. Parmi les jeux, on retrouvera aussi Steam. Choisir Steam lancera ce dernier sur l'hôte en mode Big Picture et le résultat est streamé directement vers le boîtier. L'intégration des deux logiciels est très bonne puisque les menus sont adaptés à la présence de GameStream. Bien vu des deux sociétés qui semblent avoir collaboré. La seule anicroche concerne l'impossibilité d'accéder à l'overlay Steam via les touches Shift + Tab sous GameStream, un bug qui date et qui nous aura posé problème dans nos tests.

Notez que Nvidia fournit selon les modèles un pad sans fil. Il est assez lourd, 308 grammes, et le toucher de son plastique n'est pas particulièrement agréable. Il utilise cependant le WiFi Direct ce qui est une bonne chose pour la latence. On pourra brancher à la shield également un clavier/souris. Pour ce qui est des contrôleurs, mêmes limites que pour Steam Link si ce n'est que les contrôleurs PS4 ne marchent pas en sans fil ici (sans modification du firmare en mode root). Il en va de même pour le Steam Controller même avec son dongle.

Android vous obligera également, selon les modèles, à utiliser un logiciel tiers, Virtual Here USB Server , pour "déporter" le port USB vers votre machine distante. Cela déplace le problème, le support dépendra alors des pilotes Windows. Nous vous conseillons de regarder à l'avance la méthode pour utiliser votre pad préféré.

Notez enfin que contrairement à ce que l'on trouve via Steam, il n'est pas possible de prendre contrôle du PC lorsque l'on stream, un écran avec un logo Nvidia recouvrant l'écran de votre PC principal lors du streaming. Pas particulièrement utile et l'on aimerait pouvoir le désactiver !

Côté prix le ticket d'entrée est plus élevé, comptez 199 euros pour le modèle 16 Go, et 299 pour le modèle équipé d'un disque dur 500 Go.

Et Moonlight ?

Une des différences entre les logiciels de Valve et de Nvidia est que le second ne propose pas de solution pour streamer ses jeux vers un autre PC. Officieusement, il existe cependant une alternative avec Moonlight , un logiciel Open Source compatible GameStream disponible pour de multiples plateformes (dont Android et iOS) et également pour Windows.

En pratique le port Windows est réalisé en Java et si l'on peut passer sur bon nombres de bugs, le plus gros problème est qu'il effectue le décodage de manière logicielle (et pas particulièrement optimisée), ce qui réclame une machine beaucoup plus puissante que notre machine de test équipée d'un Celeron. Sachez cependant que la solution existe.

Les solutions que nous n'avons pas retenues

Notez qu'il existe d'autres solutions que nous n'avons pas retenues pour notre test, elles présentent en général des désavantages mais selon les situations, peuvent dépanner. Il faudra distinguer deux problèmes, le flux vidéo (et audio), et le contrôle à distance.

Pour la vidéo d'abord, si la distance est assez courte, notez qu'il existe de longs câbles HDMI. Il n'y a pas de limites dans la spécification et l'on trouve des câbles passifs certifiés jusqu'à 15 mètres de longueur, capables de faire transiter du 1080p. Attention cependant à vous assurer que le câble est bien certifié HDMI pour éviter les déconvenues. Au delà, des câbles actifs existent permettant d'atteindre 30 mètres, mais le prix est généralement conséquent pour des câbles certifiés. Tant qu'elle est physiquement possible, la connexion HDMI filaire est bien entendu idéale.

Il est également possible d'utiliser des boîtiers HDMI sans fil. L'idée est d'encoder directement la sortie HDMI, l'envoyer en réseau, et la décoder dans un boîtier HDMI placé derrière l'écran. Ces solutions visent souvent le cas d'une utilisation dans la même pièce, comme par exemple pour relier un vidéo projecteur à sa source. Ils utilisent en général une connexion WiFi Direct 5 GHz dont la portée est assez courte, et très sensible aux murs. Selon la distance, c'est une solution cependant.

Une dernière option est d'utiliser des adapateurs dits Wireless Display. Egalement connu sous le nom de Miracast, la norme vise surtout le cas ou l'on souhaite relier un PC portable à un diffuseur HDMI dans une même pièce. Pour pouvoir l'exploiter, le PC doit disposer d'une carte WiFi (d'ou son utilisation qui vise principalement les PC portables), Windows s'occupant de capturer, d'encoder, et de transférer le flux vidéo. Bien évidemment la qualité et la latence vont dépendre des adaptateurs, les premiers prix ne sont compatibles que 2.4 GHz en général et leur qualité vidéo assez piètre. Les meilleurs modèles sont compatibles 5 GHz avec les mêmes limites que ce que nous évoquions plus haut. Dans tous les cas, la latence est en prime assez haute, ces adaptateurs visant plus les cas d'utilisation d'entreprise ou de lecture de vidéo distante.


La plupart des adaptateurs nécessitent une prise USB pour s'alimenter

Notez qu'on peut tomber sur d'autres problèmes, le Wireless Display Adapter de Microsoft par exemple, considéré comme l'un des meilleurs modèles et que nous envisagions de tester impose le cryptage HDCP sans raison valable. C'est particulièrement dommage pour les moniteurs/diffuseurs non compatibles, en plus d'être totalement incompatible avec notre protocole de test !

En ce qui concerne le contrôle à distance, on pourra pourra utiliser une manette sans fil pour jouer, avec le récepteur placé sur son PC. Là encore il faudra faire attention aux distances, les manettes Bluetooth ont une portée assez courte, et si le WiFi Direct fait en général mieux, la portée variera en fonction de vos conditions d'utilisation.

De ces solutions, au delà d'un long câble HDMI, les compromis nous paraissent trop importants pour vous les conseiller.

Page 3 - Préalable : Écrans et moteurs des jeux

#Préalable : Écrans et moteurs des jeux]

Pour bien comprendre le fonctionnement des logiciels de streaming, nous allons revenir sur les deux prochaines pages sur la manière dont fonctionne le rendu des jeux, et ce plus particulièrement sous Windows ou le fonctionnement avec DirectX est assez particulier, et s'est grandement complexifié depuis quelques années. En commençant par la fin, à savoir l'écran ! Certains détails peuvent paraître un peu pointus mais ils vous permettront de comprendre le fonctionnement des solutions que nous avons testées.

Un écran à rafraîchissement fixe

Les problèmes autour de l'affichage viennent du fait que les écrans fonctionnent à une fréquence de rafraîchissement fixe. Pour tous les exemples qui suivent, nous allons prendre le cas d'un écran classique ayant une résolution de 1920 par 1080 pixels pour un taux de rafraîchissement de 60 Hz.

Notez pour être complet qu'il existe également désormais des moniteurs avec un taux de rafraîchissement variable, dans un premier temps avec le G-Sync propriétaire à Nvidia, puis désormais avec l'Adaptive Sync, porté par AMD mais qui fait désormais partie de la spécification Display Port. Leurs particularités ne s'appliquent pas au streaming qui reste sur un taux d'image constant, comme nous allons le voir. Nous mettrons donc de côté ces solutions mais sachez qu'elles existent.

En pratique quand l'on parle de 60 Hz, on indique que l'écran reçoit 60 images par secondes en provenance de la carte graphique, et plus précisément une image toutes les 16.66 millisecondes. Une fois l'image reçue, l'écran commence à rafraîchir son panneau avec la nouvelle image, toujours à la même cadence fixe de 16.66 millisecondes.

Si l'on parle de "commencer à rafraîchir", c'est que cette étape en elle même prend du temps. Dans le cas d'un écran LCD, les pixels sont indépendants et seuls ceux qui ont changés depuis l'image précédente changent de couleur. Contrairement aux écrans cathodiques d'antan, il n'y a plus (hors modèles spécifiques) d'effet de balayage, même si l'on peut parfois percevoir un scintillement sur certains modèles. En pratique, ce que l'on perçoit est le scintillement du rétroéclairage (une source lumineuse placée derrière les LCD, souvent à base de néons ou de leds) qui, lorsque la luminosité n'est pas au maximum, peut être contrôlé par un PWM (qui allume et éteint rapidement le rétro éclairage pour réduire la luminosité "perçue").

Si un pixel était blanc sur l'image précédente et passe au noir sur la suivante, le pixel va amorcer sa migration, passant par une série de gris avant d'arriver au noir, une étape qui prend selon les écrans quelques millisecondes, vous pouvez le voir ici en pratique :


Sur notre écran de test, il faut compter environ 3,7 millisecondes pour voir l'écran passer du noir au blanc, on le voit ici augmenter progressivement sa luminosité avant d'arriver au niveau de blanc. Il est annoncé par le constructeur avec un "temps de réponse" de 2 millisecondes

Qui plus est, toutes les transitions de couleurs ne vont pas s'effectuer exactement à la même vitesse ! Passer du blanc au noir, le grand écart, n'est pas forcément le plus lent sur les écrans modernes, les transitions de couleurs éloignées mais non absolues (orange clair a violet foncé au hasard, ou plus conventionnellement gris clair vers gris foncé) pouvant être plus longues. Tout dépend évidemment des technologies utilisés par les moniteurs.

En pratique, si la réactivité de l'écran joue évidemment son rôle sur la latence que l'on va percevoir dans les jeux, ce n'est qu'une toute petite partie de la chaîne. Le taux de rafraîchissement va par contre avoir un impact décuplé par la suite.

Un moteur de jeu : CPU + GPU

Le lien entre l'écran et le PC reste bien entendu la carte graphique. C'est elle qui évidemment est reliée à l'écran, et qui a pour tache d'envoyer les images dans la bonne résolution, et au taux de rafraîchissement supporté par l'écran.

Mais en pratique la carte graphique n'est pas le centre du PC, d'un point de vue technique elle reste un périphérique asservi et piloté par le processeur qui reste le centre de tout. En pratique la carte graphique dispose d'une grande autonomie, mais elle doit être dirigée par un jeu et son moteur graphique.

Qu'est ce qu'un moteur de jeu donc ? Il s'agit d'une application tournant sur le processeur, qui va remplir plusieurs tâches dans une boucle infinie :

  • Récupérer les informations récentes (clavier, souris, réseau, etc...)
  • Mettre à jour le modèle de simulation du jeu en fonction des informations et du temps passé depuis la dernière image calculée
  • Effectuer les tâches nécessaires pour que le GPU puisse calculer la prochaine image
  • Donner l'ordre à la carte graphique de calculer une image, puis de "l'afficher"

La première parait évidente. En pratique au début de la boucle, le moteur interroge et récupère les derniers événements des joueurs, comme par exemple vos pressions éventuelles sur le clavier, la souris ou un pad, et éventuellement des informations en provenance d'un serveur dans le cas d'un jeu réseau.

Ces informations vont servir à mettre à jour le "modèle" de simulation du jeu, c'est la seconde étape. Si vous avez appuyé sur le bouton du frein dans un jeu de voiture par exemple, la vitesse du véhicule va devoir diminuer (de quelle manière, dans quelle proportions est la tâche du moteur qui regarde par exemple la force de pression sur un bouton analogique, ou qui peut prendre en compte le temps qui s'est écoulé depuis que vous avez commencer à appuyer sur le frein, etc...). L'autre étape primordiale est de calculer le temps qui s'est écoulé depuis la dernière image calculée.

Pour commencer, nous allons imaginer le cas où la synchronisation verticale est active, c'est à dire que l'on ne va pas tenter de calculer plus d'images que l'écran ne peut en afficher. Dans un monde parfait, il s'est donc écoulé exactement 16.66 millisecondes. Pendant ces 16.66 millisecondes, notre voiture s'est déplacée. En fonction de la vitesse, de la direction de la voiture, et éventuellement d'autres facteurs, le moteur calcule le nouvel emplacement du véhicule sur la piste.

Outre la modélisation interne au moteur (comme la vitesse ou la position), il faut mettre à jour la représentation géométrique. Notre voiture s'est déplacée, on connaît sa position, mais il faut également déplacer les triangles qui la composent. On va également déplacer en avant la caméra qui a avancé. Une jauge indiquant les freins va aussi changer de couleur et l'on pourrait même voir apparaître de la fumée autour des roues suite à un blocage de roues (ce qui nécessite de rajouter des effets).

Le travail préparatoire reste effectué sur le CPU avant que l'ordre final (des buffers de commandes) soit envoyé au GPU pour qu'il calcule l'image. Dans un monde idéal, il est obligatoire de limiter au maximum les interactions entre le CPU et le GPU qui doivent être capables d'effectuer leurs tâches respectives de manière indépendante. Si la synchronisation verticale est appliquée, DirectX va "bloquer" le moteur CPU pour s'assurer que la boucle ne soit pas exécutée plus de fois que nécessaire.

Si l'on tente de résumer cela par un schéma, on retrouve quelque chose qui ressemble à cela, nous prenons le cas de trois images successives (A, B et C) et nous regardons les étapes par lesquelles elles passent :

Vous retrouvez sur cette frise le temps qui s'écoule en millisecondes, chaque période de 16.66 ms étant matérialisée. Parlons d'abord des événements sur le pad dans notre cas du jeu de voiture (ou clavier/souris). Il y a de fortes chances pour que vos appuis sur le pad ne soient pas alignés parfaitement avec le rythme imposé par votre écran. Quand le moteur (en bleu) va récupérer les dernières informations, un temps s'est écoulé depuis le moment ou vous avez appuyé sur le bouton, et il est par définition variable et incompressible. Il prend en compte la transmission de l'information par le pad (via éventuellement un récepteur sans fil, puis une couche USB, jusque aux API DirectInput/Xinput de Microsoft) jusqu'au moteur.

Le moteur travaille ensuite à la préparation de l'image, pour l'exemple le temps reste limité à 8 millisecondes. Dans un monde idéal, un développeur de jeu voudra maximiser au mieux l'utilisation du processeur en utilisant au mieux l'intervalle qui lui est donné (16.66 ms ici) tout en s'assurant de rester impérativement en dessous ! Passer au dessus décalerait tout.

Ensuite, le GPU va enfin calculer l'image a partir des commandes qu'il a reçu, un travail qu'il fait quasiment seul (piloté plus ou moins par le driver graphique qu'on mettra de côté, en fonction de la version de DirectX utilisée), on le voit en vert. Il y aura toujours un décalage entre le moment ou le moteur va commencer à préparer l'image et celui ou le GPU va la calculer : c'est normal. Pendant que l'image A est calculée par le GPU, l'image B est préparée par le CPU, et ainsi de suite. Le rendu de l'image dans notre exemple prend 15 millisecondes. La encore, on reste sous le couperet des 16,6 ms.

Le rendu de l'image s'effectue dans un buffer et l'image "complète" est disponible à la fin du rendu (soit 33ms tout de même après que le CPU ait commencé à travailler !), prête à être affichée... ou presque !

Page 4 - Préalable : DXGI, Swap Chain, V-Sync, Tearing...

# DXGI, Swap chain

Notre schéma page précédente reste simpliste, en pratique l'image rendue n'est pas affichée aussitôt à l'écran. Sous Windows, cette gestion des buffers est assez particulière, et s'est complexifiée ces dernières années. Pour l'exemple toujours, nous prenons le cas d'une application qui tourne en plein écran avec la synchronisation verticale activée.

Windows dispose depuis Vista d'une API baptisée DXGI  qui regroupe les tâches de bas niveau. Parmi celles-ci on retrouve le rôle essentiel de la swap chain.

L'image qui vient d'être rendue par le GPU n'est en effet pas directement affichée à l'écran. Etant donné qu'on ne peut jamais prédire réellement quand la prochaine image sera prête, il est nécessaire d'avoir un mécanisme qui permet d'avoir toujours quelque chose à afficher. Résultat, l'image qui est actuellement affichée à l'écran est stockée dans un buffer (appelé front buffer) dont le contenu n'est pas modifiable.

L'idée de la swap chain est assez simple, DXGI gère en pratique pour le jeu une "file" de buffers. A l'image d'une file d'attente, les images rendues par le GPU prennent place dans la file au fur et a mesure qu'elles sont calculées, celle qui est en tête de la file étant affichée quand vient son tour (le haut de la file est considéré comme le front buffer, les suivantes des back buffers). Le nom de swap chain (également appellée flip queue) vient du fait qu'en pratique l'ordre des buffers est changé de manière virtuelle : dans le cas de trois buffers A, B et C, le front buffer se "déplace" d'un cran à chaque fois comme vous pouvez le voir sur ce diagramme de Microsoft.


La position des buffers en mémoire sur la carte graphique ne change pas, chaque flip déplace les pointeurs

En pratique, il y a beaucoup d'avantages a avoir une file d'images prêtes à être affichées. Plus le nombre de buffers est élevé et mieux on peut parer à des ralentissement et éviter les saccades. L'inconvénient est qu'augmenter la taille de la file rajoute de la latence.

Qu'est ce que cela donne en pratique ? Voici notre diagramme (à peu près) complet, avec une swap chain de 4 images :

Nous vous montrons toujours le parcours de trois images. Ici les images sont rendues dans le dernier back buffer, en bas de la file, puis remontent la file au fur et a mesure pour arriver jusqu'au front buffer, puis d'être enfin visibles à l'écran (cf page précédente).

Vous pouvez voir qu'en pratique la latence peut paraître élevée, quasi 100 millisecondes entre le moment ou l'on appuie sur notre pad et le moment ou l'image est visible à l'écran pour cet exemple.

Le nombre de buffers joue un rôle primordial sur la latence, mais il n'y a pas de constante d'un jeu a l'autre. En effet, chaque jeu peut choisir la longueur de sa swap chain lorsqu'il démarre et selon les techniques de rendu utilisées, certains peuvent avoir besoin de chaînes plus longues que d'autres. En général on dispose toujours au minimum de 2 ou 3 buffers sous DirectX

Certains jeux permettent parfois de réduire le nombre d'images précalculées, c'est le cas de Project Cars par exemple qui dispose d'un réglage dans ses options. Les drivers peuvent aussi interférer sur le réglage, directement chez Nvidia, et via un utilitaire tiers chez AMD.

Cependant, réduire au minimum le nombre de back buffers est en pratique une fausse bonne idée. Si vous réduisez la latence théorique, en pratique tout ira bien si votre carte graphique et votre processeur sont toujours capables de fournir des images toutes les 16.6 ms. S'il y a un ralentissement quelconque, vous augmentez dramatiquement le risque que la file soit vide, et donc que la carte graphique soit obligée de renvoyer à l'écran la même image qu'au cycle précédent. Et comme le rendu du moteur CPU reste, V-Sync oblige, reste cadencée a l'écran, l'impression de saccade est très perceptible.

Et sans V-Sync ?

Si l'on désactive la synchronisation verticale, les choses se compliquent un peu. Sur le fond l'idée est simple, le moteur n'est plus synchronisé avec le taux de rafraîchissement de l'écran, il peut donc tenter de calculer un maximum d'images. Pour l'exemple nous avons pris un cas ou le CPU n'est pas limitant, et le GPU est capable de calculer 120 images par secondes :

A chaque image rendue, l'image est ajoutée à notre file, faisant remonter les autres à l'exception du front buffer qui reste lui toujours synchronisé à l'écran. Dans notre cas, seule une image sur deux calculée est affichée, notre écran reste toujours limité a 60 images par secondes.

Est ce mieux qu'avant ? Sur la latence, on peut voir qu'en moyenne elle va être plus basse, même si l'on peut se retrouver avec une variance un peu plus grande qu'auparavant entre le moment ou l'on appuie sur le bouton et le moment ou l'image est visible. Si l'on extrapole, on peut voir que plus les rendus CPU et GPU seront rapides, et plus la latence sera réduite.

Bien évidemment, calculer des images qui ne seront pas affichées ne sert à rien et fait augmenter la consommation et les nuisances sonores de sa machine.

Les choses deviennent beaucoup plus problématiques lorsque l'on considère le fait qu'en pratique, et contrairement à nos exemples, le temps de calcul n'est pas constant d'une image à l'autre. Dans notre exemple du jeu de voiture, un grand nombre de véhicules a l'écran fera baisser les performances. Ces variations peuvent faire que l'on se retrouve dans un cas ou notre file est vide ou quasiment. Plus la file est courte, et plus ce risque est important.

Les opérations de copies dans les buffers n'étant pas immédiates, on peut se retrouver avec un cas ou le GPU était entrain de copier une image dans le premier back buffer (en première position dans la file) au moment même ou l'écran réclame sa nouvelle image. Résultat ? Sous Windows en plein écran, on se retrouve avec cela :

On retrouve en bas de l'écran un bout de la nouvelle image, et en haut les restes de l'ancienne image (avec un bout d'une autre image encore plus ancienne !). Un effet de déchirement appelé tearing en anglais.

Windows et le tearing

Si la cause du tearing est connue, elle intervient avant tout parce que les API de Microsoft font le choix explicite d'afficher des images qui ne sont pas complètes, plutôt que d'attendre une nouvelle image complète a afficher. Ce choix historique de Microsoft est encore présent aujourd'hui dans les jeux lorsque l'on est en mode plein écran.

Le mode plein écran est lui même quelque chose d'ancien. Historiquement, les jeux prenaient complètement la main sur l'écran, oubliant tout le reste de Windows. Un mode explicite qui n'existe plus vraiment dans les Windows modernes. Vous le savez sûrement, depuis Windows Vista, Microsoft à introduit DWM, son nouveau bureau accéléré par la carte graphique. En pratique, chaque fenêtre dispose de son propre buffer (une surface dans le langage de Microsoft) et la carte graphique est utilisée pour "composer" l'affichage.

Or, même si vous tapez très vite dans votre traitement de texte, vous aurez remarqué qu'il n'y a jamais d'effets de déchirements à l'écran ! Pour une bonne raison : DWM n'autorise pas le tearing, seuls des buffers complets sont utilisés.

La synchronisation verticale n'est cependant pas forcée ce qui fait qu'il est possible de cumuler l'absence de tearing et l'absence de V-Sync... en utilisant quand les jeux le supportent le mode "plein écran fenêtré". Un mode très utile à ceux qui possèdent deux écrans.

Dans ce mode, on passe par DWM pour le rendu ce qui pourrait paraître pire pour la latence. En pratique il n'en est rien : sous Windows 10, nous trouvons une latence strictement identique en mode plein écran "pur" et en mode fenêtré. Historiquement ce n'était pas le cas, passer par un mode "exclusif" était préférable pour la latence.

La raison de cette non différence tient probablement dans le fait que le mode plein écran "exclusif" ne l'est plus vraiment sous Windows 10, du au fait que Microsoft veut pouvoir "composer" par dessus les jeux ses notifications qui ne sauraient attendre :


Au cas ou vous auriez oublié avoir volontairement désactivé Windows Defender 20 secondes avant, une notification bien utile vient vous le rappeler en plein jeu ! Cela change de la publicité pour Office qui est apparue juste avant !


Page 5 - Mesures de latence

#Mesures de latence

Afin de mesurer la latence des différentes solutions, nous avons mis au point un protocole de test assez particulier dans le but d'obtenir les mesures les plus réalistes possibles. Notre but étant d'obtenir des mesures exactes entre le moment où l'on appuie sur un bouton, et le moment où l'écran réagit.

Pour cela, nous avons choisi d'utiliser un Steam Controller que nous avons démonté afin d'y récupérer de manière électrique l'information de l'impulsion sur l'un des boutons du pad. Le câble qui récupère l'information est branché dans un oscilloscope.

Une seconde entrée de l'oscilloscope est reliée à une photodiode qui permet de mesurer l'intensité lumineuse. Celle-ci est placée sur un écran Iiyama ProLite E2283HS, un écran 22 pouces 1080p disposant d'un taux de rafraîchissement de 60 Hz. Il est équipé d'une dalle TN et dispose d'une entrée HDMI. Cet écran est annoncé par son constructeur avec un temps de réponse de 2 millisecondes.

Nous avons enfin développé une application en C++ utilisant l'API DirectX 11 de Microsoft (et DXGI/DirectInput) qui est lancée sur notre PC principal (celui qui stream vers les diverses solutions). Son fonctionnement est simple : elle affiche un carré blanc à l'écran. Lorsque l'on appuie sur le bouton du Steam Controller, l'API DirectInput avertit le programme qui change la couleur du carré en noir. Lorsque le bouton est relâché, le carré redevient blanc. En parallèle, l'application pilote également l'oscilloscope USB qui enregistre de manière indépendante les informations du contrôleur et de la photodiode sur toute la période du test, et ce toutes les 0.1 millisecondes. Les données sont enregistrées et analysées par la suite.

Nous mesurons via les données collectées par l'oscilloscope le temps exact (à 0.1ms près) qui s'est écoulé entre le début de la pression sur le bouton (indiqué par une baisse de tension via le câble soudé sur le contrôleur) et le moment ou la photodiode voit l'écran commencer sa transition du blanc au noir (comme expliqué précédemment dans notre article). Nous mesurons également en sens inverse le moment ou le bouton est relâché, et le moment ou l'écran entame sa transition du noir au blanc.

Etant donné que l'écran ne se rafraîchit que toutes les 16,67 millisecondes (en 60 Hz), et que nos pressions sur le bouton sont aléatoires, nous effectuons pour chaque test une moyenne sur 500 mesures, afin de lisser au maximum la variabilité.

Pour être parfaitement complet, indiquons que le Steam Controller est branché directement sur le PC principal. Nous avons dû faire cette concession du fait que le Steam Controller n'est pas supporté directement par la console Nvidia Shield TV. S'il existe des solutions alternatives (fonctionnelles) comme par exemple Virtual Here USB Server , nous avons été confronté à un autre bug de GameStream, qui ne permet pas d'afficher l'overlay Steam (accessible par les touches Shift+Tab), nécessaire pour configurer correctement le Steam Controller.

Cette concession n'est pas très grave : nous avons mesuré en pratique une différence d'environ 1 milliseconde entre un branchement sur le PC principal, et un branchement sur le boîtier Steam Link pour vous donner une idée.

Notez également que pour vous donner un ordre de grandeur le plus réaliste possible, nous utilisons le Steam Controller en mode sans fil. Ce dernier peut être utilisé au choix en mode USB filaire, ou en mode WiFi Direct via un dongle fourni. Il s'agit d'une connexion WiFi point à point entre le contrôleur et son dongle, ne nécessitant pas de routeur (le pad Xbox One utilise également le WiFi Direct). Nous avons mesuré à moins de 2 millisecondes le coût de cette implémentation sans fil, soit quelque chose de très négligeable lorsque l'on la compare au confort qu'elle apporte, c'est pour cela que nous l'avons utilisé.

Pour terminer, notre PC principal est relié aux différentes solutions de streaming en Gigabit Ethernet via un switch. Nous n'utilisons pas le WiFi, ce dernier n'ayant qu'un impact mesuré sur la latence (vous pouvez vous en rendre compte en pingant votre routeur). Le problème principal du WiFi tient au débit et sa stabilité dans le temps en fonction des interférences éventuelles, nous l'évoquerons un peu plus tard dans l'article.

Configuration

Notre PC principal est équipé comme suit : - Intel Core i7 6700K - Asus Z170-A - GeForce GTX 970/Radeon R290X - Windows 10

Nos solutions de streaming sont pour rappel : - Boitier Steam Link - PC Asus VivoPC VM42  (Intel Celeron 2957U) + Steam sous Windows 10 - Nvidia Android Shield TV

On notera que l'utilisation de Windows 10 est particulièrement contraignante sur le mini PC équipé d'un Celeron. Windows 10 démarre en effet un certain nombre de tâches à sa convenance, et il nous est impossible de les débrayer, nous obligeant a réaliser plusieurs fois les tests tant les ralentissements constatés sur un petit CPU sont importants.

Qu'il s'agisse de l'anti-malware (qui même désactivé temporairement exécute tout de même un processus pouvant saturer un core), le .NET optimizer ou les vérifications périodiques de mises à jour, ces multiples processus sont une plaie qu'il faudra prendre en compte si vous optez pour cette solution, tant l'impact est visible à l'oeil nu lorsqu'il s'agit de streaming !

Passons enfin aux mesures !

Latences mesurées

Nous avons mesuré la latence avec et sans V-Sync avec les différentes solutions et les différents encodeurs supportés. Pour le cas de l'Android Shield TV, l'encodage est réalisé par la GeForce sans possibilité de réglages. Pour les solutions Steam, on a le choix entre les encodeurs H.264 suivants :

  • CPU (libx264)
  • AMD AMF
  • Intel Quicksync
  • Nvidia NVENC
  • Nvidia NVENC + NVFBC

Nous ajoutons également une mesure sur le PC en local, sans streaming. Avant toute chose, notons qu'il existe une incompatibilité entre l'encodeur H.264 AMD (AMF) et le décodage QuickSync. Ce dernier est inutilisable dans nos tests sur notre machine, un bug qui n'apparaît qu'avec cette combinaison qu'on évitera. L'encodage AMF, décodé par le petit SoC Marvell du Steam Link ne pose aucun problème ce qui laisse penser que le problème est lié a QuickSync.

Nous commençons avec la synchronisation verticale désactivée :


Commençons par la mesure locale, cette dernière est particulièrement basse. On le doit en grande partie au fait que notre application de test, sans V-Sync, tourne à près de 5000 FPS sur notre machine. Conformément à ce que l'on expliquait précédemment, on compare donc ici le meilleur cas possible localement en matière de latence, ce qui nous donne une bonne idée du coût réel du streaming.

Le cout dépend de deux facteurs, tout d'abord les plateformes. Indépendamment des encodeurs utilisés, on voit une tendance nette : l'Android Shield TV reste la plus lente, suivie de notre mini PC sous Windows 10, et enfin de Steam Link. Ce petit boîtier est significativement plus rapide que les autres solutions.

Ensuite il faut prendre en compte les encodeurs. La encore on note des différences a peu près communes entre les plateformes. Quicksync est en général la solution la plus lente, suivie d'AMD AMF puis du mode CPU qui reste très rapide au final sur notre véloce Core i7 6700K. Ce sont les solutions d'encodage Nvidia qui disposent de la latence la plus faible, et plus particulièrement du mode NVFBC. Nous reviendrons rapidement sur ce qui le différencie, mais regardons avant ce qui se passe lorsque l'on active la synchronisation verticale :


Le streaming plus rapide que le rendu local ? Oui, et pas qu'un peu, on retrouve jusque 30 millisecondes d'écart avec une machine Steam Link et l'encodeur Nvidia par rapport au rendu sur l'écran.

C'est là que nos explications sur le rendu rentrent en compte. On pourrait croire que les solutions de streaming capturent l'image qui va être affichée à l'écran (le front buffer), l'encodent, et l'envoient vers le réseau. Cela ne marche pas ainsi !

En pratique, les solutions de streaming vont récupérer les images dans les back buffers, plus précisément dans le buffer "complet" le plus en bas de la swap chain. Si l'on reprend notre schéma :

L'image sera récupérée dans le dernier back buffer (le 3), une fois que la copie à été réalisée par le GPU, ce qui permet de gagner un temps significatif par rapport au moment ou l'image doit être affichée à l'écran ! Ce temps est utilisé pour encoder, transférer, puis décoder l'image et l'afficher immédiatement sur la machine distante, ce qui peut être plus rapide en pratique en fonction de la longueur de la swap chain utilisée par l'application.

L'idée est plutôt bonne et il faut savoir que et Steam, et Nvidia utilisent ce principe.

Steam a cependant une autre optimisation. Si vous comparez les valeurs entre V-Sync activé et désactivé, vous noterez que les valeurs sont sensiblement identiques pour les solutions Steam. C'est l'autre astuce de Steam, ils désactivent la synchronisation verticale sur le PC source. Encore une fois si l'on se réfère à ce que nous expliquions page précédente, on comprends l'idée : en désactivant la synchronisation verticale on limite au maximum la latence du moteur ce qui laisse plus de marge pour l'encodage.

Qui plus est, l'encodeur ne transmettra jamais plus de 60 images en pratique à la destination. Ce qui fait que V-Sync actif ou pas, en pratique on se retrouvera avec seulement 60 images par secondes transférées... et une absence de tearing. Là encore c'est un choix effectué par Nvidia et Steam : ils ne capturent et n'encodent que des images qui ont été rendues dans leur intégralité. En quelque sorte, l'esprit du V-Sync est présent, qu'il soit actif ou non dans les jeux, il est simplement déporté de DXGI vers la solution de streaming. L'idée est plutôt astucieuse et si l'on pourra toujours pinailler sur cette optimisation non débrayable, en pratique nous avons du mal à voir un point négatif.

Cette optimisation est effectuée au niveau des routines de capture de Steam, on peut s'en apercevoir en regardant le cas particulier des NVFBC qui payent très cher l'activation du V-Sync. Derrière cet acronyme (NV Frame Buffer Capture), on retrouve une méthode alternative de capture des buffers de l'écran, réalisée directement au niveau de la carte graphique sans devoir repasser par la mémoire centrale. L'intérêt est qu'il est possible via les API de Nvidia d'envoyer directement le buffer capturé vers l'encodeur ce qui permet à la solution d'avoir une latence très serrée, on le voit lorsque la synchronisation verticale est désactivée.

Cependant attention, la capture n'est pas la même ! Ainsi, dans les jeux, Steam va privilégier la capture de la swap chain du jeu, tandis que le mode NVFBC effectue la capture dans la swap chain de Windows. Cela permet d'avoir (joie !) une capture des notifications. Théoriquement, il y a un petit avantage à capturer directement le frame buffer de l'application, et non celui de Windows. En pratique, s'il existe, il est minime et les gains apportés par le fait d'effectuer les opérations directement sur la carte graphique sont largement supérieurs.

Et le mode "Bande passante illimité" ?

Dans la présentation de Steam, nous vous indiquions que choisir le mode de bande passante illimité augmente la latence, d'après l'interface. Dans nos tests, ce n'est pas le cas, nous n'avons pas noté de différence entre le mode de bande passante automatique et l'illimité, et ce indépendamment de l'encodeur utilisé, entre deux machines Steam.

En résumé...

Pour résumer tout cela, la latence reste globalement particulièrement bonne en streaming avec les diverses solutions, à condition de privilégier la désactivation de la synchronisation verticale. Dans le pire des cas, on se retrouve avec une latence proche de celle d'un jeu ou la synchronisation verticale est activée, et parfois bien en dessous. Si le mode de capture alternatif de Nvidia a clairement l'avantage, reste à voir comment tout ce la se traduit sur la question de la qualité d'images, au moins aussi importante que celle de la latence !

Page 6 - Encodage H.264, bande passante et WiFi

#Encodage H.264, bande passante et WiFi

Comme nous l'indiquions un peu plus tôt, les solutions que nous testons exploitent les API d'encodage H.264 accélérées présentes dans les processeurs et cartes graphiques. Ces solutions ne sont pas nouvelles, nous avions eu l'occasion de les évoquer il y a quelques années dans cet article et plus récemment dans les tests des nouvelles architectures processeurs comme Skylake.

Certaines de ces solutions sont rapides, très rapides même avec un encodage plus rapide que le temps réel. Mais attention, leur mode de fonctionnement ne correspond pas à ce dont on a besoin.

En effet, une des particularités de H.264 est qu'il est capable pour compresser, de faire références à différents types d'images. Les images sont découpées en blocs et les frames peuvent contenir des blocs de différents types. En fonction des types de blocs qu'elles contiennent, on leur donnera un nom différent.

Vous pouvez retrouver une explication plus complète dans cet article , mais pour rappel, on retrouve en H.264 trois types d'images (appelées frames) :

  • I-Frame : Une image qui ne fait référence qu'a elle même, et peut être décodée sans informations supplémentaires. On parle pour les blocs qui la composent d'intra-prédiction.
  • P-Frame : En plus d'autoriser des blocs intra-prédit, les blocs d'une P-Frame peuvent également faire référence à une image précédente. On parle d'inter-prédiction (prédiction d'une image vers une autre).
  • B-Frame : En plus d'autoriser les blocs intra-prédit et inter-prédit, les blocs des B-Frames peuvent faire référence à une image future.

Ce schéma résume la situation :

Les B-Frame sont un point important de H.264 et les encodeurs matériels les utilisent, comme le montre cette image issue d'un article précédent sur le sujet :


En bleu, les blocs inter prédits (prédiction temporelle, par rapport à une image précédente), en orange/rouge, les blocs intra prédits (prédiction spatiale, à l'intérieur de l'image). En vert, les blocs qui viennent du futur : ils font référence à une image suivante !

Vous l'avez peut être deviné, les blocs B vont être problématiques dans notre application. En effet, pour pouvoir décoder une B-Frame, il faut disposer des images futures à laquelle elle fait référence ! Evidemment les références sont toujours proches, on ne va pas faire référence à une image à la fin du film pour une image au début : une fenêtre de quelques images est autorisée, et le décodeur s'assurera d'avoir les images prêtes à l'avance. En pratique, cela impose un délai entre le décodage de l'image et son affichage. Sur un tuner TV, travailler sur un buffer d'une seconde d'avance n'est pas un problème. Pour du streaming de jeu, c'est bien évidemment impossible ! D'autant qu'il faudra rajouter la même fenêtre au niveau de l'encodage !

Pour parer à ce problème, les API des divers constructeurs proposent un mode de fonctionnement spécifique qualifié de "basse latence". En pratique ces modes désactivent l'utilisation des B-Frames, limitent la quantité de blocs "I" (ils sont plus gourmands en bande passante et en temps d'encodage), et limitent la nombre d'images référençables en arrière. Vous pouvez trouver un exemple de ces limites dans le cas d'Intel sur un article disponible sur leur site . On y apprends par exemple qu'ils recommandent d'encoder en ne faisant des inter-références qu'a une seule image en arrière !

Ces limites vont bien évidemment avoir un impact important sur la qualité visuelle de l'image. Pour compenser, une solution utilisée à la fois par Valve et Nvidia est d'augmenter le débit.

Bande passante

Nous avons mesuré la bande passante utilisée par les différentes solutions, nous mesurons le débit moyen sur 10 secondes lors d'une scène complexe sous Project Cars :


[ Mo/s ] [ Mbit/s ]

Nous indiquons la bande passante en Mo/s et en Mbit/s, la seconde étant plus généralement utilisée pour évoquer les bitrates des vidéos. Première constatation donc, ces débits sont excessivement élevées, autour de 30 Mbit/s, ce qui correspond au débit moyen d'un Blu-Ray !

On notera que pour GameStream, Nvidia vise un peu au dessus de Valve mais les débits restent comparables. Il n'y a pas de réglage de débit possible pour l'instant chez Nvidia. Chez Valve, nous vous indiquons ici le débit du mode Automatique par défaut.

Si vous vous demandez pourquoi Valve a choisi ce qui ressemble a une limite de 30 Mbit/s pour tous les encodeurs, la réponse est a chercher dans Steam Link : c'est une limitation du SoC Marvell 88DE3005 que nous a confirmé Valve, impossible d'aller au delà. Résultat la valeur par défaut est appliquée aussi pour le streaming local. Quid du mode illimité ?


[ Mo/s ] [ Mbit/s ]

La bande passante explose et l'on dépasse les 100 Mbit/s. Le Gigabit Ethernet sera largement conseillé pour exploiter ce mode.

Et en WiFi ?

Nous en parlions dans la section consacrée à la latence, l'utilisation du WiFi pour le streaming pose un problème a cause de la stabilité, ou non, de la connexion. En effet, si l'influence sur la latence est minimal, la nécessité de la minimiser empêche d'utiliser des solutions de mitigations classiques utilisées par exemple par les lecteurs de vidéo distants (comme par exemple Kodi ou Plex). Pour limiter l'impact de l'instabilité du WiFi, les logiciels de ce type utilisent un buffer de plusieurs secondes qui permet de lisser les éventuelles congestions réseaux. Une technique qui, a l'image des B-Frames n'est pas utilisable.

Le problème du WiFi vient avant tout des bandes de fréquences utilisées, 2.4 GHz et 5 GHz qui peuvent également l'être par d'autres appareils dont les radios (mais pas seulement, comme le montre cette étude d'Intel... sur les câbles USB 3 ! ) peuvent interférer. Résultat, votre point d'accès surveille d'éventuelles interférences et attendra - si elles sont courtes - qu'elles s'arrêtent pour envoyer les paquets. Si les interférences persistent des paquets peuvent être perdus et devront être renvoyés.

S'ajoute aussi la problématique en milieu urbain des réseaux de vos voisins. Les points d'accès vont de la même manière se surveiller et se synchroniser pour éviter de se marcher sur les pieds. Une politesse qui à du sens quand l'idée du WiFi est de transférer rapidement, en une fois, des données avant de libérer les ondes. Transférer des grandes quantités de données en continu, bien que possible, n'est pas le cas d'utilisation idéal du WiFi.

Cela veut il dire qu'il faudra oublier totalement l'idée de streamer en WiFi ? Non, mais il faut être conscient qu'en fonction de votre domicile et de votre installation, les résultats peuvent être très variables !

Pour vous donner une idée de la qualité de votre réseau, un test simple consiste a copier un gros fichier entre les deux machines en regardant en temps réel le débit (soit via le moniteur de ressources de Windows ou tout autre logiciel de ce type). Plus que le débit, qui devra être au dessus de 4 Mo/s (ou 13 Mo/s si vous visez le mode illimité dans Steam), c'est sa stabilité dans la durée qui va compter. Si vous voyez des moments de pause dans la copie ou des baisses, il y a de fortes chances pour que l'expérience de streaming soit imparfaite. Dans le cas de Steam, si ce dernier détecte que votre bande passante pose problème, il pourra réduire le débit ou le framerate, ce qui aura dans les deux cas un effet assez désastreux même s'il permet de parer à des problèmes courts.

Pour terminer, on vous donnera quelques conseils pour maximiser vos chances :

  • Privilégiez le 5 GHz lorsque possible. Le conseil vaut particulièrement en milieu urbain ou la bande de fréquence des 5 GHz est beaucoup moins utilisée (même si elle commence à être déployée de plus en plus dans les box des fournisseurs d'accès Internet). L'inconvénient du 5 GHz est sa portée réduite, il traverse plus difficilement les murs ce qui peut poser problème en fonction de l'emplacement de votre matériel. Sa courte portée joue cependant en votre faveur en évitant également les interférences qui viennent de trop loin.

  • Vérifiez les canaux utilisés. Le standard WiFi définit plusieurs canaux, qui représentent plusieurs bandes de fréquences différentes afin d'éviter les congestions. Pour bien choisir votre canal, il est conseillé de regarder les autres réseaux WiFi présents. De nombreux logiciels existent (y compris pour smartphones/tablettes) vous indiquant la puissance des signaux et le canal utilisé. Privilégiez un canal non utilisé si possible, ou un canal ou il y a le moins de signaux puissants. Attention également à la question de la superposition des canaux. Seuls trois canaux ne se recouvrent pas les uns les autres à 2.4 GHz, les 1, 6 et 11 qu'il faut privilégier au maximum.

  • Optimisez la position de vos antennes. La position des antennes de votre point d'accès WiFi ou de votre récepteur est excessivement importante. Changer leur orientation ou déplacer le point d'accès, en le décollant d'un mur par exemple peut avoir un impact important sur les débits que vous obtiendrez. Ajouter une antenne déportée (plutôt qu'une antenne coudée a l'arrière d'un port PCI) peut largement améliorer vos débits. Et en ce qui concerne la question de la position correcte des antennes pour les appareils qui en ont plusieurs, nous vous conseillons de lire les recommandations du manuel.

En utilisant la méthode du transfert d'un gros fichier, vous pourrez voir l'impact des différents conseils donnés ci-dessus. Dans tous les cas, n'oubliez pas de vous éloigner des antennes durant vos mesures pour éviter les comparaisons faussées. Notez malheureusement que toute la difficulté des interférence réside dans leur caractère ponctuel qui peut les rendre difficile à mesurer. Si vous pouvez en simuler certains (comme allumer votre micro ondes), d'autres sont complètement en dehors de votre contrôle (l'utilisation ou non du WiFi sur le même canal par un de vos voisins).

Notez que d'autres solutions comme le CPL existent, mais là encore entre la bande passante maximale annoncée et la bande passante que l'on peut constater en pratique (par exemple avec notre test de la copie de fichiers), il peut y avoir des écarts drastiques en fonction de la manière dont est implémenté l'installation électrique de votre logement.

Faites également attention en général à la position des adaptateurs CPL, le choix de la prise peut faire grandement varier les performances, et dans le cas ou vous utiliseriez une multi-prise, il est conseillé de placer les adaptateurs en première position. Une fois de plus, reportez vous sur le manuel de votre matériel pour plus de détails sur leur bonne utilisation.

Page 7 - Qualité d'image - Project Cars

#Qualité d'image - Project Cars

Nous avons ensuite comparé la qualité d'image proposée par les différentes solutions. Comme nous l'avons vus, le débit est relativement similaire entre les encodages utilisés. Quid des différences en pratique ?

Pour le voir, nous avons enregistré trois vidéos de scènes sous Project Cars, Act of Agression et The Witcher 3 en 1080p60 sans compression destructrice. Nous rejouons ces vidéos d'une douzaine de secondes dont le débit est excessivement élevé (3 Gbit/s !) avec un lecteur vidéo compatible avec le rendu DirectX activé en mode "plein écran" pour obtenir des conditions similaires. En pratique les mesures de qualité sont identiques qu'elles soient effectuées en jeu ou ainsi : l'utilisation de vidéos nous permet de comparer plus directement les solutions les unes aux autres.

Nous enregistrons ensuite le résultat obtenu via une carte de capture BlackMagic Intensity Pro 4K en 1080p60, là encore sans compression destructrice. Après avoir réaligné les vidéos avec la source, nous comparons chaque vidéo enregistrée avec la source en calculant pour chaque image qui les composent le SSIM.

Pour rappel, le SSIM est un algorithme qui tente de mesurer la similarité structurelle entre deux images, il donne une plutôt bonne bonne approximation de la manière dont l'oeil humain perçoit la similarité entre deux images. L'inconvénient du SSIM est que comme tous les benchmarks, il s'agit d'une valeur pour laquelle on peut "optimiser" les encodeurs. Malgré tout les résultats sont assez parlants en général et un SSIM plus élevé signifie, en général, un encodage d'une meilleure qualité.

L'échelle du SSIM se mesure entre 0 et 1. Plus la valeur est proche de 1 et plus la qualité de l'image encodée est identique à la source. Nous utilisons le logiciel qpsnr  pour réaliser ces calculs.

Voici ce que cela donne en pratique, avec pour Steam les réglages de bande passante par défaut (30 Mbit/s) :

Utilisez un navigateur compatible HTML5 pour voir le graphique !

Ce graphique est dynamique, vous pouvez sélectionner les encodages que vous souhaitez comparer. Pour vous permettre de voir plus finement les différences et les comportements des encodeurs, l'échelle s'adapte automatiquement en fonction de votre sélection. Vous retrouvez sur chaque ligne les encodeurs sous Steam Link, Steam en mode 30 Mbit/s et mode bande passante illimitée.

Par défaut nous avons sélectionné tous les encodages capturés sur Steam Link, c'est en effet la seule plateforme qui permet de comparer tous les encodeurs matériels (pour rappel, l'encodage AMD ne se décode pas via QuickSync).

Notre scène sous Project Cars correspond au passage dans un tunnel. Vers la fin, la voiture sort du tunnel ce qui provoque un changement important de contenu visuel, et aussi de luminosité que gèrent assez mal les encodeurs, d'où la chute vertigineuse de tous les SSIM.

Quand on compare les encodeurs, on peut voir qu'AMD et Nvidia sont au coude à coude, talonnés de très prêt par l'encodage CPU, très efficace lui aussi. L'encodeur d'Intel termine en dernière place assez loin, ce qui est surprenant. Le plus surprenant est peut être le mode de capture NVFBC. Théoriquement ce dernier ne joue que sur la méthode de capture et non sur l'encodage (qui est toujours réalisé via NVENC), mais très clairement il y a une différence nette entre les deux modes.

Il est possible que les API de Nvidia ne permettent pas de régler aussi finement NVENC lorsque l'on envoi les images du CPU que lorsque l'on active la capture + encodage directement sur la carte graphique. Si elles le permettent, Valve aura fait un choix différent qui se remarque nettement sur la qualité.

Pour rester sur le sujet Nvidia, on voit que la qualité d'image mesurée sur Shield Android TV, bien qu'avec une bande passante un tout petit peu au dessus de ce que l'on avait constaté avec Steam Link, est un petit peu en dessous. Nous y reviendrons.

La plus grosse surprise pour nous reste la comparaison, à encodeur égal, entre la qualité mesurée décodée sur Steam Link en mode 30 Mbit/s, et décodée sous Windows 10 via QuickSync. L'impact du décodeur est net, et variable en fonction des paires. Pour les décodages des flux Nvidia et CPU, on voit que la qualité est légèrement meilleure sur Steam Link que sur notre PC sous Windows 10. Par contre l'encodage Intel... gagne significativement en qualité quand décodé par une puce Intel !

Avant de regarder à quoi tout cela ressemble en pratique, notons qu'en mode bande passante maximale, le niveau est nettement au dessus et surtout chute beaucoup moins lors de la sortie du tunnel. Les écarts sont lissés, y compris entre les deux modes de capture Nvidia.

Voyons maintenant à quoi ressemble tout cela en image, avec tout d'abord une capture en entrée de tunnel en début de scène :

Cliquez pour ouvrir le comparateur d'images dans un nouvel onglet

Nous vous indiquions notre surprise de voir l'encodage QuickSync être si mal noté lorsque décodé par Steam Link. On voit clairement pourquoi quand on compare l'encodage Intel à tous les autres : il sacrifie fortement la route. La texture de la route est, décodée sur Steam Link, un amas de blocs, il n'y a pas d'autres mots ! Même le mode NVFBC fait significativement mieux et l'on comprends la hiérarchie.

Quand l'on regarde tous les "W10", c'est à dire les différents modes décodés par QuickSync sur notre Celeron, on comprend pourquoi l'encodage Intel s'en sort mieux sous Windows : la route est littéralement floutée ! Tous les encodages apparaissent légèrement plus flous sur la route, ce qui aide fatalement l'encodage Intel qui en avait grand besoin pour cacher ses très moches artefacts de compression. L'impact du flou se ressent aussi sur la montagne mais d'une manière moins prononcée.

Notez que si augmenter massivement la bande passante permet de gagner a nouveau de la texture sur la route, l'effet de flou apparaît toujours sur les encodages max. Et globalement, sur tous les encodeurs on notera que les HUDs dans les coins inférieurs de l'écran ne sont pas nets.

Terminons par le rendu obtenu sur la Nvidia Shield avec l'encodage par GameStream qui propose de son côté un peu plus de textures. Comparé aux autres encodages Nvidia vu sur Steam Link ou Windows, on est clairement au dessus. La baisse de note s'explique cependant par le fait que pour une raison inconnue, les couleurs ne sont pas correctes ! Les verts apparaissent saturés, ce que l'on voit particulièrement sur le capot, mais qui se ressent sur toute l'image. Nous ne savons pas s'il s'agit d'une particularité d'Android, ou si Nvidia applique de lui même cette correction (possiblement pour "verdir" légèrement l'interface d'Android ?), dans tous les cas cela crée une différence assez dommageable sur les mesures. Dommage car la qualité est plutôt bonne sur ce test.

Voyons maintenant ce qui se passe en sortie de tunnel, pour faire tant chuter la moyenne de nos encodeurs...

Cliquez pour ouvrir le comparateur d'images dans un nouvel onglet

En sortie de tunnel, on est peut être ébloui par le changement de luminosité, mais certainement pas par la qualité de tous les encodages ! Le niveau est excessivement bas. On notera une fois de plus que visuellement, l'encodage GameStream pour la Shield fait bonne impression comparé aux autres encodages 30 Mbit/s sur le niveau de détails, même si la compression de couleurs se fait toujours sentir. On le voit nettement sur les deux lignes du hud en bas a gauche, la verte étant significativement moins floue que la rouge ! Les encodages haut débit font largement mieux que tout le reste et limitent la casse !

En résumé

Bien évidemment les images défilent rapidement sous Project Cars (pour peu que vous rouliez vite !) mais le manque de netteté des HUDs, qui sont eux fixes, est particulièrement visible et ce dans tout le modes, en plus des impressions de manque de qualité et de flou que l'on ressent sur les zones animées rapidement. Bien entendu le bitrate illimité aide, mais la perte de qualité reste nette par rapport à l'original. Voyons ce qui se passe sur une scène un peu plus fixe...

Page 8 - Qualité d'image - Act of Agression

#Qualité d'image - Act of Agression

Passons à un autre style de jeu avec Act of Agression. Il s'agit d'un jeu de stratégie temps réel. Contrairement à Project Cars, on passe dans un RTS beaucoup plus de temps a observer ses unités et ses buildings, ainsi que le terrain.

Les déplacements sont également beaucoup plus contenus, mais pas pour autant faciles : il y a un effet de parallaxe sur la carte. Pour notre test nous avons enregistré une scène au début d'une mission solo. L'écran se déplace de haut en bas et des unités bougent sur l'écran. Cela nous laisse l'opportunité de regarder plus précisément les performances des encodeurs sur des mouvements plus lents. Voyons ce que cela donne en calculant les SSIM :

Utilisez un navigateur compatible HTML5 pour voir le graphique !

On notera que sur la durée mesurée, les SSIM sont particulièrement plats ce qui est une bonne chose, si ce n'est vers la fin ou l'on note un pic. A cet endroit l'écran se noircit nettement et tous les encodeurs peinent sur la première image avant de remonter. Visuellement cependant cela reste relativement imperceptible.

Si l'on se concentre une fois de plus d'abord sur les encodeurs décodés par Steam Link, on retrouve un ordre assez proche de précédemment avec AMD en tête, suivi par l'encodage CPU et NVENC. Une fois de plus les encodages Intel et NVFBC ferment la marche.

Et quand on compare ces encodages, décodés sur un PC avec QuickSync, on retrouve une fois de plus les mêmes phénomènes : perte de qualité sur tout les encodeurs, sauf sur l'Intel qui gagne significativement.

Si l'on passe au bitrate illimité, là encore tous les encodeurs se tiennent dans un mouchoir. Terminons par GameStream pour la Nvidia Shield, qui se place entre les modes CPU et Nvidia sous Steam Link.

Est ce que tout cela se traduit en image ?

Cliquez pour ouvrir le comparateur d'images dans un nouvel onglet

Il y a beaucoup de choses à voir sur ces comparaisons une fois de plus. Et ce que l'on observe a l'écran confirme les scores obtenus plus haut. Des encodages décodés sur Steam Link, l'AMD est le plus convaincant suivi d'assez prêt par le Nvidia, un peu plus flou sur les cratères par exemple. Le mode CPU est assez bon sauf sur le visage en bas de l'écran, ce qui est assez dommage. L'encodage Intel est très flou et produit des artefacts, par exemple tout en bas de l'écran. C'est particulièrement mauvais comparativement aux autres modes. Le NVFBC une fois de plus fait une mauvaise prestation, à peine mieux que ce que propose Intel.

Il est intéressant de comparer ces encodages à celui proposé par GameStream pour la Shield. Mais si l'on compare GameStream à la source, on peut avoir une impression très bizarre, celle que la capture de la Shield offre plus de détails par endroit ! En pratique le fait que Nvidia change la saturation et le contraste des couleurs fait que certains détails ressortent plus, c'est particulièrement visible sur les textures de terrain en bas de l'écran ou le contraste augmenté fait ressortir la version Shield dans les captures, alors qu'il n'y a pas en pratique plus de détails, il y en a moins. On voit sur le visage par exemple que la compression est bien là, et sur le lot d'unités en haut a gauche, on voit apparaître des artefacts rouges. En pratique le niveau reste plutôt très bon mais le changement de contraste et de saturation tend à tromper l'oeil.

On voit qu'une fois de plus, le décodage QuickSync est dommageable sur la qualité d'image pour notre plateforme Windows, avec des zones beaucoup plus floues a encodages identiques. Cela arrange l'encodeur Intel dont le décodeur cache la misère, mais cela reste moins bon que le décodage du pourtant très basique SoC Marvell...

Avoir un bitrate illimité résout la majorité des problèmes et tous les encodages se comportent de la même manière, on ne voit pas vraiment de différence entre les encodeurs, ce qui est assez logique.

En résumé

Sur le papier, une scène plus fixe est plus simple à compresser pour nos encodeurs, qui s'en sortent pour la plupart assez bien. Mais en pratique le fait que la scène bouge moins fait qu'on est beaucoup plus attentif aux détails et aux éventuels artefacts de compression. Le décodage Intel reste par contre un problème tant il crée du flou, seul le bitrate illimité permet réellement de l'effacer.

Voyons maintenant ce que donne un jeu comme The Witcher 3.

Page 9 - Qualité d'image - The Witcher 3

#Qualité d'image - The Witcher 3

The Witcher 3 est un jeu à la troisième personne en vue subjective, on se déplace derrière notre personnage. Nous avons choisi une scène au tout début du jeu ou nous sortons de la pièce principale pour aller vers l'extérieur, elle a l'avantage de provoquer un changement de luminosité important. Regardons ce que cela donne avec le calcul des SSIM :

Utilisez un navigateur compatible HTML5 pour voir le graphique !

Dans notre scène, nous commençons dans le fond de la pièce en restant statique un instant près du feu avant d'avancer vers l'entrée. Plus l'on s'approche de l'entrée et plus le contraste dynamique fait qu'une grande partie de l'écran s'assombrit, faisant remonter les scores des SSIM avant de redescendre progressivement lorsque l'on s'approche de la porte pour sortir.

En commençant sur les encodage décodés par Steam Link, , on retrouve notre trio de tête AMD/CPU/NVENC, avec possiblement un avantage pour la version CPU qui reste plus constante tout le long de la scène.

Une fois de plus l'encodage Intel et le mode de capture NVFBC ferment la marche, avec un petit avantage pour ce dernier mais l'écart est clairement significatif par rapport au reste des encodeurs. La Shield se retrouve une fois de plus avec notre trio de tête, sans surprise.

Le passage au décodage sur notre PC avec QuickSync nous propose le même scénario qu'auparavant : tout le monde est perdant sauf l'encodage Intel qui gagne significativement en qualité. Le résultat reste tout de même assez loin de notre trio de tête capturé avec Steam Link.

Le mode illimité permet de gagner en qualité, et surtout en constance, particulièrement sur la zone au milieu ou les autres encodages baissent significativement.

Regardons comment tout cela se traduit en image, avec tout d'abord une première image extraite de cette zone basse au milieu.

Cliquez pour ouvrir le comparateur d'images dans un nouvel onglet

Les effets de lumière dirigent notre regard vers les détails sur la table. On notera que les couleurs ne sont pas forcément très fidèles avec les divers encodages.

Sur notre personnage principal, on remarquera que l'encodage Intel détruit la texture des cheveux, complètement lisses quand décodé sur Steam Link, et ressemblant plus à une tache qu'autre chose une fois décodé par QuickSync sous Windows. On remarquera que ce dernier préserve "assez bien" la moitié gauche de la chemise du personnage, plutôt illuminée, tandis que la partie droite est sacrifiée complètement, quelque chose qui culmine dans la main droite. Comparer les modes "Steam Link Intel" et "W10 Intel auto" montre bien la différence dans l'application un peu hasardeuse du filtrage par le décodeur QuickSync.

On notera un autre point commun à tous les encodages, ils n'aiment pas particulièrement le texte jaune sous le HUD à droite de l'écran. Le contour noir bave plus ou moins fortement sur le jaune, changeant au mieux la couleur, et bavant au pire en vert.

Augmenter le bitrate sauve la situation mais on note que la partie droite de la chemise reste toujours sacrifiée par le décodeur QuickSync qui lisse beaucoup trop cette partie de la scène.

Regardons enfin ce qui se passe lorsque l'on approche de la porte.

Cliquez pour ouvrir le comparateur d'images dans un nouvel onglet

Le cas est ici plus favorable, nous sommes dans la partie ou tous les encodeurs remontent sur notre graphique plus haut, et on le comprend visuellement : la moitié gauche de l'écran est noircie et l'on y décèlera rien. Cette situation nous donne un cas typique des changements que l'on va observer d'une seconde à l'autre avec les solutions de streaming. Souvenez-vous du flou massif des cheveux dans l'image au dessus sur l'encodage Intel et comparez ici... c'est le jour et la nuit !

Pire, tout ce qui est décodé sur la plateforme Windows voit un arrière de chemise sans texture. On trouve plus de texture sur l'encodage CPU décodé par Steam Link que sur n'importe quel encodage a bitrate maximal décodé sous Windows, un comble !

En résumé

Voir des textures apparaître et disparaître ainsi est, vous l'aurez deviné, assez inconfortable à l'usage. C'est malheureusement une faiblesse du choix de l'encodage H.264 temps réel utilisé ici. Utiliser le décodage QuickSync amplifie grandement le problème, pouvant entraîner un désagrément visuel assez net.

Page 10 - Impact sur les performances, consommation

#Impact sur les performances

Nous avons également voulu voir l'impact, s'il y en avait un, des encodeurs sur les performances dans les jeux. Activer le streaming réduit il les performances, et si oui, cela se fait il de la même manière en fonction des encodeurs utilisés ?

Pour mesurer cela nous regardons les performances sous Project Cars en mode High, dans une scène sous la pluie avec le MSAA désactivé afin d'augmenter la charge GPU. Nous effectuons les mesures avec une GeForce GTX 970 comme base pour tous les encodeurs, à l'exception évidemment de l'encodage AMD. Nous comparons dans les deux cas les performances sans streaming avec celles avec streaming.

Regardons ce que cela donne en pratique :


Ajouter du streaming à un impact sur les performances, mais celui-ci est assez variable en fonction qu'il s'effectue ou non sur la carte graphique. Dans le cas de l'encodage QuickSync, processeur, ou via la méthode de capture alternative NVFBC, la perte de performances est limitée, moins de 5% au maximum. On pourrait être surpris de l'absence d'impact d'un encodage processeur, mais rappelons que notre machine source est équipée d'un Core i7-6700K et que bien souvent les jeux sont loin d'exploiter tous les cores à 100% sous DirectX 11. En pratique nous avons noté que la consommation de l'encodage est de l'ordre d'un coeur saturé sur notre Core i7 6700K.

Par contre si l'on utilise l'encodage NVENC traditionnel, la perte est plus nette. Il en va exactement de même si on utilise l'encodage AMD AMF, on se retrouve respectivement avec une perte de presque 13 et presque 18% de performances par rapport à un streaming désactivé. Un point non négligeable qu'il faudra prendre en compte dans vos réglages pour vous assurer de rester au-dessus des 60 FPS sur votre machine source pour streamer dans les meilleures conditions possibles.

Consommation à la source

De la même manière, nous avons regardé la consommation à la prise de notre PC source, nous la comparons là aussi au streaming désactivé pour pouvoir voir le surcout de l'encodage :


La consommation en encodage processeur est celle qui augmente le plus significativement, mais l'on retrouve une augmentation avec tous les encodeurs. Bien que l'augmentation de la charge CPU soit limitée, l'encodeur est multithreadé (par défaut sur 4 threads), la charge est donc répartie sur les coeurs disponibles ce qui implique une consommation en watts assez élevée.

Consommation en réception

Nous terminerons par la consommation relevée à la prise sur nos différences machines en réception, lors du décodage :


Si la consommation de notre petit PC est admirablement basse, on sera surtout scotché par la consommation ridiculement faible du Steam Link. On savait, de sa présence dans les clefs Chromecast, que le SoC Marvell ne consommait pas grand-chose, mais tout de même ! Dans tous les cas, ces consommations sont très contenues.

Page 11 - Conclusion

Après ce long tour des solutions de streaming, il s'avère - comment souvent - que la solution parfaite n'existe pas. En pratique, chacune des solutions que nous avons testées disposent d'avantages et d'inconvénients qui seront plus ou moins gênants en fonction de ce que vous attendez.

Un constat s'impose tout de même sur la question de la latence qu'on aurait pu voir comme un vrai problème. En pratique, si toutes les solutions n'ont pas les mêmes performances, on se retrouve dans des conditions tout à fait correctes pour la majorité des jeux avec l'intégralité des solutions. Il n'y a bien que les amateurs de FPS allergiques au V-Sync qui pesteront sur cette dernière. Pour eux, viser les solutions à la latence la plus faible sera conseillé. Les autres admireront le travail effectué, particulièrement par Valve pour réduire massivement la latence et rendre le streaming local amplement supportable, pour ne pas dire dans le meilleur des cas très confortable.

La qualité d'image est un autre point qui variera en fonction du type de jeu utilisé. Quelque chose que l'on a remarqué dans tous nos tests est le problème posé par le choix technologique du H.264. Encoder l'intégralité de l'écran comme un flux vidéo pose quelques problèmes de lisibilité sur les zones fixes comme les HUD (particulièrement quand ils sont sur un fond semi-transparent comme dans Project Cars), zones de textes, et autres rangées de boutons. Le résultat n'est pas forcément mauvais dans le cadre d'une utilisation éloignée de l'écran, mais même avec un débit d'encodage maximal, on aura noté que la lisibilité n'est pas forcément parfaite et pourra déranger dans des jeux ou il y a beaucoup de lecture. Pour le reste, la qualité d'image va assez fortement varier en fonction des solutions.

Si l'on doit placer une première déception, ce sera du côté du décodage QuickSync d'Intel, utilisé dans le cadre du Streaming local Steam. Ce décodage a tendance à filtrer de manière beaucoup trop importante les détails, ce qui dessert assez fortement la qualité visuelle, même lorsque l'on met toutes les chances de son côté en choisissant le bitrate illimité, on l'a vu dans The Witcher 3 par exemple. Intel compense avec son décodage la propension de son encodeur QuickSync a produire un peu plus d'artefacts en mode temps réel que les autres. En pratique, c'est une déception importante, pour un point sur lequel nous n'aurions pas pensé, en commençant notre dossier, qu'il aurait une influence si forte.

Sur une machine plus rapide que notre Celeron, on pourra se permettre de désactiver le décodage accéléré d'Intel, mais cela augmentera la consommation, et la complexité de la solution à utiliser, surtout quand l'on compare cela aux autres solutions que nous avons testés.

On se doit de rappeler également les montagnes de problèmes que causent Windows 10 sur une machine disposant d'un très petit processeur, dans le cas d'une utilisation de jeu et de streaming. On pourra penser ce que l'on veut des décisions de Microsoft de limiter les possibilités de débrayer certaines parties de son système d'exploitation, et l'augmentation à l'inverse du lancement automatique de processus gourmands. Reste que si ces derniers peuvent être assez peu perceptibles sur une machine puissante, sur une petite machine leur impact se fait sentir. Et dans le cas de notre streaming, ces multiples processus intempestifs créent des ralentissements nets du décodage. Un ancien Windows 7 posera moins de problèmes, même si on rappellera que le mode Big Picture de Steam reste - lui aussi -gourmand lorsqu'il fonctionne localement. Viser plus haut que notre modeste Celeron sera nécessaire.

Une alternative aurait pu être un autre système d'exploitation, comme SteamOS . Il s'agit d'une variante de la distribution Linux Debian proposée par Valve, pour créer des Steam Machines. Si le streaming est bien disponible, malheureusement la version actuelle ne gère pas le décodage accéléré QuickSync d'Intel. Sur notre Celeron, le décodage logiciel est trop léger, ce qui se traduit par une impossibilité de décoder les 60 images par secondes. En pratique le résultat est utilisable mais l'on voit sous la forme de ralentissement les images qui n'ont pas pu être décodées. Cela se traduit aussi par une augmentation importante de la latence, dépassant les 105ms dans notre test. Sur une machine plus adaptée cependant, SteamOS pourrait être une solution envisageable.

Parlons également de la Shield Android TV de Nvidia. Cette dernière se distingue surtout par le fait que le streaming de jeu n'est qu'une des fonctionnalités proposées par le boitier dont l'intérêt principal reste Android TV. En pratique on regrettera le manque de réglages et un certain nombre de petits bugs et limitations récalcitrantes (on pense par exemple au bug du Shift+Tab, et a la gestion de certains pad USB tiers). Son plus gros point faible reste la latence, plutôt très élevée comparativement à nos autres solutions même si elle restera acceptable. Si vous privilégiez les jeux rapides, une autre solution sera préférable. La qualité d'image est de son côté plutôt bonne, avec le seul regret que les couleurs ne soient pas fidèles, étant plus saturées que la source. Le prix de la Shield Android TV sera également un facteur important, mais une fois de plus, il est difficile de dissocier ce qui reste une fonctionnalité du reste de ce que propose Android TV.

La solution qui propose le compromis le plus intéressant à nos yeux reste le boîtier Steam Link de Valve. Malgré un SoC Marvell anémique, le boîtier Steam Link offre une consommation imperceptible, une convivialité importante avec le mode Big Picture déporté, une qualité d'image très acceptable (meilleure à débit égal que ce que l'on obtient sous Windows, rappelons le !) et surtout une latence minuscule. Sur ce point Valve fait carton plein et l'on ne pourra que regretter que le SoC Marvell limite le débit du flux H.264 à 30 Mbit/s. Sans cette limitation, il aurait été difficile de reprocher quoique ce soit au boîtier Steam Link, surtout ramené à son prix de 55 euros. On pourra toujours se plaindre de l'obligation d'utiliser Steam et de se retrouver dans l'écosystème de Valve (même si l'on rappellera que l'on peut ajouter à Steam n'importe quelle application) mais en 2016 il est difficile de parler de jeu PC sans eux.

Notez enfin qu'en ce qui concerne le choix de l'encodeur, il est préférable dans nos tests d'utiliser celui inclus dans votre carte graphique, AMD ou Nvidia, en fonction de ce dont vous disposez. AMD dispose d'un petit avantage sur la qualité d'image, et Nvidia sur la latence. Dans le cas d'une carte Nvidia, on vous déconseillera par contre l'option NVFBC qui impose une qualité d'image trop réduite en pratique pour un gain de latence certes important, mais probablement pas justifié par la différence visuelle constatée. Utiliser la carte graphique pour encoder réduira légèrement les performances dans les jeux. Si cela vous pose un problème, l'encodage processeur reste excessivement efficace comme vous avez pu le voir dans nos tests. Une piste à ne pas négliger.

Nous terminerons en notant que des nouveautés sont attendues dans ce domaine, avec notamment la multiplication des encodeurs vidéo HEVC (le successeur du H.264). Cependant nous n'en attendons pas vraiment de miracles. Une grande partie du problème posé par l'encodage temps réel utilisé ici est que pour réduire la latence, on limite les encodeurs à ne travailler que sur une image à la fois, empêchant d'utiliser beaucoup des fonctions avancées du H.264 (comme les B-Frames par exemple). Si HEVC permet en général de meilleurs résultats comparé à H.264, c'est lorsque l'on en utilise toutes les possibilités. Difficile de s'attendre à ce que, pareillement limité, HEVC change complètement la donne.

Il en va de même pour l'introduction d'un mode d'encodage deux passes spécifique au streaming dans les Radeon RX 480 par AMD. Le constructeur ne détaille pas exactement son fonctionnement, mais en général, pour être utile le mode 2 passes travaille sur une serie d'images à la fois. Quelque chose qui serait tout à fait acceptable dans le cas d'une vidéo conférence ou d'un streaming en ligne (ajouter 100ms ne serait pas dramatique si l'on augmente la qualité), mais qui le serait beaucoup moins pour le cas particulier du streaming local de jeux.

Copyright © 1997-2019 HardWare.fr. Tous droits réservés.