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

En este documento, se explica cómo usar el protocolo HTTP Live Streaming (HLS) para transmitir datos en vivo en YouTube desde un codificador. Este documento está destinado a los proveedores de codificadores que desean agregar compatibilidad con la transferencia HLS a sus productos. La transferencia HLS es una buena opción para el contenido premium que requiere alta calidad y alta resolución con una latencia relativamente más alta. Para obtener una breve comparación de los diferentes protocolos de transferencia que admite YouTube Live Streaming, consulta Comparación de protocolos de transferencia de YouTube Live Streaming.

Para transmitir datos en vivo con HLS, el codificador debe enviar una serie de playlists de contenido multimedia y segmentos de contenido multimedia al extremo HLS de YouTube mediante solicitudes HTTP PUT o POST. Desde la perspectiva del codificador, el extremo HLS de YouTube parece ser un servidor HTTP pasivo.

Cada segmento de contenido multimedia representa el contenido multimedia real de una breve parte de la transmisión que dura entre uno y cuatro segundos. Cada playlist de contenido multimedia describe cómo volver a ensamblar los segmentos de contenido multimedia en el orden de transmisión correcto.

Requisitos de formato de contenido multimedia

La transferencia HLS de YouTube tiene los siguientes requisitos para el contenido de audio y video:

• El audio y el video deben estar multiplexados en formato M2TS.
• Los códecs de video compatibles son H.264 y HEVC.
• Se admiten velocidades de fotogramas de hasta 60 fps.
• Solo se admite el GOP cerrado.
• El códec de audio compatible es AAC, y solo se admite el audio de una sola pista.

Consulta los requisitos más detallados en la sección Segmentos de contenido multimedia.

HDR

Se admite el video de alto rango dinámico (HDR) con el códec HEVC y tiene los siguientes requisitos adicionales:

• Los estándares de color compatibles son PQ de 10 bits y HLG con luminancia no constante. Más específicamente:
  • El formato de croma debe ser YUV 4:2:0 de 10 bits.
  • La función de transferencia debe ser PQ (también conocida como SMPTE ST 2084) o HLG (también conocida como ARIB STD-B67).
  • Los colores primarios deben ser Rec. 2020.
  • Los coeficientes de la matriz deben ser Rec. 2020 con luminancia no constante.
• Se admiten valores de muestra de rango limitado (o rango MPEG) y de rango completo (o rango JPEG). Es importante que el rango se establezca según el rango de valores de muestra que usa el contenido. Se recomiendan los valores de muestra de rango limitado.

Cómo obtener una URL de transferencia HLS

Cómo obtener una URL de transferencia HLS desde la API de YouTube

Para obtener la URL de transferencia completa, los codificadores pueden usar la API de YouTube Live Streaming para insertar un recurso liveStream con las siguientes propiedades:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

En la respuesta de la API, el campo cdn.ingestionInfo.ingestionAddress especifica la URL de transferencia principal, y el campo cdn.ingestionInfo.backupIngestionAddress especifica la URL de transferencia de respaldo. Para obtener más detalles, consulta la documentación de l liveStreams recurso.

Cómo obtener una URL de transferencia HLS desde YouTube Creator Studio

**Precaución:** Este método para obtener URLs de transferencia HLS es una función beta y puede cambiar en el futuro.

En la interfaz web de YouTube Creator Studio, después de que el creador de YouTube hace clic en "Crear transmisión", YouTube muestra una "Clave de transmisión" que consta de caracteres alfanuméricos y guiones. Esta clave secreta identifica al creador y la transmisión en YouTube.

Puedes construir una URL de HLS a partir de esta clave de transmisión de la siguiente manera:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

... donde $STREAM_KEY es la clave de transmisión que se muestra en la interfaz web. Por ejemplo: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

Para mayor confiabilidad, puedes transmitir una segunda copia redundante de la transferencia a esta URL de respaldo:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

Ten en cuenta que el respaldo tiene dos diferencias con la URL principal: cambiaron el nombre de host y el parámetro copy=. La transferencia de respaldo debe enviar un valor de parámetro copy= diferente al de la transferencia principal para evitar dañar la transmisión.

Cómo completar la URL de transferencia HLS

Las URLs obtenidas con cualquiera de los métodos son plantillas incompletas; cada una termina con un parámetro de consulta file= vacío. Para formar la URL final, el codificador debe agregar el nombre de archivo de una playlist de contenido multimedia o un segmento de contenido multimedia al final de la URL y, de esta manera, completar el parámetro file=.

Se aplican las siguientes reglas al valor del parámetro file=:

• El codificador puede construir un nombre de archivo de playlist de contenido multimedia o segmento de contenido multimedia a partir de caracteres alfanuméricos, guiones bajos, barras diagonales, guiones y puntos. No se admiten otros caracteres.
• El codificador no debe codificar la URL del nombre de archivo.
• El codificador puede incluir componentes de ruta de acceso relativos o absolutos en los nombres de archivo, aunque nunca es obligatorio. Si el codificador incluye un componente de ruta de acceso dentro de un nombre de archivo de segmento de contenido multimedia, debe hacer referencia a la misma ruta de acceso en la entrada de playlist correspondiente.

Requisitos del protocolo HLS

Las playlists de contenido multimedia y los segmentos de contenido multimedia que envía el codificador deben cumplir con la especificación de la segunda edición de HTTP Live Streaming.

La especificación de HLS define dos tipos de playlist: playlist de contenido multimedia y playlist principal. Como YouTube transcodifica el contenido transmitido a diferentes resoluciones y velocidades de bits, el codificador no necesita enviar contenido con diferentes velocidades de bits a YouTube. Como resultado, YouTube solo admite playlists de contenido multimedia para la transferencia HLS, y se ignoran las playlists principales. (Una playlist principal proporciona un conjunto de transmisiones de variantes, cada una de las cuales describe una versión diferente del mismo contenido).

El codificador debe hacer lo siguiente:

• Enviar exactamente una transmisión codificada con la resolución más alta que deseas publicar para los usuarios (resolución y códec únicos).
• Multiplexar audio y video.
• Usar HTTPS y una conexión persistente para todas las solicitudes.

Las siguientes secciones contienen requisitos más específicos para las playlists de contenido multimedia y los segmentos de contenido multimedia.

Playlists de contenido multimedia

Una playlist de contenido multimedia contiene una lista de segmentos de contenido multimedia que se pueden concatenar para representar una transmisión multimedia continua y decodificable. La playlist de contenido multimedia le indica al servidor qué segmentos de contenido multimedia esperar y cómo ordenarlos correctamente en la transmisión reensamblada.

Requisitos

• El nombre del archivo de la playlist de contenido multimedia debe terminar con .m3u8 o .m3u.

• La primera playlist de contenido multimedia que se envía para una transmisión debe comenzar con el número de secuencia 0 , y el número de secuencia debe aumentar de forma monotónica.

• La etiqueta EXT-X-MEDIA-SEQUENCE debe identificar el número de secuencia del primer segmento de contenido multimedia que aparece en la playlist.

• Una playlist de contenido multimedia no debe contener más de cinco segmentos pendientes. Un segmento está pendiente si el servidor no lo recibió o no confirmó su recepción.

  Además de los segmentos pendientes, también incluye algunos segmentos confirmados en cada playlist de contenido multimedia. Esta práctica hace que sea menos probable que se omita un segmento si se pierde una playlist de contenido multimedia en el servidor. Por ejemplo, puedes incluir hasta dos segmentos confirmados y hasta cinco segmentos pendientes en cada playlist de contenido multimedia.

  Ten en cuenta que el servidor confirma la recepción de un segmento de contenido multimedia mostrando una respuesta 200 (OK) o 202 (Accepted) cuando se sube ese segmento. Una respuesta 202 indica que el servidor recibió el segmento antes de una playlist que lo identifica.

• Envía una playlist de contenido multimedia actualizada para cada segmento de contenido multimedia de modo que el servidor pueda recuperarse rápidamente si se pierde una playlist de contenido multimedia.

• A medida que el servidor confirma la recepción de los segmentos de contenido multimedia, puedes aumentar el valor de la etiqueta EXT-X-MEDIA-SEQUENCE para evitar que la playlist de contenido multimedia se vuelva demasiado larga. Por ejemplo, si el servidor ya confirmó la recepción de los primeros nueve segmentos de contenido multimedia, la siguiente playlist de contenido multimedia podría mostrar los segmentos de contenido multimedia octavo, noveno y décimo.

• No se admiten las etiquetas EXT-X-KEY y EXT-X-SESSION-KEY.

Ejemplos

En la siguiente lista, se muestra un ejemplo de los archivos que se espera que envíe el codificador:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

En el siguiente ejemplo, se muestra una playlist de contenido multimedia enviada en medio de una transmisión de video en vivo. Como el ejemplo es de la mitad de una transmisión, la etiqueta EXT-X-MEDIA-SEQUENCE tiene un valor distinto de cero.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

Segmentos de contenido multimedia

En la siguiente lista, se identifican los requisitos para los segmentos de contenido multimedia:

• Nombres de archivo
  • Los nombres de archivo de los segmentos de contenido multimedia en la URL deben tener la extensión de nombre de archivo .ts y deben coincidir con los nombres de archivo de la playlist.
  • Los nombres de archivo de los segmentos de contenido multimedia deben ser únicos en los reinicios del codificador y los reinicios de la transmisión.
• Formato
  • Los segmentos de contenido multimedia deben estar en formato M2TS y deben inicializarse automáticamente.
  • Cada segmento M2TS debe contener un solo programa MPEG-2.
  • El segmento M2TS debe contener un PAT y un PMT, y los dos primeros paquetes de la transmisión en un segmento deben ser un PAT y un PMT.
• Contenido
  • El audio y el video deben estar multiplexados.
  • Los códecs de video compatibles son H.264 y HEVC.
  • Se admite HDR con HEVC (consulta los requisitos de HDR).
  • Se admiten velocidades de fotogramas de hasta 60 fps.
  • Solo se admite el GOP cerrado.
  • El códec de audio compatible es AAC, y solo se admite el audio de una sola pista.
  • Se recomienda que los segmentos de contenido multimedia tengan una duración de entre uno y cuatro segundos, como se explica en la siguiente sección. Los segmentos de contenido multimedia no deben tener una duración superior a 5 segundos.
  • Los segmentos de contenido multimedia solo deben encriptarse en la capa TLS/SSL con HTTPS. No se admiten otros mecanismos de encriptación.

Duración del segmento de contenido multimedia

Esperamos que la transferencia HLS se use para contenido premium que requiera alta calidad y alta resolución. Por lo general, la transferencia HLS tiene una latencia más alta que las transferencias basadas en RTMP y WebRTC porque se basa en segmentos.

Recomendamos una duración de segmento de contenido multimedia de uno a cuatro segundos, ya que tener segmentos de contenido multimedia más pequeños puede generar una latencia más baja, aunque a costa de una tasa de almacenamiento en búfer más alta y una eficiencia de codificación más baja. Como se indicó en la sección anterior, los segmentos de contenido multimedia no deben durar más de 5 segundos.

Velocidades de bits

En el Centro de ayuda de YouTube, se proporcionan lineamientos para la configuración de la velocidad de bits.

Ten en cuenta que, por lo general, HEVC produce entre un 25% y un 50% más de compresión de datos con la misma calidad de video en comparación con H.264. Por lo tanto, los valores de tasa de bits en el extremo inferior de los rangos sugeridos se pueden usar con HEVC para ahorrar ancho de banda, lo que es especialmente útil para el contenido 4K.

Otros requisitos

• Los codificadores deben establecer el encabezado User-Agent en la solicitud HTTP con la siguiente sintaxis, que incluye el nombre del fabricante, el nombre del modelo y la versión:

  User-Agent: <manufacturer> / <model> / <version>
  

  Nota: Esta información solo se usará para la depuración. No se usará para decisiones funcionales en el manejo de transmisiones.

Subtítulos

La transferencia HLS admite dos opciones para enviar subtítulos:

• Envía subtítulos con solicitudes HTTP POST independientes. Esto funciona para todas las transferencias HLS.
• Los subtítulos 608/708 incorporados funcionan con las transferencias HLS que usan el códec de video H264 , pero no con las transferencias que usan el códec de video HEVC. Para obtener más detalles, consulta los Requisitos de subtítulos en vivo en el Centro de ayuda de YouTube.

Códigos de respuesta HTTP

En las siguientes secciones, se explican los códigos de respuesta que YouTube muestra en respuesta a los segmentos de contenido multimedia y las playlists de contenido multimedia que se entregan con HLS.

200 (OK)

En respuesta a una solicitud PUT o POST, una respuesta HTTP 200 (OK) indica que el servidor de YouTube recibió una operación esperada y la controló correctamente.

En respuesta a una solicitud DELETE, una respuesta HTTP 200 (OK) indica que el servidor de YouTube recibió la solicitud y la ignoró. El servidor de YouTube no requiere que el cliente BORRE ningún recurso en la transmisión y, además, ignora las solicitudes DELETE. Por motivos de rendimiento, YouTube recomienda que los clientes no envíen DELETEs.

202 (Accepted)

Una respuesta HTTP 202 (Accepted) indica que el servidor de YouTube recibió el segmento de contenido multimedia antes de recibir una playlist de contenido multimedia que lo contenga. Esto indica al cliente que debe enviar la playlist de contenido multimedia que contiene ese segmento de contenido multimedia lo antes posible para evitar una demora en el procesamiento de ese segmento. Ten en cuenta que esto no será un problema si el codificador envía una playlist de contenido multimedia actualizada para cada segmento de contenido multimedia.

400 (solicitud incorrecta)

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

• La URL presenta errores de forma.
• No se puede analizar la playlist o contiene etiquetas no compatibles.

401 (no está autorizado)

Una respuesta HTTP 401 (no está autorizado) indica que el parámetro cid de la URL base del extremo HLS de YouTube está dañado o venció. El cliente debe actualizar el parámetro cid para continuar.

405 (Method Not Allowed)

Una respuesta HTTP 405 (Method Not Allowed) indica que la solicitud no era una solicitud POST, PUT o DELETE.

500 (Internal Server Error)

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