Introduction
—
Pourquoi cette série

L’IRL est souvent présenté comme quelque chose de simple :

un téléphone, une caméra, un réseau, et “ça devrait marcher”.

Dans la réalité, l’IRL est un enchaînement de choix techniques, de compromis, d’échecs, de redémarrages, et parfois… d’abandons en plein live.

Cette série, Les chemins de l’IRL, n’est pas un guide parfait.

C’est un retour d’expérience réel, construit sur le terrain, avec ses erreurs, ses corrections et ses apprentissages.

Ce premier épisode pose la base : le setup.

Le problème de départ

Au début, mon approche était classique :

• une caméra = un flux
• plusieurs RTMP
• OBS qui jongle
• beaucoup de bande passante

Sur le papier, tout fonctionnait.

Sur le terrain :

• des flux qui disparaissent
• des images qui arrivent en retard
• du son qui dérive
• des redémarrages forcés
• une latence qui tue toute interaction avec les viewers

Le constat était simple :

👉 le problème n’était pas OBS, mais la chaîne entière.

Changer de logique : agréger avant de diffuser

La première décision structurante a été celle-ci :

Arrêter d’envoyer plusieurs flux vers Internet.

À la place :

• récupérer toutes les sources localement
• stabiliser et choisir la vue avant l’upload
• n’envoyer qu’un seul flux propre vers le serveur

C’est ce choix qui a tout débloqué.

Les caméras

Le setup repose sur :

• 2 DJI Osmo Action 5 Pro

Pourquoi ?

• excellente stabilisation
• encodage matériel fiable
• comportement prévisible en mobilité

Les caméras :

• encodent en H.264
• audio en mono
• se connectent en Wi-Fi local

👉 Elles ne streament plus directement vers Internet.

Moblin : le cerveau mobile

Sur iPhone, Moblin devient le cœur du système.

Il permet :

• de recevoir les deux flux caméras
• de choisir la vue envoyée
• d’adapter le bitrate au réseau
• de gérer les variations 4G / 5G

Moblin n’est plus un simple “outil de stream” :

c’est un agrégateur intelligent.

Le transport : SRT(LA)

Le flux sortant de Moblin utilise :

• SRT (Secure Reliable Transport)
• en mode Low Latency
• avec l’implémentation officielle

Pourquoi SRT et pas RTMP ?

• meilleure tolérance aux pertes
• latence maîtrisable
• correction d’erreurs intégrée
• comportement stable sur réseau mobile

C’est ici que la latence a réellement commencé à baisser.

OBS dans le cloud

Le flux arrive ensuite sur un VPS qui héberge :

• OBS Studio
• les overlays
• la diffusion multi-plateformes

OBS ne fait plus de magie :

• il reçoit un seul flux
• il ajoute l’habillage
• il diffuse vers Twitch et YouTube

Le plugin multi-RTMP évite les encodages multiples.

Le dashboard IRL

Pour éviter de “deviner” si tout va bien, j’ai développé un petit dashboard :

Il affiche :

• l’état d’OBS
• l’état du flux entrant
• la charge CPU
• l’état Twitch / YouTube
• un bouton de rechargement des overlays

Le tout est :

• responsive
• sécurisé
• accessible depuis un téléphone

👉 En IRL, un coup d’œil doit suffire.

Le contrôle à distance

Depuis un second téléphone :

• OBS Blade
• changement de scène
• start / stop live
• preview

Aucun ordinateur à sortir du sac.

Aucune manipulation lourde en public.

Le résultat

Après plusieurs stress tests (dont un live de plus de 2h) :

• flux stable
• latence réduite
• plus de dérive audio
• plus besoin de redémarrer OBS en live
• interactions enfin naturelles avec le chat

Le live est redevenu… du live.

Conclusion de l’épisode 1

Ce setup n’est pas figé.

Mais il repose désormais sur une base claire :

• moins de flux
• moins de points de rupture
• plus de contrôle
• moins de stress

Dans le prochain épisode, on s’attaquera à un sujet clé :

👉 la latence, comment la mesurer, la comprendre, et la réduire sans casser la stabilité.