L’hôte Remote Play de Steam plante dans le propre encodeur de Steam et Valve a fusionné un deuxième rapport

L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.

L’hôte Remote Play de Steam plante avec un SIGSEGV à l’intérieur de l’encodeur FFmpeg fourni par Steam, et Valve a fusionné un deuxième rapport dans le premier. Le numéro 13704, ouvert le 8 octobre et portant les propres labels Streaming et SteamOS de Valve, met la faute dans la corruption du tas « à l’intérieur de l’encodeur vidéo FFmpeg fourni par Steam, frappé lors de la libération d’un AVFrame pendant avcodec_send_frame ».

Le chemin signalé est une machine Steam diffusée en continu vers une trame Steam. L’hôte exécute SteamOS 3.8.28 sur la branche stable avec un GPU AMD Navi 33, capturant via PipeWire et VAAPI, sur le libavcodec 62.28.102 fourni par Steam, et le rapport indique que le choix du codec ne change que la fréquence à laquelle cela se produit : « H.264 plante quelques minutes après le streaming ; HEVC peut fonctionner pendant des heures ».

Valve a fusionné le rapport d’une deuxième machine le 13 octobre

Le deuxième rapport, numéro 13731, provenait d’un matériel différent : un Ryzen 7 7800X3D avec une Radeon RX 9070 XT, encodage sur le GPU intégré, avec Steam Link sur un iPad comme client. Valve l’a fermé dans les 13 minutes : « cela ressemble au même problème que #13704. Fermeture en double. »

Son auteur a dénombré « 7 fois de suite le 13 octobre », aussi bien en H.264 qu’en HEVC, chacun crashant quelques secondes après la connexion. Ils ont déclenché la sonde unique du codec matériel de Steam, que le client enregistre lorsqu’il essaie CUDA, ne parvient pas à charger libcuda et revient à VAAPI, et qui « semble s’exécuter une seule fois par processus Steam ».

La ligne de journal du noyau nomme CGameStreamVideo segfaulting dans la libc, et les adresses de pannes lors des sept plantages étaient 0x440, 0x441, 0x10 et 0xc51. La pile au-dessus traverse la libvideo de Steam dans av_freep et avcodec_send_frame.

Deux rapports, c’est là que s’arrêtent les preuves

Valve a étiqueté 13704 et a jugé le deuxième rapport comme le même bug, ce qui constitue l’ensemble de sa position publique. Il n’a pas été précisé ce qui corrompt le tas, ni si la faute réside dans la propre libvideo de Steam ou dans les bundles Steam de la copie FFmpeg, et 13704 était toujours ouvert le 14 octobre.

Deux machines, c’est deux machines. Les deux hôtes exécutent SteamOS sur des graphiques AMD et tous deux encodent via la propre copie fournie de Steam de FFmpeg, et c’est tout ce que le modèle va avec les rapports qui existent.

C’est aussi le couplage que Valve a poussé. Valve a qualifié la Steam Machine d’hôte idéal pour un Steam Frame en septembre, alors que le streaming de jeux VR entre les deux ne fonctionnait pas encore, et que la lecture à distance de jeux plats était la voie utilisée par ces deux rapports.

Les paramètres de Remote Play ont évolué rapidement : le client bêta a augmenté son plafond à 1 Gbit/s le 3 octobre, avec l’avertissement de Valve concernant le coût de latence. La pièce qu’aucun journaliste ne peut échanger est l’encodeur que Steam apporte avec lui.