Kyber : Jean-Baptiste Kempf chasse sur les terres de Shadow avec son nouveau projet
Même s’il n’a pas pu reprendre le service Shadow dont il a été brièvement le directeur technique — c'est Octave Klaba qui l'a emporté —, Jean-Baptiste Kempf reste très investi dans le cloud gaming. Le président de VideoLAN a dévoilé récemment Kyber, une technologie de streaming bidirectionnelle à très basse latence.
Cette nouvelle solution est ambitieuse et intéressante à plusieurs égards. Pour commencer, elle est open source et multiplateforme. « Contrairement à Shadow, c’est du soft », explique Jean-Baptiste Kempf dans sa présentation donnée à Paris Video Tech mi-décembre.
Côté serveur, Kyber s’appuie sur FFmpeg, un outil incontournable d’encodage vidéo qui prend en charge tous les principaux codecs. Côté client, c’est une version de VLC débarrassée du superflu qui sert de base. Le lien entre les deux est assuré par le nouveau protocole de transport QUIC.
Ces fondations libres et éprouvées permettent à Kyber de fonctionner sur toutes les plateformes : Windows, Mac, Linux, iOS, Android et même dans un navigateur web. Il n’est pas question d’application utilisable directement par le grand public, Kyber doit prendre la forme d’un kit de développement logiciel (SDK) intégrable à d’autres programmes. Pourquoi pas Shadow ?
D’après les vidéos de démonstrations, la technologie permet, au mieux, de n’avoir qu’une ou deux frames de décalage entre le client (par exemple un smartphone Android) et le serveur (par exemple un Mac), ce qui permet de jouer convenablement même aux titres exigeants. En millisecondes, le développeur et son équipe ont mesuré une latence de 16 ms avec un écran 60 Hz ou 10 ms avec un écran 240 Hz.
Selon Jean-Baptiste Kempf, pour un usage d’accès à distance d’un ordinateur à la Parsec, Kyber pourrait convenir dès ce début d’année. Pour des usages plus avancés, comme du contrôle de drones, il faudrait patienter plusieurs mois. Les améliorations à attendre semblent plus porter sur la qualité de la vidéo (réduction des artefacts, meilleure gestion de l’effet de flou, prise en charge éventuelle du HDR…) que la latence. Le projet n’est pas encore officiellement lancé, son site est vide pour le moment.
First ✅
Sinon ça à l’air pas mal ce projet et la parenté avec VLC est rassurante
@vicento
Tu sors 🥳
@vicento
So années 2005 ! 🤡
La notion de latence n'est pas très clair pour moi, j'ai l'impression qu'il s'agit de latence au niveau du logiciel seulement, et que cela ne prend pas en compte la latence du réseau (qui est très variable en fonction des cas), ou alors que le test a été effectué sur un LAN pour limiter cette latence réseau. Et quelque part cela peut se comprendre...
Donc la comparaison avec Shadow et les 25ms, là aussi je ne sais pas de quelle latence on parle.
Donc le titre est à changer aussi.
@totoguile
C’est en LAN effectivement, mais la latence dont il est question ne correspond pas juste au ping, elle correspond au temps d’encodage de l’image côté serveur, sa transmission par le réseau, et le décodage côté client.
12 ms c’est rien du tout. Pour donner une idée, un écran 60Hz, qui affiche donc 60 images / seconde, affiche une image toutes les 16ms (1/60).
Autrement dit, avec 12 ms de latence, on a de quoi transmettre les images plus vite que le moniteur (serveur ou client) ne peut les afficher.
Pour aller encore plus loin : ils font justement une démo très pertinente où le serveur est relié à un écran 60Hz, et le client à un écran 120Hz.
Et bien très logiquement : le client affiche les images AVANT le serveur, puisque son moniteur peut refresh toutes les 8 ms, tandis que le serveur doit attendre 16 ms avant d’afficher la prochaine frame, preuve qu’on est vraiment dans un ordre de grandeur ridicule concernant la latence.
J’attends la techno avec impatience, puisque je viens de quitter Shadow pour me monter un ordi de streaming domestique (et ça marche sacrément bien sur Mac et Apple TV).
Oui, c'est ma compréhension également (latence logicielle --> latence d'encodage etc...)
@Rez2a
J’ai quand même des doutes, on verra les performances dans des conditions non idéale et où le ping n’est pas proche de 0.
@redchou
Ça c’est le meilleur des cas, il faut retenir que sur un réseau local, la techno permet l’envoi d’images plus vite que la plupart des écrans peuvent rafraîchir l’image affichée, donc ça permet d’avoir du streaming sans latence ressentie. Ce n’est pas de la théorie, c’est de la pratique, mais sur un réseau local.
Pour du streaming par internet, là il va forcément y avoir plus de latence, mais je suis pas inquiet, pour l’avoir déjà pratiqué plusieurs années avec Shadow (qui a en toute vraisemblance une moins bonne techno et la latence due à internet), faut deja être sacrément exigeant pour être gêné par la latence.
Toujours marrant ces histoires de latence ou les gens oublient qu'elles se cumulent dans le pire des cas...
Latence réseaux.
Latence video : du double ou triple buffering à 60 hertz ca fait déja16 à 30 ms.
Input lag (le temps entre un click et sa répercution à l'écran): même sur une machine à 240 fps, un windows de base tourne autour de 20 ms à 10 ms si bien optimisé.
@mimolette51
Le triple/double buffering n'a de sens que si le jeu est rendu sur l'ordinateur qui l'affiche. Pour du cloud gaming ce n'est pas le cas.
Comme c'est assez nouveau, les algorithmes sont encore peu détaillés voire secrets et l'on n'a pas encore toutes les subtilités. Et je ne pense pas que Kempf ne soit pas au courant de tout cela...
C'est au contraire une bonne chose d'avoir un projet sérieux et open source qui fasse surface.
Côté client, c’est une version de VLC débarrassée du superflu qui sert de base
Il m'est arrivé de regarder le code de VLC, et je dis : Chapeau.
Car ce code est loin d'être simple - en tous cas en ce qui concerne la partie à laquelle je me suis intéressée.
En réseau local, ça permettrait aussi d’avoir un simple Mac Mini ou Mac Studio et des clients légers plutôt qu’un ordinateur portable. VNC sans latence, quoi.