Entrega contenido de YouTube en vivo a través de DASH

En este documento, se proporcionan lineamientos para usar el formato de entrega de Transmisión adaptable y dinámica a través de HTTP (DASH) para transmitir datos en vivo en YouTube desde un codificador. Su objetivo es ayudar a los proveedores de codificadores a agregar compatibilidad con la entrega de DASH a sus productos.

Información sobre DASH

A continuación, se indican algunas funciones y atributos clave de DASH:

• Se basa en estándares abiertos.
• Se basa en HTTP. Como resultado, DASH es compatible con la infraestructura de Internet y puede atravesar firewalls.
• Admite una alta tasa de bits de transferencia. DASH admite varias sesiones HTTP simultáneas y la entrega de segmentos no secuenciales, lo que proporciona mayor capacidad de recuperación que los protocolos que dependen de una sola conexión TCP.
• Entrega segura a través de HTTPS.
• Entrega sin pérdidas a través de HTTP y HTTPS
• No depende de códecs.
• Admite MP4 con H264 y AAC, así como WebM con VP8/VP9 y Vorbis/Opus.

Especificaciones

• DASH se describe en ISO/IEC 23009-1:2014 Information technology -- Dynamic adaptive streaming over HTTP (DASH).
• WebM a través de DASH se describe en la especificación de WebM DASH.

Requisitos

En las siguientes subsecciones, se explican los requisitos para usar DASH y transmitir contenido en vivo a YouTube.

Tiempos

El extremo de DASH de YouTube se comporta como un servidor HTTP pasivo que registra las llamadas al método PUT que envía un codificador.

• El extremo de DASH admite conexiones TCP simultáneas. Puedes reutilizar las conexiones según HTTP/1.1.
• El MPD y los segmentos de inicialización deben colocarse con PUT en un plazo de 3 segundos después del primer segmento de medios. (Te recomendamos que incluyas el segmento de inicialización en el MPD).
• Cada segmento o MPD debe usar una solicitud PUT independiente. No se admite la carga de varios segmentos en varias partes.
• Las operaciones PUT para segmentos de medios pueden superponerse en el tiempo para mejorar el ancho de banda de carga.
• Los segmentos se pueden proporcionar en orden no secuencial dentro de un período de aproximadamente 3 segundos.
• El MPD y los segmentos de inicialización se deben actualizar al menos cada 60 segundos con un availabilityStartTime y un startNumber actualizados. (Como se indicó anteriormente, el segmento de inicialización se puede incluir en el MPD. En ese caso, una solicitud PUT puede actualizar ambos segmentos).

Estructura de la URL

Tu codificador debe formar URLs de PUT agregando una cadena a la URL base del extremo de YouTube. Debes crear el extremo de transferencia DASH con la API de YouTube Live Streaming.

Posteriormente, el codificador puede obtener la URL base del extremo de forma programática a través de la API de YouTube Live Streaming. La URL base también se puede ver en la IU de Eventos en vivo de YouTube si quieres proporcionarla al codificador de forma manual.

La cadena que se agrega a la URL base puede contener el siguiente conjunto de caracteres ASCII:

• Letras en minúsculas: a-z
• Letras mayúsculas: De la A a la Z
• Dígitos: 0-9
• Caracteres especiales: _ (guion bajo), - (guion), . (punto)

URLs de MPD

Además del requisito anterior, la URL del MPD debe terminar con .mpd, lo que permite que el servidor de YouTube identifique fácilmente el MPD. Las demás URLs de segmento no deben terminar con .mpd.

URLs de inicialización y segmentos de medios

La URL del segmento de inicialización y todas las URLs de los segmentos de medios deben terminar con .mp4 si los datos están en un contenedor BMFF de ISO o con .webm si los datos están en un contenedor WebM.

Contenido de la MPD

El MPD debe estar completo y cumplir con el estándar de DASH. Debe contener exactamente uno de cada uno de los siguientes elementos. En esta lista, se identifican los elementos que YouTube requiere específicamente, y el estándar DASH podría identificar elementos obligatorios adicionales. Los elementos se representan con la sintaxis de XPath y son coherentes con el estándar de DASH.

• /mpd:MPD/attribute::type
• /mpd:MPD/mpd:Period
• /mpd:MPD/mpd:Period/mpd:AdaptationSet
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/attribute::mimeType (video/mp4 or video/webm)
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::media
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::initialization
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::startNumber

Ten en cuenta los siguientes requisitos para los valores de los elementos:

• El atributo minimumUpdatePeriod del elemento <MPD> debe establecerse en un valor igual o inferior a 60 segundos (PT60S).
• El atributo media del elemento <SegmentTemplate> debe especificar que las URLs de segmentos de medios se generan con $Number$. (El atributo startNumber identifica el número que se asignará al primer segmento de medios).

Longitud del segmento de inicialización

El segmento de inicialización no debe superar los 100 KB. (Por lo general, un segmento de inicialización es mucho más pequeño que eso). Si el segmento de inicialización se incluye en el MPD, la URL de data:, que contiene el segmento, no debe superar los 100 KB.

Salida del codificador

El segmento de inicialización y los segmentos de medios deben constituir un flujo de archivos ISO BMFF o WebM multiplexado con GOPs (grupos de imágenes) cerrados.

• El tamaño del GOP debe ser de aproximadamente 2 segundos y no debe superar los 8 segundos.
• La transmisión multiplexada debe contener pistas de audio y video.

Prácticas recomendadas adicionales

Encriptación

YouTube admite la encriptación de transmisiones a través de HTTPS. Te recomendamos que uses esta función.

Segmentos de inicialización en el MPD

Puedes representar el segmento de inicialización directamente en el MPD con una URL data:, según el RFC 2397. Esto simplifica la configuración de la transmisión y reduce la posibilidad de que el segmento de inicialización no corresponda al resto de la transmisión.

El XPath de este elemento es el siguiente:

/mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute:data

Duraciones de los tramos objetivo

Para obtener un buen rendimiento de la transferencia y un buen equilibrio entre la capacidad de procesamiento y la latencia, la duración de los segmentos de medios debe ser de entre 1 y 5 segundos. Te recomendamos que comuniques la duración objetivo de esos segmentos en el MPD con estos dos elementos:

• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::duration
• /mpd:MPD/mpd:Period/mpd:AdaptationSet/mpd:SegmentTemplate/attribute::timescale

La duración calculada a partir de esos atributos debe estar dentro de un factor de 2 de todas las duraciones reales de los segmentos, o el rendimiento de la transmisión puede verse afectado.

Ten en cuenta que la duración objetivo para la transferencia no es igual a la duración de los fragmentos de la transmisión en vivo que produce YouTube. YouTube transcodifica y vuelve a segmentar la entrada, y la duración objetivo de la salida depende de si una transmisión se optimiza para la calidad de transmisión o para la latencia.

Reintentos y retirada exponencial

Todas las solicitudes PUT HTTP deben realizarse con un tiempo de espera, que recomendamos establecer en un valor 500 milisegundos mayor que la duración del segmento.

Una solicitud PUT de segmento de medios que falla, ya sea por tiempo de espera agotado o por otros errores, corresponde a una brecha en la transmisión de video. Por lo tanto, debes volver a intentar cualquier solicitud de este tipo con una retirada exponencial binaria aleatoria:

1. Después de un error, espera un período aleatorio entre [0 ... 100] milisegundos y vuelve a intentar la solicitud.
2. Si la solicitud vuelve a fallar, espera un período aleatorio entre [0 ... 200] milisegundos y vuelve a intentarlo.
3. Si la solicitud vuelve a fallar, espera un período aleatorio entre [0 ... 400] milisegundos y vuelve a intentarlo.
4. etc.

Ten en cuenta que las fallas repetidas se deben informar al operador del codificador, ya que corresponden a una transmisión fallida.

Códigos de respuesta HTTP

En las siguientes secciones, se explican los códigos de respuesta que YouTube devuelve en respuesta a los segmentos que se entregan a través de DASH.

200 (OK)

Una respuesta HTTP 200 (OK) indica que el servidor de YouTube recibió una operación esperada y la controló correctamente.

202 (Aceptado)

Una respuesta HTTP 202 (Aceptado) a cualquier operación PUT o POST indica que la operación fue inesperada y se aceptó para su procesamiento diferido. Sin embargo, la operación diferida podría tener éxito o fallar, por lo que la respuesta no garantiza que YouTube pueda procesar la operación correctamente.

Esta respuesta ocurre con mayor frecuencia cuando un segmento se entrega de forma no secuencial. Por lo general, YouTube puede procesar correctamente el segmento aceptado después de recibir los segmentos anteriores, por lo que no es necesario que lo vuelvas a enviar.

Por ejemplo, YouTube puede devolver una respuesta 202 en cualquiera de los siguientes casos:

• Se recibe un segmento de inicialización antes del MPD.
• Los segmentos de medios se reciben antes que el MPD y los segmentos de inicialización.
• Se recibe un segmento de medios antes que un segmento anterior, por ejemplo, se recibe el segmento 3 antes que el segmento 2.

Sin embargo, una respuesta 202 también puede indicar que el identificador del elemento es incorrecto si YouTube no puede validar por completo el identificador al recibir la solicitud POST o PUT. Por ejemplo, esto ocurre cuando YouTube recibe y acepta un segmento de inicialización antes de recibir el MPD, pero el segmento de inicialización resulta no ser válido. En este caso, YouTube acepta el segmento de inicialización y devuelve un código 202. Luego, determina si el segmento es válido cuando recibe el MPD. Para evitar esta situación en particular, incluye el segmento de inicialización en el MPD.

400 (solicitud incorrecta)

Una respuesta HTTP 400 (solicitud incorrecta) indica que ocurrió uno de los siguientes problemas:

• La URL tiene un formato incorrecto.
• La publicación es demasiado grande (más de 10 MB).
• No se puede analizar la MPD.
• El segmento de inicialización del MPD está dañado.

401 (no está autorizado)

Una respuesta HTTP 401 (No autorizado) indica que la URL base del extremo de YouTube DASH está dañada o venció.

405 (Method Not Allowed)

Una respuesta HTTP 405 (Method Not Allowed) indica que se envió una solicitud que no era POST ni PUT.

409 (Conflicto)

Una respuesta HTTP 409 (conflicto) a cualquier operación PUT o POST indica que YouTube no puede procesar la solicitud. Por ejemplo, esta respuesta puede ocurrir si el solicitante envió numerosos segmentos de medios, pero YouTube aún no tiene el MPD, el segmento de inicialización o ambos. En ese ejemplo, el codificador debería volver a transmitir el MPD y los segmentos de inicialización antes de volver a intentar la solicitud fallida.

500 (error interno del servidor)

Una respuesta HTTP 500 (error interno del servidor) indica que el servidor no pudo procesar la solicitud. En el caso de este error, te recomendamos que reintentes la solicitud con una retirada exponencial.

Ejemplos

Secuencia de URLs

La siguiente secuencia de URLs muestra una serie de solicitudes PUT que se realizarían para entregar contenido a través de DASH. La secuencia supone que la URL base del extremo de YouTube DASH es la siguiente:

http://upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=

La secuencia muestra los segmentos de MPD y de inicialización enviados por separado. Sin embargo, el segmento de inicialización se puede representar directamente en la MPD, y se recomienda esa práctica. Además, el MPD y los segmentos de inicialización se deben actualizar al menos cada 60 segundos. Por lo tanto, con el tiempo, las URLs de esos segmentos volverían a aparecer en esta secuencia y, luego, serían seguidas por URLs de más segmentos de medios.

PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=dash.mpd
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media001.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media002.mp4
PUT upload.youtube.com/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media003.mp4
...

Segmentos WebM

MPD con segmento de inicialización incorporado

El siguiente MPD de ejemplo tiene un segmento de inicialización incorporado en una URL de datos de RFC 2397. Te recomendamos que insertes el segmento de inicialización de esta manera en lugar de enviarlo por separado.

Este ejemplo cumple con los requisitos para la transferencia de WebM (VP8 o VP9, Opus) a YouTube. La mayor parte de la URL de datos se omitió para facilitar la lectura:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="data:video/mp4;base64,AAAAGGZ0eXBpc...AAA"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

El siguiente ejemplo de MPD, que no tiene un segmento de inicialización incorporado, también cumple con los requisitos para la transferencia de WebM (VP8 o VP9, Opus) a YouTube:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic" 
     profiles="urn:mpeg:dash:profile:isoff-live:2011" 
     minimumUpdatePeriod="PT60S"
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:52:58" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/webm">
      <ContentComponent contentType="video" id="1"/>
      <SegmentTemplate timescale="1000"
           duration="2000"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.webm"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media-$Number%09d$.webm"/>
      <Representation id="1" width="1920" height="1080">
        <SubRepresentation contentComponent="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Inicialización

A continuación, se muestra el diseño de un segmento de inicialización de WebM de ejemplo. Consiste en la parte del flujo de WebM hasta el primer clúster, sin incluirlo.

Medios

A continuación, se muestra el diseño de un segmento de medios WebM de muestra. Consta de un solo clúster de WebM. Al igual que con un flujo ISO BMFF, el segmento de inicialización antepuesto a una serie de clústeres debe producir un flujo WebM válido.

Segmentos ISO BMFF

MPD con segmento de inicialización incorporado

El siguiente MPD de ejemplo tiene un segmento de inicialización incorporado en una URL de datos de RFC 2397. Te recomendamos que insertes el segmento de inicialización de esta manera en lugar de enviarlo por separado.

Este ejemplo cumple con los requisitos de la transferencia de BMFF de ISO (H.264, AAC) a YouTube. La mayor parte de la URL de datos se omitió para facilitar la lectura:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="urn:mpeg:dash:schema:mpd:2011"   
    xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" 
    type="dynamic"
    minimumUpdatePeriod="PT30S" 
    availabilityStartTime="2016-05-04T20:47:25" 
    minBufferTime="PT12S" 
    profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
             media="/dash_upload?cid=ug50-xg26-cbc1-2p0h&staging=1&copy=0&file=media$Number%09d$.mp4"
             initialization="data:video/mp4;base64,AAAAGGZ0eXBpc281AA...AA"
             duration="306"
             startNumber="1"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" 
codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

MPD

El siguiente MPD de ejemplo, que no tiene un segmento de inicialización incorporado, también cumple con los requisitos para la transferencia de ISO BMFF (H.264, AAC) a YouTube:

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="urn:mpeg:dash:schema:mpd:2011"
     xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd"
     type="dynamic"
     profiles="urn:mpeg:dash:profile:isoff-live:2011"
     minimumUpdatePeriod="PT60S" 
     minBufferTime="PT12S"
     availabilityStartTime="2016-04-13T20:51:31" >
  <Period start="PT0S" id="1">
    <AdaptationSet mimeType="video/mp4" codecs="avc1.4d401e,mp4a.40.2">
      <ContentComponent contentType="video" id="1"/>
      <ContentComponent contentType="audio" id="2"/>
      <SegmentTemplate timescale="600"
           duration="1200"
           startNumber="1"
           initialization="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=init.mp4"
           media="/dash_upload?cid=xxxx-xxxx-xxxx-xxxx&copy=0&file=media$Number%09d$.mp4"/>
      <Representation id="1" width="640" height="360" bandwidth="526952">
        <SubRepresentation contentComponent="1" bandwidth="526952" codecs="avc1.4d401e"/>
        <SubRepresentation contentComponent="2" bandwidth="125584" codecs="mp4a.40.2"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Inicialización

En el siguiente diagrama, se muestra el diseño de un ejemplo de segmento de inicialización ISO BMFF multiplexado. YouTube no necesariamente usa los átomos, pero este es un ejemplo conforme. En particular, se representan las pistas de audio y video.

Medios

En el siguiente diagrama, se muestra el diseño de un ejemplo de segmento de medios ISO BMFF multiplexado. YouTube no necesariamente usa todos los átomos, pero este es un ejemplo conforme. En particular, se representan las pistas de audio y video. Se puede agregar una serie de estos segmentos a un segmento de inicialización para producir un flujo multiplexado ISO BMFF válido y completo.

Limitaciones conocidas

Ingestas de RTMP y DASH

No es posible combinar las transmisiones de RTMP y DASH en YouTube. Esto se aplica al cambio entre los dos durante una transmisión, así como al uso de uno como método de transferencia principal y el otro para la transferencia de copia de seguridad.