MPEG-DASH explicado y cómo se compara con HLS

Si has abierto las DevTools de Chrome en Netflix o YouTube y has visto peticiones de archivos terminados en .mpd y .m4s, has visto MPEG-DASH en acción. El archivo XML es un manifiesto, los archivos .m4s son segmentos cortos de MP4 fragmentado de vídeo y audio, y tu navegador los está cosiendo en tiempo real sobre HTTP plano.

DASH es el primo de estándar abierto de HLS. Donde Apple es dueña de HLS, el organismo de estándares MPEG/ISO es dueño de DASH. Donde HLS usa playlists de texto .m3u8, DASH usa manifiestos XML .mpd. Donde HLS insistía originalmente en H.264, DASH nunca tuvo preferencia de códec. Los dos protocolos resuelven el mismo problema desde puntos de partida diferentes, y un servicio de streaming sensato en 2026 envía ambos. MPEG-DASH —Dynamic Adaptive Streaming over HTTP— es el estándar ISO/IEC 23009-1 para entregar vídeo como una cadena de segmentos fMP4 cortos descritos por un manifiesto XML (.mpd) y descargados sobre HTTP ordinario.

Esta guía recorre lo que un .mpd contiene realmente, cómo funciona la jerarquía Period / AdaptationSet / Representation de DASH, dónde encaja el DRM, los argumentos a favor y en contra de DASH frente a HLS, y qué pasa cuando intentas guardar uno de estos flujos en disco.

Puntos clave {#key-takeaways}

• MPEG-DASH es el estándar abierto ISO para streaming HTTP adaptativo — ISO/IEC 23009-1. HLS es RFC 8216.
• El manifiesto .mpd es XML, no texto plano. Describe Periods, AdaptationSets y Representations —una jerarquía estricta que el reproductor recorre al inicio y en cada cambio de calidad.
• DASH es agnóstico de códec por diseño. H.264, H.265, VP9, AV1, AAC, Opus —el manifiesto declara las cadenas de códec y el reproductor decodifica.
• Los segmentos de medios son MP4 fragmentado (.m4s), los mismos fragmentos CMAF usados por el HLS moderno. Un único conjunto de bytes puede servir a ambos protocolos.
• El DRM usa MPEG Common Encryption (CENC) para que un único archivo cifrado funcione con Widevine, PlayReady o FairPlay según el módulo de descifrado del cliente.
• Las plataformas Apple no soportan DASH de forma nativa. iPhone, iPad, Safari y Apple TV requieren HLS —solo DASH es inviable.
• Netflix, YouTube, Disney+, Hulu y Max envían DASH y HLS uno junto al otro; Apple TV+, iTunes y Twitch envían solo HLS.

La explicación sencilla

Olvídate de las siglas por un momento. Un servicio de streaming tiene el mismo problema en cualquier caso: enviar un vídeo largo a espectadores con conexiones desordenadas, permitirles buscar al instante, permitirles adaptarse a cambios de ancho de banda a mitad de reproducción, y hacerlo barato sobre HTTP de uso común. La solución generalizada en la industria es cortar el vídeo en segmentos cortos, escribir un manifiesto que los liste y dejar que el reproductor descargue lo que necesite en orden. HLS hace esto con playlists de texto; DASH lo hace con manifiestos XML. El trabajo es el mismo; el papeleo es diferente.

Desde la perspectiva de un reproductor, el enfoque DASH se siente casi idéntico a HLS. El reproductor descarga un pequeño manifiesto al inicio, aprende qué calidades y pistas de audio están disponibles, elige una de cada según ancho de banda y viewport, y luego descarga un flujo de segmentos cortos y los entrega al decodificador. Los cambios de calidad ocurren entre segmentos. Los flujos en directo funcionan haciendo que el manifiesto crezca con el tiempo. La búsqueda es instantánea porque el reproductor salta a cualquier segmento que cubra la marca de tiempo objetivo.

La diferencia visible para el usuario entre los dos protocolos es pequeña pero real. Los playlists HLS son texto plano; los manifiestos DASH son XML. Los segmentos HLS fueron históricamente .ts (MPEG-2 Transport Stream) y ahora suelen ser fMP4; los segmentos DASH siempre han sido fMP4, con la extensión .m4s. Las organizaciones promotoras también son diferentes: Apple inventó y administra HLS, mientras que DASH salió de MPEG y del DASH Industry Forum como estándar ISO abierto sin un único proveedor al mando. Para la introducción equivalente, HLS en detalle cubre el aspecto de un playlist .m3u8 de principio a fin.

Cómo funciona DASH realmente

Un flujo DASH es un manifiesto XML más una pila de segmentos MP4 fragmentado, todo servido sobre HTTP ordinario. Misma forma que HLS, formato distinto en cada capa.

El manifiesto .mpd

Lo primero que descarga un reproductor DASH es la Media Presentation Description —el .mpd. A diferencia del playlist en texto plano de HLS, este es un documento XML con un esquema definido. Aquí tienes un ejemplo ligeramente recortado:

<?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>

Cada atributo significa algo concreto. type="static" marca esto como VOD (un flujo en directo es type="dynamic"). mediaPresentationDuration="PT1H30M" es una duración ISO 8601. Cada Representation lleva una cadena de códec y un presupuesto de ancho de banda. El SegmentTemplate es donde ocurre la magia: en lugar de listar cada URL de segmento como hace HLS, DASH deja que el manifiesto declare un patrón de URL y el reproductor calcula las URL al vuelo.

Periods, AdaptationSets y Representations

La jerarquía estricta dentro del manifiesto es el corazón conceptual de DASH:

• Period — una porción contigua de la línea de tiempo. La mayoría de las películas son un único Period; las cadenas usan múltiples Periods para empalmar anuncios o límites de capítulo.
• AdaptationSet — una colección de codificaciones alternativas del mismo contenido, intercambiables en tiempo de ejecución. Una película típica tiene un AdaptationSet de vídeo, uno o más AdaptationSets de audio (uno por idioma) y uno o más AdaptationSets de subtítulos.
• Representation — una única codificación concreta. 1080p H.264 a 5 Mbps es una Representation; 720p H.264 a 2,8 Mbps es otra; 720p VP9 a 1,5 Mbps es otra. El reproductor elige una Representation por AdaptationSet y puede intercambiarla por una diferente en cualquier límite de segmento dentro del mismo AdaptationSet.

Este modelo de tres niveles es más estructurado que el enfoque plano de variantes-y-segmentos de HLS, por lo que DASH gana en extensibilidad: múltiples pistas de audio, pistas de trick-play, pistas de miniaturas e inserción de anuncios por Period encajan limpiamente sin inventar nueva sintaxis de manifiesto.

Segmentos e inicialización

Los bytes de una Representation vienen en dos sabores. El segmento de inicialización es un pequeño archivo fMP4 que contiene la caja moov —parámetros de códec, metadatos de pista y configuración del decodificador. El reproductor lo descarga una vez por Representation. Los segmentos de medios son el audio y vídeo reales, normalmente de 2 a 6 segundos cada uno, cortados en límites de fotograma clave para las pistas de vídeo, de modo que el reproductor pueda empezar a decodificar desde el inicio de cualquier segmento.

Cuando el manifiesto establece startWithSAP="1", cada segmento comienza con un Stream Access Point —el equivalente DASH de la marca EXT-X-INDEPENDENT-SEGMENTS de HLS, garantizando que los segmentos son decodificables de forma independiente. Sin esa garantía, los segmentos posteriores pueden depender de los anteriores, lo que hace inseguro el cambio adaptativo. Como las URL del SegmentTemplate están guiadas por patrones (v1/seg-$Number$.m4s), el manifiesto puede describir una película de 90 minutos en unos pocos cientos de bytes de XML. SegmentTimeline es la alternativa cuando las duraciones no son uniformes.

Common Encryption (CENC)

La historia de DRM en DASH pasa por MPEG Common Encryption (CENC), ISO/IEC 23001-7. CENC cifra los propios segmentos de medios con AES-128 en modo CTR bajo una clave de contenido, y luego declara qué sistemas DRM pueden emitir esa clave. En el .mpd, verás elementos ContentProtection como este:

<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>

El primer bloque declara el ID de clave por defecto bajo CENC. El segundo es el UUID de Widevine; el tercero es el de PlayReady. El Content Decryption Module de tu navegador lee el bloque que coincida con su DRM soportado, envía una petición de licencia al servidor de licencias del servicio con los datos PSSH (Protection System Specific Header) embebidos, y recibe la clave de contenido necesaria para descifrar los segmentos. Para el panorama completo, consulta cómo Widevine y PlayReady controlan los flujos premium. El soporte de FairPlay en DASH es históricamente poco común —FairPlay se diseñó para HLS— pero CMAF + el cifrado CBCS han hecho técnicamente posible FairPlay sobre DASH multi-DRM en un pequeño conjunto de plataformas.

Agnóstico de códec por diseño

HLS originalmente privilegiaba H.264 (los primeros dispositivos Apple no podían decodificar nada más), y añadir códecs nuevos requería un proceso de especificación de varios años. DASH nunca eligió un códec —el manifiesto simplemente declara cadenas de códec (avc1.640028, hev1.1.6.L150.B0, vp09.00.50.08, av01.0.05M.08) y el reproductor comprueba si su decodificador los soporta. Por eso YouTube pudo enviar AV1 sobre DASH años antes de que llegara el soporte equivalente en HLS en Apple. Como la capa de manifiesto es lo único que los reproductores DASH necesitan entender, VidMost puede analizar un .mpd, recorrer las URL del SegmentTemplate, descargar cada fragmento fMP4 y remultiplexar el resultado sin importar qué códec haya dentro.

DASH frente a HLS: la comparación honesta

DASH y HLS resuelven el mismo problema con distintos compromisos. Ninguno es universalmente mejor. Aquí tienes el argumento para cada uno a lo largo de los ejes que realmente importan.

Formato del manifiesto

El .mpd de DASH es XML con un esquema definido —extensible (las nuevas características obtienen nuevos elementos, validados por esquema, los reproductores antiguos ignoran lo que no entienden) pero verboso. El .m3u8 de HLS es texto plano con etiquetas #EXT-X-, legible de un vistazo y fácil de greppear. DASH gana en estructura y validación automática; HLS gana en legibilidad humana.

Latencia

Ambos empezaron con latencia de segundos a decenas de segundos. Ambos han lanzado extensiones de baja latencia: LL-HLS usa segmentos parciales, recargas de playlist bloqueantes y preload hints (Apple reemplazó su diseño anterior basado en HTTP/2 push por EXT-X-PRELOAD-HINT), mientras que LL-DASH usa segmentos con codificación de transferencia por trozos y el perfil Common Media Application Format Live. Ambos apuntan a una latencia glass-to-glass de 2–5 segundos en producción. Para latencia por debajo del segundo, bajas a WebRTC.

Soporte de códecs

DASH ha sido agnóstico de códec desde el primer día. H.264, H.265, VP9, AV1, AAC, Opus, FLAC, AC-4 —el manifiesto declara la cadena de códec y el reproductor decide. HLS empezó solo con H.264 porque el hardware del iPhone original así lo exigía. Apple ha ampliado el soporte de forma constante: H.265 sobre fMP4 desde 2017, Dolby Vision y HDR10 desde 2018, AV1 desde la generación del iPhone 15. El HLS moderno no está bloqueado en H.264, pero la historia de códecs del protocolo tiene un retraso que DASH nunca tuvo.

DRM

Ambos se apoyan en el cifrado a nivel de segmento basado en AES, pero los sistemas DRM superpuestos difieren. DASH suele usar CENC con Widevine y PlayReady —un único archivo cifrado funciona con ambos porque la clave de contenido es la misma; solo difiere el formato de la petición de licencia. HLS históricamente usa FairPlay Streaming (solo Apple) más, cada vez más, Widevine mediante CMAF + CBCS. Una vez que tu servicio está en CMAF, los mismos segmentos cifrados pueden servir a ambos tipos de manifiesto y a los tres grandes sistemas DRM.

Soporte de Apple/iOS

HLS es obligatorio en iOS, iPadOS, Safari y Apple TV. DASH no está soportado de forma nativa en ninguna plataforma Apple. Este es el factor decisivo más grande en la estrategia de DASH frente a HLS. La reproducción DASH en Safari solo es posible mediante Media Source Extensions más un shim JavaScript como shaka-player o dash.js, e incluso entonces no cubre cada caso límite de iOS (AirPlay, controles de la pantalla de bloqueo, picture-in-picture). Cualquier servicio dirigido a iPhones debe enviar HLS. Solo DASH es inviable.

Compatibilidad de CDN y la convergencia CMAF

Ambos protocolos son HTTP puro. Cualquier CDN que sirva archivos estáticos puede servir un flujo DASH o HLS —el coste y la configuración de la CDN son esencialmente idénticos. El desarrollo más importante de la última década es que DASH y HLS ahora comparten bytes de segmento. CMAF —el Common Media Application Format, ISO/IEC 23000-19— define un perfil de MP4 fragmentado que satisface tanto a DASH como al HLS moderno. Un servicio de streaming puede codificar una vez en segmentos CMAF y escribir tanto un .mpd como un .m3u8 que apunten exactamente a los mismos archivos .m4s. Esto es lo que realmente está ocurriendo en YouTube, Netflix, Apple y la mayoría de los proveedores de vídeo alojado en 2026.

Quién envía qué en 2026

• Netflix — DASH principal en web, Windows, Android, televisores inteligentes y consolas; HLS como respaldo para Safari e iOS.
• YouTube — DASH en web y Android con VP9 / AV1; HLS para iOS, Safari, AirPlay y la mayoría de aplicaciones de TV.
• Apple TV+, iTunes Store — solo HLS.
• Twitch — solo HLS, para directo y VOD, desde la retirada de la reproducción RTMP en 2014.
• Disney+, Hulu, Max, Amazon Prime Video — DASH o HLS según el cliente, a menudo los mismos segmentos CMAF bajo ambos manifiestos.

HLS es dueño de los dispositivos Apple y comparte el resto del mercado con DASH. La mayoría de los grandes servicios soportan ambos porque la alternativa es dejar una audiencia fuera.

Qué significa esto si quieres guardar un vídeo

Saber cómo funciona DASH hace concreto el problema práctico de la descarga. Cada problema que sufren los usuarios de HLS al intentar guardar un flujo se aplica también a DASH, a menudo peor:

• El “Guardar como” del navegador solo obtiene el .mpd. Ese es el manifiesto XML. No contiene ningún byte de vídeo. Abrirlo en VLC solo funciona mientras la sesión de red siga siendo válida y las URL de los segmentos no hayan expirado.
• Los segmentos DASH son archivos .m4s —un segmento de inicialización más decenas o cientos de segmentos de medios por Representation. Cada uno es un fragmento de MP4 fragmentado inútil por sí solo. Para obtener un único archivo reproducible tienes que descargar el segmento de inicialización más cada segmento de medios en orden y remultiplexarlos. (Si tienes dudas sobre lo que hay realmente dentro de un .m4s, consulta contenedor frente a códec.)
• Tendrías que analizar XML, recorrer las URL del SegmentTemplate y remultiplexar. Eso significa escribir código que entienda los marcadores $Number$, $Time$, $RepresentationID$ y $Bandwidth$, ensamblar URL, descargarlas en paralelo sin martillear la CDN y pasar los bytes por ffmpeg o mp4box. No es un script de fin de semana —es software real.
• La selección de variante importa. Elige la Representation equivocada y habrás descargado una copia a 480p de una película de 1080p. Los tokens también expiran —muchas URL de .mpd y de segmentos están firmadas y caducan en minutos.

VidMost gestiona todo esto. Analiza el .mpd, elige las Representations de vídeo y audio de mayor calidad, descarga cada segmento en paralelo y remultiplexa los fragmentos CMAF en un único MP4 limpio. Para flujos DASH protegidos por DRM (la configuración común de Widevine + PlayReady), el soporte integrado de Widevine L3 de VidMost funciona allí donde la reproducción L3 está disponible —el techo real de calidad lo fija el servicio y el nivel de DRM, y las plataformas premium suelen limitar los flujos L3 a 480p–720p. Pegas una URL; obtienes un MP4.

Errores y conceptos equivocados habituales

Un puñado de confusiones relacionadas con DASH aparece constantemente en hilos de foros. Vale la pena aclararlas.

• “MPEG-DASH es cosa de Google.” No lo es. DASH es un estándar abierto MPEG / ISO (ISO/IEC 23009-1), impulsado por el DASH Industry Forum —un consorcio que incluye a Adobe, Microsoft, Netflix y Qualcomm. Google ayudó a desarrollarlo y lo usa en YouTube, pero ningún proveedor es dueño de la especificación.
• “DASH es más nuevo y por tanto mejor.” DASH (2012) es más nuevo que HLS (2009), pero “mejor” depende de tu mezcla de plataformas. Si tu audiencia está en iPhone, HLS gana a la fuerza. Si tu audiencia está en Android y televisores inteligentes con máxima flexibilidad de códec, gana DASH. La mayoría de los servicios envían ambos.
• “El .mpd es el vídeo.” No lo es. Es el manifiesto. El vídeo real vive en los segmentos .m4s a los que el manifiesto hace referencia.
• “Si un sitio usa DASH, mi reproductor HLS no puede reproducirlo.” Cierto para los reproductores nativos. Pero la mayoría de los reproductores web modernos —shaka-player, dash.js, hls.js, video.js— gestionan ambos dentro del navegador entregando segmentos al elemento de vídeo mediante Media Source Extensions.
• “DASH siempre significa DRM.” No es así. Muchos flujos DASH se envían sin cifrado: emisiones de eventos en directo, plataformas educativas y la mayoría del contenido gratuito de YouTube. El DRM es una capa opcional declarada mediante elementos ContentProtection.

Reflexiones finales

DASH es el gemelo de universo paralelo de HLS. Ambos cortan el vídeo en segmentos cortos, los describen en un manifiesto y los envían sobre HTTP plano. Las diferencias —XML frente a texto plano, estándar ISO frente a especificación de Apple, agnóstico de códec frente a dependiente del historial de códecs— importan dentro de la industria pero rara vez le importan al espectador. Lo que importa es que los servicios de streaming que licencian contenido de cada estudio del mundo se han asentado en estos dos protocolos, convergiendo cada vez más en segmentos CMAF compartidos bajo ambos manifiestos. Una vez que puedes reconocer una petición .mpd y entender la jerarquía Period / AdaptationSet / Representation, el comportamiento extraño del streaming moderno deja de ser misterioso —es todo el mismo bucle: descargar manifiesto, elegir variantes, descargar segmentos, decodificar, repetir. Si prefieres saltarte la capa de protocolo por completo y simplemente guardar el vídeo, VidMost gestiona HLS, MPEG-DASH, fMP4, CMAF y flujos protegidos por DRM.

Lectura relacionada

• Cómo se reproduce realmente el vídeo en línea — el pipeline de streaming general desde la cámara hasta tu pantalla.
• ¿Qué es HLS y M3U8? — el protocolo hermano cubierto de principio a fin.
• Por qué cambia la calidad del vídeo a mitad de reproducción — la lógica ABR dentro de cada reproductor DASH y HLS.
• Contenedores de vídeo frente a códecs — qué hay realmente dentro de un segmento .m4s.
• ¿Qué es el contenido protegido por DRM? — cómo Widevine, PlayReady y FairPlay controlan las variantes cifradas que no puedes simplemente guardar.