WHIP et WHEP pour le broadcast : OBS, audio Opus et conversion WebRTC vers SRT

WebRTC ne se limite plus aux appels vidéo. Avec WHIP pour la contribution et WHEP pour la lecture, il devient un composant pratique d’un workflow broadcast : OBS envoie un programme live avec une latence interactive, un navigateur ouvre un retour basse latence et une gateway convertit la même route en SRT pour un décodeur ou un centre MCR.

WHIP, WHEP, WebRTC, SRT et HLS ne résolvent toutefois pas le même problème. Ce guide explique où placer chaque protocole, comment l’audio Opus influe sur l’interopérabilité et comment configurer un workflow OBS vers WHIP sans présenter WebRTC comme un remplacement universel de SRT.

WHIP, WHEP et WebRTC en une minute

WHIP est un standard proposé de l’IETF publié sous la forme de la RFC 9725. Il utilise un échange HTTP simple pour établir la session WebRTC : l’encodeur envoie une offre SDP, le serveur retourne une réponse SDP, puis le média circule sur le chemin ICE/DTLS/SRTP négocié.

WHEP applique un modèle HTTP comparable à la lecture. En septembre 2026, il reste un Internet-Draft actif de l’IETF, et non une RFC publiée. Les implémentations sont déjà utiles, mais les versions et les lecteurs doivent encore être testés avec soin.

Le workflow broadcast

Une architecture WebRTC utile n’emploie pas nécessairement WebRTC de bout en bout :

OBS / caméra / navigateur
        │ WHIP (contribution WebRTC)
        ▼
    Route Vajracast
     ├── WHEP → retour navigateur, preview, spectateur basse latence
     ├── SRT  → MCR, serveur de production distant, décodeur broadcast
     ├── HLS  → audience plus large et diffusion CDN
     └── Fichier → enregistrement

Le workflow inverse est tout aussi utile :

Encodeur terrain / récepteur satellite / flux partenaire
        │ SRT
        ▼
    Route Vajracast
        │ WHEP
        ▼
Mur vidéo navigateur, réalisateur, journaliste, client ou retour de contrôle

Cette conversion de protocoles live répond à un besoin opérationnel. WHIP simplifie la contribution depuis les encodeurs logiciels. WHEP rend la lecture basse latence accessible aux navigateurs. SRT reste adapté au transport résilient entre sites et aux décodeurs matériels.

Configurer OBS pour envoyer en WHIP

OBS publie un guide officiel du streaming WHIP. La configuration de base est volontairement plus courte qu’une URL SRT complète.

1. Créer l’entrée WHIP

Dans Vajracast :

1. Créez ou ouvrez une route.
2. Ajoutez une entrée et choisissez WHIP.
3. Enregistrez l’entrée.
4. Copiez l’URL du point d’entrée WHIP et l’identifiant d’accès affiché pour cet endpoint lorsque l’authentification est activée.

Gardez ces informations confidentielles. Un bearer token WHIP remplit le même rôle opérationnel qu’une clé de stream : une personne qui le possède peut potentiellement publier sur l’entrée.

2. Saisir l’endpoint dans OBS

Dans OBS, ouvrez Paramètres → Stream et renseignez :

Ne collez pas une URL SRT dans le champ serveur WHIP. WHIP emploie un endpoint HTTPS pour la signalisation ; le chemin média WebRTC est négocié après cet échange HTTP.

OBS précise que WHIP n’est pas disponible dans tous les packages de l’application. Son guide officiel recommande notamment aux utilisateurs du PPA Ubuntu 24.04 qui ont besoin de WHIP d’utiliser la version Flatpak. Consultez la documentation OBS correspondant à votre plateforme avant de rechercher une panne côté serveur.

3. Commencer avec des réglages média prudents

Les capacités du service et l’état du réseau comptent davantage qu’un preset universel. Voici un point de départ pratique :

H.264 et VP8 sont les codecs vidéo obligatoires à implémenter pour les endpoints WebRTC selon la RFC 7742. D’autres codecs peuvent être disponibles, mais « pris en charge par OBS » ne signifie pas automatiquement « accepté par chaque service WHIP » ni « décodé par chaque navigateur ». H.264 constitue souvent le pont le plus pratique lorsque la route doit aussi alimenter des systèmes broadcast conventionnels.

4. Contrôler la route avant le direct

Vérifiez séparément quatre niveaux :

1. OBS indique une connexion réussie et un débit sortant stable.
2. L’entrée WHIP est saine dans Vajracast.
3. Les informations de codecs audio et vidéo correspondent à la route attendue.
4. Une preview WHEP ou une sortie en aval joue avec une bonne synchronisation labiale et le bon mapping audio.

Si la signalisation aboutit mais qu’aucun média n’arrive, vérifiez l’UDP, la connectivité ICE, le pare-feu et la négociation des codecs. Une réponse HTTP 201 ne prouve pas à elle seule que le chemin média est fonctionnel.

Pourquoi Opus est important

Opus n’est pas un codec anecdotique dans WebRTC. La RFC 7874 impose son implémentation aux endpoints WebRTC, aux côtés de G.711 PCMA et PCMU. Opus doit normalement être préféré lorsque l’endpoint sait traiter de l’audio large bande.

Il convient bien à la contribution interactive parce qu’il gère la parole comme la musique, adapte son débit et fonctionne avec un faible délai algorithmique. L’interopérabilité broadcast dépend néanmoins de l’appareil situé en aval.

SRT n’impose pas de codec audio. Il transporte le format média choisi par l’émetteur et le récepteur, souvent dans un MPEG-TS. Convertir WHIP vers SRT peut donc recouvrir deux opérations :

• Réemballer si les formats sont compatibles : conserver H.264 et Opus lorsque le récepteur SRT accepte les deux.
• Transcoder pour assurer l’interopérabilité : conserver ou convertir la vidéo et convertir Opus en AAC, MP2 ou AC-3 lorsque le décodeur, le MCR, le point d’ingestion CDN ou la chaîne satellite l’exige.

Testez aussi le nombre de canaux. Une source Opus stéréo orientée navigateur n’est pas équivalente à un programme broadcast multicanal, même si les deux affichent « audio présent ». Utilisez une matrice audio lorsqu’il faut séparer, remapper ou convertir les canaux pour la destination.

WHIP vers SRT : quand la conversion est utile

Contributeur distant vers un MCR

Un journaliste ou un producteur envoie une scène composée dans OBS via WHIP. Vajracast convertit la route en SRT Caller ou Listener pour le centre MCR. Le contributeur bénéficie d’un workflow OBS simple ; la régie reçoit le protocole qu’elle maîtrise déjà.

Contribution logicielle vers un décodeur matériel

La source entre en WHIP puis ressort sous forme de flux SRT/MPEG-TS compatible avec un décodeur SDI ou HDMI. Une normalisation H.264 et une conversion Opus vers AAC peuvent être nécessaires.

Une contribution, plusieurs chemins de diffusion

Une entrée WHIP peut alimenter une preview WHEP basse latence, une destination de production SRT, une audience HLS et un enregistrement. Chaque sortie poursuit un objectif différent de latence et de compatibilité ; imposer un seul protocole à toute la chaîne serait moins efficace opérationnellement.

SRT vers WHEP : apporter les flux broadcast au navigateur

La conversion SRT vers WHEP est utile lorsque la source est déjà un flux de contribution broadcast, mais que les spectateurs sont des opérateurs, clients, journalistes ou producteurs utilisant un navigateur.

Cas d’usage fréquents :

• mur vidéo navigateur réunissant plusieurs flux entrants ;
• contrôle de confiance pour un producteur distant ;
• preview client sans installer VLC ni lecteur SRT ;
• retour quasi temps réel pour une équipe de production distante ;
• lecteur interne basse latence en parallèle d’une sortie HLS publique plus retardée.

Cette conversion ne transforme pas un navigateur en moniteur broadcast étalonné. La gestion des couleurs, le désentrelacement, les codecs, l’exposition des canaux audio et le décodage matériel restent importants. Utilisez WHEP pour l’accès et l’immédiateté ; conservez un monitoring broadcast adapté lorsqu’il faut certifier la conformité du signal.

WebRTC, SRT ou HLS ?

WebRTC atteint souvent une latence inférieure à la seconde dans de bonnes conditions, mais il ne supprime pas les limites du réseau. Un chemin congestionné ou très dégradé peut geler, réduire la qualité ou se déconnecter. SRT ajoute volontairement un budget de latence afin de retransmettre les paquets. Le choix dépend donc de la priorité : interaction ou récupération ; consultez le guide d’optimisation de la latence SRT pour ce volet du transport.

Problèmes fréquents

OBS affiche une erreur d’authentification

Vérifiez séparément l’URL de l’endpoint WHIP et le bearer token. Ne réutilisez pas une clé RTMP sauf si le fournisseur indique explicitement qu’elle sert aussi d’identifiant WHIP.

La signalisation fonctionne, mais la route ne reçoit aucun média

Contrôlez l’UDP sortant, le NAT, la configuration ICE/STUN/TURN et le pare-feu. La signalisation HTTPS et le média SRTP utilisent des chemins réseau distincts.

La vidéo fonctionne, mais l’audio disparaît après conversion en SRT

Le récepteur SRT ne prend peut-être pas en charge Opus dans MPEG-TS. Consultez ses codecs audio acceptés et transcodez vers AAC-LC, MP2, AC-3 ou un autre format pris en charge.

WHEP fonctionne dans un lecteur, mais pas dans un autre

WHEP reste un draft en évolution et le profil de codec négocié peut varier entre les clients. Testez les versions exactes des navigateurs et lecteurs utilisés en production.

La latence augmente avec le temps

Mesurez séparément la capture et l’encodage, le réseau, le traitement de la gateway, le jitter buffer du lecteur et l’affichage. La « latence WebRTC » est la somme de toute la chaîne, pas une seule métrique serveur.

Checklist de déploiement

• Utiliser une version récente d’OBS qui inclut WHIP.
• Protéger l’URL WHIP et le bearer token comme une clé de stream.
• Commencer avec H.264 et Opus, sauf si tous les endpoints ont été validés avec un autre codec.
• Vérifier que le récepteur SRT accepte Opus avant de choisir le passthrough.
• Valider le profil vidéo, le pixel format, la cadence, le codec audio, la fréquence d’échantillonnage et le nombre de canaux.
• Tester la connectivité UDP/ICE depuis le véritable réseau du contributeur.
• Créer les sorties WHEP, SRT, HLS et enregistrement selon leurs usages distincts.
• Superviser indépendamment l’entrée WHIP et chaque endpoint de sortie.
• Configurer le failover lorsque le flux est critique pour la production.
• Tester toute la chaîne avant le direct, y compris la reconnexion après une interruption réseau.

À retenir

WHIP et WHEP facilitent l’intégration de WebRTC dans les systèmes broadcast parce qu’ils standardisent les extrémités : publier vers un service et lire depuis celui-ci. Ils ne remplacent pas le routage, la supervision, la conversion des codecs, l’enregistrement ni le transport résilient.

L’architecture la plus utile est souvent hybride. Employez WHIP lorsqu’un encodeur logiciel ou un navigateur doit contribuer simplement avec une faible latence, WHEP lorsqu’un navigateur doit lire immédiatement, SRT lorsque le réseau ou le récepteur professionnel impose un transport résilient, et HLS lorsque l’échelle de l’audience est prioritaire.

La passerelle SRT Vajracast réunit ces workflows dans une même route : entrée WHIP, preview WHEP, remise SRT, distribution HLS, enregistrement, supervision de santé et failover sans imposer le même protocole à tous les participants.