Latence vidéo : optimiser le temps réel WebRTC
Réponse courte
La latence vidéo en WebRTC mesure le délai entre l'émission d'une frame et sa réception par l'autre participant. En conditions normales, l'ordre de grandeur est 200 ms à 1 seconde pour l'interaction, bien en deçà du streaming différé (HLS, 5–30 s). Les facteurs principaux sont la distance au SFU, la qualité réseau, le choix de chemin ICE et le dimensionnement serveur.
Latence WebRTC vs streaming différé
| Protocole | Latence typique | Usage |
|---|---|---|
| WebRTC | 200 ms – 3 s | Dialogue, vidéo en temps réel, assistance |
| WebSocket (data) | 50 – 500 ms | Signalisation, chat |
| HLS / DASH | 5 – 30 s | Webinaire massif, replay |
| RTMP | 2 – 5 s | Ingestion streaming |
Pour la communication temps réel, WebRTC est le protocole adapté.
Les 6 facteurs de latence WebRTC
1. Distance réseau au SFU
Chaque milliseconde de RTT (Round Trip Time) s'ajoute. Un SFU en France minimise la latence pour les participants européens.
2. Chemin ICE (direct vs TURN)
- Direct (P2P ou SFU proche) : latence minimale ;
- Relais TURN : latence additionnelle (1 hop serveur) ;
- TURN TCP fallback : latence plus élevée que UDP.
3. Codecs et encodage
- VP8/VP9/H.264 : encodage hardware accéléré = latence réduite ;
- Résolution et fps : 720p/30fps = bon compromis latence/qualité ;
- Simulcast : le SFU choisit la couche sans retranscoder.
4. Dimensionnement SFU
Un SFU saturé (CPU, bande passante) ajoute du jitter et du buffering : latence perçue qui grimpe.
5. Qualité réseau client
- Wi-Fi saturé, 4G faible → adaptation bitrate → latence variable ;
- Packet loss → retransmissions → latence additionnelle.
6. Architecture (SFU vs MCU)
Le SFU (forwarding sans transcodage) a une latence inférieure au MCU (mixage/transcodage).
Latence acceptable par usage
| Usage | Latence cible | Protocole |
|---|---|---|
| Conversation / vidéo en temps réel | < 300 ms idéal | WebRTC |
| Assistance / diagnostic | < 1 s | WebRTC |
| Réunion 10+ participants | < 1–2 s | WebRTC + SFU |
| Live interactif (Q&R) | < 3 s | WebRTC ou hybride |
| Webinaire massif (passif) | 5–30 s acceptable | HLS/DASH |
Comment mesurer la latence ?
- getStats() API : RTT, jitter, packet loss côté client ;
- Monitoring serveur : latence SFU, charge CPU ;
- Tests réseau : postes pare-feu, 4G, Wi-Fi en pilote ;
- MOS score : qualité perçue audio/vidéo.
Optimiser la latence : checklist DSI
- SFU hébergé proche des participants (France) ;
- TURN documenté avec UDP prioritaire, TCP fallback ;
- SFU dimensionné pour le nombre de participants ;
- Codecs hardware-accelerated activés ;
- Simulcast / SVC pour l'adaptation sans retranscodage ;
- Monitoring continu (alertes jitter > 30 ms).
Latence et scalabilité
La scalabilité ne doit pas dégrader la latence : c'est pourquoi le SFU horizontal (pas le MCU) est le standard.
Comment Leagora optimise la latence ?
Infrastructure WebRTC avec SFU en France, TURN documenté, simulcast, monitoring. Contact pour un atelier réseau.
Produits : meeting.leagora.io (vidéo en temps réel), assistance-video.fr (assistance 1:1).
FAQ
Quelle latence minimale avec WebRTC ?
~150–200 ms en conditions optimales (direct, même réseau). En production B2B : 300 ms – 1 s est réaliste.
Le TURN augmente-t-il la latence ?
Oui, d'un hop serveur (~20–100 ms selon distance). Moins que l'échec de connexion sans TURN.
La latence dépend-elle du navigateur ?
Marginalement : Chrome, Firefox, Safari récents ont des performances comparables. Le réseau domine.
HLS peut-il avoir une latence faible ?
LL-HLS (Low Latency HLS) vise 2–5 s : mieux que HLS classique, mais au-dessus de WebRTC pour l'interaction.
Leagora.io garantit-il une latence chiffrée ?
Leagora.io documente les facteurs. Les garanties SLA sont contractuelles.
À retenir
- Latence WebRTC = 200 ms – 1 s en production (sub-secondaire en optimal).
- SFU France + TURN documenté + simulcast = triptyque optimisation.
- Leagora.io = hub infrastructure ; produits métier sur les sites satellites.