Resumen
Brightcove Live proporciona un servicio sólido para crear eventos de transmisión en vivo o transmisiones en vivo las 24 horas, los 7 días de la semana. Esta guía describe las mejores prácticas para optimizar sus transmisiones en vivo
Contexto de contenido
El tipo de contenido que se transmite debe tenerse en cuenta, ya que tiene un impacto en la configuración requerida para mantener la calidad de la entrada. Tenga en cuenta que existen compensaciones y el uso de la configuración más alta posible puede causar problemas como marcos omitidos.
Con base en la información a continuación, le recomendamos que pruebe diferentes combinaciones de configuraciones para la calidad y el rendimiento antes de su evento en vivo.
Los parámetros de entrada clave se describen en la siguiente tabla:
Parámetro | Notas |
---|---|
Tasa de bits de entrada | La tasa de bits que envía el codificador. Las tasas más altas son más susceptibles a la pérdida de la red, por lo que deben mantenerse tan bajas como sea posible. |
Resolución de entrada | Debe coincidir con el contenido de origen. No hay ningún beneficio en hacer esto mayor que la fuente original y cuanto mayor sea este valor, mayor será la tasa de bits necesaria para admitirlo. |
Tasa de bits de entrada a la relación de perfil superior |
La tasa de bits de entrada debe ser más alta que la tasa del perfil superior, pero demasiado más alta puede provocar la pérdida de fotogramas u otros problemas; por ejemplo, si su tasa máxima es 1080p 30 fps, la entrada idealmente debe ser de alrededor de 4 MBPS. Tenga en cuenta que esto se ve afectado por el perfil.
Si necesita una salida superior de alta tasa de bits, vale la pena probar el |
Perfiles |
Los diferentes perfiles (línea de base, principal, alto) comprimen los datos en cantidades ascendentes (línea de base: más bajo, alto: más alto). Una mayor compresión mejora la velocidad de transmisión, pero también requiere mayores recursos de CPU para decodificar los datos. A menos que el codificador esté muy restringido en los recursos disponibles, se debe evitar el perfil de línea de base. Por otro lado, es más probable que el uso de un perfil alto a velocidades de bits altas provoque la omisión de tramas debido al aumento de los recursos de CPU de decodificación necesarios.
Ver también Estructura GOP debajo. |
Cuadros por segundo |
Esto debería coincidir con la fuente.
Las velocidades más altas requerirán velocidades de bits de entrada proporcionalmente más altas, por ejemplo, con contenido de deportes de acción, un flujo de entrada de 60 fps transporta sustancialmente más datos que un flujo de 30 fps. Es más probable que las velocidades altas, como 60 fps, tengan problemas de salto de fotogramas en contenido complejo a velocidades de bits altas. |
Tasa de fotogramas clave |
La configuración más eficiente para esto es la duración del segmento x la velocidad de fotogramas; por ejemplo, si tiene segmentos de 6 segundos y 30 fps, la velocidad de fotogramas clave 180 (6x30) resultaría en la carga de decodificador más baja.
Sin embargo, para tener en cuenta las fluctuaciones, esto se establece en 2 x la velocidad de fotogramas, por ejemplo, 60 para una velocidad de fotogramas de 30 fps. |
Estructura GOP | Ver Estructura GOP debajo. |
Problemas clave con la transmisión
Hay varios problemas que se encuentran generalmente relacionados con problemas con la experiencia de transmisión desde el codificador a Brightcove:
-
Inestabilidad de la red que afecta a la entrada:
- Si bien Internet es generalmente bastante confiable, no es infalible y ocurren problemas. Es más probable que los problemas se noten en velocidades de bits más altas.
- Si se tarda más en cargar el video que en tiempo real, esto puede resultar en un desvío de entrada (el tiempo en que se recibe el video es sustancialmente más tarde que cuando se envió)
- Sobrecarga del transcodificador que resulta en saltos de fotogramas: si bien hacemos todo lo posible para asegurarnos de que nuestros transcodificadores tengan suficiente sobrecarga, a veces los picos repentinos en la complejidad del contenido, los contratiempos / recuperaciones de la red u otras interrupciones en nuestros transcodificadores pueden provocar saltos de fotogramas. Cuanto más compleja sea la entrada, más probable será que se encuentren fotogramas omitidos. También existe un problema conocido en el que los cambios de una imagen fija durante un período prolongado, por ejemplo, más de 5 minutos y un cambio repentino en el contenido de la acción, pueden causar una sobrecarga.
- Codificador que envía duraciones de fotogramas variables: la velocidad de fotogramas debe ser constante y debe ser tal que permita un intervalo de fotogramas clave que sea constante. Por ejemplo, para una velocidad de fotogramas como 29,97, también conocida como 30000/1001 o 23,976, también conocida como 24000/1001, no es posible establecer un fotograma clave en un intervalo regular y, como tal, debe evitarse.
- El codificador envía fotogramas clave que no tienen una duración constante, la frecuencia de fotogramas clave debe ser un mínimo de 2 veces la frecuencia de fotogramas en segundos. Por ejemplo, para una velocidad de fotogramas de 30 fps, el intervalo de fotogramas clave debe ser de 60 fotogramas, que es de 2 segundos y debe ser un intervalo máximo de una vez por segmento; por ejemplo, si tiene un segmento de 6 segundos, el intervalo máximo sería de 180 fotogramas en 30 fps
Tipos de contenido
Generalmente, el contenido más complejo requerirá el uso de la más alta de estas configuraciones y, como tal, es más susceptible a los fotogramas saltados. La siguiente tabla muestra algunos ejemplos en orden de complejidad. Tenga en cuenta que estos son solo ejemplos y que casi todas las configuraciones de codificador son diferentes. Deben realizarse pruebas y verificación.
Tipo de contenido | Configuración de ejemplo |
---|---|
Cámara web |
|
Conferencia web |
|
Animación |
|
Talking Head / Noticias |
|
Concierto en vivo |
|
Deporte en directo |
|
Deporte en vivo alto FPS |
|
Verificación y prueba
Idealmente, los clientes deberían comenzar con la configuración más baja posible en su contenido más complejo (el contenido más cambiante) y probar con su contenido aumentando las distintas configuraciones hasta que el resultado sea aceptable. Esto se debe a que, por lo general, cuanto más alta sea la configuración, es más probable que se encuentren problemas en la red o en la transcodificación.
Estructura GOP
La estructura del grupo de imágenes (GOP) del video depende primero del perfil que se utiliza como:
- Base el perfil solo admite marcos I y P y codificación de entropía CAVLC
- Principal y Elevado Admite marcos I, B y P y codificación de entropía CABAC
Los perfiles principal y alto generalmente dan como resultado una mejor compresión con mejor calidad, pero también requieren cálculos adicionales para codificar y decodificar, por lo que pueden ser más susceptibles a los fotogramas saltados. Además, como estos perfiles utilizan tramas B (bidireccionales), inducen cierto retraso en el proceso de codificación.
El perfil de línea de base requiere menos CPU para codificar y decodificar, pero como ofrece menos compresión, requiere una tasa de bits más alta para mantener la calidad y, como tal, es más susceptible a problemas de red.
Notas sobre los tipos de tramas y su posible impacto en el rendimiento:
- Fotogramas I: utiliza la mayor cantidad de ancho de banda. Es mejor agregarlo para cambios completos de escena o en los límites del segmento, es decir, cuanto más cambia el contenido, más necesita (menor longitud de GOP)
- Fotogramas P: son la unidad base entre fotogramas I
- Fotogramas B: usa fotogramas anteriores y futuros, cuanto más añadas, mejor será la compresión, pero cuanto mayor sea la CPU y la latencia
El uso de Yo enmarca Idealmente, debería limitarse al inicio de los segmentos (crítico si se usa el paso a través) o cambios de escena. Deben evitarse todos los fotogramas I o un gran número de ellos, ya que esto puede provocar un exceso de carga que provoque la omisión de fotogramas.
Notas adicionales:
- Use opciones para evitar la colocación densa de fotogramas clave (ejemplo:
min_keyin
= 3+). - Utilice opciones que garanticen una cadencia regular de inserción de fotogramas clave. Por ejemplo, en lugar de especificar la longitud de GOP en segundos, especifíquela en fracciones o cuadros exactos.
Bitrate
- Ancho de banda de entrada mínimo: 2,5 mbps
- Ancho de banda de entrada máximo: 10 mbps
- Hacer la transmisión "casi CBR"" - con
max_bitrate
= 1.1 * tasa de bits objetivo. - Utilice el modo de control de frecuencia estricto compatible con HRD, si está disponible.
Protocolo
Es importante tener en cuenta que Internet no es una red de distribución garantizada y que, si bien una conexión a Internet puede considerarse "buena", puede que no sea lo suficientemente buena para una transmisión de video en vivo confiable con alta calidad. Una pequeña interrupción en la ruta entre el codificador del cliente y la plataforma de transcodificación de Brightcove, como una pequeña cantidad de congestión en un ISP, una conmutación por error no planificada entre enrutadores o problemas similares, puede causar una interrupción en la salida de video. En transmisiones en vivo de alto riesgo, es una práctica normal tener múltiples redes dedicadas que consisten en fibra dedicada, ancho de banda satelital reservado o ancho de banda comprometido en una red administrada. Esto tiene un costo sustancial y, en la mayoría de los casos, es posible lograr un resultado suficientemente bueno a través de Internet. Sin embargo, si es fundamental mantener un transporte sin fallas, considere AWS Direct Connect o un ISP que pueda proporcionar cierto nivel de ancho de banda dedicado.
Las opciones que recomendamos son (en orden):
- SRT - proporciona una buena combinación de velocidad de transporte (UDP) con cierto control y resistencia a errores. No está disponible en todos los codificadores, aunque existen herramientas que pueden traducir desde RTP local como srt-transmit.
- RTMP - al estar basado en TCP, proporciona un buen nivel de resistencia a errores, las desventajas son que esto conlleva una sobrecarga sustancial. Tenga en cuenta que no todas las funciones, como varias pistas de audio, están disponibles con RTMP.
- RTP-FEC - proporciona transporte rápido basado en UDP con cierta resistencia a errores
- RTP - proporciona transporte rápido y funciones avanzadas sin resistencia a errores
Codificadores compatibles
Ver Codificadores compatibles para eventos en vivo para obtener una lista de codificadores que se sabe que funcionan con Live. Tenga en cuenta que otros codificadores también pueden funcionar, pero no se han probado.
CDN compatibles
- Akamai
- Amazon CloudFront
Reintentos
Recomendamos habilitar reintentos para la conexión RTMP desde el codificador. Una gran cantidad de reintentos con un intervalo de reintento de 5 segundos mitigará cualquier problema de conectividad intermitente entre el codificador y el punto de entrada.
Configuración del trabajo
Configuración de trabajo recomendada
Campo | Valor recomendado |
---|---|
ad_audio_loudness_level |
-23 (Estándar EBU R.128) |
Requisitos de entrada
La siguiente tabla muestra los requisitos para la transmisión en vivo de entrada.
Artículo | Requisito |
---|---|
Protocolo | rtmp , rpt , rtp-fec , o srt (todo excepto rtmp son para entradas MPEG2-TS)[1-1] |
Formato de video | h.264 |
Formato de audio | CAA |
Frecuencia máxima de muestreo de audio | hasta 48000 Hz (Brightcove Support puede aumentar este valor a pedido) |
Resolución | Hasta 1080p (ancho: 1920 píxeles; alto: 1080 píxeles) |
Bitrate | Debe ser al menos tan alto como la tasa de bits de salida más alta; máximo: 10 MBPS.
En casi todos los casos, Brightcove Support ha descubierto que el uso de la tasa de bits constante para el flujo de entrada reduce en gran medida la posibilidad de problemas. |
Cuadros por segundo | 30 fps (puede enviar un Solicitud de soporte tener el límite elevado a 60 fps) |
Rebanadas | Si su codificador tiene esta opción, configúrela en 1 |
Notas
- [1-1] Si tiene varias pistas de video / audio en su entrada TS, elegiremos la primera para cada una. También recomendamos encarecidamente el uso de FEC, ya que TS simple sobre UDP a través de Internet es muy poco confiable. Para FEC, podríamos notar que el menor los valores que use para las filas / columnas, más confiable será la corrección de errores (a costa de un mayor ancho de banda.
Recomendaciones de archivos fuente de pizarra
- Resolución: (mejor en su escalera de codificación)
- FPS: (igual que su fuente)
- Bitrate: (mejor en tu escala de codificación o mejor)
- Audio: (la misma velocidad de bits, canales, frecuencia de muestreo y bits por muestra que su mejor interpretación, o igual que la entrada)
Recomendaciones de salida
A continuación se muestran las configuraciones de salida recomendadas, pero tenga en cuenta que para muchos codificadores, la entrada RTMP está limitada a 10 MBPS (video + audio) y una velocidad de cuadros de 30 fps.
Artículo | Recomendación |
---|---|
Códec de vídeo | h264 es actualmente la única opción |
Códec de audio | aac es actualmente la única opción |
Ancho | Si no width o height se suministra, se utilizan las dimensiones de la fuente. Si alguno width o height se suministra, la otra dimensión se calculará para mantener la relación de aspecto de la fuente. |
Altura | Si no width o height se suministra, se utilizan las dimensiones de la fuente. Si alguno width o height se suministra, la otra dimensión se calculará para mantener la relación de aspecto de la fuente. |
Bitrate | Menor o igual a la tasa de bits de entrada |
Tasa de fotogramas clave | 2 segundos |
Preguntas más frecuentes
- ¿Qué tan pronto debe comenzar a transmitir después de crear un trabajo en vivo?
- En Brightcove Live, hay dos condiciones cuando el estado cambia de
waiting
afinishing
:- si el trabajo está en el esperando estado (aún no iniciado) y el
max_waiting_time_ms
ha transcurrido, el trabajo está terminado / desactivado. - Si el trabajo está en el desconectado estado (iniciado, pero desconectado) y el
reconnect_time
ha transcurrido, el trabajo está terminado / desactivado.
Si el
event_length
es superior a 30 minutos, el trabajo finalizará en 30 minutos. Si elevent_length
es menos de 30 minutos, el trabajo terminará enevent_length
.Por ejemplo, si el
event_length
es de 60 minutos, entonces, el trabajo en vivo terminará en 30 minutos. Si elevent_length
es de 15 minutos, luego, el trabajo en vivo terminará en 15 minutosLa
reconnect_time
no tiene ningún efecto para el estado de espera. - si el trabajo está en el esperando estado (aún no iniciado) y el
- ¿Cuáles son las limitaciones de las configuraciones de trabajo simultáneas en vivo?
-
Un máximo de 5 activos esperando, sin comenzar Se permiten trabajos en cualquier momento.
Limitaciones adicionales en trabajos concurrentes:
- El número de
channel
(24x7) trabajos está limitado a 0 o un número bajo por región (dependiendo del tipo de cuenta). - El número de concurrentemente corriendo
event
Los puestos de trabajo están limitados por región, generalmente a 100. - El número de concurrentemente esperando para conectarse
event
Los trabajos se limitan a 5. - El número de puestos de trabajo SEP por región está limitado a 3 o 10 (consulte Regiones de AWS admitidas).
El equipo de soporte puede ajustar cualquiera de estos límites a nivel de cuenta. Comuníquese con su Gerente de Éxito del Cliente si necesita capacidad adicional.
- El número de
- ¿Brightcove Live puede impulsar la calidad de 1080p siempre que el ancho de banda de entrada sea suficiente?
- Sí, la entrada de 1080p está habilitada para todas las cuentas.
- ¿DRM está disponible?
- ¡Sí! Comuníquese con su Gerente de Éxito del Cliente si está interesado en agregar soporte DRM a su cuenta real.