MPEG-DASH expliqué, et comment il se compare à HLS

Si vous avez ouvert les DevTools de Chrome sur Netflix ou YouTube et vu des requêtes pour des fichiers se terminant par .mpd et .m4s, vous avez regardé MPEG-DASH à l’œuvre. Le fichier XML est un manifeste, les fichiers .m4s sont de courts segments MP4 fragmenté de vidéo et d’audio, et votre navigateur les assemble en temps réel via du HTTP simple.

DASH est le cousin à standard ouvert de HLS. Là où Apple possède HLS, l’organisme de normalisation MPEG/ISO possède DASH. Là où HLS utilise des playlists texte .m3u8, DASH utilise des manifestes XML .mpd. Là où HLS insistait à l’origine sur H.264, DASH n’a jamais eu de préférence de codec. Les deux protocoles résolvent le même problème à partir de points de départ différents, et un service de streaming bien pensé en 2026 livre les deux. MPEG-DASH — Dynamic Adaptive Streaming over HTTP — est le standard ISO/IEC 23009-1 pour livrer la vidéo sous forme d’une chaîne de courts segments fMP4 décrits par un manifeste XML (.mpd) et récupérés via du HTTP ordinaire.

Ce guide parcourt ce qu’un .mpd contient réellement, comment fonctionne la hiérarchie Period / AdaptationSet / Representation de DASH, où s’inscrit le DRM, les arguments pour et contre DASH face à HLS, et ce qui se passe quand vous essayez de sauvegarder l’un de ces flux sur disque.

Points clés {#key-takeaways}

• MPEG-DASH est le standard ouvert ISO pour le streaming HTTP adaptatif — ISO/IEC 23009-1. HLS est RFC 8216.
• Le manifeste .mpd est en XML, pas en texte brut. Il décrit les Periods, AdaptationSets et Representations — une hiérarchie stricte que le lecteur parcourt au démarrage et à chaque changement de qualité.
• DASH est agnostique en matière de codec par conception. H.264, H.265, VP9, AV1, AAC, Opus — le manifeste déclare les chaînes de codec et le lecteur décode.
• Les segments média sont du MP4 fragmenté (.m4s), les mêmes fragments CMAF utilisés par le HLS moderne. Un seul ensemble d’octets peut servir les deux protocoles.
• Le DRM utilise MPEG Common Encryption (CENC) pour qu’un seul fichier chiffré fonctionne avec Widevine, PlayReady ou FairPlay selon le module de déchiffrement du client.
• Les plateformes Apple ne supportent pas DASH nativement. iPhone, iPad, Safari et Apple TV requièrent HLS — DASH-seul est rédhibitoire.
• Netflix, YouTube, Disney+, Hulu et Max livrent tous DASH et HLS côte à côte ; Apple TV+, iTunes et Twitch ne livrent que HLS.

L’explication simple

Oubliez les acronymes un instant. Un service de streaming a le même problème dans les deux cas : livrer une longue vidéo à des spectateurs sur des connexions désordonnées, leur permettre de chercher instantanément, leur permettre de s’adapter aux changements de bande passante en cours de lecture, et le faire à bas coût sur du HTTP de base. La solution adoptée par toute l’industrie est de découper la vidéo en courts segments, d’écrire un manifeste qui les liste, et de laisser le lecteur récupérer ce dont il a besoin dans l’ordre. HLS fait cela avec des playlists texte ; DASH fait cela avec des manifestes XML. Le travail est le même ; la paperasse est différente.

Du point de vue d’un lecteur, l’approche DASH ressemble presque à HLS. Le lecteur récupère un petit manifeste au démarrage, apprend quelles qualités et pistes audio sont disponibles, en choisit une de chaque selon la bande passante et le viewport, puis récupère un flux de courts segments et les alimente au décodeur. Les changements de qualité se produisent entre segments. Les flux en direct fonctionnent en faisant grandir le manifeste au fil du temps. La recherche est instantanée parce que le lecteur saute au segment couvrant l’horodatage cible.

La différence visible pour l’utilisateur entre les deux protocoles est petite mais réelle. Les playlists HLS sont en texte brut ; les manifestes DASH sont en XML. Les segments HLS étaient historiquement des .ts (MPEG-2 Transport Stream) et sont maintenant généralement en fMP4 ; les segments DASH ont toujours été en fMP4, avec l’extension .m4s. Les organismes sponsors sont également différents : Apple a inventé et gère HLS, tandis que DASH est issu de MPEG et du DASH Industry Forum sous forme de standard ISO ouvert sans fournisseur unique à sa tête. Pour l’introduction correspondante, HLS en détail couvre à quoi ressemble une playlist .m3u8 de bout en bout.

Comment fonctionne réellement DASH

Un flux DASH, c’est un manifeste XML plus un tas de segments MP4 fragmenté, le tout servi via du HTTP ordinaire. Même forme que HLS, format différent à chaque couche.

Le manifeste .mpd

La première chose qu’un lecteur DASH récupère est la Media Presentation Description — le .mpd. Contrairement à la playlist en texte brut de HLS, c’est un document XML avec un schéma défini. Voici un exemple légèrement allégé :

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
     type="static"
     mediaPresentationDuration="PT1H30M"
     minBufferTime="PT2S"
     profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period id="0" start="PT0S">
    <AdaptationSet mimeType="video/mp4" segmentAlignment="true"
                   startWithSAP="1" maxWidth="1920" maxHeight="1080">
      <Representation id="v1" codecs="avc1.640028"
                      width="1920" height="1080" bandwidth="5000000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="v1/init.mp4"
                         media="v1/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
      <Representation id="v2" codecs="avc1.4d401f"
                      width="1280" height="720" bandwidth="2800000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="v2/init.mp4"
                         media="v2/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
    </AdaptationSet>
    <AdaptationSet mimeType="audio/mp4" lang="en">
      <Representation id="a1" codecs="mp4a.40.2" bandwidth="128000">
        <SegmentTemplate timescale="1000" duration="4000"
                         initialization="a1/init.mp4"
                         media="a1/seg-$Number$.m4s"
                         startNumber="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Chaque attribut signifie quelque chose de concret. type="static" marque ceci comme VOD (un flux en direct est type="dynamic"). mediaPresentationDuration="PT1H30M" est une durée ISO 8601. Chaque Representation porte une chaîne de codec et un budget de bande passante. Le SegmentTemplate est là où la magie opère : au lieu de lister chaque URL de segment comme le fait HLS, DASH laisse le manifeste déclarer un motif d’URL et le lecteur calcule les URL à la volée.

Periods, AdaptationSets et Representations

La hiérarchie stricte à l’intérieur du manifeste est le cœur conceptuel de DASH :

• Period — une tranche contiguë de la chronologie. La plupart des films sont une seule période ; les diffuseurs utilisent plusieurs périodes pour insérer des publicités ou des limites de chapitres.
• AdaptationSet — une collection d’encodages alternatifs du même contenu, interchangeables à l’exécution. Un film typique a un AdaptationSet vidéo, un ou plusieurs AdaptationSets audio (un par langue), et un ou plusieurs AdaptationSets de sous-titres.
• Representation — un encodage concret unique. Du 1080p H.264 à 5 Mbps est une Representation ; du 720p H.264 à 2,8 Mbps en est une autre ; du 720p VP9 à 1,5 Mbps en est une autre. Le lecteur choisit une Representation par AdaptationSet et peut basculer vers une autre à toute frontière de segment à l’intérieur du même AdaptationSet.

Ce modèle à trois niveaux est plus structuré que l’approche plate variantes-et-segments de HLS, ce qui est pourquoi DASH l’emporte sur l’extensibilité : pistes audio multiples, pistes trick-play, pistes de vignettes et insertion publicitaire par période s’intègrent proprement sans inventer de nouvelle syntaxe de manifeste.

Segments et initialisation

Les octets d’une Representation arrivent en deux saveurs. Le segment d’initialisation est un petit fichier fMP4 contenant la boîte moov — paramètres de codec, métadonnées de piste et configuration du décodeur. Le lecteur le récupère une fois par Representation. Les segments média sont l’audio et la vidéo proprement dits, chacun typiquement long de 2 à 6 secondes, coupés sur des frontières d’images-clés pour les pistes vidéo afin que le lecteur puisse commencer à décoder à partir du début de n’importe quel segment.

Quand le manifeste fixe startWithSAP="1", chaque segment commence par un Stream Access Point — l’équivalent DASH du drapeau EXT-X-INDEPENDENT-SEGMENTS de HLS, garantissant que les segments sont indépendamment décodables. Sans cette garantie, les segments en aval peuvent dépendre de segments antérieurs, ce qui rend le basculement adaptatif risqué. Comme les URL du SegmentTemplate sont pilotées par motif (v1/seg-$Number$.m4s), le manifeste peut décrire un film de 90 minutes en quelques centaines d’octets de XML. SegmentTimeline est l’alternative quand les durées ne sont pas uniformes.

Common Encryption (CENC)

L’histoire DRM de DASH passe par MPEG Common Encryption (CENC), ISO/IEC 23001-7. CENC chiffre les segments média eux-mêmes avec AES-128 en mode CTR sous une clé de contenu, puis déclare quels systèmes DRM peuvent émettre cette clé. Dans le .mpd, vous verrez des éléments ContentProtection comme ceci :

<ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc"
                   cenc:default_KID="34e5db32-8625-47cd-ba06-68fca0655a72"/>
<ContentProtection schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
  <cenc:pssh>AAAAW3Bzc2gAAAAA...</cenc:pssh>
</ContentProtection>
<ContentProtection schemeIdUri="urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95">
  <cenc:pssh>AAACfHBzc2gAAAAA...</cenc:pssh>
</ContentProtection>

Le premier bloc déclare l’identifiant de clé par défaut sous CENC. Le second est l’UUID de Widevine ; le troisième est celui de PlayReady. Le Content Decryption Module de votre navigateur lit le bloc correspondant à son DRM supporté, envoie une demande de licence au serveur de licences du service avec les données PSSH (Protection System Specific Header) intégrées, et reçoit en retour la clé de contenu nécessaire pour déchiffrer les segments. Pour le tableau complet, voir comment Widevine et PlayReady gardent les flux premium. Le support FairPlay dans DASH est historiquement peu commun — FairPlay a été conçu pour HLS — mais CMAF + chiffrement CBCS ont rendu le FairPlay-sur-DASH cross-DRM techniquement possible sur un petit ensemble de plateformes.

Agnostique en matière de codec par conception

HLS privilégiait à l’origine H.264 (les premiers appareils Apple ne pouvaient rien décoder d’autre), et ajouter de nouveaux codecs prenait un processus de spécification pluriannuel. DASH n’a jamais choisi de codec — le manifeste déclare juste des chaînes de codec (avc1.640028, hev1.1.6.L150.B0, vp09.00.50.08, av01.0.05M.08) et le lecteur vérifie si son décodeur les supporte. C’est pourquoi YouTube a pu livrer AV1 sur DASH des années avant qu’un support HLS équivalent ne soit livré chez Apple. Comme la couche manifeste est la seule chose que les lecteurs DASH doivent comprendre, VidMost peut analyser un .mpd, parcourir les URL du SegmentTemplate, récupérer chaque fragment fMP4 et remultiplexer le résultat sans se soucier du codec à l’intérieur.

DASH face à HLS : la comparaison honnête

DASH et HLS résolvent le même problème avec des compromis différents. Aucun n’est universellement meilleur. Voici les arguments pour chacun sur les axes qui comptent réellement.

Format du manifeste

Le .mpd de DASH est en XML avec un schéma défini — extensible (les nouvelles fonctionnalités obtiennent de nouveaux éléments, validés par schéma, les anciens lecteurs ignorent ce qu’ils ne comprennent pas) mais verbeux. Le .m3u8 de HLS est en texte brut avec des balises #EXT-X-, lisible d’un coup d’œil et facile à grep. DASH gagne sur la structure et la validation automatique ; HLS gagne sur la lisibilité humaine.

Latence

Les deux ont commencé avec une latence de quelques secondes à quelques dizaines de secondes. Les deux ont livré des extensions à faible latence : LL-HLS utilise des segments partiels, des rechargements de playlist bloquants et des indices de préchargement (Apple a remplacé sa conception antérieure de push HTTP/2 par EXT-X-PRELOAD-HINT), tandis que LL-DASH utilise des segments à transfert en blocs et le profil Common Media Application Format Live. Les deux visent une latence glass-to-glass de 2 à 5 secondes en production. Pour une latence inférieure à la seconde, on descend vers WebRTC.

Support des codecs

DASH a été agnostique en matière de codec dès le premier jour. H.264, H.265, VP9, AV1, AAC, Opus, FLAC, AC-4 — le manifeste déclare la chaîne de codec et le lecteur décide. HLS a commencé H.264-uniquement parce que le matériel iPhone d’origine l’exigeait. Apple a progressivement élargi le support : H.265 sur fMP4 depuis 2017, Dolby Vision et HDR10 depuis 2018, AV1 depuis la génération iPhone 15. Le HLS moderne n’est pas verrouillé sur H.264, mais l’historique de codecs du protocole a un décalage que DASH n’a jamais eu.

DRM

Les deux s’appuient sur un chiffrement de segment basé sur AES, mais les systèmes DRM par-dessus diffèrent. DASH utilise communément CENC avec Widevine et PlayReady — un seul fichier chiffré fonctionne avec les deux parce que la clé de contenu est la même ; seul le format de la demande de licence diffère. HLS utilise historiquement FairPlay Streaming (Apple uniquement) plus, de plus en plus, Widevine via CMAF + CBCS. Une fois votre service en CMAF, les mêmes segments chiffrés peuvent servir les deux types de manifeste et les trois principaux systèmes DRM.

Support Apple/iOS

HLS est obligatoire sur iOS, iPadOS, Safari et Apple TV. DASH n’est nativement supporté sur aucune plateforme Apple. C’est le plus gros facteur décisif dans la stratégie DASH face à HLS. La lecture DASH dans Safari n’est possible que via les Media Source Extensions plus une couche d’adaptation JavaScript comme shaka-player ou dash.js, et même alors elle ne couvre pas chaque cas limite iOS (AirPlay, contrôles d’écran de verrouillage, picture-in-picture). Tout service ciblant les iPhones doit livrer HLS. DASH-seul est rédhibitoire.

Compatibilité CDN et la convergence CMAF

Les deux protocoles sont du pur HTTP. Tout CDN qui sert des fichiers statiques peut servir un flux DASH ou HLS — les coûts et la configuration de CDN sont essentiellement identiques. Le développement le plus important de la dernière décennie est que DASH et HLS partagent maintenant les octets de segments. CMAF — le Common Media Application Format, ISO/IEC 23000-19 — définit un profil MP4 fragmenté qui satisfait à la fois DASH et le HLS moderne. Un service de streaming peut encoder une seule fois en segments CMAF et écrire à la fois un .mpd et un .m3u8 qui pointent vers exactement les mêmes fichiers .m4s. C’est ce qui se passe réellement chez YouTube, Netflix, Apple et la plupart des fournisseurs vidéo hébergés en 2026.

Qui livre quoi en 2026

• Netflix — DASH principal sur web, Windows, Android, téléviseurs connectés et consoles ; HLS de repli pour Safari et iOS.
• YouTube — DASH sur web et Android avec VP9 / AV1 ; HLS pour iOS, Safari, AirPlay et la plupart des applications TV.
• Apple TV+, iTunes Store — HLS uniquement.
• Twitch — HLS uniquement, pour le direct et la VOD, depuis le retrait de la lecture RTMP en 2014.
• Disney+, Hulu, Max, Amazon Prime Video — DASH ou HLS selon le client, souvent les mêmes segments CMAF sous les deux manifestes.

HLS possède les appareils Apple et partage le reste du marché avec DASH. La plupart des grands services supportent les deux parce que l’alternative est de laisser une partie de l’audience sur la touche.

Ce que cela signifie si vous voulez sauvegarder une vidéo

Connaître le fonctionnement de DASH rend le problème pratique du téléchargement concret. Chaque souci que rencontrent les utilisateurs HLS en essayant de sauvegarder un flux s’applique aussi à DASH, souvent en pire :

• Le Enregistrer sous du navigateur ne récupère que le .mpd. C’est le manifeste XML. Il contient zéro octet vidéo. L’ouvrir dans VLC ne fonctionne que tant que la session réseau est encore valide et que les URL des segments n’ont pas expiré.
• Les segments DASH sont des fichiers .m4s — un segment d’init plus des dizaines ou centaines de segments média par Representation. Chacun est un morceau MP4 fragmenté inutile seul. Pour obtenir un seul fichier lisible, vous devez récupérer le segment d’init plus chaque segment média dans l’ordre et les remultiplexer. (Si vous n’êtes pas au clair sur ce qu’il y a réellement dans un .m4s, voir conteneur face à codec.)
• Vous devriez analyser du XML, parcourir les URL du SegmentTemplate et remultiplexer. Cela signifie écrire du code qui comprenne les espaces réservés $Number$, $Time$, $RepresentationID$ et $Bandwidth$, assembler des URL, les récupérer en parallèle sans matraquer le CDN, et faire passer les octets à travers ffmpeg ou mp4box. Ce n’est pas un script de week-end — c’est du vrai logiciel.
• Le choix de la variante compte. Choisissez la mauvaise Representation et vous avez téléchargé une copie 480p d’un film en 1080p. Les jetons expirent aussi — de nombreuses URL .mpd et URL de segments sont signées et périment en quelques minutes.

VidMost gère tout cela. Il analyse le .mpd, choisit les Representations vidéo et audio de plus haute qualité, télécharge chaque segment en parallèle, et remultiplexe les fragments CMAF en un seul MP4 propre. Pour les flux DASH protégés par DRM (la configuration Widevine + PlayReady commune), le support Widevine L3 intégré de VidMost fonctionne partout où la lecture L3 est disponible — le plafond de qualité réel est fixé par le service et le niveau DRM, et les plateformes premium plafonnent typiquement les flux L3 à 480p–720p. Vous collez une URL ; vous obtenez un MP4.

Pièges et idées reçues fréquents

Une poignée de confusions liées à DASH apparaissent constamment dans les fils de forum. Cela vaut la peine de les clarifier.

• « MPEG-DASH est une chose de Google. » Non. DASH est un standard ouvert MPEG / ISO (ISO/IEC 23009-1), piloté par le DASH Industry Forum — un consortium incluant Adobe, Microsoft, Netflix et Qualcomm. Google a aidé à le développer et l’utilise sur YouTube, mais aucun fournisseur unique ne possède la spécification.
• « DASH est plus récent et donc meilleur. » DASH (2012) est plus récent que HLS (2009), mais « meilleur » dépend de votre mix de plateformes. Si votre audience est sur iPhone, HLS l’emporte par contrainte. Si votre audience est sur Android et téléviseurs connectés avec une flexibilité maximale de codec, DASH l’emporte. La plupart des services livrent les deux.
• « Le .mpd est la vidéo. » Non. C’est le manifeste. La vidéo réelle vit dans les segments .m4s que le manifeste référence.
• « Si un site utilise DASH, mon lecteur HLS ne peut pas le lire. » Vrai pour les lecteurs natifs. Mais la plupart des lecteurs web modernes — shaka-player, dash.js, hls.js, video.js — gèrent les deux à l’intérieur du navigateur en alimentant les segments à l’élément vidéo via les Media Source Extensions.
• « DASH signifie toujours DRM. » Non. Beaucoup de flux DASH sont livrés sans chiffrement : diffusions d’événements en direct, plateformes éducatives, et la plupart du contenu YouTube gratuit. Le DRM est une couche optionnelle déclarée via les éléments ContentProtection.

Pour conclure

DASH est le jumeau d’univers parallèle de HLS. Tous deux découpent la vidéo en courts segments, les décrivent dans un manifeste, et les livrent via du HTTP simple. Les différences — XML face à texte brut, standard ISO face à spécification Apple, agnostique en codec face à dépendant de l’historique des codecs — comptent à l’intérieur de l’industrie mais rarement pour les spectateurs. Ce qui compte, c’est que les services de streaming sous licence de contenu de tous les studios du monde se sont arrêtés sur ces deux protocoles, convergeant de plus en plus vers des segments CMAF partagés sous les deux manifestes. Une fois que vous pouvez reconnaître une requête .mpd et comprendre la hiérarchie Period / AdaptationSet / Representation, l’étrange comportement du streaming moderne cesse d’être mystérieux — c’est toujours la même boucle : récupérer le manifeste, choisir les variantes, récupérer les segments, décoder, répéter. Si vous préférez sauter complètement la couche protocolaire et simplement sauvegarder la vidéo, VidMost gère HLS, MPEG-DASH, fMP4, CMAF et les flux protégés par DRM.

Pour aller plus loin

• Comment la vidéo en ligne se lit réellement — le pipeline de streaming en vue d’ensemble de la caméra à votre écran.
• Qu’est-ce que HLS et M3U8 ? — le protocole jumeau couvert de bout en bout.
• Pourquoi la qualité vidéo change en cours de lecture — la logique ABR à l’intérieur de chaque lecteur DASH et HLS.
• Conteneurs vidéo face aux codecs — ce qu’il y a réellement dans un segment .m4s.
• Qu’est-ce que le contenu protégé par DRM ? — comment Widevine, PlayReady et FairPlay gardent les variantes chiffrées que vous ne pouvez pas simplement sauvegarder.