Se usó la API de Cloud Translation para traducir esta página.

Cómo publicar contenido de YouTube en vivo a través de DASH

En este documento, se proporcionan lineamientos sobre el uso del formato de entrega DASH para transmitir datos en vivo en YouTube desde un codificador. Está diseñada para ayudar a los proveedores de codificadores a agregar compatibilidad con la entrega DASH a sus productos.

Información sobre la dieta DASH

En la siguiente lista, se enumeran algunas características y atributos clave de la DASH:

Basado en estándares abiertos.
Basado en HTTP. Como resultado, la forma de comer 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 mayor resiliencia que los protocolos que dependen de una sola conexión TCP.
Entrega segura mediante HTTPS.
Entrega sin pérdidas mediante HTTP y HTTPS.
Independiente del códec.
Admite MP4 que contiene H264 y AAC, así como WebM que contiene VP8/VP9 y Vorbis/Opus.

Especificaciones

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

Requisitos

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

Timing

El extremo DASH de YouTube se comporta como un servidor HTTP pasivo y registra las llamadas al método PUT enviadas por un codificador.

El extremo DASH admite conexiones TCP simultáneas. Puedes volver a usar las conexiones según HTTP/1.1.
Los segmentos MPD e Inicialización deben estar PUT en un plazo de 3 segundos del primer segmento multimedia. (Te recomendamos que incluyas el segmento de inicialización en la MPD).
Cada segmento o MPD debe usar una solicitud PUT independiente, por lo que no se admite la carga de varias partes de varios segmentos.
Las operaciones PUT para los segmentos de contenido multimedia pueden superponerse a tiempo para mejorar el ancho de banda de carga.
Los segmentos se pueden proporcionar en un orden no secuencial dentro de un período de aproximadamente 3 segundos.
Los segmentos MPD e Inicialización deben actualizarse al menos cada 60 segundos con un availabilityStartTime y 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

Tu codificador debe formar URL PUT agregando una string a la URL base del extremo de YouTube. Debes crear el extremo de transferencia DASH mediante la API de transmisión en vivo de YouTube.

Luego, el codificador puede obtener la URL base del extremo de manera programática mediante la API de transmisión en vivo de YouTube. La URL base también se puede ver en la IU de Eventos en vivo de YouTube si deseas proporcionar la URL al codificador de forma manual.

La string 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)

URL de MPD

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

Inicialización y URL del segmento multimedia

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

Contenido MPD

La MPD debe estar completa y cumplir con el estándar DASH. Debe contener exactamente uno de cada uno de los siguientes elementos. Esta lista identifica los elementos que YouTube exige en particular, y el estándar DASH puede identificar elementos obligatorios adicionales. Los elementos se representan con 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 URL de segmentos multimedia se generan con $Number$ . (El atributo startNumber identifica el número que se asignará al primer segmento 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). 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

Los segmentos de inicialización y medios deben constituir una transmisión multiplexada de archivos ISO/BMFF o WebM con GOP (grupos de imágenes) cerrados.

El tamaño del GOP debe ser de aproximadamente 2 segundos y debe ser inferior a 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 mediante HTTPS. Le recomendamos que utilice esta función.

Segmentos de inicialización en MPD

Puedes representar el segmento de inicialización directamente en la MPD mediante 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 para 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 segmentos objetivo

Para obtener un buen rendimiento de transferencia y una buena compensación entre la capacidad de procesamiento y la latencia, los segmentos de medios deben durar entre 1 y 5 segundos.Le recomendamos que comunique la duración objetivo de esos segmentos en la MPD mediante 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 del segmento 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 de los fragmentos de la transmisión en vivo que produce YouTube. YouTube transcodifica y vuelve a fragmentar la entrada, y la duración objetivo del resultado depende de si una transmisión está optimizada para la calidad o la latencia.

Reintentos y retirada exponencial

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

Después de un error, espera un período aleatorio entre [0 ... 100] milisegundos y vuelve a intentar la solicitud.
Si la solicitud vuelve a fallar, espera un período aleatorio entre [0 ... 200] milisegundos y vuelve a intentarlo.
Si la solicitud vuelve a fallar, espera un período aleatorio entre [0 ... 400] milisegundos y vuelve a intentarlo.
Y así sucesivamente.

Ten en cuenta que las fallas repetidas deben indicarse al operador de 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 YouTube muestra en respuesta a segmentos entregados 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 procesó correctamente.

202 (Aceptado)

Una respuesta HTTP 202 (Aceptada) a cualquier operación PUT o POST indica que la operación fue inesperada y que 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 publica de forma no secuencial. Por lo general, YouTube puede procesar correctamente el segmento aceptado después de recibir los segmentos anteriores, sin necesidad de que vuelvas a enviarlo.

Por ejemplo, YouTube puede mostrar 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 segmentos de inicialización y MPD.
Un segmento multimedia se recibe antes que un segmento anterior, como el segmento 3 antes del segmento 2.

Sin embargo, una respuesta 202 también puede indicar que el identificador de elemento es incorrecto si YouTube no puede validar por completo el identificador al recibir la solicitud POST o PUT. Por ejemplo, una de las veces que esto ocurre cuando YouTube recibe y acepta un segmento de inicialización antes de recibir la MPD, pero el segmento de inicialización resulta no ser válido. En este caso, YouTube acepta el segmento de inicialización y muestra un 202, luego determina si el segmento es válido cuando reciba 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 publicación es demasiado grande (más de 10 MB).
La MPD no se puede analizar
El segmento de inicialización en la MPD está dañado

401 (no está autorizado)

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

405 (Método no permitido)

Una respuesta HTTP 405 (Método no permitido) indica que se envió una solicitud diferente de POST o PUT.

409 (Conflicto)

Una respuesta HTTP 409 (Conflicto) a una 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 multimedia, pero YouTube aún no tiene la MPD, el segmento de inicialización o ambos. En ese ejemplo, el codificador tendría que retransmitir los segmentos MPD e Initialization antes de reintentar la solicitud con errores.

500 (Error de servidor interno)

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

Ejemplos

Secuencia de URL

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

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

La secuencia muestra 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 se deben actualizar al menos cada 60 segundos. Por lo tanto, las URL de esos segmentos volverán a aparecer en esta secuencia y, luego, aparecerán las URL 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 de 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 que incorpores el segmento de inicialización de esta manera en lugar de enviarlo por separado.

Este ejemplo cumple con la transferencia de WebM (VP8 o VP9, Opus) a YouTube. La mayor parte de la URL de datos se recurrió a la legibilidad:

<?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 muestra, que no tiene un segmento de inicialización incorporado, también cumple con los requisitos de 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 muestra. Consiste en la parte de la transmisión de WebM, pero no incluye el primer clúster.

Contenido multimedia

A continuación, se muestra el diseño de un segmento multimedia de muestra de WebM. Consiste en un solo clúster de WebM. Al igual que con una transmisión ISO BMFF, el segmento de inicialización antepuesto a una serie de clústeres debería producir una transmisión WebM válida.

Segmentos ISO BMFF

MPD con segmento de inicialización incorporado

Este ejemplo cumple con la transferencia ISO BMFF (H.264, AAC) a YouTube. La mayor parte de la URL de datos se recurrió a la legibilidad:

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

Contenido multimedia

En el siguiente diagrama, se muestra el diseño de un segmento de medios ISO BMFF multiplex de muestra. YouTube no utiliza necesariamente todos los átomos, pero este es un ejemplo acorde. 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 una transmisión de BMFF ISO multiplex válida y completa.

Limitaciones conocidas

Transferencias de RTMP y DASH

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