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á dirigido a los proveedores de codificadores que deseen agregar compatibilidad con la transferencia de HLS a sus productos. La transferencia de 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 la transmisión en vivo de YouTube, consulta Comparación de protocolos de transferencia de la transmisión en vivo de YouTube.

Para transmitir datos en vivo con HLS, el codificador debe enviar una serie de listas de reproducción de medios y segmentos de medios al extremo de HLS de YouTube con solicitudes HTTP PUT o POST. Desde la perspectiva del codificador, el extremo de HLS de YouTube parece ser un servidor HTTP pasivo.

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

Requisitos de formato de los medios

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

  • El audio y el video deben multiplexarse en formato M2TS.
  • Los códecs de video admitidos 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 admitido es AAC, y solo se admite audio de una sola pista.

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

HDR

Los videos de Alto rango dinámico (HDR) se admiten con el códec HEVC y tienen los siguientes requisitos adicionales:

  • Los estándares de color admitidos son PQ y HLG de 10 bits 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 la muestra que usa el contenido. Se recomiendan valores de muestra de rango limitado.

Cómo obtener una URL de transferencia de HLS

Cómo obtener una URL de transferencia de HLS de 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 copia de seguridad. Para obtener más detalles, consulta la documentación del recurso liveStreams.

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

En la interfaz web de YouTube Creator Studio, después de que el creador 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 tanto al creador como a la transmisión para 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 la URL de copia de seguridad tiene dos diferencias con respecto a la URL principal: cambiaron el nombre de host y el parámetro copy=. La transferencia de la copia de seguridad debe enviar un valor de parámetro copy= diferente al de la transferencia principal para evitar que se dañe la transmisión.

Cómo completar la URL de transferencia de HLS

Las URLs obtenidas con cualquiera de los métodos son plantillas incompletas; cada una termina con un parámetro de búsqueda file= vacío. Para formar la URL final, el codificador debe agregar el nombre de archivo de una playlist de medios o un segmento de medios al final de la URL, lo que completa el parámetro file=.

Las siguientes reglas se aplican al valor del parámetro file=:

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

Requisitos del protocolo HLS

Las listas de reproducción de medios y los segmentos de medios que envía el codificador deben satisfacer la especificación de HTTP Live Streaming, 2ª edición.

La especificación de HLS define dos tipos de playlists: la playlist de medios y la playlist principal. Dado que YouTube transcodifica el contenido transmitido a diferentes resoluciones y tasas de bits, el codificador no necesita enviar contenido con diferentes tasas de bits a YouTube. Por lo tanto, YouTube solo admite playlists de medios para la transferencia de 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 cumplir con los siguientes requisitos:

  • Envía exactamente una transmisión codificada con la resolución más alta que quieras ofrecer a los usuarios (una sola resolución y un solo códec).
  • multiplexar audio y video
  • Usar HTTPS y una conexión persistente para todas las solicitudes

En las siguientes secciones, se incluyen requisitos más específicos para las playlists de medios y los segmentos de medios.

Playlists de contenido multimedia

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

Requisitos

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

  • La primera playlist de medios que se envíe para una transmisión debe comenzar en 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 medios que aparece en la playlist.

  • Una playlist de medios 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 medios. Esta práctica reduce la probabilidad de que se omita un segmento si se pierde una playlist de medios en el servidor. Por ejemplo, puedes incluir hasta dos segmentos confirmados y hasta cinco segmentos pendientes en cada playlist de medios.

    Ten en cuenta que el servidor confirma la recepción de un segmento de medios con una respuesta 200 (OK) o 202 (Accepted) en la carga de ese segmento. Una respuesta 202 indica que el servidor recibió el segmento antes de que una playlist lo identificara.

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

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

  • 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 medios enviada en medio de una transmisión de video en vivo. Dado que 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 medios

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

  • Nombres de archivo
    • Los nombres de los archivos de segmentos de medios en la URL deben tener la extensión .ts y coincidir con los nombres de los archivos en la playlist.
    • Los nombres de los archivos de segmentos de medios deben ser únicos en todos los reinicios del codificador y los reinicios de la transmisión.
  • Formato
    • Los segmentos de medios deben estar en formato M2TS y deben inicializarse por sí mismos.
    • Cada segmento M2TS debe contener un solo programa MPEG-2.
    • El segmento M2TS debe contener una PAT y una PMT, y los dos primeros paquetes de Transport Stream en un segmento deben ser una PAT y una PMT.
  • Contenido
    • El audio y el video deben estar multiplexados.
    • Los códecs de video admitidos 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 audio de una sola pista.
    • Se recomienda que los segmentos de medios tengan una duración de entre uno y cuatro segundos, como se explica en la siguiente sección. Los segmentos de medios no deben tener una duración superior a 5 segundos.
    • Los segmentos de medios solo deben encriptarse en la capa TLS/SSL con HTTPS. No se admiten otros mecanismos de encriptación.

Duración del segmento de medios

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

Recomendamos una duración del segmento de medios de uno a cuatro segundos, ya que tener segmentos de medios más pequeños puede generar una menor latencia, aunque a costa de una mayor tasa de rebuffer y una menor eficiencia de codificación. Como se indicó en la sección anterior, los segmentos de medios 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 tasa de bits.

Ten en cuenta que, por lo general, HEVC genera 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 la 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 en 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>

Subtítulos

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

  • Envía subtítulos cerrados con solicitudes HTTP POST independientes. Esto funciona para todas las transmisiones de HLS.
  • Los subtítulos incorporados en formato 608 o 708 funcionan con las transferencias de 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 los subtítulos instantáneos 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 devuelve en respuesta a los segmentos de medios y las playlists de medios 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ó y descartó la solicitud. El servidor de YouTube no requiere que el cliente borre ningún recurso del flujo y, además, ignora las solicitudes de eliminación. Por motivos de rendimiento, YouTube recomienda que los clientes no envíen solicitudes de eliminación.

202 (Aceptado)

Una respuesta HTTP 202 (Aceptado) indica que el servidor de YouTube recibió el segmento de medios antes de recibir una playlist de medios que lo contenga. Esto indica al cliente que debe enviar la playlist de medios que contiene ese segmento de medios 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 medios actualizada para cada segmento de medios.

400 (solicitud incorrecta)

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

  • La URL presenta errores de forma.
  • No se puede analizar la playlist o contiene etiquetas no admitidas
401 (no está autorizado)

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

405 (Método no permitido)

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

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.