CGJU
CGJU
5 mai 2026 · Temps de lecture 7 minutes

Définition et classification de la latence de streaming

La latence de streaming est le décalage temporel entre la capture du signal et sa lecture chez le spectateur, généralement divisée en latence verre-à-verre (Glass-to-Glass Latency) et latence de bout en bout. Selon le niveau de latence, les solutions de streaming se classent en plusieurs catégories :

  • Streaming traditionnel : latence de 10-30 secondes, comme HLS standard, DASH
  • Streaming à faible latence : latence de 2-5 secondes, comme LL-HLS, Low-Latency DASH
  • Streaming à ultra-faible latence : latence de 500ms-1 seconde, comme WebRTC, SRT
  • Interaction en temps réel : latence inférieure à 200ms, comme la visioconférence

Les exigences de latence varient considérablement selon les applications. Le streaming e-commerce nécessite une latence de 2-3 secondes pour accompagner l'interaction par commentaires en direct, tandis que le streaming d'événements sportifs peut accepter une latence de 5-10 secondes. Choisir la bonne technologie à faible latence implique de trouver un équilibre entre latence, coût, compatibilité et qualité d'image.

Principe technique de WebRTC

WebRTC (Web Real-Time Communication) est une technologie de communication en temps réel initiée par Google, initialement conçue pour les appels vidéo entre navigateurs, aujourd'hui largement utilisée également dans les scénarios de streaming à faible latence.

Composants clés de WebRTC

  • Capture média : capture audio-vidéo via l'API getUserMedia
  • Codec : prend en charge VP8, VP9, H.264, AV1, etc.
  • Couche transport : basée sur le protocole RTP/RTCP, utilise UDP
  • Traversée NAT : résout les problèmes de traversée réseau via les serveurs STUN/TURN
  • Moteur média : traitement d'annulation d'écho, réduction de bruit, tampon de gigue, etc.

Architecture de streaming WebRTC

Le streaming WebRTC utilise généralement une architecture SFU (Selective Forwarding Unit). L'émetteur pousse le flux audio-vidéo vers le serveur SFU, qui se charge de le transmettre à chaque spectateur. Comparé à l'architecture MCU, le SFU ne fait que transmettre sans réencodage, offrant une latence plus faible et une meilleure évolutivité.

// Exemple de code côté lecteur WebRTC
const peerConnection = new RTCPeerConnection({
    iceServers: [
        { urls: 'stun:stun.l.google.com:19302' }
    ]
});

peerConnection.ontrack = (event) => {
    const video = document.getElementById('video');
    video.srcObject = event.streams[0];
};

// Réception de l'SDP distant et réponse
async function receiveOffer(offerSdp) {
    await peerConnection.setRemoteDescription(
        new RTCSessionDescription(offerSdp)
    );
    const answer = await peerConnection.createAnswer();
    await peerConnection.setLocalDescription(answer);
    return answer;
}

LL-HLS HLS à faible latence

LL-HLS (Low-Latency HLS) est une extension HLS à faible latence présentée par Apple en 2019. Grâce à l'introduction de technologies comme les segments partiels (Partial Segments) et la mise à jour incrémentielle des playlists, elle réduit la latence HLS des 10-30 secondes traditionnelles à 2-5 secondes.

Technologies clés de LL-HLS

  • Segments partiels (Partial Segments) : les segments TS sont découpés en parties plus petites, chaque partie pouvant être chargée indépendamment
  • Indice de préchargement de playlist : indique à l'avance l'adresse du segment suivant via EXT-X-PRELOAD-HINT
  • Mise à jour Delta : ne renvoie que les modifications de la playlist, réduisant le transfert de données
  • Rapport de rendu : prend en charge un basculement de débit plus fin via EXT-X-RENDITION-REPORT
  • Push HTTP/2 : utilise HTTP/2 Server Push pour envoyer les données de segment à l'avance

Exemple de playlist LL-HLS

#EXTM3U
#EXT-X-VERSION:9
#EXT-X-TARGETDURATION:2
#EXT-X-MAP:URI="init.mp4"
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.0,CAN-SKIP-UNTIL=12.0
#EXT-X-PART-INF:PART-TARGET=0.5
#EXT-X-MEDIA-SEQUENCE:100
#EXT-X-GAP
#EXTINF:2.0,
gap_100.mp4
#EXT-X-PROGRAM-DATE-TIME:2026-05-05T12:00:00.000Z
#EXTINF:2.0,
file101.mp4
#EXT-X-PART:URI="part102_1.mp4",DURATION=0.5,INDEPENDENT=YES
#EXT-X-PART:URI="part102_2.mp4",DURATION=0.5
#EXT-X-PART:URI="part102_3.mp4",DURATION=0.5
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="part102_4.mp4",BYTERANGE-START=0

Protocole SRT

SRT (Secure Reliable Transport) est un protocole de transport open source développé par Haivision, basé sur UDP. Il combine à la fois la fiabilité de TCP et la faible latence d'UDP, et est largement utilisé dans la radiodiffusion et le streaming professionnel.

Caractéristiques clés de SRT

  • Retransmission ARQ : retransmet automatiquement les paquets perdus pour garantir la fiabilité de la transmission
  • Estimation de bande passante : surveille en temps réel l'état du réseau et ajuste dynamiquement le débit d'envoi
  • Chiffrement AES-128 : fonction de chiffrement intégrée pour garantir la sécurité du contenu
  • Multiplexage : prend en charge le transport de plusieurs flux sur une seule connexion
  • Mode faible latence : tampon de latence configurable pour équilibrer latence et stabilité

Comparaison des données de latence

Voici une comparaison des performances de latence des trois technologies dans des configurations typiques :

  • WebRTC : latence de bout en bout 300ms - 1 seconde, adapté aux scénarios d'interaction en temps réel
  • SRT : latence de bout en bout 500ms - 2 secondes, adapté au streaming professionnel et au transport de sources de contribution
  • LL-HLS : latence de bout en bout 2 - 5 secondes, adapté à la distribution à grande échelle

Comparaison de compatibilité

Compatibilité navigateurs

  • WebRTC : pris en charge par Chrome, Firefox, Safari, Edge, meilleure compatibilité
  • LL-HLS : pris en charge nativement par Safari, Chrome/Firefox/Edge nécessitent hls.js
  • SRT : pas de support natif dans les navigateurs, nécessite WebAssembly ou une conversion par passerelle

Compatibilité appareils

  • WebRTC : pris en charge nativement par iOS/Android, faible support sur les téléviseurs intelligents
  • LL-HLS : pris en charge nativement par iOS/macOS, compatibilité moyenne sur Android
  • SRT : bon support sur les appareils professionnels, support limité sur les appareils grand public

Analyse des cas d'utilisation

Cas d'utilisation WebRTC

  • Streaming interactif : chat vidéo, PK, streaming e-commerce
  • Surveillance en temps réel : caméras de sécurité, télémédecine
  • Éducation en ligne : petits groupes, cours interactifs
  • Jeu en cloud : streaming de jeux, bureau cloud

Cas d'utilisation LL-HLS

  • Streaming à grande échelle : concerts, événements sportifs
  • Streaming e-commerce : présentation de produits, interaction par commentaires
  • Streaming d'actualités : reportages sur le terrain, conférences de presse
  • Distribution CDN : utilisation de l'infrastructure HTTP existante

Cas d'utilisation SRT

  • Transport de sources de contribution : renvoi de signal du terrain vers le studio
  • Transport sur réseau étendu : transmission de signaux interrégionaux
  • Réseaux difficiles : réseaux mobiles, liaisons satellite
  • Production audiovisuelle : flux de production de streaming professionnel

Conseils de choix

Lors du choix d'une technologie de streaming à faible latence, il est recommandé de prendre en compte plusieurs dimensions :

1. Exigences de latence

Si vous avez besoin d'une ultra-faible latence inférieure à 1 seconde, WebRTC est le choix privilégié ; si vous pouvez accepter une latence de 2-5 secondes, LL-HLS offre des avantages en termes de compatibilité et de coût de distribution.

2. Échelle du public

L'architecture SFU de WebRTC a une capacité de support limitée par serveur (généralement 1000-5000 connexions simultanées). La distribution à grande échelle nécessite une cascade ou une combinaison avec un CDN. LL-HLS, basé sur HTTP, peut pleinement utiliser l'infrastructure CDN existante et supporter sans problème des millions de connexions simultanées.

3. Coût de développement

La pile technologique WebRTC est complexe, nécessitant la gestion de la signalisation, de la traversée NAT, de la récupération de perte de paquets, etc., avec des coûts de développement et de maintenance plus élevés. LL-HLS, basé sur l'extension HLS standard, est relativement simple à développer et son écosystème est plus mature.

4. Solution hybride

Dans de nombreux scénarios, la meilleure solution consiste à combiner plusieurs technologies, par exemple :

  • L'émetteur utilise SRT pour transmettre vers le serveur, garantissant la stabilité de l'émission
  • Après transcodage côté serveur, sortie simultanée WebRTC et LL-HLS
  • Les spectateurs interactifs passent par WebRTC pour une faible latence, les spectateurs ordinaires passent par LL-HLS pour garantir la fluidité
  • L'enregistrement et le timeshift utilisent le HLS standard

Conclusion

Chaque technologie de streaming à faible latence a ses avantages et ses inconvénients, il n'y a pas de solution miracle. WebRTC offre les meilleures performances en termes de latence, mais son coût de distribution est élevé ; LL-HLS offre une bonne compatibilité et est facile à distribuer, mais sa latence est relativement plus élevée ; SRT présente des avantages dans le domaine du transport professionnel, mais son support terminal est limité.

Lors du choix réel, il faut juger globalement en fonction du scénario métier, des exigences de latence, de l'échelle du public et des capacités de l'équipe technique. Pour la plupart des applications de streaming destinées aux utilisateurs finaux, LL-HLS est un choix équilibré ; pour les scénarios à forte interaction, WebRTC est indispensable ; tandis que dans le domaine du streaming professionnel et du transport de signaux, SRT est le partenaire idéal.

Si vous souhaitez expérimenter rapidement la lecture HLS, vous pouvez utiliser notre lecteur M3U8 en ligne, sans avoir à écrire de code pour lire des flux vidéo HLS dans le navigateur.

Articles recommandés

Plus d'articles intéressants et d'outils pratiques

Vous voulez essayer le lecture de streaming immédiatement ?

Utilisez notre lecteur M3U8 en ligne gratuit, pas besoin de coder, lisez directement les flux HLS dans le navigateur

Essayer maintenant ➡