Se connecter Commencer à diffuser
← Base de connaissances
Toutes les plateformesVIDÉO

Encoder une vidéo de diffusion avec HandBrake ou ffmpeg

16 juil. 2026 · 6 min de lecture

Steam n'examine pas une diffusion avant sa mise en ondes - il valide le compte, la connexion et l'encodage. Ratez l'un de ces trois éléments et le flux est refusé d'emblée ou décroche en pleine diffusion sans avertissement. Cet article couvre les trois : qui est autorisé à diffuser, la spécification d'encodage publiée par Valve et la raison d'être de chaque réglage, où va réellement le flux, et à quoi s'attendre concrètement une fois en direct.

Ce compte peut-il seulement diffuser ?

Aucun des réglages d'encodage ci-dessous n'a d'importance si le compte lui-même n'est pas autorisé à diffuser, et c'est l'étape que les gens sautent parce qu'elle n'a rien à voir avec la vidéo. Steam exige que le compte de diffusion soit non limité - au moins 5 $ de dépenses historiques sur la plateforme - et qu'il détienne soit la permission « Broadcast Live », soit une inscription à la Store Broadcast Beta. Le compte doit également posséder le jeu diffusé ou y avoir accès d'une autre manière, et il ne peut pas être Community Banned. Manquez l'un de ces points et un flux H.264 High@4.1 parfaitement conforme ne passera toujours pas en direct, et de l'extérieur l'échec est identique à un mauvais encodage - le flux refuse simplement de démarrer, sans rien dans le journal de l'encodeur à incriminer. Écartez cette possibilité avant de passer une soirée à remettre en question vos réglages de débit. C'est une vérification de cinq minutes contre un gouffre d'encodage de plusieurs heures, et c'est une assurance bon marché de le faire en premier plutôt qu'en dernier.

La spécification de Valve, en intégralité

Tout ce qui suit provient de la documentation même de Valve à l'adresse partner.steamgames.com, et non de suppositions. Le codec vidéo doit être H.264, Profile High, Level 4.1. La fréquence d'images est de 30 ou 60 FPS, le rapport d'aspect est 16:9, et l'intervalle entre images-clés doit être de 2 secondes. Le débit maximal est de 7000 kbps CBR. L'audio est en AAC-LC, plafonné à 128 kbps. Aucun de ces paramètres n'est une suggestion - Valve valide le flux au regard de ceux-ci lorsqu'il se connecte, et un champ hors spécification est la raison pour laquelle une diffusion qui paraît correcte dans votre encodeur ne passe jamais en direct. Nous traitons les mêmes chiffres avec plus de contexte dans les spécifications vidéo et l'encodage pour Steam.

Se connecter à Steam : le côté RTMP

Encoder selon la spécification vous donne un flux conforme ; il faut encore l'envoyer quelque part, et cette partie pose moins de problèmes aux gens parce qu'elle est plus simple que les réglages d'encodage, pas parce qu'elle serait non documentée. Le point d'ingestion de diffusion de Steam est un point de terminaison RTMP standard : rtmp://ingest-rtmp.broadcast.steamcontent.com/app. Vous ne choisissez pas de région vous-même - Steam sélectionne pour vous le serveur d'upload réel en fonction de l'emplacement du compte, de la même manière qu'il choisit aussi les serveurs de téléchargement pour l'installation des jeux. La clé de flux est générée à l'adresse steamcommunity.com/broadcast/upload sous "Create RTMP Token." Lorsque vous le créez, vous sélectionnez l'ID de l'application de base du jeu, pas une entrée de DLC ou de démo, puisque la diffusion se rattache à l'application de base quelle que soit l'édition dont vous faites la promotion.

OBS est le logiciel vers lequel la plupart des gens se tournent pour tester cela, mais il n'a rien de propre à Steam - n'importe quel encodeur compatible RTMP se connecte de la même façon, qu'il s'agisse d'OBS, de vMix, d'un boîtier matériel, ou de ffmpeg qui pousse directement vers l'URL ci-dessus avec votre clé de flux. En termes OBS, c'est le service de streaming « Custom », avec l'URL d'ingestion dans le champ Server et la clé dans le champ Stream Key. La couche RTMP ne se soucie pas de ce qui a produit les bits, seulement qu'ils correspondent à la spécification de Valve une fois arrivés.

Une chose à vérifier si la connexion elle-même ne s'établit pas, indépendamment de tout ce qui touche à l'encodage : RTMP fonctionne par défaut sur le port TCP 1935. Sur une connexion domestique, cela pose rarement problème, mais sur un réseau d'entreprise, un VPN d'entreprise ou une VM cloud verrouillée, le port sortant 1935 peut être bloqué par un pare-feu qui n'a aucun problème avec le trafic web normal sur 80 et 443. Si l'encodeur ne parvient pas du tout à atteindre l'URL d'ingestion - pas un flux rejeté, simplement aucune connexion - , c'est la première chose à écarter avant de supposer qu'il s'agit d'un problème du côté de Steam.

Le seul réglage qui échoue brutalement : l'intervalle entre images-clés

La plupart des champs de la spécification se dégradent en douceur si vous êtes légèrement à côté - un débit un peu au-dessus du plafond peut simplement être plafonné par l'ingestion de Steam. L'intervalle entre images-clés ne fonctionne pas ainsi. Valve est explicite : s'il n'est pas exactement de 2 secondes, votre flux ne parviendra pas à démarrer. Aucune tolérance.

Un intervalle entre images-clés de 2 secondes signifie qu'une image complète est encodée toutes les 2 secondes, les images intermédiaires y faisant référence. À 30 fps, cela correspond à une longueur de GOP de 60 images ; à 60 fps, c'est 120. La plupart des encodeurs ont par défaut une autre valeur - souvent 4 ou 5 secondes, réglée pour la taille de fichier plutôt que pour la conformité en direct - , c'est donc le réglage que les gens oublient même quand tout le reste est correct. Valve cite ici vMix nommément : sa valeur par défaut est Main Profile à Level 3.0, et cette combinaison doit être modifiée avant qu'une sortie vMix ne passe. Voyez-y un avertissement : les valeurs par défaut de votre propre encodeur ne sont probablement pas non plus celles de Steam, et vérifiez-les explicitement plutôt que de faire des suppositions.

Pourquoi un débit constant, et non variable

La spécification de Valve exige du CBR, pas du VBR, et la raison est propre au streaming en direct plutôt qu'à la qualité vidéo en général. Le débit variable permet à l'encodeur de consacrer plus de bits aux images complexes et moins aux images simples, ce qui est parfait pour un fichier que vous regarderez une fois d'un bout à l'autre. Un serveur d'ingestion en direct doit se prémunir par une mise en mémoire tampon calée sur un débit de données attendu à peu près constant ; un flux qui oscille de 2000 kbps à 9000 kbps et inversement fait soit manquer soit déborder cette mémoire tampon, et l'un comme l'autre se traduit par des saccades ou une connexion interrompue. Le CBR sacrifie un peu de qualité sur les scènes simples au profit d'un débit de données autour duquel le côté ingestion peut s'organiser, ce qui est exactement ce dont une diffusion 24/7 a besoin.

7000 kbps est le plafond documenté par Valve, pas une cible. Vous en approcher au plus près ne laisse aucune marge si votre matériau source dépasse brièvement le débit que vous avez fixé, ce qui est un comportement d'encodeur normal même en mode CBR. Une cible plus sûre consiste à encoder quelques centaines de kbps sous le plafond - 6000 kbps est un choix raisonnable, et c'est notre valeur par défaut pour la même raison.

Ce que Steam fait de votre flux après l'ingestion

Il vaut la peine de savoir ce qu'il advient du flux une fois qu'il est accepté, surtout pour éviter de sur-concevoir en vue d'un problème que Steam résout déjà. Dès qu'une diffusion dépasse environ 10 spectateurs simultanés, Steam active automatiquement le transcodage et génère des rendus en résolution inférieure - 720p, 480p et 360p - en plus de votre flux 1080p original. Cela se passe entièrement côté serveur ; vous n'envoyez jamais plus d'un flux et ne configurez jamais vous-même une échelle de résolutions. Le flux CBR unique décrit ci-dessus est le seul encodage dont vous êtes responsable. Si vous avez l'habitude de plateformes où vous poussez vous-même plusieurs variantes de débit, vous pouvez abandonner cette habitude ici - un seul flux 1080p propre à la spécification ci-dessus constitue tout le travail, et cela signifie aussi que la qualité de ce flux unique compte davantage, et non moins, puisque c'est le master à partir duquel tout le reste est dérivé en dessous du seuil de transcodage.

Encoder avec HandBrake

HandBrake produira une sortie conforme, mais les champs qui comptent pour Steam se trouvent en dehors de ses préréglages par défaut. Réglez le conteneur sur MP4 et le codec vidéo sur H.264 (x264). Sous Framerate, choisissez votre cible - 30 ou 60 - et réglez-la sur Constant, et non sur Variable. Pour le contrôle du débit, utilisez Average Bitrate réglé à 6000 kbps plutôt qu'un mode basé sur la qualité (CRF), car le CRF produit par conception un débit variable.

Le profil, le niveau et l'intervalle entre images-clés se trouvent dans la chaîne d'options x264 de l'onglet Advanced. Réglez Profile sur High et Level sur 4.1 dans leurs menus déroulants respectifs, puis ajoutez keyint=60:min-keyint=60 à la chaîne d'options pour 30 fps, ou keyint=120:min-keyint=120 pour 60 fps - c'est votre intervalle de 2 secondes exprimé en images. Dans l'onglet audio, encodez en AAC à 128 kbps.

La même chose avec ffmpeg

Si vous préférez le scripter, chaque champ ci-dessus correspond à une option. Ceci encode selon la spécification en 30 fps avec une cible de 6000 kbps et un GOP de 2 secondes :

ffmpeg -i input.mp4 -c:v libx264 -profile:v high -level 4.1 -r 30 -g 60 -keyint_min 60 -sc_threshold 0 -b:v 6000k -maxrate 6000k -bufsize 12000k -c:a aac -b:a 128k -ar 44100 -pix_fmt yuv420p output.mp4

L'association qui mérite une explication est celle de -b:v, -maxrateet -bufsize réglés sur des valeurs identiques ou apparentées - c'est ce qui fait que libx264 tient réellement le CBR au lieu de dériver vers son comportement par défaut proche du VBR. -g 60 est la longueur de GOP pour 30 fps (utilisez 120 à 60 fps), et -sc_threshold 0 empêche l'encodeur d'insérer une image-clé supplémentaire aux changements de scène, ce qui romprait sinon l'intervalle fixe de 2 secondes qu'exige Valve.

Vérifier votre sortie avant de la diffuser en direct

Plutôt que de croire sur parole que votre encodeur a fait ce que vous lui avez demandé, il vaut la peine de relire le fichier avant de l'acheminer vers l'ingestion de Steam. ffprobe, livré avec ffmpeg, affichera le profil, le niveau et la fréquence d'images réellement présents dans la sortie plutôt que ceux que vous aviez demandés :

ffprobe -v error -select_streams v:0 -show_entries stream=profile,level,r_frame_rate,bit_rate -of default=noprint_wrappers=1 output.mp4

Cela renvoie exactement ce qui a été inscrit dans le fichier - si le profil affiche « Main » au lieu de « High », ou si le niveau apparaît en 3.1 au lieu de 4.1, vous le saurez avant que Steam ne vous l'apprenne à la dure. La longueur du GOP est un peu plus laborieuse à confirmer directement, mais une vérification approximative consiste à compter les paquets vidéo sur les premières secondes ; en 30 fps avec un intervalle de 2 secondes, vous devriez voir une image clé environ toutes les 60 images. C'est une petite étape, mais elle transforme « le flux a été rejeté, et maintenant ? » en « le niveau est mauvais, corrigez ce seul champ » - une boucle de débogage bien plus courte.

Latence : à quoi s'attendre réellement

Valve ne publie aucun chiffre officiel de latence pour les diffusions de la boutique ; considérez donc tout ce que vous lisez à ce sujet - y compris ici - comme un chiffre rapporté, et non comme une spécification. Avec cette réserve : les utilisateurs rapportent couramment une latence d'environ 30 secondes sur les diffusions de la boutique, contre à peu près 15 secondes sur Twitch. Les notes de mise à jour de Valve ont revendiqué une latence inférieure à 1 seconde, mais spécifiquement pour les diffusions entre amis en tête-à-tête, pas pour le flux de la page boutique, et certains utilisateurs rapportent que cette amélioration n'est jamais apparue sur les diffusions de la boutique. Prenez le chiffre d'environ 30 secondes comme un ordre de grandeur rapporté par la communauté plutôt que comme un engagement écrit de Valve.

Pour une vidéo préenregistrée en boucle, rien de tout cela n'a d'importance en pratique. La latence ne devient un problème que lorsque quelqu'un, à l'autre bout, doit interagir avec ce qui se passe en direct - lire le chat, réagir en temps réel, minuter un compte à rebours. Une boucle 24/7 d'une bande-annonce ou d'un extrait de gameplay n'a rien de live à désynchroniser, si bien qu'un délai de 30 secondes est invisible pour quelqu'un qui se contente de regarder votre page de magasin. Ce n'est une contrainte réelle que si vous essayez de faire passer quelque chose d'interactif par la même connexion ; voir faire tourner une diffusion préenregistrée en boucle pour savoir ce qui fonctionne bien ou non en boucle.

Ou faites l'impasse totale sur l'encodeur

Tout ce qui précède existe parce que l'ingestion de Steam est intraitable sur l'encodage, et non parce que les chiffres sont difficiles à trouver. Avec Loopcast, vous téléversez le fichier que vous avez et nous le transcodons automatiquement en 1920x1080 à 30 fps, avec un intervalle entre images clés de 2 secondes, un CBR de 6000 kbps et de l'audio AAC-LC à 128 kbps et 44,1 kHz - la même spécification que celle décrite ci-dessus, appliquée sans que vous touchiez à un réglage de codec ou à une URL RTMP. Une fois que vous avez obtenu une clé de flux de Steam, voir obtenir un clé de flux pour le connecter, et si un flux refuse un jour de démarrer, dépannage de diffusion couvre les causes les plus courantes, tant l'encodage que l'éligibilité.

Faites l'impasse sur les réglages de l'encodeur

Téléversez une vidéo, collez votre clé de flux Steam, lancez la diffusion. À partir de $0.72/jour.

Commencer à diffuser · $0.72/jour
Un blocage ? Demandez sur notre Discord →