Internet événementiel : préparer la connexion et tester le secours

Dessiner les usages Internet et ceux du réseau local

Internet relie aux services externes ; le réseau local fait communiquer les appareils du lieu, par exemple commande de console ou vidéo IP. Le Wi-Fi donne accès à un réseau. Un bon signal Wi-Fi peut coexister avec une sortie insuffisante vers la plateforme. Dessinez les fonctions nécessaires et notez leur responsable.

Séparez les usages sur le plan : encodeur et plateformes, intervenants distants, exploitation technique, accueil et participants. Convenez avec IT des switches, VLAN, SSID et politiques. Des noms Wi-Fi distincts peuvent organiser les utilisateurs ; demandez aussi comment la capacité est réservée si tous partagent la même sortie.

Lors de la demande, précisez si vous prévoyez du streaming (en espagnol), des invités distants, des transferts de fichiers, de l’interprétation ou un accès public. Ces tâches diffèrent en permissions, horaires et tolérance aux coupures. Un transfert peut attendre ; une intervention en direct exige son parcours prêt au moment prévu.

Questions au lieu et au fournisseur avant le montage

Demandez par écrit point de livraison, activation, débits montant et descendant convenus, partage et support pendant le spectacle. Si l’offre est dite dédiée, demandez ce qui est exclusif : port, segment local, capacité réservée ou circuit. Cela précise la prestation et les dépendances restantes.

Confirmez DHCP ou adressage convenu, authentification, restrictions de port et portail captif. Fournissez à IT destinations et protocoles pour autoriser et tester le nécessaire dans ses politiques. Ouvrir une page web est un premier contrôle ; il reste à vérifier l’accès de l’encodeur au serveur d’ingest qui recevra le direct.

À l’hôtel ou en congrès, testez le point physique avant l’ouverture et demandez quels événements partageront le service. Dehors, vérifiez la portée d’une liaison fixe et les alternatives sur place. Convenez de l’accès autorisé au coffret ou au support, de l’alimentation et de la protection des câbles. Gardez le contact technique accessible si le port est loin de la régie.

Calculer le débit montant selon les envois simultanés

Listez vidéo et audio de l’encodeur, second envoi, participants distants et autres transferts simultanés. Additionnez les besoins selon l’architecture et gardez une marge d’exploitation. Si une plateforme redistribue votre direct, chaque spectateur ne crée pas automatiquement un nouvel envoi depuis le lieu. Plusieurs sorties directes de l’encodeur, en revanche, comptent.

YouTube distingue débits montant et descendant et recommande une marge par rapport au débit total envoyé. Le partage du réseau limite aussi la capacité de chaque connexion. Vérifiez cette orientation pour YouTube et ajoutez les besoins des autres services simultanés. Consultez ses conseils de streaming.

Résolution, cadence et codec modifient les réglages d’envoi. Avant de finaliser, consultez la table actuelle de la plateforme et l’encodeur prévu. Conférence, match et diffusions parallèles peuvent demander des réglages différents. Consultez les réglages officiels d’encodeur YouTube pour le flux à préparer.

Exemple de calcul proposé ici : deux envois de 8 Mbps totalisent 16 Mbps avant autres usages et marge. C’est un point de départ, pas une garantie qu’une offre de 16 Mbps suffise. Il reste à considérer surcharge réseau, débit soutenu et résultat de l’essai jusqu’à destination.

Tester le câble à la position réelle de l’encodeur

OBS recommande une liaison filaire pour le streaming, le Wi-Fi pouvant être instable. Branchez le poste au point autorisé et suivez son parcours jusqu’à destination. Un test dans le hall ne représente pas nécessairement le port de régie. Le guide OBS sur les problèmes de connexion détaille les vérifications.

Notez port, switch, adaptateur, type et longueur de câble, protection du parcours. Choisissez les liaisons avec IT ou le fournisseur selon normes et distances du projet. Étiquetez les deux extrémités et repérez les risques de débranchement : table déplacée, porte ou service peuvent affecter un câble qui fonctionnait au premier essai.

Pour longues distances, passages entre bâtiments ou autres réseaux, demandez une étude spécifique. Revoyez parcours, alimentation, circulation et accès aux appareils plutôt que d’ajouter câbles et switches à mesure. Un montage anticipé permet le contrôle avant la répétition générale.

Comprendre le secours lors de la perte du parcours principal

Dessinez principale et secours avec leurs dépendances : fournisseur, accès physique, routeur, switch, alimentation et destination. Deux connexions peuvent aboutir au même appareil ou partager l’énergie. Demandez quelle diversité est offerte et quelle panne couvrir : liaison, équipement ou alimentation. Identifiez ainsi les limites du secours.

Haivision Gateway documente des parcours SRT active-active et active-backup, et distingue secours de liaison et d’équipement. Extrémités et configuration doivent être compatibles. Si cette architecture est proposée, revoyez la documentation de redondance SRT Haivision avec le fournisseur ; deux modems raccordés ne définissent pas encore la gestion du transport.

Un routeur avec failover change la sortie ; bonding ou redondance de transport peuvent employer plusieurs parcours selon leur conception. Demandez que la proposition identifie solution, récepteur ou service associé. Un changement d’IP ou de session peut imposer une reconnexion. Testez la bascule et observez le lecteur final pour mesurer ce que voit et entend le public.

Si le secours est cellulaire, testez sur place à un horaire représentatif. Vérifiez antennes, alimentation, forfait et trafic prévu. La capacité peut varier à l’arrivée du public ; documentez limites et reprise du programme. Un bon essai préalable aide à planifier, sans fixer la capacité de tout le spectacle.

Du test de débit à un essai jusqu’au public

Sauvegardez le test de débit avec heure, point et conditions. Envoyez ensuite depuis l’encodeur et le compte réels, avec mouvement, audio et durée représentative. YouTube recommande un contenu proche du direct et le suivi de son état. Consultez ses réglages et essais d’ingest en préparant la répétition.

Dans OBS, distinguez pertes d’images réseau et problèmes de rendu ou d’encodage. Les dropped frames réseau indiquent un parcours instable vers le serveur ou un débit non soutenu. Sauvegardez indicateurs et logs pour revoir le tronçon avec opérateur ou fournisseur. Le guide de diagnostic de connexion OBS aide à distinguer ces situations.

Observez aussi depuis une connexion extérieure à la production. Écoutez la voix, vérifiez image, synchronisation et accès sur les appareils prévus. Gardez les autres flux actifs et notez l’effet de la charge ajoutée. L’aperçu en régie est utile ; le contrôle externe complète ce qui se passe à destination.

Invités distants, langues et enregistrement local

Avec chaque invité distant, répétez entrée, retour, partage d’écran et conversation avec la salle. Convenez de qui donne l’accès, suit le programme et fournit l’alternative en cas de perte de connexion. Le réseau de l’invité fait partie de l’intervention même depuis une autre ville.

En cas d’interprétation simultanée (en espagnol), ajoutez parcours des interprètes et auditeurs, permissions de plateforme et essai par langue. Récepteurs indépendants et application audio en réseau ont des besoins distincts. Vérifiez la solution complète avant de remplacer l’une par l’autre.

Pour un enregistrement local, convenez des signaux sauvegardés et écoutez un extrait. En cas de coupure du direct, le fichier peut servir à une livraison ultérieure ; il ne conservera que les canaux enregistrés et le direct aura sa propre reprise. Le centre d’aide technique permet de revoir les domaines de cette chaîne.

Préparer la connexion et répéter la reprise

Réservez l’essai de panne à une répétition convenue, avant ouverture ou début du direct de production. Mesurez temps de reprise et gestes opérateur. Vérifiez chaque destination pour décrire le résultat, y compris toute interruption vue par le public de test.

1. Lister les usages

   Relevez appareils, plateformes, envois simultanés et usages publics. Convenez avec lieu et fournisseur de la capacité et des responsables.

2. Confirmer le point de livraison

   Vérifiez port, permissions, adressage, horaires et support. Identifiez principale et secours.

3. Monter à la position réelle

   Installez et étiquetez Ethernet, switches et alimentation prévus. Testez avec l’encodeur à son poste réel.

4. Ouvrir chaque application

   Envoyez vers l’ingest réel, passez les appels distants et écoutez les langues ou services dépendant du réseau.

5. Ajouter les usages simultanés

   Activez les flux représentatifs et observez encodeur, réseau et lecture externe pendant la durée convenue.

6. Tester bascule et retour

   Interrompez de façon contrôlée le parcours principal pendant la répétition. Vérifiez la reprise du programme puis le retour au principal.

7. Suivre la connexion pendant le spectacle

   Gardez indicateurs et contact support accessibles. Notez changements et pannes pour l’analyse après l’événement.

Isoler les coupures dans OBS

Comparez les parcours et conservez le log affecté. Une amélioration après plusieurs réglages ne désigne pas une cause unique. Répétez un essai à la fois avec encodeur et destination de l’événement.

Bon test de débit, mais streaming instable

Si plusieurs tronçons changent ensemble, une émission stable ne dit pas lequel a résolu la coupure.

Pour plusieurs destinations, relevez le parcours complet : encodeur, connexion, service intermédiaire et destination. Répétez des essais comparables après intervention du fournisseur ou changement de tronçon. Observez où la coupure apparaît et ce qui change lorsqu’elle disparaît.

Préparez une alternative déjà testée. Plusieurs changements peuvent rétablir l’émission sans révéler la cause. Pour enquêter, changez une variable par essai et conservez le résultat ; une session stable doit encore tenir pendant la durée prévue du service.

Le guide OBS sur les problèmes de connexion propose de comparer serveurs ou services, d’examiner le débit dynamique et de travailler avec le fournisseur Internet. Choisissez selon vos résultats d’essai.

1. Reproduire le montage

   Testez avec caméras, cartes de capture et audio de l’événement. Sauvegardez heure, durée, destination, débit et pertes d’images. Séparez alertes réseau, rendu et encodage.

2. Comparer les deux parcours

   Testez un envoi direct puis via le service intermédiaire avec des réglages comparables. Répétez après intervention du fournisseur. Utilisez le résultat pour situer le tronçon qui change.

3. Fournir les données au fournisseur

   Transmettez heures et logs des coupures. Pour maintenir un envoi pendant l’enquête, évaluez réduction de débit ou débit dynamique ; convenez avec la production de l’effet sur l’image.

Sauvegarder le log de la session ayant subi la coupure

Utilisez le log de la session concernée pour identifier connexion et adaptateur actifs lors de la coupure.

Avant de remplacer du matériel, vérifiez que le fichier concerne la panne : heure, session, adaptateur. Un log d’une autre connexion peut conduire à modifier un réseau non impliqué.

Vérifiez modèle du poste, versions et changements précédant la panne. Après réglage, répétez un essai complet et soutenu ; la disparition d’un avertissement est une observation, pas la fin de l’essai.

Pour câble, connexion et pilote, consultez le guide Ethernet de Microsoft.

1. Reproduire et sauvegarder cette session

   Pendant un envoi de test, notez l’heure exacte de coupure. Arrêtez-le et sauvegardez le log avant de fermer OBS. Après redémarrage, distinguez log précédent et actuel ; vérifiez l’adaptateur utilisé.

2. Changer un élément à la fois

   Comparez câble et port avec des éléments éprouvés. Notez renégociation du lien, déconnexion ou seules pertes d’images vers la destination. Une indication de 100 Mbps ne démontre pas, seule, un manque de débit.

3. Revoir le pilote avec le support

   Si les coupures suivent une mise à jour, vérifiez le pilote du modèle exact. Conservez un installateur de secours et testez tout changement hors service.

Wi-Fi connecté, mais accès Internet encore bloqué par l’hôtel

Avoir une IP et avoir terminé l’authentification sont deux contrôles distincts.

Avant le montage, demandez à IT une connexion de production autorisée et l’expiration de session. Si le secours utilise ce Wi-Fi, testez l’accès avec routeur et appareils prévus. Un téléphone naviguant directement sur le Wi-Fi de l’hôtel ne teste pas les clients derrière le routeur.

1. Localiser le blocage

   Vérifiez association Wi-Fi, adresse attribuée, ouverture du portail et accès d’un ordinateur derrière le routeur. Sur GL.iNet, Login Mode remet DNS en automatique et suspend certains services pendant l’accès ; vérifiez ensuite ceux qui restent actifs.

2. Consulter le panneau de votre firmware

   En v4.8.x, Global Mode et Policy Mode présentent des contrôles distincts. Vérifiez si une politique VPN bloque ce client avant de modifier les réglages.

3. Convenir de l’accès avec l’hôtel

   Si le portail échoue encore, demandez à IT d’autoriser le routeur ou de fournir une autre connexion. Une fois l’accès prêt, testez envoi et reconnexion de l’encodeur avant le spectacle.

Câble et Wi-Fi vers le même routeur : quelle panne couvre le secours ?

Vérifiez si le routeur détecte la perte d’Internet lorsque le lien physique local reste connecté.

Suivez les deux parcours jusqu’à leur sortie. S’ils rejoignent le même routeur et fournisseur, passer du câble au Wi-Fi conserve ces dépendances. Cela peut couvrir une panne du câble ; convenez avec IT de la panne visée avant de parler de secours Internet.

1. Noter où finit chaque parcours

   Relevez connexion, passerelle et équipement de sortie avec IT. Deux IP différentes ne révèlent pas l’infrastructure partagée.

2. Vérifier ce que détecte le routeur

   Dans Multi-WAN de GL.iNet, Interface Status Track contrôle la disponibilité ; désactivé, il se fonde sur l’état physique. Vérifiez cette option et les priorités d’interface dans le firmware prévu.

3. Tester une panne avec câble toujours connecté

   Convenez avec IT d’une perte contrôlée de la sortie Internet, en plus du débranchement du câble. Observez appel ou direct, notez la reprise, puis répétez au retour au principal.

Load Balance répartit les connexions : tester l’upload de l’encodeur

Avec un accès fixe et un mobile, mesurez le débit de l’encodeur sur chacun avant d’additionner leurs Mbps dans une proposition. Sur Multi-WAN GL.iNet, Load Balance répartit les nouvelles connexions selon le ratio configuré. Cela peut aider l’ensemble des postes ; une seule connexion d’envoi n’obtient pas automatiquement la somme des liaisons.

Le guide Multi-WAN précise que ce ratio ne garantit pas la même répartition du trafic déjà actif. Un ordinateur peut ouvrir plusieurs connexions ; compter les postes ne suffit pas à connaître l’usage réparti.

Testez chaque accès séparément avec débit, destination et durée de l’événement. Répétez ensuite avec le mode prévu et les autres tâches actives : invités distants, transferts et réception de fichiers. Observez de l’extérieur et sauvegardez connexion et réglages de chaque essai.

Avec un Spitz AX GL-X3000, vérifiez aussi le manuel de ce modèle : une seule SIM est active à la fois, la seconde sert de réserve. Pour deux accès cellulaires simultanés, identifiez l’appareil et le modem assurant chacun.

Avant d’ajouter un routeur, convenir de l’adressage du réseau audio

En ajoutant Internet, prévenez l’opérateur audio avant de raccorder un routeur au switch de production. Dessinez l’entrée de la liaison externe et les appareils déjà communicants. Demandez à IT de vérifier attribution des adresses et ports prévus.

Sur Avantis ou dLive avec M-DL-DANT64/128, la note du fabricant avertit qu’ajouter un réseau DHCP peut changer l’adresse de la carte et provoquer une perte audio temporaire. Revoyez donc l’adressage avant de brancher le routeur.

Sauvegardez adresses, noms et schéma avant l’intervention. Convenez d’un créneau d’essai ; testez avec un signal reconnaissable à chaque destination. Si une application ne trouve plus la console, vérifiez aussi l’adresse actuelle avant de toucher au patch fonctionnel.

Identifiez aussi le connecteur : sur ces cartes, Control Network et pont interne servent au contrôle sans transporter d’audio. La même note en précise la portée. Étiquetez le câblage et actualisez le plan pour distinguer accès de contrôle et parcours Dante.

Sur le poste de production, nommer chaque connexion par sa fonction

Un ordinateur peut participer à plusieurs réseaux. Identifiez chaque connexion par sa fonction : Internet, contrôle audio ou liaison d’un appareil. Notez aussi adaptateur physique et application utilisatrice pour suivre le parcours sans deviner.

Digiface Dante fournit un exemple : outre l’audio USB, elle peut donner un accès Ethernet au Mac. RME a modifié ce support avec le firmware 64 ; depuis cette version, l’extension netifc n’est plus nécessaire. Vérifiez matériel et version en préparant le poste plutôt que de répéter la configuration d’un autre événement.

Avec toutes les connexions prévues, vérifiez sortie streaming et accès aux appareils locaux. Répétez les deux après changement d’adaptateur. Le fonctionnement d’une application confirme seulement cette partie ; vérifiez l’autre avant de clore l’essai.

Sauvegardez une capture des interfaces avec le schéma. L’opérateur suivant dispose ainsi d’un repère pour identifier les changements. Cela aide aussi le lieu lorsque l’accès Internet coexiste avec un réseau technique propre.

Pour distribuer l’audio, fournir la liste des destinations au réseau

Une demande réseau est plus claire si elle précise qui reçoit chaque signal. Séparez audio destiné à un poste et contenu distribué à plusieurs salles, enregistreurs ou processeurs. Cette liste permet de vérifier la distribution avant d’ajouter des connexions.

Dante utilise unicast par défaut. Multicast partage des canaux entre plusieurs récepteurs, mais consomme encore du débit sans abonné. Une liste de destinations est donc plus utile qu’une demande de multicast généralisé.

Notez les appareils ajoutés pendant le programme et les parcours retirables en fin de séquence. Revoyez avec audio et responsable réseau avant l’ouverture. Actualisez la liste pour tout nouveau poste : la connectivité change même si fichiers ou musique restent identiques.

Repérer Primary et Secondary avant de brancher un appareil

Quand production, diffusion et personnel du lieu coexistent, un port libre peut tenter quelqu’un. Identifiez qui peut raccorder les appareils et placez un schéma au rack. Avant de brancher un nouvel ordinateur, vérifiez à quel réseau appartient la prise.

Audinate décrit Primary sur un réseau physique et Secondary sur un autre, séparé, pour les appareils redondants. Ceux sans redondance vont sur Primary. Deux prises réseau ne confirment pas à elles seules la fonction de ce modèle.

Incluez audio et accès Internet de chaque poste dans le schéma. Si une prise n’est pas identifiée, consultez le responsable réseau avant de l’utiliser. Régler cela au montage évite les branchements improvisés pendant une panne.

Paquets tardifs et corrompus : deux essais distincts

Si Internet fonctionne mais l’audio local coupe, vérifiez la liaison de cet audio. Un test de débit externe n’emprunte pas nécessairement le tronçon entre switch et récepteur.

Dans Network Status, Latency Errors signale les arrivées proches ou hors délai ; Packet Errors, les paquets corrompus entre switch et récepteur. Pour ces derniers, comparez le câble à un câble éprouvé, hors service.

Répétez le même audio et surveillez le retour des erreurs. Une comparaison à la fois : changer câble, switch et réglages ensemble empêche d’isoler l’effet.

Fiche de connexion pour coordonner lieu et production

Listez les tâches dépendant d’Internet. Pour chacune, notez salle, horaire, application et responsable : diffusion, invités distants, accueil ou accès public. Repérez les usages simultanés.

Ajoutez contacts du lieu et du fournisseur avec leur mission. Précisez qui demande le service, confirme la commande et peut intervenir pendant l’événement.

Joignez la proposition de connexion reçue et indiquez les points à confirmer. Si point de livraison ou horaire d’activation restent inconnus, désignez qui les obtiendra.

Télécharger la fiche de connexion (TXT) — fiche vierge de planification ; la remplir n’envoie aucune demande.

SRT : distinguer pertes détectées et paquets non récupérés

Si vous recevez le direct avec un Makito X4 Decoder, sauvegardez les compteurs du flux en début et fin d’essai. Notez les heures de coupure.

Dans la section SRT du manuel 1.7, Lost Packets compte les pertes détectées pouvant être récupérées. Skipped Packets désigne les paquets arrivés trop tard et écartés ; Recovered Packets (SRT), ceux récupérés à temps.

Comparez ces variations à l’image et au son à destination. N’attribuez pas une panne au dernier segment à partir d’un total cumulé pouvant inclure des incidents antérieurs.

Teams : revoir ports et destinations avec IT

Microsoft documente TCP 80/443 et UDP 3478–3481, ainsi que les URL et plages IP de Teams. Fournissez à IT la liste officielle pour vérifier le parcours dans ses politiques.

Testez audio, vidéo et partage d’écran sur le poste et la connexion de l’événement. Notez coupures et reconnexions. Ouvrir une page web ne complète pas cet essai.

Web Presenter HD/4K : confirmer la connexion utilisée pour l’envoi

Avec Ethernet et téléphone connectés, vérifiez Setup → Network → Connection Priority. Le manuel de mai 2024 permet de choisir la connexion d’envoi ; pour le partage de connexion mobile avec Ethernet branché, il indique Mobile.

Préparez le partage de connexion du téléphone et testez le parcours choisi en observant le lecteur final. Relevez bascule et retour. Choisir la priorité ne dispense pas de tester la reprise.

Web Presenter HD/4K : surveiller Data Rate et Cache

Data Rate affiche le débit de l’encodeur même hors antenne. Cache indique le remplissage du buffer ; à 100 %, le direct est compromis. Notez les deux et observez le lecteur externe.

Manuel Web Presenter, mai 2024, p. 14.