DASH vs HLS : avantages, inconvénients et comment choisir le bon protocole de streaming

HLS et MPEG-DASH répondent au même problème fondamental : comment diffuser de la vidéo via une infrastructure HTTP classique tout en adaptant la qualité au réseau, à l'appareil et aux conditions de lecture de l'utilisateur ?

À première vue, ces deux technologies semblent similaires. Tous deux utilisent un manifeste, divisent le contenu multimédia en petits segments, prennent en charge plusieurs débits binaires et peuvent être diffusés via des CDN standard. Mais dans le cadre des opérations de diffusion et de streaming en production, ces différences ont leur importance. Elles ont une incidence sur la couverture des appareils, les choix en matière de DRM, la latence, l’insertion publicitaire, la complexité du packaging, la surveillance, le comportement des lecteurs et le niveau de complexité opérationnelle auquel votre équipe doit faire face.

Ce guide propose une comparaison pratique entre HLS et DASH, avec suffisamment de détails techniques pour aider les ingénieurs, les chefs de produit et les équipes commerciales à prendre une décision éclairée.

En bref

Si vous avez besoin d’une règle simple : le HLS est généralement le choix par défaut le plus sûr pour une large audience grand public, tandis que le DASH est souvent mieux adapté aux workflows ouverts, basés sur des normes, prenant en charge plusieurs DRM et non centrés sur Apple. Dans de nombreux environnements OTT professionnels, la réponse n’est ni l’un ni l’autre. La solution consiste à créer un seul paquet multimédia conforme au format CMAF et à publier à la fois des manifestes HLS et DASH à partir du même ensemble de segments.

Question	Meilleur choix par défaut	Pourquoi
Avez-vous besoin d’une lecture fiable sur iPhone, iPad, Apple TV et Safari ?	HLS	HLS reste le choix par défaut de l'écosystème Apple et est profondément intégré à la lecture Apple.
Ciblez-vous Android TV, les téléviseurs connectés, les navigateurs, les décodeurs et les lecteurs personnalisés ?	DASH ou HLS	Les deux solutions sont possibles, mais la certification des lecteurs et des appareils devient rapidement le facteur déterminant.
Avez-vous besoin de workflows Widevine et PlayReady ?	DASH	DASH est généralement associé à Widevine et PlayReady dans de nombreux environnements de navigateurs, d’Android et de téléviseurs connectés.
Avez-vous besoin de FairPlay ?	HLS	La diffusion FairPlay est généralement associée au protocole HLS dans les environnements Apple.
Souhaitez-vous un ensemble de segments multimédias avec deux manifestes ?	CMAF avec HLS + DASH	Une configuration courante aujourd’hui consiste à partager des fichiers MP4 fragmentés avec des manifestes HLS et DASH distincts.
Avez-vous besoin d’une latence aussi faible que possible sur HTTP à grande échelle ?	Cela dépend	Il existe bien des versions HLS et DASH à faible latence, mais la mise en œuvre au niveau du lecteur, du CDN ou de l’appareil importe davantage que le nom du protocole.

Fonctionnement de HLS et DASH

Ces deux protocoles sont des systèmes de streaming à débit adaptatif. Le lecteur télécharge un manifeste, choisit une version, récupère de courts segments de contenu, surveille la bande passante et l’état de la mémoire tampon, puis change de version lorsque les conditions évoluent.

Avec HLS, le manifeste est une liste de lecture : une liste de lecture principale pointe vers des listes de lecture multimédia, et ces dernières pointent vers des segments. Avec DASH, le manifeste est un MPD, qui décrit les périodes, les ensembles d’adaptation, les représentations et l’adressage des segments.

Couche	Terme HLS	Terme DASH	Signification opérationnelle
Manifeste de niveau supérieur	Playlist principale	MPD	Point d’entrée que le lecteur sollicite en premier.
Groupe de pistes	Liste de lecture multimédia / groupe de rendus	Ensemble d’adaptations	Regroupements d’éléments audio, vidéo, de sous-titres ou de langues alternatives.
Variante de qualité	Flux de variante	Représentation	Combinaison spécifique de débit binaire, de résolution et de codec.
Bloc multimédia	Segment	Segment	Petit fichier ou plage d’octets récupérée pendant la lecture.
Métadonnées temporelles / événements	DATERANGE, ID3, balises CUE	EventStream, emsg	Utilisées pour la signalisation publicitaire, les métadonnées et les événements d’application.

HLS : forces et faiblesses

Le HLS, ou HTTP Live Streaming, a été créé par Apple et est défini publiquement dans la RFC 8216. Il ne s'agit pas seulement d'un protocole, mais aussi d'un véritable écosystème. Cet écosystème constitue sa plus grande force.

Avantages du HLS

• Excellent support d’Apple : si iOS, iPadOS, tvOS et Safari sont importants, le HLS est généralement incontournable.
• Large familiarité opérationnelle : les encodeurs, les outils de packaging, les CDN, les plateformes SSAI, les outils d’assurance qualité et les systèmes de surveillance prennent presque toujours en charge le HLS.
• Modèle de manifeste simple : les playlists HLS sont au format texte et relativement faciles à analyser en cas d’incident.
• Solide expérience en direct et en diffusion linéaire : HLS est largement utilisé pour les événements sportifs en direct, les chaînes linéaires, les chaînes FAST, la diffusion simultanée et la distribution OTT.
• Option HLS à faible latence : le LL-HLS peut réduire la latence « glass-to-glass » lorsque le lecteur, la source et le CDN le prennent correctement en charge.
• Maturité de l’insertion publicitaire : les workflows SCTE-35 sont généralement mis en œuvre via des techniques de cueing HLS telles que DATERANGE ou les balises de marqueurs publicitaires.

Inconvénients du HLS

• L’influence d’Apple façonne la feuille de route : c’est souvent un avantage, mais cela signifie également que certaines décisions sont dictées par l’écosystème plutôt que par les normes à proprement parler.
• Fragmentation des DRM : le HLS avec FairPlay s’impose naturellement sur les appareils Apple, mais les workflows Widevine et PlayReady peuvent vous orienter vers le DASH ou le double encapsulation.
• Le comportement des navigateurs varie : Safari lit le HLS en natif, tandis que de nombreux autres navigateurs de bureau s’appuient sur des lecteurs JavaScript tels que hls.js.
• Le HLS traditionnel peut s’avérer inefficace : les anciens workflows HLS basés sur le MPEG-TS peuvent entraîner une duplication des efforts de stockage et d’encapsulation si le format DASH est également requis.
• La latence n’est pas automatiquement faible : un HLS standard avec des segments longs peut encore présenter un décalage de plusieurs dizaines de secondes par rapport au direct, à moins que le flux de travail ne soit conçu pour une faible latence.

DASH : forces et faiblesses

MPEG-DASH est un protocole de streaming adaptatif basé sur des normes internationales. Il est indépendant du codec, riche en manifestes et largement utilisé dans les écosystèmes des navigateurs, d’Android, des téléviseurs connectés et des décodeurs. C’est également la solution la plus courante pour les flux protégés par Widevine et PlayReady.

Avantages de DASH

• Conception fondée sur des normes : DASH est développé par le biais des normes MPEG/ISO et bénéficie du travail d’interopérabilité de l’association DASH-IF.
• Modèle de manifeste flexible : les MPD peuvent décrire des présentations complexes comprenant des périodes, des ensembles d’adaptation, des pistes audio multilingues, des sous-titres, des angles de caméra alternatifs et des événements.
• Forte compatibilité avec les DRM : DASH est couramment associé à Common Encryption, Widevine et PlayReady.
• Bien adapté aux lecteurs Web et aux téléviseurs connectés : de nombreux lecteurs HTML5 utilisent les Media Source Extensions pour prendre en charge la lecture DASH dans les navigateurs.
• Compatible avec le format CMAF : DASH fonctionne bien avec le conditionnement fragmenté MP4/CMAF, qui peut également prendre en charge le protocole HLS à partir des mêmes segments multimédias.
• Option DASH à faible latence : le transfert par blocs, des segments plus courts et la prise en charge par les lecteurs permettent de répondre aux cas d’utilisation nécessitant une faible latence.

Inconvénients de DASH

• Pas de lecture native universelle sur les appareils Apple : si votre service doit fonctionner parfaitement sur iPhone et Apple TV sans la complexité d’un lecteur personnalisé, DASH seul ne suffit généralement pas.
• Complexité des manifestes : les MPD sont puissants, mais peuvent être plus difficiles à déboguer lors d’un incident en direct que les playlists HLS.
• L'importance de la certification des appareils : certains téléviseurs connectés et décodeurs interprètent les profils DASH différemment, ce qui rend les tests indispensables.
• Dépendance vis-à-vis du lecteur : DASH nécessite souvent une couche de lecture JavaScript ou un SDK natif plutôt que de s’appuyer sur un simple élément vidéo natif.
• Les outils opérationnels varient : la surveillance DASH, la signalisation publicitaire et la manipulation des manifestes sont performantes dans les piles matures, mais moins universelles que les outils HLS de base.

Comparaison visuelle : les points forts de chaque protocole

Catégorie	HLS	DASH	Conclusion pratique
Appareils Apple	Excellent	Limité sans solutions de contournement pour les lecteurs	Utilisez HLS pour atteindre les utilisateurs Apple.
Android / Chrome / lecteurs Web	Bon avec la prise en charge des lecteurs	Très performant avec les lecteurs MSE	Les deux peuvent fonctionner ; testez votre lecteur cible.
Téléviseurs connectés	Bon, mais variable selon la plateforme	Bon, mais dépend du profil	La certification l'emporte sur la théorie.
DRM	FairPlay est une évidence ; les autres DRM varient	Widevine et PlayReady sont courants	La prise en charge de plusieurs DRM implique souvent l'utilisation de deux manifestes.
Insertion de publicités	Très abouti dans les flux de travail en direct/linéaires	Très performante, notamment avec EventStream/emsg	Les deux fonctionnent ; les attentes en matière de SSAI en aval sont importantes.
Lisibilité des manifestes	Listes de lecture au format texte simple	MPD XML plus riches	Le HLS est souvent plus simple à utiliser dans une salle de contrôle.
Faible latence	LL-HLS	LL-DASH	La qualité de la mise en œuvre prime sur l’image de marque.
Stockage multimédia unique	Compatible avec CMAF HLS	Compatible avec CMAF DASH	Le format CMAF permet de réduire les doublons.

Couverture des appareils : la différence commerciale la plus importante

Le premier critère à prendre en compte n’est pas la pureté technique, mais l’endroit où se trouvent vos spectateurs. Si vous avez besoin d’une couverture sur les appareils Apple, le protocole HLS est généralement incontournable. Si vous développez un service destiné aux navigateurs, à Android TV, aux décodeurs, aux consoles de jeux ou aux téléviseurs connectés, le protocole DASH peut s’avérer tout aussi intéressant, voire plus.

Le piège consiste à supposer que la prise en charge mentionnée dans une fiche technique signifie une prise en charge effective en production. Les téléviseurs connectés, en particulier, peuvent se révéler impitoyables. Deux appareils peuvent prétendre prendre en charge DASH tout en divergeant sur la synchronisation, les combinaisons de codecs, la gestion des sous-titres, la configuration DRM ou le comportement en direct.

Latence : HLS vs DASH n’est pas la bonne question à se poser en premier lieu

Les équipes demandent souvent quel protocole présente la latence la plus faible. La bonne question est plutôt : quelle implémentation de bout en bout permet de maintenir une latence faible sans augmenter le rebuffering, la fragilité opérationnelle ou le coût du CDN ?

La latence est influencée par la taille du GOP de l’encodeur, la durée des segments, la prise en charge des segments partiels, le comportement de l’origine, les règles de mise en cache du CDN, la politique de mise en mémoire tampon du lecteur, la cadence de rafraîchissement de la playlist/du MPD et les performances de l’appareil. HLS et DASH disposent tous deux de modes à faible latence, mais aucun n’est une solution miracle.

Facteur de latence	Impact	Risque opérationnel
Segments plus courts	Peuvent réduire la latence	Augmentation du nombre de requêtes, pression accrue sur le CDN et le serveur d'origine.
Segments partiels / blocs	Peuvent réduire le délai de diffusion en direct	Nécessitent un encodeur, une source, un CDN et un lecteur compatibles.
Tampon du lecteur plus petit	Peut réduire la latence « glass-to-glass »	Plus sensible à la gigue et à la perte de paquets.
Suivi du début de la diffusion en direct	Permet de maintenir la lecture au plus près du direct	Peut entraîner une instabilité de la lecture si le réglage est trop agressif.
Comportement du cache CDN	Contrôle la disponibilité du manifeste et des parties	Des en-têtes de cache incorrects peuvent compromettre la conception à faible latence.

DRM : un domaine où DASH présente souvent un avantage

Pour les services de VOD premium et par abonnement, la gestion des droits numériques (DRM) est souvent le facteur décisif. DASH est largement utilisé avec Common Encryption, Widevine et PlayReady. HLS est le choix naturel pour FairPlay sur les appareils Apple.

Dans la pratique, de nombreux services premium proposent du contenu adapté aux deux écosystèmes. Les fichiers multimédias peuvent être conformes au format CMAF, mais les manifestes, la signalisation DRM et les processus d’acquisition de licence diffèrent selon les plateformes.

Publicité et SCTE-35

HLS et DASH peuvent tous deux transporter des signaux publicitaires. Dans HLS, les repères SCTE-35 sont souvent représentés par des balises DATERANGE ou cue dans la liste de lecture. Dans DASH, les événements chronométrés peuvent être transportés via EventStream dans le MPD ou via des champs emsg dans les segments multimédias.

L’important n’est pas seulement de savoir si le protocole peut exprimer le marqueur. L’important est de savoir si votre plateforme d’insertion publicitaire, votre distributeur en aval, votre outil de surveillance et votre lecteur interprètent tous le marqueur de la même manière.

Flux de travail	Approche HLS	Approche DASH
Marqueur de pause publicitaire SSAI	DATERANGE, balises de repère, SCTE-35 mappés dans les métadonnées de la playlist	EventStream ou emsg transportant des données d'événements chronométrés
Insertion publicitaire côté client	Le lecteur lit les balises du manifeste ou les métadonnées	Le lecteur lit les événements MPD ou les messages emsg intégrés
Surveillance	Vérification de la continuité de la liste de lecture et des segments multimédias	Vérification des périodes/événements MPD et de la synchronisation des segments
Problèmes courants	Les marqueurs apparaissent en retard, durée manquante, problèmes de discontinuité	Problèmes liés aux limites de période, à la synchronisation des événements et à l’interprétation du lecteur

Le CMAF a changé la donne

Auparavant, les équipes devaient souvent créer des paquets HLS et DASH distincts, avec parfois des médias en double. Le CMAF a considérablement simplifié l’utilisation de segments MP4 fragmentés comme base multimédia commune pour HLS et DASH.

Cela ne signifie pas pour autant que HLS et DASH deviennent identiques. La logique des manifestes, la signalisation DRM et le comportement des lecteurs diffèrent toujours. Mais cela signifie que le modèle opérationnel peut être simplifié :

Coût total de possession : où va réellement l’argent

Il n’existe pas de règle universelle selon laquelle HLS serait moins cher que DASH, ou inversement. Le protocole en lui-même ne constitue généralement pas un poste de facturation. La différence de coût provient de l’écosystème qui l’entoure : appareils, packaging, SSAI, DRM, surveillance, assurance qualité des lecteurs et support opérationnel.

Dans la pratique, le coût total de possession le plus bas résulte généralement de la réduction au minimum des flux de travail redondants. Un workflow unique exclusivement HLS peut s’avérer rentable si votre audience et vos partenaires l’acceptent. Un workflow unique exclusivement DASH peut être efficace dans des environnements Android, de navigateur ou d’opérateur contrôlés. Mais pour l’OTT grand public, l’architecture gagnante est souvent un workflow basé sur CMAF qui publie à la fois HLS et DASH à partir d’une base multimédia partagée.

Domaine de coût	Impact du HLS	Impact du DASH	Recommandations sur le coût total de possession
Encodage	En général, aucune différence majeure si la même échelle de codecs est utilisée.	En général, il n'y a pas de différence majeure si la même chaîne de codecs est utilisée.	Ce qui coûte cher, ce sont les échelles en double, pas le type de manifeste. Alignez les codecs, les GOP et les rendus dans la mesure du possible.
Conditionnement	Coût faible pour le HLS seul ; plus élevé si vous avez également besoin du DASH et que vous générez des sorties multimédias distinctes.	Coût faible pour le DASH seul ; plus élevé si vous avez également besoin du HLS et que vous générez des sorties multimédias distinctes.	Le format CMAF permet de réduire le stockage et les doublons au niveau du packaging en partageant les segments multimédias entre les deux manifestes.
Stockage	Le format HLS MPEG-TS traditionnel associé à un fMP4 DASH distinct peut entraîner une duplication du stockage multimédia.	Le format fMP4 DASH est efficace, mais entraîne tout de même une duplication des coûts si le HLS utilise des segments TS distincts.	Utilisez des fichiers MP4 fragmentés/CMAF lorsque la prise en charge par les appareils le permet.
Requêtes CDN	Le HLS à faible latence peut augmenter le volume de requêtes en raison des segments partiels et des mises à jour fréquentes des listes de lecture.	Le DASH à faible latence peut également augmenter le volume de requêtes en raison de la diffusion par morceaux et des accès fréquents aux MPD/segments.	Le choix de la faible latence relève souvent autant d’une décision liée au CDN et au coût des requêtes que d’un choix de protocole.
SSAI	Technologie très aboutie pour les flux de travail en direct et linéaires ; de nombreux fournisseurs disposent d’outils performants privilégiant le protocole HLS.	Peut nécessiter une validation plus minutieuse d’EventStream/emsg en fonction du fournisseur SSAI et du parc d’appareils.	Les coûts augmentent lorsque les marqueurs publicitaires doivent être transformés et testés différemment pour chaque plateforme en aval.
DRM	FairPlay s’impose naturellement ; la gestion de plusieurs systèmes DRM au-delà d’Apple peut compliquer le packaging et le flux de licences.	Widevine et PlayReady sont courants ; la prise en charge d’Apple nécessite généralement toujours HLS/FairPlay.	Les services premium supportent souvent le coût lié à la complexité du multi-DRM ainsi qu’à l’utilisation de deux manifestes.
Développement du lecteur	Natif sur Apple, mais nécessite souvent la prise en charge d’un lecteur JavaScript ailleurs.	Nécessite souvent la prise en charge du SDK/MSE du lecteur, en particulier sur le Web et les téléviseurs connectés.	Le protocole le moins coûteux est celui que vos appareils cibles prennent en charge de manière fiable avec le moins de code personnalisé possible.
Assurance qualité et certification	La compatibilité avec Apple est excellente, mais le protocole HLS non-Apple nécessite encore des tests approfondis.	Les profils DASH et les implémentations sur les appareils peuvent varier considérablement.	La certification des téléviseurs connectés et des décodeurs peut peser lourdement sur le coût total de possession (TCO) du protocole.
Surveillance et exploitation	Les listes de lecture sont plus faciles à inspecter manuellement par les ingénieurs.	Les MPD sont plus riches, mais plus complexes à déboguer en cas d’incident.	La formation, les outils et le temps de réponse aux incidents représentent des coûts réels.

Quand le HLS peut s’avérer plus économique

• Public principalement Apple : si la plupart des visionnages ont lieu sur iOS, Safari et Apple TV, le HLS réduit la complexité liée au lecteur et à la prise en charge.
• Distribution simple de contenu FAST ou de chaînes en direct : de nombreux partenaires en aval, plateformes SSAI et outils de surveillance maîtrisent déjà les workflows HLS en direct.
• Complexité DRM limitée : si FairPlay ou une diffusion non chiffrée financée par la publicité répond aux besoins, le HLS permet de conserver un flux de travail relativement simple.
• Équipe opérationnelle réduite : les manifestes HLS sont plus faciles à inspecter rapidement, ce qui peut réduire le temps de dépannage.

Quand DASH peut s’avérer plus économique

• Parc d’appareils non Apple maîtrisé : Android TV, décodeurs d’opérateurs, lecteurs Web ou applications pour téléviseurs connectés peuvent déjà privilégier DASH.
• Exigences Widevine / PlayReady : DASH peut simplifier la conception de la gestion des droits numériques (DRM) lorsque les appareils Apple ne constituent pas la cible principale.
• Intégrations de plateformes basées sur les normes : certains partenaires de distribution et certains appareils privilégient les profils DASH et la signalisation d’événements basée sur MPD.
• Flux de travail centrés sur le CMAF : DASH s’associe naturellement aux médias MP4 fragmentés, en particulier lorsque le protocole HLS peut utiliser les mêmes segments CMAF.

Où les coûts doublent souvent

Le modèle de coût total de possession (TCO) dangereux n’est ni HLS ni DASH. Il s’agit de deux piles de diffusion totalement distinctes : deux ensembles de rendus encodés, deux formats de segments, deux transformations de marqueurs publicitaires, deux configurations DRM, deux pipelines de surveillance et deux matrices d’assurance qualité.

Cette duplication se traduit par des coûts de calcul, de stockage, de requêtes CDN, de temps d’ingénierie et de risques opérationnels. Si vous avez besoin des deux protocoles, concevez le flux de travail de manière à partager autant d’éléments de la chaîne que possible.

Architecture	Profil probable du TCO	Pourquoi
HLS uniquement	Le plus bas pour les services à forte présence Apple ou les services simples à large audience	Un seul protocole, des outils éprouvés, moins de scénarios de lecture à certifier.
DASH uniquement	Le plus économique pour les environnements contrôlés non Apple ou ceux des opérateurs	Bonne compatibilité DRM et moins d’exigences spécifiques à Apple.
HLS séparé + DASH séparé	Coût le plus élevé	Duplication des workflows de packaging, de stockage, de surveillance, de test et de gestion des incidents.
Fichiers multimédias CMAF + manifestes HLS et DASH	Souvent la meilleure solution pour une diffusion OTT à grande échelle	Couverture plus large des appareils grâce à des segments partagés et à une réduction des doublons.

Avantages et inconvénients opérationnels

Le meilleur protocole sur le papier peut tout de même s’avérer être un mauvais choix opérationnel. Les équipes de diffusion doivent réfléchir à la surveillance, au débogage, aux exigences des partenaires de distribution et à la manière dont les incidents seront gérés à 2 heures du matin.

Avantages opérationnels du HLS

• Inspection simple des playlists à l’aide d’outils de traitement de texte courants.
• Prise en charge étendue des CDN et de la surveillance.
• Parfaitement adapté aux workflows linéaires en direct et FAST.
• Compatibilité native avec les appareils Apple et FairPlay.

Inconvénients opérationnels du format HLS

• Peut nécessiter un encapsulage supplémentaire pour les DRM non Apple et certains workflows de télévision connectée.
• Les différents lecteurs peuvent gérer différemment les discontinuités, les métadonnées et le comportement des flux en direct.
• Le format HLS MPEG-TS hérité peut compliquer l'efficacité du double protocole.

Avantages opérationnels du format DASH

• Modèle de manifeste riche pour les services complexes.
• Alignement solide sur plusieurs DRM en dehors des écosystèmes Apple.
• Bien adapté aux SDK de lecteurs basés sur des normes et aux plateformes de télévision connectée.
• Fonctionne naturellement avec le CMAF et les architectures modernes à faible latence.

Inconvénients opérationnels de DASH

• Débogage MPD plus complexe.
• Moins utile en tant que solution à protocole unique si les appareils Apple sont importants.
• Les différences d’implémentation entre les appareils peuvent poser problème en l’absence d’une matrice de certification.

Architecture recommandée pour la plupart des diffuseurs

Pour la plupart des diffuseurs, des éditeurs FAST et des services OTT premium, l’approche la plus robuste consiste à :

1. De regrouper les contenus multimédias au format CMAF dans la mesure du possible. De veiller à un alignement précis des segments et de réduire le stockage redondant.
2. Publier du HLS pour Apple et une compatibilité étendue. Le considérer comme la couche de diffusion universelle.
3. Publier du contenu au format DASH lorsque les exigences de la plateforme, de la gestion des droits numériques (DRM) ou de l’appareil l’imposent. En particulier pour les écosystèmes Widevine, PlayReady et de télévision connectée.
4. Effectuer des tests de validation sur de véritables appareils, et pas uniquement sur des lecteurs installés sur des ordinateurs portables. Les téléviseurs connectés, les décodeurs et les navigateurs mobiles mettent en évidence les problèmes que les fiches techniques ne révèlent pas.
5. Surveillez à la fois les manifestes et les segments multimédias. Une liste de lecture HLS en bon état ne garantit pas que le MPD DASH soit en bon état, et inversement.

Liste de contrôle pratique avant de faire votre choix

Domaine	Questions à se poser
Appareils utilisés par le public	Quel pourcentage du visionnage a lieu sur des appareils Apple, Android, sur le Web, sur des téléviseurs connectés et sur des décodeurs ?
DRM	Avez-vous besoin de FairPlay, Widevine, PlayReady ou des trois à la fois ?
Insertion publicitaire	Votre plateforme SSAI prend-elle en charge les balises HLS, les événements DASH, ou les deux ?
Latence	Quel est l’objectif réel de latence « de l’écran à l’écran », et votre pile CDN/lecteur est-elle capable de le prendre en charge ?
Opérations	Votre équipe est-elle en mesure d’inspecter, de signaler et de résoudre les problèmes liés aux deux types de manifestes ?
Spécifications des partenaires	Les distributeurs exigent-ils un protocole, une durée de segment, un codec, un système DRM ou un format de marqueur SCTE spécifiques ?
Stockage et encapsulation	Pouvez-vous utiliser le format CMAF pour éviter la duplication des fichiers multimédias pour HLS et DASH ?

Recommandation finale

Ne choisissez pas HLS ou DASH simplement parce que l’un vous semble plus moderne. Faites votre choix en fonction de votre parc d’appareils, de vos exigences en matière de DRM, de votre objectif de latence, de votre workflow d’insertion publicitaire et de vos capacités opérationnelles.

Pour les services de diffusion et OTT destinés au grand public, le HLS est généralement indispensable. Pour les DRM non Apple, les lecteurs web basés sur des normes et de nombreux workflows de télévision connectée, le DASH est souvent tout aussi important. La solution moderne la plus aboutie consiste souvent à utiliser les deux protocoles, sur une base multimédia conforme au CMAF.

Cela vous offre la portée pratique du HLS, la flexibilité normalisée du DASH et un modèle de packaging que votre équipe opérationnelle est réellement en mesure de gérer.

Références

• RFC 8216 : HTTP Live Streaming
• Spécification de création HLS d’Apple pour les appareils Apple
• Directives DASH-IF
• Extensions Media Source du W3C