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

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

Información sobre la forma de comer DASH

En la siguiente lista, se enumeran algunas funciones y atributos clave del DASH:

• Se basa en estándares abiertos.
• Basado en HTTP. Como resultado, DASH es compatible con la infraestructura de Internet y puede atravesar firewalls.
• Admite una tasa de bits de transferencia alta. DASH admite varias sesiones HTTP simultáneas y la entrega de segmentos no secuenciales, lo que proporciona una mayor resiliencia que los protocolos que se basan en una sola conexión TCP.
• Entrega segura a través de HTTPS.
• Entrega sin pérdidas a través de HTTP y HTTPS.
• Es independiente del códec.
• Admite MP4 que contiene H264 y AAC, además de WebM que contiene VP8/VP9 y Vorbis/Opus.

Especificaciones

• DASH se describe en el artículo ISO/IEC 23009-1:2014 Tecnología de la información: transmisión dinámica adaptable a través de HTTP (DASH).
• WebM sobre DASH se describe en la especificación WebM DASH.

Requisitos

En las siguientes subsecciones, se explican los requisitos de uso de DASH para enviar transmisiones en vivo a YouTube.

Tiempos

El endpoint DASH de YouTube se comporta como un servidor HTTP pasivo, ya que registra llamadas al método PUT enviadas por un codificador.

• El extremo de DASH admite conexiones TCP simultáneas. Puedes volver a usar las conexiones según HTTP/1.1.
• Los segmentos de MPD y de inicialización deben tener el estado PUT dentro de los 3 segundos posteriores al primer segmento de medios. (Te recomendamos que incluyas el segmento Inicialización en la MPD).
• Cada segmento o MPD debe usar una solicitud PUT independiente. No se admite la carga de varias partes de varios segmentos.
• Es posible que las operaciones PUT para segmentos de medios se superpongan en el tiempo para mejorar el ancho de banda de carga.
• Se pueden proporcionar en un orden no secuencial en un período de aproximadamente 3 segundos.
• Los segmentos de inicialización y MPD deben actualizarse 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 la MPD. En ese caso, una solicitud PUT puede actualizar ambos segmentos).

Estructura de la URL

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

Luego, el codificador puede obtener la URL base del extremo de forma programática mediante 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 proporcionar la URL al codificador de forma manual.

La cadena adjunta a la URL base puede contener el siguiente conjunto de caracteres ASCII:

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

URLs de MPD

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

URL de inicialización y segmentos de medios

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

Contenidos MPD

La MPD debe estar completa y cumplir con el estándar DASH. Debe contener exactamente uno de los siguientes elementos: Esta lista identifica los elementos que YouTube exige específicamente, y el estándar DASH podría identificar elementos obligatorios adicionales. Los elementos se representan mediante la sintaxis XPath y son coherentes con el estándar 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 contenido multimedia).

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 se incluye el segmento de inicialización en la MPD, la URL data:, que contiene el segmento, no debe superar los 100 KB.

Salida del codificador

El segmento de inicialización y los segmentos multimedia deben constituir una transmisión de archivos WebM o BMFF ISO multiplexada con GOP (grupos de imágenes) cerrados.

• El tamaño del GOP debe ser de aproximadamente 2 segundos y menor a 8 segundos.
• La transmisión multiplexada debe contener tanto pistas de audio como de video.

Prácticas recomendadas adicionales

Encriptación

YouTube admite la encriptación de transmisiones mediante HTTPS. Te recomendamos que utilices esta función.

Segmentos de inicialización en MPD

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

La XPath de este elemento es la siguiente:

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

Nota: La URL data: no debe superar los 100,000 bytes.

Duraciones de los segmentos objetivo

Para obtener un buen rendimiento de la transferencia y una buena compensación entre la capacidad de procesamiento y la latencia, la duración de tus segmentos de medios debe ser de entre 1 y 5 segundos.Te recomendamos que comuniques la duración objetivo de esos segmentos en la MPD usando 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 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 de la transferencia no es igual a la duración del fragmento de la transmisión en vivo que produce YouTube. YouTube transcodifica y vuelve a fragmentar la entrada, y la duración objetivo de salida depende de si la transmisión está optimizada para la calidad de transmisión o para la latencia.

Reintentos y retirada exponencial

Todas las solicitudes PUT de 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 un segmento de medios que falla, ya sea debido al tiempo de espera u otros errores, corresponde a un intervalo en la transmisión de video por Internet. Por lo tanto, debes reintentar cualquier solicitud de este tipo con una retirada exponencial binaria aleatorizada:

1. Después de una falla, 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 intentar la solicitud.
3. Si la solicitud vuelve a fallar, espera un período aleatorio entre [0 ... 400] milisegundos y vuelve a intentar la solicitud.
4. etc.

Ten en cuenta que las fallas repetidas deben indicarse al operador del codificador, ya que corresponden a una transmisión con errores.

Códigos de respuesta HTTP

En las siguientes secciones, se explican los códigos de respuesta que muestra YouTube en respuesta a los segmentos proporcionados mediante DASH.

200 (OK)

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

202 (Aceptado)

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

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

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

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

Sin embargo, una respuesta 202 también puede indicar que el identificador del artículo es incorrecto si YouTube no puede validarlo por completo al momento de recibir la solicitud POST o PUT. Por ejemplo, una de las veces que esto ocurre es cuando YouTube recibe y acepta un segmento de inicialización antes de recibir la MPD, pero el segmento de inicialización resulta no válido. En este caso, YouTube acepta el segmento de inicialización, devuelve un 202 y, luego, determina si el segmento es válido al momento de recibir la MPD. Puedes evitar esta situación en particular si incluyes el segmento de inicialización en la MPD.

400 (solicitud incorrecta)

Una respuesta HTTP 400 (Solicitud incorrecta) indica que se produjo uno de los siguientes problemas:

• La URL presenta errores de formato.
• La entrada es demasiado grande (más de 10 MB).
• No se puede analizar la MPD.
• El segmento de inicialización en la MPD está dañado.

401 (no está autorizado)

Una respuesta HTTP 401 (no autorizado) indica que la URL base para el extremo de DASH de YouTube está dañada o ha caducado.

405 (Método no permitido)

Una respuesta HTTP 405 (Método no permitido) indica que se envió una solicitud distinta de POST o 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 podría ocurrir si el solicitante envió varios segmentos de medios, pero YouTube aún no tiene la MPD, el segmento de inicialización o ambos. En ese ejemplo, el codificador tendría que volver a transmitir los segmentos de inicialización y MPD antes de reintentar la solicitud con errores.

Importante: Un codificador DEBE administrar este código de respuesta correctamente porque se puede mostrar en cualquier momento, incluso durante las operaciones normales. Aunque no hay límite en la cantidad de reintentos, las fallas repetidas se deben indicar al operador del codificador que la transmisión está fallando.

500 (Error interno del servidor)

Una respuesta HTTP 500 (Error de servidor interno) indica que el servidor no pudo procesar la solicitud. En este caso, te recomendamos que vuelvas a intentar la solicitud con la retirada exponencial.

Ejemplos

Secuencia de URL

La secuencia de URL a continuación muestra una serie de solicitudes PUT que se harían para entregar contenido a través de DASH. La secuencia supone que la URL base para el extremo de DASH de YouTube es:

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

En la secuencia, se muestran los segmentos de inicialización y MPD 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, los segmentos de inicialización y MPD deben actualizarse 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, las seguidas por las 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

La siguiente MPD de muestra tiene un segmento de inicialización incorporado en una URL de datos RFC 2397. Te recomendamos incorporar el segmento Inicialización de esta manera en lugar de enviarlo por separado.

Este ejemplo cumple con las especificaciones de la transferencia de WebM (VP8 o VP9, Opus) a YouTube. La mayor parte de las URLs de los datos se eludieron 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

La siguiente MPD de ejemplo, que no tiene un segmento de inicialización incorporado, también cumple con las especificaciones 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 ejemplo de segmento de inicialización de WebM. Consiste en la parte de la transmisión de WebM hasta el primer clúster, pero sin incluirlo.

Medios

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

Segmentos ISO de BMFF

MPD con segmento de inicialización incorporado

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

Este ejemplo cumple con las especificaciones de la transferencia de ISO BMFF (H.264, AAC) a YouTube. La mayor parte de las URLs de los datos se eludieron 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

La siguiente MPD de ejemplo, que no tiene un segmento de inicialización incorporado, también cumple con las especificaciones 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 de BMFF multiplexado ISO. YouTube no necesariamente utiliza los átomos, pero este es un ejemplo consistente. En particular, se representan tanto las pistas de audio como las de video.

Medios

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

Limitaciones conocidas

Transferencias RTMP y DASH

No es posible combinar transferencias RTMP y DASH a YouTube.Esto se aplica al cambio entre los dos durante una transmisión y al uso de uno como método de transferencia principal y el otro para la transferencia de respaldo.