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 desean 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 ver una breve comparación de los diferentes protocolos de transferencia que admite YouTube en vivo, consulta Comparación de protocolos de transferencia de YouTube en vivo.
Para transmitir datos en vivo con HLS, el codificador debe enviar una serie de playlists y segmentos de medios al extremo HLS de YouTube con solicitudes HTTP PUT o POST. Desde la perspectiva del codificador, el extremo HLS de YouTube parece ser un servidor HTTP pasivo.
Cada segmento multimedia representa el contenido multimedia real de una breve parte de la transmisión que dura entre uno y cuatro segundos. En cada playlist de contenido multimedia, se describe cómo volver a ensamblar los segmentos de contenido multimedia en el orden de transmisión correcto.
Requisitos de formato multimedia
La transferencia de HLS de YouTube tiene los siguientes requisitos para el contenido de audio y video:
- El video y el audio 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 GOP cerrado.
- El códec de audio compatible 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
El video de Alto rango dinámico (HDR) es compatible con el códec HEVC y tiene 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 crominancia 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 de luminancia no constante Rec. 2020.
- 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 valores de muestra de rango limitado.
Cómo obtener una URL de transferencia HLS
Cómo obtener una URL de transferencia 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 de 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 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 al creador y la transmisión a YouTube.
Puedes crear una URL HLS a partir de esta clave de transmisión de la siguiente manera:
https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY©=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©=0&file=
Para mayor confiabilidad, puedes transmitir una segunda copia redundante de la transferencia a esta URL de copia de seguridad:
https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY©=1&file=
Ten en cuenta que la 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 copias de seguridad debe enviar un valor de parámetro copy= diferente al de la transferencia principal para evitar dañar la transmisión.
Completa la URL de transferencia de HLS
Las URLs que se obtienen con cualquiera de los métodos son plantillas incompletas, y cada una termina con un parámetro de consulta file= vacío. Para formar la URL final, el codificador debe adjuntar el nombre de archivo de una playlist o un segmento multimedia 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 crear un nombre de playlist o segmento multimedia 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 del archivo como URL.
- El codificador puede incluir componentes de ruta de acceso relativos o absolutos en los nombres de archivo, aunque esto nunca es obligatorio. Si el codificador incluye un componente de ruta dentro del nombre de un archivo de segmento multimedia, debe hacer referencia a la misma ruta en la entrada de la playlist correspondiente.
Requisitos del protocolo HLS
Las playlists y los segmentos multimedia que envía el codificador deben cumplir con las especificaciones de la 2ª edición de HTTP Live Streaming.
La especificación de HLS define dos tipos de playlist: la playlist multimedia 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. Como resultado, YouTube solo admite playlists multimedia para la transferencia de HLS, y se ignoran las playlists principales. (Una playlist maestra 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 deseas mostrar a los usuarios (códec y resolución únicos).
- audio y video.
- Usa HTTPS y una conexión persistente para todas las solicitudes.
En las siguientes secciones, se incluyen requisitos más específicos para las playlists y los segmentos de contenido multimedia.
Playlists de contenido multimedia
Una playlist multimedia contiene una lista de segmentos multimedia que se pueden concatenar para representar una transmisión multimedia continua y decodable. La playlist multimedia le indica al servidor qué segmentos multimedia esperar y cómo ordenarlos correctamente en la transmisión recompilada.
Requisitos
El nombre del archivo de la playlist multimedia debe terminar con
.m3u8o.m3u.La primera playlist multimedia que se envía para una transmisión debe comenzar en el número de secuencia
0, y el número de secuencia debe aumentar de forma monótona.La etiqueta
EXT-X-MEDIA-SEQUENCEdebe identificar el número de secuencia del primer segmento de medios que aparece en la playlist.Una playlist 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 destacados, incluye algunos segmentos reconocidos en cada playlist multimedia. Esta práctica reduce la probabilidad de que se omita un segmento si se pierde una playlist de contenido multimedia del servidor. Por ejemplo, puedes incluir hasta dos segmentos reconocidos y hasta cinco segmentos pendientes en cada playlist multimedia.
Ten en cuenta que el servidor confirma la recepción de un segmento de contenido multimedia cuando muestra una respuesta
200(OK) o202(Accepted) en la carga de ese segmento. Una respuesta202indica que el servidor recibió el segmento antes de una playlist que lo identifica.Envía una playlist multimedia actualizada para cada segmento multimedia para que el servidor pueda recuperarse rápidamente si se pierde una playlist multimedia.
A medida que el servidor confirma la recepción de los segmentos multimedia, puedes incrementar el valor de la etiqueta
EXT-X-MEDIA-SEQUENCEpara evitar que la playlist multimedia sea demasiado larga. Por ejemplo, si el servidor ya confirmó la recepción de los primeros nueve segmentos multimedia, la siguiente playlist multimedia podría incluir los segmentos octavo, noveno y décimo.Las etiquetas
EXT-X-KEYyEXT-X-SESSION-KEYno son compatibles.
Ejemplos
En la siguiente lista, se muestra un ejemplo de los archivos que se espera que el codificador envíe:
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 multimedia que se envía 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 medios
En la siguiente lista, se identifican los requisitos para los segmentos de medios:
- Nombres de archivo
- Los nombres de archivo de segmento multimedia en la URL deben tener la extensión del nombre de archivo
.tsy deben coincidir con los nombres de archivo de la playlist. - Los nombres de archivo de segmento multimedia deben ser únicos en todos los reinicios del codificador y los reinicios de la transmisión.
- Los nombres de archivo de segmento multimedia en la URL deben tener la extensión del nombre de archivo
- 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 flujo de transporte en un segmento deben ser un PAT y un PMT.
- Contenido
- El video y el audio deben estar unidos.
- 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 GOP cerrado.
- El códec de audio compatible es AAC, y solo se admite audio de una sola pista.
- Se recomienda que los segmentos multimedia tengan una duración de entre uno y cuatro segundos, como se explica en la siguiente sección. Los segmentos 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 medios
Esperamos que la transferencia de HLS se use para el contenido premium que requiera alta calidad y resolución. La transferencia de HLS suele tener una latencia más alta que las transferencias basadas en RTMP y WebRTC, ya que la transferencia de HLS se basa en segmentos.
Recomendamos una duración de segmento multimedia de uno a cuatro segundos, ya que tener segmentos 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 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 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 tasa de bits en el extremo inferior de los rangos sugeridos se pueden usar con HEVC para ahorrar ancho de banda, lo que es muy útil para el contenido 4K.
Otros requisitos
Los codificadores deben configurar el encabezado
User-Agenten 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 con solicitudes HTTP POST independientes. Esto funciona para todas las transferencias de HLS.
- Los subtítulos incorporados en formato 608/708 funcionan con transferencias HLS que usan el códec de video H264, pero no con las que usan el códec de video HEVC. Para obtener más detalles, consulta los Requisitos de Subtitulado instantáneo en el Centro de ayuda de YouTube.
Códigos de respuesta HTTP
En las siguientes secciones, se explican los códigos de respuesta que muestra YouTube en respuesta a los segmentos y las playlists 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 manejó correctamente.
En respuesta a una solicitud DELETE, una respuesta HTTP 200 (OK) indica que el servidor de YouTube recibió y ignoró la solicitud. El servidor de YouTube no requiere que el cliente borre ningún recurso de la transmisión y, además, ignora las solicitudes de eliminación. Por motivos de rendimiento, YouTube recomienda que los clientes no envíen solicitudes DELETE.
- 202 (Aceptado)
Una respuesta HTTP 202 (Aceptado) indica que el servidor de YouTube recibió el segmento multimedia antes de recibir una playlist multimedia que lo contiene. Esto le indica al cliente que debe enviar la playlist multimedia que contiene ese segmento 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 multimedia actualizada para cada segmento 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.
- La playlist no se puede analizar 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 HLS de YouTube está dañado o vencido. El cliente debe actualizar el parámetro
cidpara continuar.- 405 (método no permitido)
Una respuesta HTTP 405 (método no permitido) indica que la solicitud no era una solicitud 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. Para este error, te recomendamos que vuelvas a intentar la solicitud con la retirada exponencial.