Technologies de streaming

QUIC, MoQ et CMCD : guide pour les ingénieurs broadcast

Comprenez QUIC, Media over QUIC et CMCD : schémas de diffusion, avantages, sécurité, télémétrie du lecteur et vérifications avant déploiement.

12 min de lecture Mis à jour 14 septembre 2026

Trois technologies, trois fonctions distinctes

Pourquoi un direct peut-il se figer alors que l'encodeur fonctionne et que le CDN renvoie des réponses réussies ? Le problème peut venir du transport, de la distribution des médias, du tampon ou du terminal. QUIC, Media over QUIC (MoQ) et Common Media Client Data (CMCD) interviennent à des niveaux différents. Distinguer leurs rôles permet de choisir une amélioration mesurable.

Technologie	Fonction	Bénéfice technique
QUIC	Transport chiffré sur UDP, à la base de HTTP/3.	Des flux indépendants et une connexion plus rapide peuvent faciliter la diffusion sur des réseaux variables.
MoQ / MOQT	Publication et abonnement à des objets média nommés, sur QUIC ou WebTransport.	Organiser la diffusion selon la disponibilité du direct, les priorités et les relais.
CMCD	Informations du lecteur envoyées aux services de diffusion ou d'analyse.	Relier les mesures de livraison à l'état du lecteur.

Spécifications vérifiées le 14 septembre 2026. QUIC v1 et HTTP/3 font l'objet de RFC publiées. MOQT reste un projet IETF : ce guide s'appuie sur la révision 21 du 8 septembre 2026. L'API WebTransport est une recommandation candidate du W3C. CMCD v2 est publié dans CTA-5004-B, daté du 14 avril 2026. La publication d'une spécification ne garantit pas sa prise en charge par un téléviseur, un SDK ou un CDN donné.

Ce guide décrit des architectures. Il n'annonce aucune prise en charge actuelle de MoQ ou CMCD par Evrideo. Vérifiez les interfaces et l'interopérabilité auprès de vos fournisseurs avant tout déploiement.

Leur place dans la chaîne de diffusion

La production, la programmation et la régie centrale déterminent toujours le programme. L'encodage détermine la compression et une part importante de la latence. Les deux chemins ci-dessous se séparent après l'encodage. Un diffuseur MoQ exige un format média et un lecteur compatibles ; changer uniquement le transport ne transforme pas un lecteur HLS en lecteur MoQ.

Production / fichiers → régie centrale → encodage

Streaming HTTP

1. Empaqueteur + origine : HLS / DASH
2. CDN : HTTP/3 / QUIC ou HTTP/2 / TCP
3. Lecteur : demandes média et rapports CMCD

Diffusion MoQ

1. Publication MoQ : format média + pistes
2. Relais MoQ : objets sur QUIC / WebTransport
3. Lecteur MoQ : réception, tampon et décodage

Lire chaque chemin de haut en bas. En HTTP, les données CMCD remontent avec les requêtes du lecteur ; les événements peuvent rejoindre un collecteur distinct. La télémétrie d'un service MoQ nécessite une intégration explicite. Ces exemples présentent deux chemins possibles, pas un empilement obligatoire.

Les flux de contribution peuvent conserver leurs interfaces existantes. Une passerelle ou une intégration dans l'encodeur serait nécessaire pour publier leur sortie en MoQ. QUIC et CMCD ne modifient ni le codec, ni les droits sur les contenus, ni les pauses publicitaires programmées.

QUIC : ce qui change sous la couche média

Dans la spécification IETF, QUIC est un nom, pas un acronyme. Une connexion chiffrée sur UDP transporte plusieurs flux d'octets fiables et ordonnés. Une perte sur un flux n'oblige pas les autres à attendre les octets manquants. L'ordre reste toutefois garanti dans le flux affecté. La congestion et les limites de ressources de la connexion restent déterminantes. Voir RFC 9000.

RFC 9001 intègre TLS 1.3 à l'établissement de la connexion. Une reprise de connexion peut utiliser des données anticipées 0-RTT, sous réserve d'un état préalable, de l'accord du serveur et d'opérations compatibles avec le risque de rejeu. Cela ne garantit pas un démarrage instantané. Les identifiants de connexion peuvent aussi faciliter un changement de chemin côté client, selon les paramètres négociés et les conditions réseau.

HTTP/3 peut transporter les flux HLS et DASH existants

HTTP/3 applique les mécanismes HTTP à QUIC. Le lecteur continue à demander des manifestes, des fragments et des segments. Un CDN compatible peut donc améliorer le transport sans changer le format média. Vérifiez le protocole réellement négocié : HTTP/3 côté lecteur ne signifie pas que la liaison CDN-origine l'utilise aussi. Conservez un repli HTTP lorsque UDP est bloqué.

La récupération des pertes utilise toujours du temps et du débit

Les mécanismes de récupération et de congestion de QUIC pilotent les retransmissions et le débit d'envoi. Des flux indépendants ne créent pas de bande passante. Un accès saturé peut ralentir toutes les variantes. Les datagrammes de RFC 9221 ajoutent des messages non fiables aux flux : cette extension ne retransmet pas les datagrammes perdus. L'application doit décider comment traiter un média absent ou trop tardif.

Comparez connexion, démarrage, interruptions, charge processeur et débit reçu sur les mêmes terminaux et réseaux dégradés. Une connexion plus rapide ne compense pas plusieurs secondes d'anticipation de l'encodeur, d'empaquetage ou de tampon de lecture.

MoQ : diffuser des objets en direct via des relais

MoQ Transport, révision 21 définit les éditeurs, abonnés, pistes, groupes et objets. Une piste regroupe des groupes, qui offrent des points d'entrée ; les objets contiennent des octets définis par l'application. Les relais s'abonnent en amont et publient en aval. Mise en cache et priorisation font partie du modèle. Le transport repose sur QUIC directement ou sur WebTransport.

Le format média apporte la configuration du codec, les horodatages et les dépendances. Le projet distinct Low Overhead Media Container propose un format pour les médias encodés, notamment avec WebCodecs. Il faut convenir de la révision du transport, du format et des profils de codec. L'appellation « MoQ » ne suffit pas à assurer l'interopérabilité.

L'intérêt pratique réside dans l'ordonnancement des objets à travers les relais. En cas de congestion, un service peut privilégier des pistes importantes ou des médias récents utiles et abandonner des transferts périmés selon sa politique. Il doit respecter les dépendances de décodage : supprimer arbitrairement des objets vidéo peut interrompre l'image jusqu'au prochain point d'entrée adapté. HLS et DASH à faible latence permettent déjà une livraison progressive. Comparez donc les chaînes complètes, sans supposer que tout service HTTP attend un long segment terminé.

Séquence conceptuelle, sans détails du protocole : établissement, réponses, découverte et erreurs sont omis. Le relais peut déjà être abonné en amont. La synchronisation audio/vidéo relève de l'application média.

Un pilote pertinent serait un service de visionnage d'événement en direct avec un objectif de latence défini. Comparez démarrage, continuité et récupération avec le chemin existant dans les mêmes conditions. Une sortie HLS/DASH permet de servir les appareils hors du pilote. Les résultats de laboratoire ne constituent pas une garantie pour toute l'audience.

Lecteurs, sécurité et contraintes d'exploitation

WebTransport expose des flux et datagrammes entre navigateur et serveur, sans fournir de lecteur complet. WebCodecs expose des fonctions d'encodage et de décodage. L'application doit gérer tampon, synchronisation, sélection des pistes, rendu et reprise. Testez chaque combinaison navigateur, système, codec et terminal, y compris le passage en arrière-plan et les changements de réseau.

Validez séparément sous-titres, métadonnées synchronisées, transitions publicitaires, pistes audio alternatives, accessibilité et DRM. Un système SSAI reposant sur des manifestes HTTP personnalisés exige une intégration explicite pour alimenter MoQ. La programmation de la régie centrale reste la référence.

QUIC chiffre la connexion entre ses extrémités. Un relais qui termine cette connexion peut donc accéder au média si aucune autre protection n'est appliquée. Le projet MoQ secure objects traite du chiffrement des objets à un autre niveau. Ce projet et TLS ne fournissent pas automatiquement licences DRM commerciales, droits d'accès, décodage sécurisé ou protection des sorties. Prévoyez les autorisations des relais, la gestion des clés et la traçabilité.

L'évaluation économique doit inclure capacité des relais, rétention des objets, trafic sortant, supervision, développement des lecteurs, support et trafic de secours. Une réduction du coût global doit être démontrée pour votre audience simultanée et votre parc de terminaux.

CMCD : comprendre ce que vit le lecteur

CMCD permet au lecteur de signaler la durée de son tampon, le débit demandé ou le débit réseau estimé. L'exploitant peut rapprocher ces données des temps de réponse et du cache. Une réponse réussie prouve qu'un segment a été livré ; le lecteur peut malgré tout être proche d'une interruption.

CTA-5004-B définit le mode Requête et le mode Événement, facultatif. Le premier joint les données aux demandes d'objets média, dans des en-têtes HTTP ou un paramètre de requête. Le second transmet des rapports à des destinations configurées dans le corps d'une requête POST, indépendamment de la prochaine demande média. La réception d'une réponse est un événement, pas un troisième mode de rapport.

Les rapports partent du lecteur. Le collecteur représente un service d'analyse distinct du chemin média. L'optimisation est facultative et dépend du fournisseur : signaler un tampon faible ne garantit aucune priorité ni correction.

Les requêtes HTTP/1.1, HTTP/2 et HTTP/3 peuvent transporter CMCD. Son intérêt ne dépend donc pas d'une migration vers QUIC. MoQ ne crée pas nécessairement une requête HTTP par objet : définissez son intégration de télémétrie au lieu de supposer que les en-têtes CMCD existants suivront automatiquement.

Lire un rapport sans mélanger les versions

Ces exemples fictifs décrivent une demande DASH en direct : deux secondes de vidéo à 3 000 kbit/s, quatre secondes en tampon et un débit estimé à 6 000 kbit/s. Ils illustrent la syntaxe, sans recommander un débit ni un identifiant de session réel.

CMCD v1 : valeurs scalaires

CMCD-Object: br=3000,d=2000,ot=v
CMCD-Request: bl=4000,mtp=6000
CMCD-Session: sf=d,sid="demo-session",st=l

br indique le débit, d la durée de l'objet, ot=v la vidéo, bl le tampon et mtp le débit estimé. Les durées sont en millisecondes, les débits en kbit/s. sf=d signifie DASH et st=l désigne le direct. L'absence de version indique v1. Voir CTA-5004 v1.

CMCD v2 : listes structurées et version explicite

CMCD-Object: br=(3000;v),d=2000,ot=v
CMCD-Request: bl=(4000),mtp=(6000)
CMCD-Session: sf=d,sid="demo-session",st=l,v=2

Plusieurs champs scalaires deviennent des listes en v2. Le paramètre ;v identifie la valeur vidéo dans la liste des débits. Le guide Common Media Library de la SVTA explique la sérialisation selon la version. Utilisez un outil compatible et validez la réception. Ajouter v=2 à des données v1 ne les convertit pas.

Exemple de diagnostic : le débit estimé passe sous le débit demandé tandis que le tampon diminue. Cela justifie d'examiner la capacité de livraison ou l'adaptation. Si le tampon reste suffisant mais que l'image se fige, examinez aussi le décodage, le rendu, les horodatages et le DRM. Il s'agit d'hypothèses à vérifier avec les événements du lecteur et les données réseau.

Déploiement et critères d'acceptation

Séparez les expériences. Commencez par CMCD sur un groupe de lecteurs si la visibilité manque. Évaluez HTTP/3 indépendamment. Réservez un pilote MoQ à un usage où la réduction du délai apporte un bénéfice précis. Vous pourrez ainsi attribuer les améliorations et annuler une régression.

Vérification	Preuves attendues
Compatibilité	Versions exactes du lecteur, SDK, CDN et protocole ; négociation et chemins de repli.
Réseau	Blocage UDP, pertes, gigue, bande passante réduite et transitions Wi-Fi/mobile.
Continuité	Démarrage, reprise, changement de variante, synchronisation, sous-titres et pauses publicitaires.
Collecte CMCD	Unités et versions correctes ; valeurs inconnues omises ; champs inconnus traités sans risque.
Cache et navigateur	Paramètres CMCD exclus de la clé de cache ; en-têtes autorisés par CORS ; absence de fragmentation par spectateur.
Confidentialité	Identifiants minimisés, destinataires et rétention approuvés, journaux expurgés, validation des données client.
Rentabilité	QoE comparée à la référence, coût total, responsabilité du support et critères de retour arrière.

Un identifiant de session peut devenir corrélable avec d'autres journaux. Évitez identifiants persistants et données sensibles. Aucun secret d'authentification ne doit figurer dans la télémétrie. Définissez les destinataires autorisés et appliquez vos exigences de consentement et de confidentialité. Un tampon faible déclaré par un client ne doit jamais lui accorder une priorité illimitée.

Pour QUIC, MoQ et CMCD, fixez les seuils avant l'implémentation. Mesurez la distribution des délais de démarrage et des interruptions sur des terminaux représentatifs. Conservez les diagnostics lors d'un repli pour expliquer le chemin réellement reçu.

Consultez aussi le glossaire broadcast, le guide DRM et le guide d'insertion publicitaire guidée par le serveur. Pour étudier votre chaîne de diffusion, contactez Evrideo.

Références

Retour aux guides