Présentation du projet

Artemis Switch : suivre une image du réseau à l’écran

20 oct. 2026 3 min de lecture

Écouter en version balado

Où cette image a-t-elle attendu ? · 2:33 · voix synthétiques, script rédigé avec l’IA

Transcription

Sylvie : Un stream peut afficher un très bon débit et pourtant donner l'impression d'être en retard. Ça vous est déjà arrivé ?

Thierry : Oui, et je blâme toujours le réseau.

Sylvie : Pas si vite. Artemis Switch, c'est le fork de Moonlight-Switch d'Antoine pour la Nintendo Switch. Il s'intéresse au trajet entre la réception d'une image et son affichage. La vraie question n'est pas la vitesse du décodeur, c'est : où cette image a-t-elle attendu ?

Thierry : Et ce trajet, il ressemble à quoi ?

Sylvie : Un PC, Sunshine ou Apollo, envoie la vidéo avec le protocole Moonlight. La Switch la décode avec FFmpeg et NVDEC, la met dans une file, choisit une image, puis l'affiche avec deko3d. Et cette séparation aide à déboguer : un mauvais mode d'écran virtuel, c'est le serveur. Une file d'images décodées qui grossit, c'est le client.

Thierry : Au moins on sait qui accuser.

Sylvie : Voilà. Maintenant le détail subtil. Quand la file prend du retard, le code jette les vieilles images pour privilégier la fraîcheur. Mais il vérifie d'abord l'échéance de la plus ancienne image, avant de passer à la plus récente.

Thierry : Pourquoi cet ordre ?

Sylvie : Imagine un vigile qui remet le compteur à zéro chaque fois qu'un nouveau client entre. Si l'échéance suit la dernière image arrivée, elle recule sans cesse. La file reçoit des images, mais n'en montre jamais. En gardant l'échéance de la plus ancienne, on évite ça.

Thierry : Une petite règle, mais qui change tout.

Sylvie : Il y a aussi une classe de télémétrie qui mesure chaque étape : décodage, attente en file, rendu, soumission au GPU, débit réel. Antoine précise bien ses limites. Le pipeline client commence après la réception réseau. Il ne couvre ni l'encodage sur le PC, ni le balayage de l'écran, ni les commandes de la manette.

Thierry : Donc pas de chiffre magique de latence.

Sylvie : Non. Pour tester sur console, il garde le même serveur, la même scène, la même résolution, le même réseau, change une option à la fois, et sépare les essais en mode portable et docké. Une moyenne plus basse avec des pics pires peut sembler plus lente.

Thierry : Et compiler, ce n'est pas la même chose que bien jouer.

Sylvie : Exactement. Le README distingue lui-même les tests et les builds de la validation sur appareil. À retenir : mesurer où l'image attend, pas seulement la vitesse du décodage. L'article complet a le schéma du trajet et les liens vers les deux fichiers source.

Bibliothèque d’applications Artemis Switch, tirée du README du dépôt

Table des matières

Un stream peut afficher un bon débit tout en donnant une impression de retard. Artemis Switch est mon fork de Moonlight-Switch pour Nintendo Switch. Je m’intéresse surtout au trajet entre la réception d’une image et son affichage : où cette image a-t-elle attendu ?

1. Bien séparer le client du serveur

Artemis conserve les bases de XITRIX/Moonlight-Switch : interface Borealis, transport Moonlight/GameStream, décodage FFmpeg/NVDEC et rendu deko3d. Sunshine et Apollo restent des serveurs sur le PC. Leur administration passe par leurs propres interfaces.

Un mauvais mode d’écran virtuel relève donc du serveur. Une file d’images décodées qui grossit relève du client. La documentation des intégrations ne signifie pas que toutes les combinaisons ont été validées sur console.

2. Le trajet d’une image

flowchart TD
  H["PC : Sunshine ou Apollo"] --> N["Transport Moonlight / GameStream"]
  N --> D["Décodage FFmpeg / NVDEC"]
  D --> Q["File des images décodées"]
  Q --> S["Échéance et sélection de l’image récente"]
  S --> R["Présentation deko3d"]
  R --> P["Écran de la Switch"]
  T["FramePipelineTelemetry"] -. mesure .-> D
  T -. mesure .-> Q
  T -. mesure .-> R

Ce schéma simplifie le code du client. Il ne représente pas une mesure complète de la latence entre la manette et l’écran.

3. Quand abandonner les anciennes images ?

Dans LowLatencyFrameSelection.hpp^[1], la sélection vérifie l’échéance de la plus ancienne image avant de passer à la plus récente. Une fois l’affichage autorisé, elle libère les images anciennes. Un retard accumulé permet aussi de contourner cette attente.

Si l’échéance suivait toujours la dernière arrivée, elle pourrait reculer sans cesse. La file recevrait des images sans jamais en présenter. Cette règle précise explique mieux le travail réalisé qu’une simple promesse de faible latence.

4. Mesurer chaque étape

FramePipelineTelemetry.hpp^[2] suit le décodage, l’attente en file, le pipeline client, le rendu, la soumission GPU, le débit réel et le temps jusqu’aux premières étapes du stream. Une horloge monotone et un mutex encadrent ces mesures.

Le pipeline client commence ici après la réception réseau complète. Il ne couvre pas à lui seul l’encodage du PC, tout le réseau, le balayage de l’écran et les commandes.

Le README décrit aussi les modes Fit/Fill/Stretch, l’agrandissement de type FSR, RCAS, les profils nommés et les panneaux de diagnostic. Ce sont des outils pour comparer des compromis, pas une garantie de fréquence d’images.

5. Comparer sur console

Je garderais le même serveur, la même scène, la résolution et le réseau. Ensuite, je changerais une option de cadence à la fois en observant l’attente et les intervalles de présentation. Les modes portable et docké méritent des essais distincts.

Le dépôt distingue les tests portables et les builds des validations sur appareil. Les notes d’installation restent donc la référence avant d’assimiler compilation et expérience de jeu.

6. Sources

Références

antoinebou12. (20 octobre 2026). LowLatencyFrameSelection.hpp. [Source file or documentation] github.com.
antoinebou12. (20 octobre 2026). FramePipelineTelemetry.hpp. [Source file or documentation] github.com.
antoinebou12. (20 octobre 2026). Artemis-Switch. [Software repository] github.com.

Les références utilisent la date de publication de cet article.