Animer un webinar depuis votre régie : les prérequis techniques de la salle Studio

Avant d'animer un webinar en salle Studio, vérifiez que votre environnement technique est conforme aux exigences de la diffusion par flux encodé (RTMPS).

Contrairement à la salle webcam, ce n'est plus votre navigateur qui envoie l'image : c'est votre logiciel ou boîtier d'encodage (OBS Studio, vMix, Wirecast, encodeur matériel) qui produit un flux unique et l'envoie à la salle via une clé de stream. Ce guide couvre toutes les conditions à respecter, et les risques encourus si elles ne le sont pas.

Sommaire

• 1 - Résumé des exigences minimales
• 2 - Comprendre la technologie utilisée
• 3 - Prérequis réseau : débit, ports et stabilité
  • 🔸 Comprendre le rôle de la connexion Internet
  • 🔸 Débit Internet recommandé
  • 🔸 Ports et configuration réseau
• 4 - Réglages de l'encodeur : vidéo, audio et paramétrage
  • 🔸 Où trouver l'URL de diffusion et votre clé de stream
  • 🔸 Résolution, débit et images par seconde
  • 🔸 Paramètres vidéo
  • 🔸 Paramètres audio
  • 🔸 Pourquoi le débit constant (CBR) est-il obligatoire ?
  • 🔸 Pourquoi une image clé toutes les 2 secondes ?
  • 🔸 Configuration pas à pas dans OBS Studio
• 5 - Prérequis matériels et logiciels
  • 💻 Configuration du poste d'encodage
  • 🎛 Logiciel ou boîtier d'encodage
• 6 - En cas de problème ou d'interruption
  • 🔸La diffusion est refusée dès le lancement
  • 🔸La diffusion s'interrompt en cours de direct
  • 🔸 L'image est saccadée ou figée chez les participants
  • 🔸 Après le webinar : prévenir les problèmes futurs

1 - Résumé des exigences minimales

Les prérequis réseau, matériels et d'encodage, en un coup d'œil.

2 - Comprendre la technologie utilisée

Vous produisez la vidéo, nous la distribuons. Votre régie sort un flux unique, envoyé en RTMPS — la version chiffrée du RTMP, standard de la contribution vidéo professionnelle.

À l'arrivée, ce flux est transcodé en plusieurs qualités : envoyé une seule fois, il est reçu dans la qualité adaptée à chaque participant, du poste en HD au mobile en 4G. En contrepartie, un débit insuffisant, un réglage hors limites ou un port bloqué interrompent la diffusion au lieu de la dégrader.

💡 Un décalage de quelques secondes. Plusieurs secondes s'écoulent entre le moment où votre régie envoie le flux et celui où vos participants le reçoivent. Ce décalage ne gêne pas le déroulé du webinar, mais il faut laisser aux participants le temps de recevoir la question, puis d'y répondre. Au moment de passer aux questions, par exemple, annoncez-le et occupez ce temps : « on passe aux questions du chat, n'hésitez pas à écrire, on remonte d'abord voir celles qui ont déjà été posées ». Vous évitez ainsi un blanc pendant que l'information arrive et que les réponses s'écrivent.

3 - Prérequis réseau : débit, ports et stabilité

🔸 Comprendre le rôle de la connexion Internet

Un seul flux compte ici : le flux montant (upload) qui part de votre encodeur vers la plateforme. Tout étant déjà mixé chez vous, vous n'avez rien à recevoir. Ce flux est envoyé en continu, à débit constant, pendant tout le direct : si la liaison montante sature, même brièvement, des images sont perdues avant d'arriver chez nous, et cette perte est définitive pour vos participants.

🔸 Débit Internet recommandé

Deux chiffres à ne pas confondre : le débit du flux, que vous réglez dans votre encodeur, et le débit montant de votre connexion, qui dépend de votre abonnement et de votre réseau. Le second doit dépasser le premier d'environ 50 % — un flux réglé à 4 500 kbps sature une ligne qui monte à 5 Mb/s, alors même que les chiffres semblent tenir.

1 000 kbps = 1 Mb/s : même unité, mais les encodeurs affichent des kbps et les tests de débit des Mb/s.

Pourquoi cette marge ? Le débit que vous réglez ne couvre que la vidéo : l'audio et l'enveloppe technique du RTMPS s'y ajoutent. Et il reste une moyenne — même en CBR, l'encodeur dépasse ponctuellement sa cible sur les scènes chargées. Une ligne utilisée à 100 % perd alors des paquets, et l'image se fige chez vos participants. Amazon, qui opère notre infrastructure de diffusion, recommande cette marge de 50 %.

⚠️ Mesurez le bon débit. C'est le débit montant (upload) qui compte, pas le descendant, souvent dix fois supérieur : une ligne annoncée à 500 Mb/s peut ne proposer que 15 Mb/s en montant. Et un test de débit mesure la capacité totale de la connexion, partagée avec tous les autres usages du réseau.

En pratique : une connexion fibre ou VDSL, en filaire, et aucun usage simultané lourd sur le réseau pendant la diffusion (visioconférence, streaming, sauvegarde cloud).

🔸 Ports et configuration réseau

Pour que votre encodeur puisse envoyer son flux, votre réseau doit autoriser en sortie :

Le port 443 est celui du HTTPS : il est presque toujours déjà ouvert. Attention toutefois, certains pare-feu filtrent par protocole et non par port, et bloquent le RTMPS malgré tout.

Deux méthodes d'autorisation, selon votre équipement

Deux façons de l'autoriser, toutes deux valables : le choix dépend de ce que sait faire votre pare-feu et de votre politique de sécurité.

Méthode 1 — Autorisation par nom de domaine (recommandée)

Autorisez simplement *.live-video.net sur le port TCP 443, en sortie.

Possible dès que votre pare-feu inspecte la couche applicative (pare-feu nouvelle génération, proxy) : le nom du serveur est visible en clair lors de la négociation TLS, sans avoir à déchiffrer le flux.

✅ Avantage : une seule règle, permanente, valable même si nos serveurs d'entrée évoluent.

Méthode 2 — Autorisation par plages d'adresses IP

Si votre pare-feu ne raisonne qu'en adresses et en ports, sans notion de nom de domaine, autorisez les plages IP de notre infrastructure de diffusion.

Ces plages sont publiées et maintenues par Amazon dans un fichier public, mis à jour en continu : https://ip-ranges.amazonaws.com/ip-ranges.json 

Ce fichier recense toutes les adresses des services Amazon. Extrayez uniquement celles identifiées par le service IVS_LOW_LATENCY, en IPv4 comme en IPv6 :

• IPv4 — champ prefixes, filtré sur service = IVS_LOW_LATENCY (ip_prefix)
• IPv6 — champ ipv6_prefixes, filtré sur service = IVS_LOW_LATENCY (ipv6_prefix)

Commandes d'extraction prêtes à l'emploi (jq) :

• curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select(.service=="IVS_LOW_LATENCY") | .ip_prefix'
• curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.ipv6_prefixes[] | select(.service=="IVS_LOW_LATENCY") | .ipv6_prefix'

Deux conditions pour que cette méthode fonctionne durablement :

1. Autorisez toutes les plages, sans filtrer par région. Notre plan de données de diffusion est global : votre encodeur est routé vers le point d'entrée le plus proche de lui, qui peut appartenir à n'importe quelle région, y compris hors d'Europe et même si votre salle est hébergée en Irlande. Ne retenir que les plages européennes provoque des échecs de connexion intermittents, difficiles à diagnostiquer.
2. Mettez la liste à jour régulièrement. Ces plages évoluent ; le champ createDate du fichier indique sa date de publication.

⚠️ L'erreur à ne pas commettre : résoudre le domaine une seule fois (nslookup, ping) et figer les adresses obtenues dans le pare-feu. La résolution varie selon le lieu et le moment : la règle tiendra pendant votre test, puis échouera quelques jours plus tard sans explication. Si vous filtrez par IP, utilisez la liste officielle complète.

Cas particulier : les réseaux avec proxy obligatoire

Certains réseaux d'entreprise forcent tout le trafic sortant à passer par un proxy HTTP. Le RTMPS n'étant pas du HTTP, un proxy qui n'accepte que HTTP/HTTPS le bloquera — même si le port 443 est ouvert et le domaine autorisé.

Ni l'autorisation par domaine ni celle par IP n'y suffisent : il faut une exception de routage direct pour le poste d'encodage. C'est la cause d'échec la plus fréquente en grand compte, à vérifier en priorité.

Anticipez le délai de traitement

Informez votre DSI plusieurs jours avant l'événement : ce type de demande met rarement moins de 48 heures à être traité, et un aller-retour est fréquent.

🔸 Conseils de stabilité réseau

• Privilégiez une connexion filaire (Ethernet). Le Wi-Fi et la 4G/5G sont fortement déconseillés en direct.
• Ne changez pas de réseau pendant la diffusion. Tout basculement, y compris vers un partage de connexion mobile, interrompt le flux.
• Évitez les VPN et les réseaux d'entreprise non configurés pour le streaming.
• N'utilisez pas de service de restream tiers. Envoyez votre flux directement à Webikeo : chaque intermédiaire ajoute de la latence et un point de défaillance.
• Fermez les applications consommant de la bande passante et, si possible, isolez le poste sur un VLAN dédié.
• Testez votre connexion avant le direct, depuis le lieu et le poste du jour J.

4 - Réglages de l'encodeur : vidéo, audio et paramétrage

C'est le cœur des prérequis de la salle Studio. Un flux hors limites n'est pas dégradé : il est refusé et la diffusion s'interrompt.

🔸 Où trouver l'URL de diffusion et votre clé de stream

L'URL de diffusion RTMPS et la clé de stream associée sont disponibles directement dans la salle de conférence, sous l'onglet « Autre ».

Deux jeux d'identifiants sont mis à votre disposition, à deux moments différents :

👉 Utilisez les clés de test. Elles permettent de vérifier toute la chaîne — ouverture réseau, réglages d'encodage, niveaux audio, cadrage — sans attendre le jour J.

Vos tests restent invisibles pour vos participants. La salle ne leur est accessible que 30 minutes avant le live ; vous, organisateur, pouvez vous y connecter à tout moment pour contrôler le rendu.

Vos tests ne génèrent pas de replay. L'enregistrement démarre dès que vous diffusez avec la clé définitive, indépendamment du bouton « lancer le live » de la salle, qui ne fait qu'afficher le lecteur à vos participants. Tant que vous utilisez les clés de test, rien n'est enregistré — en revanche, tout ce qui part avec la clé définitive l'est.

⏱ Point de vigilance : les clés définitives n'arrivent qu'une heure avant le live. Faites tous vos réglages en amont avec les clés de test ; le jour J, il ne restera qu'à remplacer la clé.

🔒 Votre clé de stream est un secret. Toute personne qui la détient peut diffuser dans votre salle. Transmettez-la par un canal sécurisé et ne l'affichez jamais lors d'un partage d'écran.

🔸 Résolution, débit et images par seconde

Les cadences européennes 25 et 50 images/seconde sont également prises en charge.

👉 Le 1280 × 720 à 3 000–4 500 kbps est le meilleur compromis pour un webinar. Au-delà, la lisibilité d'une présentation ne s'améliore pas et le risque d'instabilité augmente nettement.

🔸 Paramètres vidéo

🔸 Paramètres audio

⚠️ Vérifiez toujours qu'une source audio est active avant de lancer le direct. Un flux sans son part sans provoquer d'erreur : rien ne vous alertera, seuls vos participants le signaleront. Contrôlez vos vumètres et faites un test de captation.

À l'inverse, un flux audio seul, sans piste vidéo, n'est pas pris en charge : la connexion sera refusée.

🔸 Pourquoi le débit constant (CBR) est-il obligatoire ?

En VBR, l'encodeur augmente le débit sur les scènes complexes — animation, changement de diapositive, mouvement de caméra. Ces pics saturent la liaison montante : images perdues avant même de nous parvenir, puis buffering chez vos participants.

Le CBR maintient un débit régulier, prévisible pour le réseau comme pour les lecteurs. Passez systématiquement vos encodeurs en CBR.

🔸 Pourquoi une image clé toutes les 2 secondes ?

L'image clé est le point d'entrée d'un participant qui rejoint le direct : plus elles sont fréquentes, plus la lecture démarre vite.

Elle détermine aussi le délai de démarrage : 6 à 7 secondes avec un intervalle de 2 secondes, 3 à 4 secondes avec 1 seconde — au prix de changements de qualité plus fréquents chez les participants.

N'allez jamais au-delà de 5 secondes. Le découpage du flux ne peut plus être aligné, d'où des artefacts visuels et des erreurs de lecture au démarrage et lors des changements de qualité.

🔸 Configuration pas à pas dans OBS Studio

1. Paramètres → Flux
   • Service : Personnalisé…
   • Serveur : l'URL de diffusion RTMPS fournie dans la salle, onglet « Autre » (commence par rtmps://)
   • Clé de stream : votre clé Webikeo (clé de test pour vos essais, clé définitive le jour du live)
2. Paramètres → Sortie → Mode de sortie : Avancé — onglet Streaming
   • Encodeur : x264, ou votre encodeur matériel (NVIDIA NVENC, Apple VT…)
   • Contrôle du débit : CBR
   • Débit : 4500 Kbps (ou 3000 sur connexion modeste)
   • Intervalle d'image clé : 2
   • Préréglage d'utilisation du CPU : veryfast
   • Profil : main
   • Réglage (Tune) : zerolatency
3. Paramètres → Sortie — onglet Audio
   • Débit audio : 128 ou 160 kbps
4. Paramètres → Vidéo
   • Résolution de sortie (mise à l'échelle) : 1280x720
   • Valeurs FPS communes : 30
5. Paramètres → Général — activez l'enregistrement local en parallèle de la diffusion. C'est votre filet de sécurité en cas d'incident réseau.
6. Cliquez sur Démarrer le streaming.

💡 L'assistant de configuration automatique d'OBS propose parfois des valeurs hors limites. Corrigez-les manuellement d'après les tableaux ci-dessus.

⚠️ Laissez la vidéo multipiste désactivée. Si votre version d'OBS propose « Activer la vidéo multipiste » (Enable Multitrack Video), ne cochez pas la case : nos salles ne sont pas configurées pour l'entrée multipiste et la connexion échouerait.

5 - Prérequis matériels et logiciels

💻 Configuration du poste d'encodage

Encoder une vidéo en temps réel sollicite fortement le processeur.

• Processeur (CPU) : double cœur 2 GHz minimum, quadri cœur 2,5 GHz recommandé. Trop lent → pertes d'images, baisse de qualité, décalage image/son.
• Mémoire vive (RAM) : 4 Go disponibles minimum, 8 Go recommandés. Insuffisante → gels d'image et coupures.
• Carte graphique (GPU) : facultative, mais l'encodage matériel (NVENC, AMF, Apple VT) soulage nettement le processeur.
• Machine dédiée : rien d'autre sur le poste pendant le direct. Fermez navigateurs, visioconférences et synchronisations cloud.
• Analyses antivirus : désactivez les analyses programmées sur le créneau de diffusion.
• Alimentation et ventilation : branchez sur secteur et vérifiez la ventilation. Une surchauffe ou un mode économie d'énergie dégrade directement la fluidité du direct.

🎛 Logiciel ou boîtier d'encodage

Tout encodeur compatible RTMPS convient :

• OBS Studio (gratuit, Windows / macOS / Linux) — le plus répandu
• vMix, Wirecast, Streamlabs
• Encodeurs matériels compatibles RTMPS (Blackmagic ATEM, Teradek, LiveU, AJA…)
• FFmpeg, pour les workflows automatisés

Maintenez votre logiciel à jour : les versions anciennes peuvent ne pas gérer TLS 1.2, indispensable au RTMPS.

6 - En cas de problème ou d'interruption

🔸La diffusion est refusée dès le lancement

Ce que cela signifie : votre flux dépasse les limites acceptées, ou la connexion n'a pas pu s'établir.

Causes les plus fréquentes, dans l'ordre :

1. Résolution ou débit trop élevés. Repassez en 1280 × 720 et vérifiez que le débit ne dépasse pas le plafond de cette résolution, 4 500 kbps. Les 8 500 kbps ne valent qu'en 1920 × 1080.
2. Port 443 bloqué ou RTMPS filtré par le pare-feu de l'entreprise.
3. URL de diffusion ou clé de stream incorrecte : recopiez-les depuis l'onglet « Autre » plutôt que de les saisir à la main, et vérifiez que vous utilisez la clé définitive et non une clé de test.
4. Logiciel d'encodage trop ancien, ne prenant pas en charge TLS 1.2.

🔸La diffusion s'interrompt en cours de direct

Ce que cela signifie : votre encodeur a cessé d'envoyer des données (coupure réseau, arrêt du logiciel, erreur interne).

Ce que voient vos participants : le lecteur disparaît, remplacé par un message indiquant qu'aucun flux n'est diffusé.

Comportement de la plateforme : sans flux pendant une minute, le live est coupé. Vous pouvez le relancer — votre webinar n'est pas perdu.

Actions à effectuer :

1. Vérifiez que votre câble réseau est toujours branché et que la connexion est active.
2. Relancez la diffusion depuis votre encodeur, avec la même clé de stream.
3. Consultez le journal d'événements de votre encodeur : il indique souvent la cause exacte de la déconnexion.
4. Informez vos participants dans le chat de la salle si l'interruption se prolonge.

⚠️ Conséquence sur le replay : selon la durée de l'interruption, deux replays distincts peuvent être générés, avant et après la coupure. Réalisez alors un montage des deux fichiers et chargez-le dans votre espace client Webikeo pour remplacer le replay proposé à vos inscrits — sans quoi vos participants n'auront accès qu'à une partie du webinar.

🔸 L'image est saccadée ou figée chez les participants

Ce que cela signifie : le débit montant n'est plus suffisant ou plus stable, ou le poste d'encodage sature.

Actions à effectuer :

1. Vérifiez le compteur d'images perdues de votre encodeur.
2. Libérez la bande passante : coupez les usages simultanés sur le même réseau.
3. Si le problème persiste, réduisez le débit (par exemple de 4 500 à 3 000 kbps) : mieux vaut une image moins définie qu'une image figée.
4. Vérifiez la charge CPU : proche de 100 %, choisissez un préréglage moins gourmand ou activez l'encodage matériel.

🔸 Après le webinar : prévenir les problèmes futurs

Si des coupures ou des dégradations sont survenues pendant la session :

• Testez votre connexion Internet hors période de diffusion (débit montant, stabilité).
• Vérifiez la configuration réseau avec votre DSI (port 443, RTMPS, plages IP, pare-feu, proxy, VPN).
• Conservez le journal d'événements de votre encodeur et transmettez-le à notre service client.
• Prenez rendez-vous avec le service client avant votre prochain webinar.