Este documento 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 proveedores de codificador que quieran agregar compatibilidad con la transferencia HLS a sus productos. HLS es una buena opción para el contenido premium que requiere alta alta calidad y alta resolución a una latencia relativamente mayor. Para un resumen una comparación de los diferentes protocolos de transferencia que usa YouTube en vivo Compatibilidad con transmisiones, consulta Comparación del protocolo de transferencia de transmisiones en vivo de YouTube.
Para transmitir datos en vivo con HLS, el codificador debe enviar una serie de archivos multimedia
Playlists y segmentos de medios al extremo HLS de YouTube mediante HTTP PUT
Solicitudes 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 parte breve. que dura entre uno y cuatro segundos. Cada playlist multimedia se describe cómo volver a ensamblar los segmentos de medios de comunicación en el orden de transmisión correcto.
Requisitos de formato de medios
La transferencia HLS de YouTube tiene los siguientes requisitos para audio y video contenido:
- El video y el audio deben estar multiplexados en formato M2TS.
- Los códecs de video compatibles son H.264 y HEVC.
- Se admiten velocidades 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.
Consulte 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 la con 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 conocido como ARIB STD-B67).
- Los colores primarios deben ser Rec. 2020.
- Los coeficientes de la matriz deben ser Rec. 2020 con luminancia no constante.
- Muestras de rango limitado (o rango MPEG) y rango completo (o rango JPEG) valores admitidos. Es importante que el rango se establezca según el y el rango de valores de muestra que utiliza el contenido. Los valores de muestra de rango limitado son se recomienda.
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 Transmisión en directo de YouTube API para insertar una transmisión en vivo recurso con la siguiente 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 de
el 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 haga clic en “Crear de transmisión", YouTube muestra una “Clave de transmisión” compuesto por caracteres alfanuméricos caracteres y guiones. Esa clave secreta identifica al creador y al transmitir en 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 respecto de la URL principal: el nombre de host
y el parámetro copy= cambiaron. La transferencia de respaldo debe enviar
un valor del parámetro copy= diferente al de la transferencia principal que se debe evitar
dañar el flujo.
Completa la URL de transferencia de HLS
Las URLs obtenidas con cualquiera de los dos métodos son plantillas incompletas. termina cada uno
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 multimedia o de un segmento multimedia al final de la URL
así se completa el parámetro file=.
Las siguientes reglas se aplican al valor del parámetro file=:
- El codificador puede crear una playlist de contenido multimedia o un nombre de archivo de segmento multimedia a partir del caracteres alfanuméricos, guiones bajos, barras diagonales, guiones y puntos. no se admiten otros caracteres.
- El codificador no debe codificar el nombre de archivo en formato URL.
- El codificador puede incluir componentes de ruta de acceso relativos o absolutos en los nombres de archivo, aunque esto nunca es necesario. Si el codificador incluye un componente de ruta de acceso dentro de un nombre de archivo de Media Segment, debe hacer referencia a la misma ruta de acceso en el entrada correspondiente de la playlist.
Requisitos del protocolo HLS
Las playlists de contenido multimedia y los segmentos de medios enviados por el codificador deben cumplir con la segunda edición de la Especificación.
La especificación de HLS define dos tipos de playlists: playlist multimedia y principal. Playlist Como YouTube transcodifica el contenido transmitido en diferentes resoluciones y de bits, el codificador no necesita enviar contenido con tasas de bits diferentes a en YouTube. Por consiguiente, YouTube solo admite listas de reproducción de medios para la transferencia HLS y las playlists principales. (Una playlist principal ofrece un conjunto de variantes transmisiones, 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 desees publicar a los usuarios (resolución única y códec).
- mux de 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 segmentos de medios.
Playlists de contenido multimedia
Una playlist multimedia contiene una lista de segmentos multimedia que se pueden concatenar para representan una transmisión multimedia decodable y continua. La playlist de medios te dice qué segmentos de medios esperar al servidor y cómo ordenarlos correctamente en la en una transmisión reensamblada.
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.
0y el número de secuencia deben aumentar de forma monotónica.La etiqueta
EXT-X-MEDIA-SEQUENCEdebe identificar el número de secuencia del primer segmento multimedia de la playlist.Una playlist multimedia no debe contener más de cinco segmentos pendientes. R El segmento está pendiente si el servidor no lo recibió o no lo confirmó. de recibirla.
Además de los segmentos pendientes, incluye también algunos reconocimientos de cada playlist multimedia. Esta práctica hace que sea menos probable que un segmento que se omitirá si una playlist multimedia se pierde en el servidor. Para Por ejemplo, puede incluir hasta dos segmentos confirmados y hasta cinco segmentos pendientes en cada playlist multimedia.
Ten en cuenta que el servidor acusa recibo de un segmento de medios devolviendo Respuesta
200(OK) o202(Accepted) cuando se sube ese segmento. R La respuesta202indica que el servidor recibió el segmento antes de un la playlist que identifica el segmento.Envía una playlist de contenido multimedia actualizada para cada segmento de contenido multimedia para que las el servidor puede recuperarse rápidamente si se pierde una playlist.
A medida que el servidor confirma la recepción de segmentos de medios, puedes aumentar Valor de la etiqueta
EXT-X-MEDIA-SEQUENCEpara evitar que la playlist multimedia se convierta demasiado largo. Por ejemplo, si el servidor ya confirmó la recepción de primeros nueve segmentos multimedia, la siguiente playlist podría enumerar el 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 enviar:
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
...
El siguiente ejemplo muestra una playlist multimedia enviada en medio de un video en vivo
en tiempo real. Como el ejemplo es del medio de una transmisión, el
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 el nombre de archivo
.tsy debe coincidir con los nombres de archivo de la playlist. - Los nombres de los archivos de segmentos de medios deben ser únicos en todos los reinicios del codificador y o reiniciar la transmisión.
- Los nombres de los archivos de segmentos de medios en la URL deben tener el nombre de archivo
- Formato
- Los segmentos multimedia deben estar en formato M2TS y deben inicializarse automáticamente.
- Cada segmento de M2TS debe contener un solo programa MPEG-2.
- El segmento M2TS debe contener un PAT y un PMT, y los dos primeros Los paquetes de flujo de transporte de un segmento deben ser PAT y PMT.
- Contenido
- El video y el audio deben estar multiplexados.
- Los códecs de video compatibles son H.264 y HEVC.
- Se admite HDR con HEVC (consulta Requisitos de HDR).
- Se admiten velocidades de hasta 60 fps.
- Solo se admite GOP cerrado.
- El códec de audio compatible es AAC, y solo se permite el audio de una sola pista. no es compatible.
- 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 tienen una duración superior a 5 segundos.
- Los segmentos de medios solo se deben encriptar en la capa TLS/SSL con HTTPS. No se admiten otros mecanismos de encriptación.
Duración del segmento multimedia
Esperamos que la transferencia HLS se use para contenido premium que requiera alta calidad y alta resolución. La transferencia HLS suele tener una latencia más alta que RTMP. y basadas en WebRTC, ya que la transferencia HLS se basa en segmentos.
Recomendamos una duración del segmento de medios de uno a cuatro segundos porque tener Los segmentos de medios más pequeños pueden generar una menor latencia, aunque a un costo mayor de rebúfer y menor eficiencia de codificación. Como se mencionó en la sección anterior, Los segmentos multimedia no deben durar más de 5 segundos.
Velocidades de bits
El Centro de ayuda de YouTube Centro proporciona lineamientos para la configuración de la tasa de bits.
Ten en cuenta que el HEVC generalmente 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 del los rangos sugeridos se pueden usar con HEVC para ahorrar ancho de banda, lo cual es especialmente más útil para contenido en 4K.
Otros requisitos
Los codificadores deben establecer el encabezado
User-Agenten la solicitud HTTP mediante el siguiente sintaxis, que incluye el nombre del fabricante, el nombre del modelo y versión:User-Agent: <manufacturer> / <model> / <version>
Subtítulos
La transferencia HLS admite dos opciones para enviar subtítulos:
- Envía subtítulos mediante solicitudes HTTP POST independientes. Esto funciona para todos Transferencias de HLS.
- Los subtítulos integrados en formato 608 o 708 funcionan con transferencias HLS que usan el estándar H264 pero no con las transferencias que usen el códec de video HEVC. Para ver más consulta los requisitos del 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 segmentos de medios y listas de reproducción de medios entregados mediante 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ó con éxito.
En respuesta a una solicitud DELETE, una respuesta HTTP 200 (OK) indica que El servidor de YouTube recibió e ignoró la solicitud. El servidor de YouTube no requiere que el cliente BORRAR ningún recurso de la transmisión e ignora DELETE de solicitudes Por motivos de rendimiento, YouTube recomienda a los clientes no envíen DELETE.
- 202 (Aceptado)
La respuesta HTTP 202 (aceptado) indica que el servidor de YouTube recibió el Segmento de medios antes de recibir una playlist de contenido multimedia que lo contenga Esto indica al cliente que debe enviar la playlist multimedia que contenga ese segmento de medios lo antes posible para evitar una demora en el procesamiento que segmento. Ten en cuenta que esto no será un problema si el codificador envía una versión Playlist de contenido multimedia para cada segmento de contenido multimedia.
- 400 (solicitud incorrecta)
Una respuesta HTTP 400 (Solicitud incorrecta) indica uno de los siguientes problemas ocurrió:
- 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 La URL base del extremo HLS de YouTube está dañada o venció. El cliente Debes actualizar el parámetro
cidpara continuar.- 405 (Método no permitido)
Una respuesta HTTP 405 (Método no permitido) indica que la solicitud se no es una solicitud POST, PUT ni DELETE.
- 500 (Error interno del servidor)
Una respuesta HTTP 500 (Error interno del servidor) indica que el servidor se que no sea posible procesar la solicitud. Para este error, te recomendamos que vuelvas a intentar con el código exponencial, retirada.